As software engineers, our job is to create useful services for other humans or other services that depend on our services.
In the idealized world, we write software, deploy, and move on.
In the real world, we have to think about
- Writing software
- Debugging our own software for bugs
- Testing it locally for the change, but also for any dependencies
- Writing test code to validate our change (this sometimes is bigger than then change we made)
- Submitting it for review and address the feedback from other engineers, much like writers and editors
- Deploying it to a test and staging environment to show others
- Deploying it to a canary environment to a small set of customers to exercise it, watching metrics to ensure our software worked as expected. Working with the System Reliability Engineers, make sure the impact to customers is as expected.
- Writing monitoring for our software change
- Being on call to support our change and changes made to other engineers on our team and beyond our team.
- Deploying our changes to the production environment where live customers can interact with it.
- Collecting feedback and creating and managing a backlog for future changes.
- As the systems grow larger, the original code that we wrote may be considered a legacy of technical debt as the environment changes. There could be security, scale, coverage concerns that need to be addressed.
This is the world of a software engineer beyond just writing code. As an engineer writes more code, they have more ‘legacy’ to support. For an engineer to be effective, what they create needs to be continually groomed and tend to. How they enable others to help is an important factor to help them scale. How they enable their future self to look at code they had written 1-2 years ago can be done through rigorous automated testing and up to date document and knowledge sharing.