10 enemies of being a good programmer
Posted by Vishwas Sutar
on 1/3/2013 for Intermediate level | Points: 250
| Views : 14680
If you found plagiarised (copied)
or inappropriate content,
please let us know
the original source along with your correct email id (to communicate) for further action.
Rating: 5 out of 5
This article discusses the habits which would need to be avoided if a person wants to become a good programmer.
Introduction and background
The information technology is not a new term now. For a
common person, this is the field which guarantees good money and life (in the
context of INDIA). People working in this industry are looked up-to and
generally considered intelligent than others.
After working for quite some time in this industry, looks
like the above points are coming very close to being a myth.
Definitely this industry has been life changer for many and
also big employer, foreign currency grabber but by large it would be
interesting to know what’s the reality at ground level.
Many would comment that the quote about intelligence is
overrated and this is just another industry with revenues in dollars helping
for mammoth turnovers.
The common minimum ingredient of this industry is a
programmer (or a developer or coder) who is the one writing the programs which
are supposed to make things happen. As in every field of life, there are good
programmer and bad programmers. The other hot topic in this industry is whether
this industry possesses chunk of good programmer or not. Many wouldn't agree.
So, what makes a good programmer? This is debatable point
and to make things simpler, let’s see this the other way round i.e. discuss the
top 10 enemies which can prevent oneself from becoming a good programmer.
To know about the DONT's if anyone wants to become
a good programmer.
Programming world is a confusing world. There have been so
many languages, technologies, platforms, infrastructures to choose from which doesn't
make life of a programmer easy even though they are supposed to. In the scenario
where business needs are outscoring the engineering practices, the programming has
become a real complex thing increasingly challenged by time and budget. There has
been lot of research into software metric to measure the performance and
quality but it still not straightforward to categorize programmers and probably
say who is good or bad. Following are list of points which if we can ensure
while programming, would definitely result in better code quality, better
planning and better professional life. These points are picked up from real
incidences which always keep happening with considerable frequency and it is
observed that such incidences leads to poor quality, performance and higher
costs. These points are not just related to technical skill but rather the
attitude, awareness, behavior
- Is it
computer or my program: When something goes wrong there is a tendency
to term that it must be something wrong with computers or something else other
than me? It’s funny but it omnipresent statement one hears. Barring few cases,
it’s always the program doing something wrong rather than computer. If we take environmental,
infrastructural attributes into account while programming we won't end of
saying this. This is the biggest enemy.
- Its working on my PC: This is probably
mostly used age old statement and many have encountered it umpteen times. It is
hard to believe but it happens all the time that the programs work well on developer’s
machine but fail after deployment... Do we program for our own pc or our
programs are intended to run only on the developer’s machine? Surely not and this
is caused by insufficient programming skills and not enough knowledge of
working environments, necessary settings etc.
In most of such cases, mostly the
programmer has forgotten to update the deployed environment with some settings/
configurations, some component missing etc. rather than anything else.
- Finger pointing: I have just
changed it but I didn’t cause this error, it must be somebody else who might
have worked on the same stuff. This is a statement one would hear all the time
and it’s generally the first reaction one would hear when asked about some
error or fault. In reality, something is changed and the original functionality
is also lost then these statements are made. This is quite intriguing that
something is changed and before a change things were working and still the
programmers say this. This depicts the lack of ownership as well as
understanding and escapist attitude. Given the complexity and difficulty to
find the facts, many are encourage saying this.
There is a small remedy to overcome this and which is the practice
of performing unit testing and take my word, life would be easy.
- Skipping the validation of user input:
While programming for user interactive applications / programs, one tends to
skip the validation of user inputs under the assumption that he has coded for
it and it shall work. The minimum check which is like confirming the data
entered in GUI doesn't exceed the data type and lengths defined in the
database. No wonder, many of the defects and also the program crashes arises
out of lack of such validation.
It is better to always ensure that the data types and lengths
on GUI matches with the ones defined in data source and also it handles the
common pitfalls which can spell doom for hackers.
- Not estimating (or planning) the work or
tasks: Most of the programmer (especially junior ones) has urge to
jump into coding without estimating the work. Estimation is just not important
from planning perspective but it gives an opportunity to revisit the scope as
the estimates are bound to scope.
There might couple of tasks challenged by time and/or budget
which can be performed well without estimates but not all. Whatever may the
work or tasks if it is estimated, then it eases out planning, controlling and
monitoring and also give an avenue to ask for the help before it is too late?
- Swallowing the exceptions: Exception
handling is still a mystery for many programmers and when he/ she don’t know how to handle the exception or there is lack of good exception handling
mechanism, the exceptions are swallowed means not action is taken after the occurrence
of such exceptions or errors.
Today's programming languages offers far more sophisticated
mechanism in the form of try-catch-finally. Such swallowing habits mostly results into
application crashes putting programmers into awkward position.
- Blindly copying and pasting: In
today’s internet era, everything is available on internet and code snippets are
not exceptions to this. With super-efficient searches, it is possible to locate
code snippet which can do one's job.
Probably it can't be called wrong to copy
such code snippets and use but unfortunately the usage is always coincided by
blindly copying or retrofitting which results into partial solutions not taking
into account the existing scenario. Also one has to remember that such code
snippets needs more rigorous testing than your native code to make sure that it is doing what is needed. Another example is copying from code samples or others
code which generally skips the understanding curve resulting into inferior
quality software and it is also difficult to change such program and maintain
too. So copying and pasting is unavoidable but it would be better to invest
some time to understand what it is doing and what is expected to be done and
perform this action with sound judgment.
- Not being latest (with proven results): The technology paradigm
is characterized by the continuous changes and improvements. While working hard
and long, many programmers are not able to sync them up with such changes and
improvements. This may result in inferior solutions or far more time investment
than could be justified. Also there are many changes happening on software
engineering front where new methodologies like Agile, XP are introduced which
can address many pertinent challenges in development life cycle.
- Lack of Documentation/ comments/standardization:
No denying the fact the programs are written to be executed by computers but
they are also written which could be understood by others. Many programmers shy
away from writing enough comments or documentation which can help others about
why, how and when something is done. Essentially this helps other programmers not
attempting to understand and write something which would add to confusion.
There are many instances of coding horrors, coding mess, coding chaos which
have one thing in common and i.e. lack of documentation and standardization.
Essentially the programs shall be human readable and comprehensible.
- Speed better than accuracy:
This is a trap for even the proven programmers. Many programmers think that the
programming is 100 meter races and one has to be lightning fast to win this race
and in the process the quality, accuracy is sacrificed. This catapults into
more work (many would want this for continuity of their business) which is not
good if one looks at cost and time consumed. Accuracy could attain more priority and
speed with accuracy could be the motto.
Summary and Conclusion
This topic is exhaustive and complex to discussed and addressed on one write-up. Still these 10 point are put forth to touch base the perennial challenges in software industry. There may be more apt points and detailed discussions but hope that this write-up could help to bring some really interesting practices to the fore.
Found interesting? Add this to: