This article was cross-posted from Medium.
Over my entire career thus far, I’ve noticed a single action completely transform a developer’s effectiveness as an engineer and technical leader: read all of your system’s code.
It’s a “simple” action (though it takes time, energy, focus, and skill at extracting meaning from code), but (surprisingly) not many people on your team will do it. Developers who haven’t read the system’s code will always rely on those that have.
Understanding how the entire system works, from an architectural standpoint, is a step in the right direction — but one step above what I’m suggesting. The details are beneath the architecture. The nitty-gritty order of logical operations will make the semantics of the components/sub-systems clearer, avoids the back and forth of “but I thought it did this/that,” and provides a level of insight that makes you more effective when discussing how sub-systems interact or need to interact for a new feature.
When you do decide to read all of your system’s code, you’ll likely notice a few things happen afterward when there’s a new feature to build:
- You’ll be better equipped to identify which parts of the system need to change to accommodate the new feature. In turn, you’ll have a more informed hunch of the complexity of the new request. You’ll even be better equipped to provide meaningful insights on how those parts should change.
- Since you understand the entire system, you’re also primed to help form a more thorough and comprehensive set of edge cases.
- Your product manager(s) will rely more heavily on your informed hunch about the complexity of the feature to determine if there’s a less complex, but impactful feature that could make more sense at this time (given time and resource constraints). Ideally, the product manager would reach out to the sub-systems’ owners for that hunch; however, that increase in communication complexity only works for small teams (around a handful of engineers). There are real consequences to watch our for in this communication optimization though: make sure teammates don’t feel neglected, make sure you’re not overwhelmed with the question load, and avoid being placed on a pedestal in your team’s eyes.
- Your teammates that own the affected subsystems will seek out and value your opinion. If they’re asking you for solutions, that’s a sign that you’re either micromanaging (a real danger when you know things at that level of detail) or that you’re in the “telling” phase of situational leadership (typically for inexperienced, new hires; less experienced, “junior” teammates; or teammates with a lack of domain knowledge or self-confidence).
Outside of the context of a new feature, you’ll possibly notice a few other things happen:
- You’ll transition into a tech lead, which is a whole new can of worms.
- You’ll get pinged to review more and more pull requests (PRs). If you’re giving effective code reviews, it’ll require lots of time.
- You’ll get invited to more strategy planning meetings.
- You’ll get invited to more architecture review sessions.
- You might have a vision for how the entire system needs to evolve to meet long-term business needs.
- External stakeholders will ask you questions about the system.
- Your product manager will ask you more and more questions about feature complexity as the product evolves.
- You’ll struggle to find time to code.
- Teammates will just walk over to you (even if you have headphones on…) to get your thoughts on their idea.
- Your paycheck will increase and folks will try to promote you.
- People may start to call you “senior.”
- Teammates may start to view you as their leader.
- Your teammates will be impressed with your ability to think of so many edge cases — though they’re one action away (read the code) from being able to do the same.
- Every new feature will feel like a game of chess (so many moving parts, so many disaster scenarios to plan for, so many possible paths forward).
- You won’t be able to keep up with the evolution of the system. You’ll realize that the knowledge you worked so hard for is only a snapshot of the system in time. Your information is now outdated with every shipped PR and you’ll have to fight every day to keep the knowledge current.
Ok, so maybe don’t read the code… Life is easier that way 🙂