Join the heated discussion about this article on Hacker News 🔥
Junior Engineers care about writing Software. They value code quality, employ best practices, try to adopt cutting-edge technologies. They invest a lot of time into learning new technologies. To them, the ultimate goal is to create elegant, performant, maintainable software.
Senior Engineers care about building Systems. To them, creating software is just one of the steps. First of all, they question whether the software needs to be built in the first place. They ask what problems would it solve and why it’s important to solve them. They inquire who will be using the software and on what scale. They think about where the software would run and how they’re going to monitor whether it’s working properly. They also decide how to measure whether the software is actually solving the problems it was supposed to solve.
Building Systems is much harder than building Software. It may be even uncomfortable. As an engineer, it’s very tempting to stay in your cave and focus on polishing this beautiful piece of code. It’s tempting to think that determining requirements is the job of a Product Manager and deploying the software should be taken care of by the Operations team. However, you can bring a lot of value by being involved in these aspects of building a system. You’re the person who knows your software best and it’s you who know best how to run it, how to monitor it, how easy it is to extend it, etc. What’s more, your analytical mind and problem-solving skills make your insights about product requirements very valuable.
Technical expertise is of course very important. Elegant, performant, maintainable software is easier to run, breaks less often, is easier to extend and to reason about. However, it may solve a wrong business problem. Or maybe the customers don’t like it because of performance issues that you don’t even know about because you aren’t monitoring it.
Let’s have a deeper look at a (non-exhaustive) list of activities that are part of building a System:
- Defining Requirements - work with the Product Manager to understand what problem they want to solve; maybe you’ll have some ideas on how to solve it with much lower effort?
- Defining NFR’s - talk to your PM about the non-functional requirements - how many users should the System handle, what are the requirements for performance, throughput, latency? Are there any security or compliance considerations? Do we need auditing? What’s the desired availability?
- Planning Iterations - work with your team to propose an implementation plan; make sure you define small, demoable milestones, so that you can start delivering value ASAP; agree with the PM on the milestones.
- Determining Dependencies - make sure you identified all the dependencies outside of your team and work with your EM or with the teams directly to get some ETA’s for them. Adjust your milestones accordingly.
- Testing - depending on how your company operates, decide on your testing strategy with your team or with the QE team. Agree on the quality threshold needed for the rollout (e.g. no unresolved Major bugs or test coverage above X%).
- Deployment - work with your team to decide how the system will be deployed. Do you need some new infrastructure for it or can you reuse the existing? If you need a lot of it, what will be the cost?
- Observability - decide how are you going to monitor the health of the system and set up processes for solving production issues (e.g. team on-call). Use a third-party solution (like Sumo Logic) to set up monitors and dashboards for that purpose.
- Rollout Communication - once you agree on a rollout date with your team and the PM, make sure that all stakeholders are aware of it. Check whether any documentation changes are required.
- Measuring Success - decide on metrics that will tell you whether the project was a success. Is anyone using the new system? Do users manage to accomplish their tasks? You can leverage your Observability suite for this purpose.
I’ve met many engineers who were convinced that the only way to advance their career is by investing in their technical skills. While this is important, the only thing that matters to your company is how much impact on the business are you making. Shifting the focus from Software to Systems puts you in a much better position for increasing it.
