You’re 10x as productive when you’re working on code you wrote as on code you didn’t write.This is certainly something that I think I need to take to heart more frequently. The bigger a tech team gets, the more sluggish it can feel. It's easy to look around and think, "why isn't everyone else getting as much done as I used to?!" The answer, of course, is that I wrote it; of course I can work with it more quickly than other people. Writing a site from scratch is a lot easier than having to dive into it mid-stream and add a piece to the insides. And all those shortcuts I was able to make early on are now coming back to slow down the people I've handed things off to.
What can we learn from all this? I'd love to say, "Always code with future programmers in mind," but the reality of startups is that that will very rarely happen. Instead, we can identify projects that require a thorough understanding of the codebase (which isn't always easy to do, or isn't obvious when the project begins) and ensure the original author pairs with the new developer to explain how things work.
There's nothing like explaining why your three-year-old hack is making someone's present day miserable to improve your code quality.
The problem of 'code hand-offs' is pretty complicated. This is made worse by the fact that this industry changes very rapidly. Often code that was state of the art 5 years ago is something the next group of incoming programmers would prefer not to deal with at all. I guess it's partly self interest. As a programmer myself I know what I like to see on my resume. I'd prefer a list of completed but modern looking projects.
ReplyDeleteHow do we write code for 'twenty years?' I'm not sure. Right now what I assume is anything I do has a 3 or 4 year shelf life and therefore I try to make sure the effort involved in writing the code is reflected in its lifespan.
On a side note, I find working on open source projects and in spending time studying other people's code makes me more proficient working on unfamilar codebases.