10 enemies of being a good programmer

Posted by in Others category on for Intermediate level | Points: 250 | Views : 27987 red flag
Rating: 5 out of 5  
 8 vote(s)

This article discusses the habits which would need to be avoided if a person wants to become a good programmer.
Read How to start your software career? before this article.

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

  1. 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.

  2. 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.

  3. 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.

  4. 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. 

  5. 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?

  6. 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.

  7. 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.

  8. 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.

  9. 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.

  10. 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.

Read How to become a successful software professional after this article.
Page copy protected against web site content infringement by Copyscape

About the Author

Full Name: Vishwas Sutar
Member Level: HonoraryPlatinum
Member Status: Member,MVP
Member Since: 5/30/2011 2:13:10 AM
Country: India

Extensive and rich experience across gamut of technologies and programming languages like PB,VB,C++,VB.NET, C#, Classic ASP,ASP.NET, ASP.NET MVC.

Login to vote for this post.

Comments or Responses

Posted by: Sheonarayan on: 1/3/2013 | Points: 25
Very valid points.

Awesome article, it shows the experience !

Keep it up!

Posted by: Mmvaishnav on: 1/4/2013 | Points: 25
It's Awesome.

It would help many to become a good developer.

Thank You.
Posted by: Blessyjees on: 1/4/2013 | Points: 25

Very good article.
Thanks for sharing.
Posted by: Saratvaddilli on: 1/5/2013 | Points: 25
very good article
will keep in mind all these points
Posted by: Rwatson on: 1/7/2013 | 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 on: 1/8/2013 | 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 on: 1/10/2013 | Points: 25
Rwatson ,
Great inputs.
"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 on: 1/10/2013 | Points: 25
Absolutely good topic...
and a rare thought... Keep it up :)
Posted by: Lakhwinder.Ghuman on: 3/12/2013 | Points: 25
Good article.
Posted by: Dkdinesh172 on: 2/6/2016 | Points: 25
Nicely addressed sir.

Login to post response

Comment using Facebook(Author doesn't get notification)