5 Bad Habits of Absolutely Ineffective Programmers.
And do you have these bad habits?
Some programmers are better than others. In fact, there’s a statistical distribution: a few are absolutely brilliant, some are good, most are at least competent, some are barely competent and a few are truly dire.
That said, the difference between a good programmer and a bad one is not necessarily coding skills. In fact, it is something even more basic; bad habits. And bad habits are hard to break both in life and at work.
That said, we developers can often fail into bad habits while slammed with coding that eventually stops us from reaching our full potential. While some habits can help us speed up our work, others (like stuffing my face with peppermint as I type…) can do harm to both our business and personal life.
And often we are unaware of our bad habits and all we need is somebody to shed light on them. Like life, programming has no hard and fast rules. Sometimes you wing it to win it.
Let’s talk about some bad programming habits you should get rid of as soon as possible.
My Code Is The BEST.
Friedrich Nietzsche nailed it when he said.
“Whenever I climb I am followed by a dog called ‘Ego’.”
The kind of people that all teams need are people who are humble, hungry, and smart: humble being a little ego, focusing more on their teammates than on themselves. Hungry, meaning they have a strong work ethic, are determined to get things done, and contribute any way they can. Smart, meaning not intellectually smart but inner personally smart.
Don’t criticize other’s code, it could be yours the one in the spotlight. Try to make objective and professional observations instead, but don’t judge. Be humble and try to learn from everyone around you.
Always remember, your ego is an obstacle to your work. If you start believing in your greatness, it is the death of your creativity. Your learning stops the day you start believing that there is nothing more to learn.
I Can Fix This In A Jiffy
Angela Duckworth once said.
“There are no shortcuts to true excellence.”
Do yourself a favor. Give yourself permission to get the most out of your life. If you’re spending all your time scrubbing corners with a toothbrush, you’re kind of missing the point. Taking shortcuts doesn’t mean shortcutting the end result.
Taking shortcuts is very tempting, everyone has done it. There are actually situations where they are necessary, but overall, they are dangerous, very dangerous, and should be avoided. A shortcut that goes wrong may save you a few hours but may cause months of pain and added loss of reputation.
Take my advice seriously. I learned the hard way that taking shortcuts and living for free is not really living free.
I Remember Everything. I Don’t Need To Document.
Dick Brandon hit it bang on the nail when he observed.
“Documentation is like sex; when it’s good, it’s very, very good, and when it’s bad, it’s better than nothing.”
Documentation is the castor oil of programming. Managers think it is good for programmers and programmers love to hate it!
But that said, great developers, make it an intrinsic part of their daily routine. They realize that, as with any business function, software development teams are always in flux. Programmers might change jobs, move from one department to another, or retire. In the worst-case scenario, illness, injury, or death can sideline team members when you least expect it.
Code ages, too. Developers can easily forget how their own code works if they haven’t touched it for a year or more.
In any of these scenarios, having access to design documents, API specifications, manual pages, and code comments can mean the difference between a shipping product and a blown deadline.
And this attitude is what makes them a valuable asset to the team. You don’t become “irreplaceable” by intentionally not documenting anything. All you end up is becoming an “irreparable” liability to your team.
It Wasn’t Me!
Bruce Lee has rightly said.
“Mistakes are always forgivable, if one has the courage to admit them”
Perhaps this above statement cannot be understated and is one of the most important characteristics of a really great developer.
We always have an excuse….. It’s like if we were saying that under normal conditions we would never make a mistake, which honestly is quite hard to believe. Bad developers blame customers for not using the product “correctly.” A bad developer fails to take ownership and responsibility for the entire product and bugs. They make sure everyone knows exactly who was responsible when a bug was created by someone else.
And what exactly is achieved by pinning the blame? Nothing at all. Having a healthy attitude where we can you just say something like: “yeah, sorry, now we need to do this to fix this issue, my fault” will help you to build a reputation and to be better considered by your colleagues.
The earlier you admit to your mistakes, the more time you would have to learn and rectify the same. Simple as that!!!
Your “DONE” Is Not Done.
Rick Lemons rightly observed when he said.
“Don’t make the user provide information that the system already knows.”
If programming was sex, there would be a lot of unsatisfied computers. You can just not go in, do things halfway through, and then fall asleep. One of the concepts that I find you struggling with is the concept of “Done”.
Remember that done means: tested and approved by the user as per his requirements. It is not done from your end to be deemed done.A good developer is eager to learn new things. They strive to understand how all the pieces of the architecture work together and what state they are in. They question the design and ideas behind features to solve for a solution. They understand what makes a good user experience.
A bad developer, on the other hand, is attached to their favorite technology. They think a single method or process is the “ideal,” and that user experience and situation should never drive decisions. They bring unnecessary dependencies into the project to suit their preferences.
A bad developer behavior like this is like a bull in a China shop. Only the destruction of time, efforts, and reputation prevail in the end.
Last Thoughts.
So what is the single word that sums up everything here?
The short answer is Attitude.
Having a great attitude beats having any number of years’ experience any day. Just work is not enough, you must have the right attitude at work and instead of having the right skill, the right attitude is far more important.
Having a good, positive attitude, along with positive thinking, at work will reflect on what you do and make you a more productive employee. This can determine how well you get your projects done and also how others perceive you. A good attitude is infectious. It charges the workplace.
As Zig Ziglar has rightly summed up.
“Your attitude, not your aptitude, will determine your altitude.”
Ravi Shankar Rajan is an information technology program director working in Mumbai, India. He writes on a variety of subjects ranging from programming, leadership, creativity, and even dabbles a bit in poetry. He is also a Haiku poetry writer, archaeology enthusiast, and history maniac. Connect with Ravi on LinkedIn and Twitter. Subscribe to his blog “The Perfect Programmer” for the latest articles on programming, creativity, and much more…...