Breaking That Solution Down
Every lead developer works with many different parts of a software project and might not know all of them in detail. However, they do have a developer who is the main person to turn to for a particular area of the project. That area could be called a “system.” How well a developer understands their “system” depends on what the lead developer expects from them. Clearly communicating these expectations is like creating another system, and it’s very important for the success of your project and team.
To advance in your software development career, it is important to take ownership of and develop expertise in systems.
Maybe a “system” is:
- An epic or feature in the solution,
- A routine or method for something critical to the success of the project,
- An integration pathway with another tool or dataset,
- A business process needing knowledge, planning, effort, and maintenance,
- An open-source library that you want to bring into the solution to help solve a problem,
- The system of managing, analyzing, and solving customer requests,
- A microservice.
I was thinking about systems recently because one of my solutions is using DexieJS as a wrapper for a small IndexDb database in the browser. We starting using it 4 years ago, but it was pretty much forgotten until we needed to make some adjustments. This is a prime example of “system” that I was not fully aware of. I failed to meet my own expectations.
Okay, so what are the expectations needed to master systems?
Catalog: The lead developer is responsible for maintaining an up-to-date inventory of the systems integrated into their solutions. This list encompasses more than just features and is managed beyond a simple Kanban board. It is a dynamic, continuously evolving compilation, where each item is eventually assigned to a developer.
Documentation: Every system should be properly documented. As a lead developer, you should have a clear plan for where this documentation will be stored. For example, I recommend setting up a Starlight site directly within your monorepo.
Review: Regular review sessions (yeah, another meeting…) are essential to determine which systems are still relevant and to identify any documentation that may need sprucing up.
Walking the Walk: Ultimately, the primary responsibility of a lead developer is to set a personal standard. By consistently meeting your own expectations regarding system management and documentation, you set a strong example for less experienced team members.
Let’s Review
While this is but one facet of software engineering awesomeness, getting “systems” right is a great way to show a lead developer that you’re ready to take on more. It demonstrates that you’re not just writing code, you’re thinking bigger, taking responsibility, and contributing to the long-term health of a project. Developers who take ownership of systems become the people others rely on. And in any team, those are the ones who get trusted with more: more influence, more impact, and more opportunity to grow.