Right now, I am in a new role where the tech stack is entirely new to me. However, I am keen to explore the tech landscape to understand the opportunities and pain points. I found pair programming a good way to get to know the system better, while slowly working my way in.
Pair programming with someone working closely with the system also allows to understand the history, lesser understood context of why it came to be, and a great deal of context in a fun way.
Unexpected bonus? There is nothing like a good half hour of collective head-scratching to improve relationships with a team member.
Technical documentation can take many forms and shapes. They could be ‘readme’ files attached to code repositories to effective mini-sites to full-blown wikis consisting of code snippets, architectural diagrams, installation manuals, and FAQ fora.
The tricky thing about technical documentation is that it is no matter how extensive it is, there is almost always room for improvement in terms of either the amount of freshness of information or both.
So an attempt to bring about a small change in this area often leads to outsized impact and makes life better for everyone in the organization. And in the process of cleaning up or adding artefacts, you always learn a thing or two that you did not know before.
Automating some of your or your team’s routine tasks such as marking backlog items as stale, improving the developer experience on the build or release pipeline or simply automating your own tasks to give you some hands-off breathing time is a fun, low-effort, and non-blocking way to keep your hands in the game.
Participate in technical design discussions which will oftentimes give you the bird’s-eye view of the different systems, services and layers and the transport protocol between these. If you spend some time in the system, you could ask intuitive questions pointed towards oft-forgotten areas like performance, security, or data logging which could help guide teams to shift left on these requirements and build them early into the system. For you, this would be a terrific way to help the team while using the breadth of your technical design experience.
If you are leading a team of more than 5 direct reports, chances are that you will have lesser time than you’d like to spend on coding features. Code reviews are great pointers to many things. They give you an idea about the code architecture, but also certain subtle hints on the quality of the code being produced, the effort being made to keep technical debt in check, and the thought process of the developer.
Reading through code review comments in Pull Requests also gives a great feel of the underlying culture within the Engineering organization. How encouraging are we about juniors making mistakes to grow, do the senior engineers instruct rather than gently redirect to the right path and how anti-fragile our system is towards coding errors.
If you have time to do nothing else, I would recommend doing this. Spend at least half a day per week on going through random code reviews in the team. It is an indicator of a lot more than the feature that is being built and can serve as an effective pointer on some areas you might need to work on as a team.
There are many ways to keep abreast of the technical developments within your team. Key thing is, as with all things, to maintain the child-like curiosity and open-mindedness that kept you wide awake at night during your early days as a developer, while making sure not to block your team members, knowing that that is your primary responsibility!
Good luck, and happy coding!