To me the definition of a better programmer is one who writes code that produces the desired result with less errors.
Some people might define a good programmer as one that has a vast understanding of programming languages and concepts, while this is true this definition can only take you so far – ultimately ALL programs are written to perform a function and as error free as possible.
If the average programmer had an infinite amount of time for testing and deployment then almost ALL code would be released error free, but obviously all projects were due yesterday and usually we’re developing under less than perfect conditions, and at times pushing ourselves to the max to achieve the desired outcome. Besides this the industry is generally not that concerned with deep or stress testing applications and at times your rushed out code is just expected to work.
Here are some things you can do that will improve your overall effectiveness as a programmer (these are not language specific techniques and can be applied to just about ANY programmer, including YOU)
- Get a second opinion: In the old days it was taught that a developer should read a considerable amount, and search the internet as much as possible prior to asking colleagues. I’ve even read surveys from those times where developers actually felt embarrassed to ask questions to fellow developers in the fear that they might come off looking inexperienced. I would say shed that fear, and the good news is you also don’t need to pester those you work with, enter the era of www.stackoverflow.com, if you don’t have an account create one immediately, its almost mandatory for a modern age developer to be using and contributing to Stackoverflow. Stackoverflow WILL make you a better developer, and by using it, You directly contribute to the collective knowledge of all things programming related.
- Don’t trust your own code: Be highly suspicious of your own code. Every error in your application is almost always a direct result of your own code. View all code with suspicion, never think about any function as simple. Don’t think to yourself – “I’ll write a quick function to send an email” or “I’ll just quickly append this line of text to the end of that file” or “I’ll very quickly insert into this or that table”. You have to start thinking. Stop coding for a minute, and think things through. Every time you write a function, think “What could go wrong”, then convert this to – “What WILL go wrong”. That little append method you wrote might expect a file to actually exist, or that file could be locked. That database might be offline, that email server might be undergoing maintenance. Assume nothing, except that every function you write is inducing more possibilities for error, and its your job not only to write the function, but to eliminate as much of this error drag that WILL be caused, to the best of your ability each and every time. Start thinking of functions as in code / error drag ratios. Don’t write a function unless you are certain you can almost eliminate ANY error drag induced. It should really surprise you, after you’ve done this and your application ends up with a logical error in production.
- Think and relax: This might not always be possible, but where ever possible exercise your right to be relaxed on the job. I’m not suggesting you take hours off to play network games. What I am saying is, each time you are about to write a function or a piece of code, enter into the development of this function with a clear mind. If you need time to think things over, do exactly that. Don’t cave in to pressure from management to “look busy programming”. It’s acceptable to be sitting at your desk just thinking things though, if it helps you visualize, get some writing equipment, not on the PC and make notes, and draw diagrams, or open up notepad and run through some real use cases. If you take 50 minutes in the hour to think things through, and 10 minutes to implement your idea, even though it might not be finished, its still overall WAY more effective than thinking for 2-3 minutes, and then implementing something in 20 minutes, job done – go home, and then get a support call the next day -1 repution for You, Your Company, Your Product. When you code, you should be coding at the speed of a dinosaur, but your mind should be thinking at the speed of light. The text you are typing is coming out slow, but its quality, because you’re focused on the bigger picture, what your code is going, how it will affect the users, how that one line will prevent support calls, how that function you’ve added will mean your code deploys without you having to be there, the list continues. As a developer you should have a lot of considerations in your mind when you code.
- Modernize: If you started coding 10 years ago, then its likely your language/s of choice have seen a vast number of improvements or language enhancements. Stuff you used to write a function for years ago, is now an inbuilt language feature. Before you might have needed 10 lines of code to accomplish something that now only takes 1 line of code. Its your right as a developer to receive skill enhancement benefits while on the job, but so few companies actually offer any tangible skill improvement programs. If you were a Soccer player, most of your time on the job would involve training. As a developer you’re expected to know your job upfront, with very little emphasis on upgrading your existing skills. I’ll cut it short, You are the only one who can make your skill improvement happen, and you need to do this gradually and build it into your every day life. Don’t just write a function doing it the old way, take the time out (yes even if that means at times digressing for an hour or 2) to up skill. Use Stackoverflow or Google and find what is best current practice for the way you do things. Tell your employer that you are actively developing your skills, or that you are researching an improved way to implement if they are curious. Don’t push management to provide you with training, in my experience nothing good has ever come of it.
- Always push for more testing: This might not directly improve your coding skills, but it does go a long way in terms of PR. If functionality you’ve been working on hasn’t undergone ANY testing, then you need to explicitly emphasize this. Don’t release something and say that its ready, complete or done, if it hasn’t been tested. When I say tested, I mean thrashed by someone other than you, who can try and extract as much errors or usability issues as possible. I’ve written this article to be as practical as possible, because of this, I will assume you don’t have a team of 5 testers just waiting to take over your code for testing, and you don’t have ANY real testing in place in your organization. You need to mention this EVERY SINGLE TIME you release something, because its something non technical members of your team very quickly forget. Hand over functionality always under the clause that it needs to be tested. If no testing is possible, then you’ve covered your base when errors do come back (and they will). The point is always make the point known that you are indeed a man short (the tester), this goes a long way in protecting your reputation as a developer, because the sad reality is not enough testing ever takes place, and if you don’t make others aware of this, you’ll end up just looking like a 2nd grade developer when issues happen.
And finally – above all else take errors very seriously and fix them ASAP, its ok to have some error drag (bugs) in your application. No one I’ve ever met has ever got to the point where they can release a perfect program that’s 100% error free, but what is more important is how quickly and effectively you deal with these errors when they occur, this includes your turn around time, and your initial ability to trap, log and notify these errors.