Programmers who want to do it for a living are always in for a shock when they get their first programming job. There are the added pressures of deadlines, office communication, customer demands, and the like. These are well understood. However, there is a pain point that is rarely addressed, and can remain painful for a programmer late into his or her career. It’s difficult to make the transition between coding by yourself and coding as part of a team. In school or on independent projects, you knew the whole codebase because you wrote it – or co-wrote it with one or two other people. You knew where every module was and what every function did, and in case you forgot, all the coding standards were your own, so you found it all easy to read. And, since the whole project was written by one person, it was comparatively small. It was easy to make sweeping, system-wide changes. When you first move into a larger team, suddenly the codebase is an enormous thing, written by others and not understood. And it’s your job to improve it. It takes some getting used to.
This should go without saying, but learn to love source control, and become an expert at using it. A large but hopefully shrinking percent of schools do not teach you about source control at all. It’s indispensable. In particular, get used to a tight integration cycle, and become very good at reverting and un-reverting your changes.
Don’t panic! Learn to accept the fact that you won’t understand everything. Trite, right? You might be surprised how hard it is to pull off, though. In a sufficiently large codebase, every bad practice will be represented somewhere. Programmers are perfectionists, so this makes us want to tear our hair out. You just have to come to terms with the fact that you can’t fix everything at once. If you want, keep a to-do list. Wiping one thing off of it may not be a tremendous win for the company, but it’s great for your sanity!
This is not to say that improving the code isn’t important. It just means that you may have to accept that parts of the code aren’t pretty and instead focus on more important things, like global performance improvements. Learn to see the big picture, and focus on doing things that can help the whole codebase at once rather than one module at a time.
You won’t understand the whole codebase. Neither will anybody else. However, every piece of the code was written by someone, so for any area of the code, there will be someone who knows it. You’ll often need their help, so you’ll need to know who they are. Learn who the domain experts are in each area of your codebase. Apprentice yourself to them. Spreading knowledge through the company makes everyone stronger.
Apprenticing yourself might not sound very attractive to the Obsessive Programmer. Fortunately there’s something you can do that lets you be the guru. Become the domain expert on some area of your codebase. Your obsessive nature will make this come easily to you. Find a poorly understood section of the code, or a module written by someone no longer employed at the company. Or, find some body of knowledge so in-demand that the current domain expert has become a bottleneck – making it useful to become a second expert in that area. Being a domain expert has the side benefit of making you hard to lay off.
Once you have become a domain expert, share your knowledge, ideally through paired programming. You’re a stakeholder in the company, and you want everyone to learn. Spread your expertise around until it’s commonplace, then find a new area of expertise.
Last, I can’t overstate the importance of learning to write good tests. People are going to use your code. People are going to change your code. People are going to break your code. Tests are your last, best line of defense. How to write good tests is a big topic, so I won’t go into it here. You can get some very good information over at the google testing blog.
Working a real job may be more stressful than coding on your own, but you should see that as an opportunity to get better. Shut up and man up. It’s worth it.