Continuing part I of this series, here are some more things to add to bad habits or common fallacies and traps of programmers that are holding them from performing well.
1. Carry over the dead code/experiments/comments with you.
Go to any system/project’s codebase that is more than a year old and you will get to know what this means. You see the comment that says “Sales Invoice in next five lines” and more than 20 lines of code that is commented out and another 10 lines code that are currently working as you debug…and nobody can explain what that old commented code does but they don’t dare to clean that up.
2. I can’t fix another programmer’s code, rather I will rewrite it.
Ah! This is a classic and I admit that I had been also got hold of it in my early carrier. One programmer never says good things about another programmer’s code. I think this is in our gene and sometimes even if I think of this ,I think programmers in somewhere deep down their minds wanted a perfect world and each one has their own version J of it. Anyway, what all I can suggest is they can read martin fowler’s classic ‘refactoring’ book and this notion will go away.
3. The world can be written only with “if-else” and “for” loops and method reuse.
Junior junkie who can code for days and night and fresh from colleges or worse spent one or two years in some company can write entire systems in if-else and for loops and some procedure reuse. I think some or the other way this has a root cause of “failing to unlearn what we had learned first”. Most of these guys had learned C language as their first programming language and may found they were good at it or they presume that they are good at it. Biggest mistake our schools and some local book authors has did is they are teaching procedural and object oriented programming language the same way.
These authors had not thought over the object oriented principles, rather their focus is teaching upon the tooling of object orientation like inheritance and polymorphism and unfortunately this is the case in India which has got some credibility in IT.
4. Testing is inferior to programming. It is not what true programmer’s do. Testing is THEIR (Test Engineer’s) JOB.
I spent my early years of career in small start-ups where we don’t have luxury of appointing a separate test engineer. Whatever we write, we have to make sure that we are doing it correctly and the result of it is though I have got respect for the test engineers since I realized that say after testing for basic flows and validation errors it is very difficult to think of something different that can break the system. In regard of this thought I had learned some testing basics from various websites and still those are very handy even as a programmer.
Nowadays, While working with midsized firm and continually reading about TDD all I am realizing is, programmers had a misconception that they can write a code that had errors and they can just give it to test engineer to clear even basic things like spelling mistakes.
It is shameful that people do not want to test their own code and worst of all rely on some other individual for correcting their own mistakes.
The notion of TDD is good but their also our cleaver programmer (as well as some lousy test engineers) friends tell us the list of excuses like schedule, how can I write the test when there is no development etc.
5. Code review means somebody should check their code line by line for all aspects and point out the mistakes that they had made.
Yes, it is insane but I had seen some managers and some programmers have such ridiculous expectations from code reviews. First thing is programmer should be responsible for the code he/she is writing and not the other fellow who is helping it out to make that code better.
Code reviews should be conducted on sample basis and with the help of some tools likes of static code analysis etc. Checking the mere code conventions should not be the only intent of review. It would be more beneficial that code reviewer should do some firsthand refactoring and in that process programmer would learn things and two about the code as well as this leads to better design.
6. Creating a build means compiling the code.
For the people who have not been in the agile/product development have this misconception that compiling the code is the thing that makes the build process.
These people are missing so many steps that makes build process. I even really doubt that these people consider build as a process.
Many times project requires code signing ,obfuscation of code, replacing connection strings from test environment to production environment ,building for various platforms likes of Windows,*nix or 32 bit,64 bit as well as routine tasks as zipping the release, pushing the release over ftp, emailing about the release to stakeholders etc.
The people ignorant about the build process should really search for the continuous integration and trivial toolset of it which includes brilliant TFS, cruise control, Hudson, rake, NAnt etc.
These fallacies and traps are costing our customers millions and we should recognize it. In my opinion the root cause of these is the way SME’s hiring the resources, further on lack of training and setting the culture to sub standards.
The more I go deeper, I think the waterfall thinking model is still lurking people to write bad code and managers had their fear to adopt the bottom up management approach and what we need is agile mindset and learning organization.
“Learning is not child’s play; we cannot learn without pain.”
– Aristotle
| Share this post : |  |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
A Techie Thought 