An average developer is someone, who can write code, once explained what to do and how to do it.
A good developer is someone, who can implement something, once told what to do (he can figure out the how part)
An awesome developer given business goals can also figure out what to do.
But a great developer is someone who can just figure out what’s wrong with someone else’s code quickly. I consider the ‘Art of debugging’ as the Zenith of one’s development prowess because a great debugger can mean meeting product deadlines without compromising on quality.
Here are some of my tips if you want to be a great developer.
1. Identify the problem
A lot of times the real problem is wrapped under multiple layers of wrong design and hence wrong implementation. This means that the natural instinct of any developer is to fix the symptoms ( login not working) rather than attacking the real issue. (wrong database architecture?). It takes a lot of courage to admit a bug with the design at a late stage cause everyone wants quick results. But as we find out time and again, it saves a lot of time if you attack the real problem rather than keep on fixing symptoms.
2. Look at different ways to solve- don’t be afraid to rewrite
Once you identify the problem, always go for the “right” way to fix it rather than a seemingly “quick” fix. Quick fixes have a habit of generating plenty of side effects. This sometimes means rewriting the code and your customer/ manager may be pushing you really hard to show quick results. Be patient and fix it the correct way, it will avoid a lot of heartburn and disappointments compared to the quick and dirty solutions! But this is much easier said than done.
3. Estimate collateral damage
This is an art. In the absence of documented and updated design (which is the case with 80-90% of the world’s software), it needs deep knowledge of how the software works to estimate what all you may “break” by changing something else in the system. You can develop this knack over years of experience. But this is the ‘real’ thing.
4. Write test cases
This comes before you actually go on and implement. It’s always important to know how you can be “sure” your fix solves the problem and does not cause side effects. I have always found it very useful to write a short test document/ white box tests before implementing so I know the “target”. It’s also easy to track progress with this approach.
5. Document and then implement
If you are a good developer it will come easy to you. But in general, document what changes you want to make before you actually start coding. Never find out things incrementally. If while implementing you come across an unforeseen issue, go back to step 1 rather than continuing to incrementally change the nature of the fix.
6. Test well
Again all you need to do is to be careful while testing so your “fix” stays when deployed in the system
Bonus: And if you are really that special someone, you will share the root cause, your analysis, your fix and test procedure for someone who will look at it after you. This will make life really easy for someone else working on the system.
