As I slowly approach to the end of my second year of work at GE, I can sense how much I have changed as a programmer since I left CMU. In this article I want to put down my “lessons learnt” on paper. Chances are that in a few years I won’t even remember what it felt like to go to college. So before I forget I want to pass on the experience that no text book could ever teach me. Rather than a write a wordy reflective essay, I will just list some of the common pitfalls that you should avoid as a newly hired programmer.
Resist the urge to rewrite code
This is probably the hardest one. So it deserves some special attention. You will come across a lot of crappy code in your work life. There’s seldom any documentation. So your only option will be to read through code. And the more you read, the more you will feel the code has no structure, things are not done in a proper way, there’s a lot of repetition etc.. Well guess what? It might be crappy code, but it’s well tested crappy code. A lot of the obscure code-blocks are undocumented patches to bugs people found after months of testing. If you are new to the company, you will have absolutely no clue about all the bizarre edge cases of a program. Chances are when you rewrite a piece of code, you will produce a clean but buggy application. If you are unsure whether to rewrite or not, ask yourself these questions:
- Will cleaning up the code reduce development time in the future?
- Will it make testing easier?
- Will it make deployment less time consuming?
- Does #1, #2, #3 take more time the time it will take you to rewrite the code?
If the answer to all four of these questions are “yes”, try to see if your coworkers think the same too.
Not being satisfied by anything other than your work
This is also a hard one. If you are a hard-working and productive programmer, you will get a lot of responsibility on your shoulder. There’s nothing wrong with that. But don’t go overboard. Typically there will be others in your company who can also code. You may not think that they are as skillful as you. But practically speaking, given enough time they can also get the job done. So don’t lose your sleep trying to be a one man army. Be a team player. Learn to delegate. Document your code, so that others can fill in when you go on a well deserved vacation.
Get over the need for speed
Yes, changing that data structure to a tree will make lookups O(logn). But it will only reduce runtime from 10 minutes to 9.5. It’s usually very hard to give a find out the big O complexity of real life programs. So don’t jump at the first chance you get to apply your algorithm skills. Profile your code thoroughly. Get an understanding of what the real bottlenecks are and whether they are under your control. And even then, you should only optimize if your users are complaining about it.
Reluctance to test your code
Admit it. We all hate testing. We hated in college. We got mad at professors who graded your test cases. And we still hate it at work. The only difference is, now the code may affect the lives of hundreds or even thousands of people. So get over it. If you feel testing is a waste of time. Write test scripts. Write modular code. Write unit tests as you code. Get your co-workers to test your code. The more testing you pile up till the end, the more repulsive it will get. And then procrastination will take over and you will end up shipping buggy code.
Those were the main pitfalls I could think of. Maybe someday I will write a part 2 for this post with all the small tips and tricks I picked up over the years. Anyhow, if you manage to start your career avoiding these pitfalls, you should have a bright future ahead.