What makes a software engineer productive? You can list attributes like experience with the language, scientific mindset, intelligence, focus, a personally crafted IDE setup. Yet, in my experience, far and away the biggest factor is: familiarity with the codebase they’re changing.
That knowledge of what the system does and needs to do, it’s completely essential and entirely contextual. The easiest way to get is to create it — that is, to write that software from scratch. And then it feels completely natural. It doesn’t feel like knowledge, it feels like breathing. It feels obvious.
When you have a decent mental model of a system, sharing that with others is hard. You don’t know how much you know. If you’re the purple developer in this picture:
then you have a mental model of this system because you built it. The green and blue developers have been assigned to help, but they can’t change the system because they don’t understand it. Meanwhile, you may be changing the system fast enough that it’s impossible for them to get a grasp on it, no matter how smart they are. (I’ve been in their situation.) The solution is to work together on the system, and invest attention in transferring your mental model. Until then, Blue and Green get in your way.
This slide is part of my Collective Problem Solving keynote (also seen as Origins of Opera). People came up to me afterward: “We have a purple developer. Now I don’t feel so bad about being blue or green” or “Oh no, I’m the purple developer!”
Which developer in this picture is ten times more productive than the others? Purple developer!
Is it because they are inherently smarter? Nah. Circumstances lead to this situation.
There is not any “productive” software engineer so much as “productive in this codebase.” Spread the knowledge, spread the productivity.