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.
Objective
To know about the DONT's if anyone wants to become a good programmer.
Description
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 urged 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 ease out planning, controlling and monitoring and also given an avenue for asking 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. This swallowing 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 with sound judgment.
8. Not being latest: The technology paradigm is characterized by the continuous changes and improvements. While working hard and long, many programmers are not able to synch 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 makes other programmer 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.
10. Speed well than accuracy:This is a trap for even the proven programmers. Many programmers think that the programming is 100 ctr 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 of one looks at cost and time. Accuracy could attain more priority and speed with accuracy could be the motto.
