Top 10 myths programmers believe in
ITJC DMT
1052 Times
717 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.
Comments:(0)
Leave a Reply
