Larry Wall, the original author of the Perl programming language, once said that great developers have three virtues: laziness, impatience, and hubris.
Laziness because it drives them to write labor-saving programs and document them well so they won’t have to answer questions about them. Impatience because it motivates them to write programs that anticipate your needs. And hubris because it makes them want to write tight code that other people won’t criticize.
That said, successful developers are not necessarily the greatest of developers.
A developer who gets the everyday jobs done well is much more effective than the one who occasionally reaches dizzying coding heights. And for most employers, it’s the area under the curve that counts, not the highest point it reaches.
And the success you seek comes from how you see yourself, the world, and the habits you have to deal with life’s challenges. In fact, according to researchers at Duke University, as much as 40% of our success(or failure)happens automatically as a result of our habits.
And here are some powerful habits which can supercharge your success as a developer.
Steve Maraboli was bang on target when he said.
“The right thing to do and the hard thing to do are usually the same. And both Requires Professionalism.”
Professionalism is like the sword of Damocles. On one Hand, it is a badge of honor and pride, but on the other, it is also a marker of responsibility and accountability. The two always go hand in hand. You can’t take pride and honor in something that you can’t be held accountable for.
Imagine you have written some code and deployed into production. A serious issue happened because of your code and the production system was disrupted for one day. Needless to say, the customer incurred quite a bit of financial loss. You revert the code but whatever damage happened could not be undone.
The nonprofessional would shrug his shoulders, say “stuff happens,” and start writing the next module. The professional would sweat and fret over the slippage and will make sure that such shoddy stuff is not repeated again.
Always remember Professionalism is all about accountability. You cannot be right all the time. But you need to own up the wrong done by you.
Do not Repeat the Same Error
Amit Kalantri hit the nail on the head when he said.
“If an apology is followed by an excuse or a reason, it means they are going to commit the same mistake again they just apologized for.”
Clearly, we want our software to work. Indeed, most of us are programmers today because we got something to work once and we want that feeling of euphoria again. But we aren’t the only ones who want the software to work. Our customers and employers want it to work too. Indeed, they are paying us to create software that works just the way they want it to.
So far so good. But Software isn’t perfect. Every software will have bugs.
The key here is not aspiring to write perfect code. That is a utopian fantasy and will never happen. The message here is taking complete accountability of all the imperfections in your software. Create new bugs. Make new mistakes. But do not repeat the same mistake over and over again.
As you mature in your profession, your error rate should rapidly decrease towards zero. It won’t ever get to zero, but it is your responsibility to get as close as possible to it.
Don’t Leave Anything to Luck. It Never Works.
Jim Jenkins rightly said.
“The bitterness of poor quality remains long after the sweetness of meeting the schedule has been forgotten.”
The rule-of-thumb is that if something is deemed to go wrong, it will go wrong and no amount of luck can prevent it from happening.
That is why testing is so important. How can you know your code works? That’s easy. Test it. Test it again. Test it up. Test it down. Test it all seven days to Sunday!
Even if deadlines are stiff and the pressure is immense on you to cut corners, do not do so. Automate test cases, get into pair programming mode or even look at reusing existing test cases. But do not do anything that will curtail the sanctity of this step.
Your whole reputation depends on how well you have tested the code before deploying in production. Every single piece of code written by you should be tested. Period.
What if the code is “untestable”? The code is written in such a way that makes it difficult to test.
The short answer is making the code easy to test. And the best way to do that is to write your tests first before you write the code that passes them.
Always remember the purpose of your code is to get it executed to solve a business problem. If that objective fails, no amount of LOCs and code beautification is of any use.
You as a programmer ought to know if your code works. Nothing else is more important than this fundamental fact.
Always Create Flexible Code
Siri Hustvedt has rightly said.
“Creativity has always depended on openness and flexibility, so let us hope for more of both in the future.”
The true professional knows that delivering function at the expense of structure is a fool’s errand. It is the structure of your code that allows it to be flexible. If you compromise the structure, you compromise the future.
The fundamental assumption underlying all software projects is that software is easy to change. If you find that this is not possible then something somewhere is seriously wrong.
Too many projects get trapped into the quagmire of inflexible code. Developers come and go and they add further to the morass of inflexible code and finally we end up creating a monster that can neither be rewritten nor can be maintained easily.
The key here is identifying those portions of the code that make it inflexible. Once we find those portions, we invest time and effort and rewrite those portions instead of adding further to the mess already created. This effort will go dead against deadlines. But so be it. Get the buy-in and do the right thing.
Always follow the principle of “Merciless Refactoring”. Leave the code cleaner when you leave it and if that means doing something “extra” from what you have been told to do, do it.
And Lastly, Be a Learner Always.
Anthony J. D’Angelo was bang on target when he said.
Develop a passion for learning. If you do, you will never cease to grow.
“I want to do S4 HANA course. But the employer is not sponsoring”
“I wanted to learn Webdynpro forms. I am not able to find time from my busy schedule”
“I want to attend that Codeathon. But It is coming on Weekend.”
All these are excuses for not to learn. Your career is your responsibility. It is not your employer’s responsibility to make sure you are marketable. It is not your employer’s responsibility to train you, or to send you to conferences, or to buy you books. These things are your responsibility.
As a rule-of-thumb follow the 40–20-hour rule every week. The 40 hours of time belongs to the employer. The remaining 20 hours belongs to you, for your own learning. Make your week at a minimum of 60 hours per week to imbibe a continuous learning culture within you.
And 20 hours per week is not difficult. If you use your time wisely; travel time, lunch time, weekends, etc., you find a lot more time available at your disposal to be utilized only for yourself.
Always remember the software field is constantly changing and it is very easy to turn into an obsolete dinosaur. So if you want to stay ahead of the times and remain valuable, invest in yourself and keep learning.
As Seema Openers has righty said.
“Self-education is open to all but it is taken only by those who refuse to live a small and purposeless life.”