I think there is no better feeling for someone than to successfully run a thousand coded-program and even more to launch a desired product. I guess, this is what drives me to code for some of the High-Tech Companies around the world.
On contrary to the best feeling of launching a desired product which is a long term affair, the career of being a coder is short term goal. Coding would bring a good start to my career but it only gets limited to 12 to 15 years. After this, one tends to become more matured in their work and analytical in their approach. Many of these programmers, therefore, end up becoming the principle architect or managers or analyst. Therefore they call it a ‘Young Person’s Game’. This is very much like sports. A typical sportsperson usually peaks between 28 to 30 years of age. After which, they soon retire within the next 5 years and most of them then take up analytical or strategy oriented jobs such as coaching or score prediction analyst. A similar trend may be found in the lifecycle of a typical coder.
With programming I always loved math and statistics. But why did I opt for programming in the end? Well, some of this is because of my co-op experiences that I have had in my past. There have been instances when I have come up with great piece of code to solve certain problems. However, after I document my codes, my efforts, hard-work and smart thinking gets appreciation only by the senior developers or my supervisors. The clients on the other hand do not approve my code as it does not solve their problem. This kills most of the hard work I perform as a coder. Further more, I may have to work on a complete new piece of code all over again. I do not blame the client here because most of the time they are naive and do not end up comprehending the rapid changes in technology. Therefore, I believe communication becomes another important attribute in the skill set of a programmer.
I think that the ability to communicate effectively is one of the most important aspect at my work place. I think I can consider myself to be lucky to have an insight of being both the developer and the client in my past co-op terms. As a result, it has improved my aspect for communication when I work as a developer for my clients. I have therefore come across various stories about miscommunication from the programmer’s end rather than the client. It is so usual that nobody even questions this one-sided treatment. And almost nobody asks developers what leads to miscommunication because usually it is just too late to ask or no one cares of his or her opinion. So, it’s interesting to take a different track and clarify some typical miscommunication issues which occur in the programming practice from the point of view of developers. It is very important to talk the client’s language and understand it. Another source of miscommunication is incomplete information. There can be cases when the client doesn’t trust the team and talks round corners or gives information in portions. This hampers productivity. In my opinion miscommunication emerges because of lack of discussion of the problem. So to avoid miscommunication everything should be discussed between the team , the developer and the client..
The developer always wants to see their code working properly. So they will test it to check if it’s working correctly. But on the other hand, the client will test the application to make it fail in any possible way, and they will surely test how application is not working correctly. This is the main difference in developer testing and client testing.
As a developer, I therefore need to keep these aspect in mind before I write my code. A good written documentation of all the tests performed should be good enough to communicate with the client about the product. It is then the client’s responsibility to make sure each and every aspect is tested or not. Clients should ideally give importance to all small possible details to verify application is not breaking anywhere. After all it’s them who are the final victims of my code.