Article posted by Vishvvas
on 1/3/2013 | Views: 13169 | Category: Others
| Level: Intermediate | Points: 250
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.
If you like this article, subscribe to our RSS Feed. You can also subscribe via email to our Interview Questions, Codes and Forums section.
Found interesting? Add this to:
|Please Sign In to vote for this post.
Latest Articles from Vishvvas
|Member since:||Monday, May 30, 2011|
|Status:|| [Member] |
|Biography:||Over 16 years of experience, worked across different technologies and programming languages like PB,VB, ASP. C++, C#, VB.NET|
Posted by: Sheonarayan
| Posted on: 03 Jan 2013 08:40:35 PM | Points: 25
Very valid points.
Awesome article, it shows the experience !
Keep it up!
Posted by: Mmvaishnav
| Posted on: 04 Jan 2013 12:10:36 AM | Points: 25
It would help many to become a good developer.
Posted by: Blessyjees
| Posted on: 04 Jan 2013 02:11:18 AM | Points: 25
Very good article.
Thanks for sharing.
Posted by: Saratvaddilli
| Posted on: 05 Jan 2013 03:58:03 AM | Points: 25
very good article
will keep in mind all these points
Posted by: Rwatson
| Posted on: 07 Jan 2013 10:46:27 AM | Points: 25
I had a smile as I read this very simplistic analysis of being a "good programmer". It is obviously meant to land on the bosses desk to impress management.
Let me cover a few points.
"Not estimating (or planning) the work or tasks: "
How come 90% of projects come in at 3 times the cost, 4 times the elapsed time with .75% of the planned functionality, with 60% of projects abandoned halfway into their cycle ? (yes, read the stats if you dont believe me) The answer I give at every interview, is because "it is impossible to accurately calculate the time to produce software", using any methodology you care to name. Management and staff are upset because they dont realise that accurate planning is a myth. I am not saying don't do your best to plan, but make sure everyone understands what you are up against.
"Skipping the validation of user input"
Hey - this is such a simplistic summary. Not only do you need to validate at field level, you also have to run weeks of user ergonomic and productivity analysis. A successful project needs to have experienced and new users to pre-release test and beta-test, to prove efficient input design that doesnt drive staff mad. Field level validation is kindergarten level. I recommend that the programmer(s) actually spend a day doing the work of the data input operators or desk staff before the first release.
"Is it computer or my program"
Its always the computer! Your program IS the computer. Try sitting next to a Java developer, and watch the facial expressions as he wrestles with the complex syntax, searches Google for the undocumented 'gotchas', watch how he takes numerous coffee breaks to calm down instead of smashing the screen. We are talking about wrestling millions of man years of complex code, automatic updates, hardware driver conflicts - I bet no two programmers even have the same video card in their machines at your work. This is WAR, and its always the computer !
"Not being latest"
besides being grammatically confusing, this is the WORST bit of advice. You do NOT want to be the latest ! Ever heard of the "Bleeding edge" ? Its a joke on being "leading edge", where you spend so much of your time trying to keep up with every half baked, unproven coding standard and/or technique that you cant sleep at night. You should stick to the trusted, proven paths, and deviate with extreme caution. Sure, do keep up with new concepts, and listen to good ideas, but be very, very cautious about 'keeping latest'
"Speed well than accuracy"
Also grammatically confusing. The term accuracy means what ? Numerical accuracy ? Spelling accuracy ? Computers are already totally accurate - they don't make mistakes, so how does a programmer become accurate ? You may mean producing reliable software, or efficient software, or easy to use software, or a million other things - but this concept makes little sense as discussed.
I must stop now - but there is so much more to success in software production than is presented here.
Posted by: Edandy
| Posted on: 08 Jan 2013 02:05:51 AM | Points: 25
Great points here Vishvvas!
I recently just hired a developer from https://www.staff.com
and though he has been really doing a great job for me for the past few weeks, I believe reviewing all these points should help us have a good working relationship. That way I could understand him better and will set a good foundation for a long term work.
Posted by: Vishvvas
| Posted on: 10 Jan 2013 12:56:16 AM | Points: 25
"Not estimating (or planning) the work or tasks:" Your note about accuracy is fact and hence probably it is far more important to plan/estimate whether they prove right or wrong. FAILING TO PLAN IS PLANNING TO FAIL. Yes, it is important for stakeholders to understand what these estimates stand for.
"Skipping the validation of user input": You have explained this better. Somehow there is tendency to assume that UNIT test, pre-release test and beta-test is out of the programmer's purview and definitely this has proved fatal.
"Is it computer or my program" : Appreciate your view point. Here I wanted to emphasize that just knowing about programming language won't be sufficient to do a good job but know-how about the environments, platforms, hardware's, browsers, incompatibilities, performance criteria etc is also important.
"Not being latest" : - Very well said. Here what I would do is to add "proven" world before "latest". Yes,it is true that many projects haven't seen the light of the day because the latest were chosen with optimistic view and without proper evaluation. There are latest practices, hardware's, platforms, optimizations and improvements in programming languages which can be embraced after proper evaluation and hence could prove far handy.
Speed well than accuracy" : This could be better be said "Speed better than accuracy". Accuracy is coined in the context of fulfilling the requirements. So essentially trying to do faster sacrificing the accuracy is no less than inviting troubles, rework, quality issue.
Hope this helps.
Thanks for comments and its heartening to know that the point are useful practically.
Posted by: Baimey
| Posted on: 10 Jan 2013 05:14:42 AM | Points: 25
Absolutely good topic...
and a rare thought... Keep it up :)
By default Outlook does not validate for empty subject line. This article provides a mechanism to achieve the same.
This article is about configuring Windows live mail with gmail account.
Have you Wondered how few Experts we have in this world? It does not matter if you are in IT or Marketing etc. Let me tell you why we dont have Experts.
I am happy to inform that I, the founder of this website www.dotnetfunda.com have received the "Star Entrepreneur Award" on 28-Jan-2011.
In this article we will look into invocation of Mule's file-inbound endpoint from Command Line Interface (CLI) using Linux CRUL commandMore ...