You need to STOP these BAD developer habits NOW

Every good work of software starts by scratching a developer’s personal itch

“You suck Ravi. You are getting difficult every day.” Said Jim, my manager years back_._

I was surprised. Shocked would be the more apt word here to describe my emotions.

“Well Jim, not sure why you think like this,” I said in a voice, barely masking my sarcasm.

“I am a great developer and a very valuable asset to my team. The customer is literally eating out of my hands and in knowledge, I am far ahead of my contemporaries.”

I was getting angrier every minute.

“This very “THINKING” is your problem Ravi and unless you do something about it fast, you will never reach the pinnacle of GREATNESS.” Jim told, looking straight into my eyes.

I was dumbfounded, angry and confused, all at the same time seeing the audacity of his statement

I resisted the urge to STORM OUT of the room while allowing him to give his reasons-:

“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 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 in overall, they are dangerous, very dangerous and should be avoided. A shortcut which 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 hate it!

But all said and done, 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.

What is the need to raise all this hullabaloo and waste everybody’s time in the process?

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 destruction of time, efforts and reputation prevail in the end.

Successful projects are those which are accepted blindfolded by the end users and become part of their very working DNA.

Bringing it all together

So what is the single word that sums up everything here?

The answer is Attitude.

Having a great attitude beats having any number of years’ experience any day.

Just work is not enough, you must have right attitude at work and instead of having a right skill, right attitude is far more important. If you take up something you love doing as a profession, it’s generally said that you will love doing it and work will never be monotonous. Being an employee it’s very important that you spread the right message in the workplace.

As Zig Ziglar has rightly summed up.

“Your attitude, not your aptitude, will determine your altitude.”

About the author-:

Ravi Rajan is a global IT program manager based out of Mumbai, India. He is also an avid blogger, Haiku poetry writer, archaeology enthusiast and history maniac. Connect with Ravi on LinkedIn, Medium and Twitter.