Top 10 myths programmers believe in
ITJC DMT 1047 Times 712 People

The lack of skilled IT workers is hurting the deployment of emerging technology, according to a new survey from Gartner. In areas from cloud to cybersecurity, this crisis is expected to last for years to come.

We programmers are sometimes prone to certain self-delusions. We believe in a host of

false ideas about our coding style. And with that, we complicate our job and land

unexpected results.

Here, is a list of falsehood many of us believe in. Keeping a check on them is necessary

to implement coding best practices and improve our performance at work.

My code doesn’t need commenting:

We all hate commenting code. We come up with the most ridiculous reasons to avoid

commenting code.

Wasn’t it just yesterday you heard yourself saying, “I know what I have written. I don’t

need to comment it!”

And when commenting is downright necessary, we delay it. However, not commenting

the code is considered a bad programming practice.

Not following code documentation best practices will prove to be a costly mistake when

some major changes have to be incorporated into the code.

This shouldn’t take long:

We underestimate the time necessary to get something done. This is despite past

experiences where a minutest fix to a simple code turned into a big project and

consumed a good deal of hours and efforts.

If it is easy, it should not take more than two hours, right?

A good programmer spends time to analyze the issue and explores potential solutions

to the problem before committing on timelines.

My way is a better way:

With the advent of open source, different kinds of code, tools and applications are

readily available out there for us, for free. But, we do not like to use others stuff. We

write our own code.

After all our way of doing things is better! But, with this approach, we may end up

producing bad code examples than anything.

This can wait:

With impending deadlines, we more often than not compromise on coding standards

best practices to finish the task quickly. Of course, we do it only after promising

ourselves to fix the imperfect code and write better code as soon as possible.

The truth however is, we don’t fix the code even in the next release.

It is just a small change:

We know that even the minutest tweak in the code can have wide implications on the

final product. So, when changing a parameter, be it to fix a bug or to add functionality,

we often end up breaking a lot of things. A small change in one line is rarely a minor

change like it appears to be.

When we follow good software development practices, fiascos can be avoided at least

to some extent.

It is not a bug:

We programmers do not like to admit that there is a bug in our code. We claim that with

us the code is functioning as expected and others are doing something wrong for it to

throw unexpected results. We even program ourselves to believe that this argument is

true. Worse, some of use even declare that the bug is actually a feature!

The sooner we acknowledge a bug the sooner we can fix it and control damages.

I am in control of my project:

At times, we disregard design and architecture of the software project, and leap right

into coding. Such over confidence in our technical prowess will only make us commit

serious mistakes.

In the worst case, these mistakes can mean writing the code right from the scratch

again. So, refer project design and architecture before it is too late.

I don’t need that test:

We hate tests just like we hate commenting the code. We cite every rational and

irrational excuse to avoid or at least postpone testing. We argue that the code is

working well with certain input and tests are redundant.

Testing is an important aspect of good software development practices.

The language I use is the best:

We all have our favorite language. The problem arises when our love and loyalty to it

blinds us to its potential faults, drawbacks or limitations. Every language comes with its

advantages and disadvantages.

Ignoring this fact will limit our ability to develop better products.


Leave a Reply