Introduction
Many software engineers -including me- have joined this industry out of love for code. It is very rewarding to build software and see it come to life. But unfortunately, after a certain number of years in the industry, we start finding ourselves inundated with an increasing number of tasks that are beyond what we have originally signed up for.
A common theme among engineers approaching seniority is feeling frustrated at the diminishing amount of code they get to write on a daily basis. Instead, they find themselves being up to their eyeballs in documents, emails and hours of meetings. This is especially frustrating when a project is not moving well beyond the ideation or planning stage.
In this article, I argue that these tasks present a bigger opportunity to impact code than through directly writing it, and that a successful engineer should also welcome this added responsibility. It signals the organization’s trust in this individual’s skills and a desire to scale them to the next level. Finally, I will be giving out some guidance on how to make sure you’re still writing code in your day-to-day, even if you take on these responsibilities.
Only writing code limits your impact
Understanding the impact that you have on the code that you write is straightforward. You write it, it’s there. You refactor it, it’s better. You add tests to it, it’s easier to change. At the start of your career, your performance is measured directly through the code that you write. The quality and speed of delivery of code both play a significant part in your evaluation. The problems you face are in terms of classes and packages. It is a good life, and for me, I could hardly believe I was paid to do this!
As time goes by, you find your code is starting to become more refined. You are receiving a lot of helpful information from senior engineers either through feedback or other avenues. You find yourself raising your bar on code quality, and you’re being trusted to own larger and larger portions of the code-base.
This process that you have gone through as a junior has shaped the way you approach problems and write code. It has made you a better engineer. This process, however, did not evolve by accident. It was crafted and constantly refined by engineers more senior than you. As you approach seniority, you will be expected to become the senior engineer in many juniors’ development stories.
As a senior engineer, you are presented with opportunities to impact code in ways much larger than before. Your work, either by direct influence, or by passive leading by example, affects not only the code you write, but the code your entire organization writes. And as someone who has done their fair share of writing code, you are well-positioned to take advantage of this position.
How you can scale up your impact
But how can you actually take advantage of your influence? It starts by coming to a very important realization: Software development, much like many lines of work, is a people problem. The code is an artifact to the way people are functioning in an organization, rather than the problem or solution itself. Your job as a senior engineer is to support the organization in solving these large-scale problems.
When retrospecting an incident, it is easy to think that we wouldn’t have faced this outage if the code was written better, or if the design had accounted for a certain edge-case. But this kind of thinking attributes agency to the artifacts, rather than the people that produced them, and the processes they were under that influenced them.
In a post-mortem, you’ll always find that a people process has failed. Maybe it is a code review process that failed to catch a large mistake, or a policy caused engineers to take a riskier path than necessary to achieve a certain incentive; e.g. to save on cost, to circumvent an time-intensive review process, or to ensure an engineer covers a certain goal to get a promotion.
By herding dozens, hundreds or thousands of engineers down a path to success through appropriate processes, the tech will be in a better shape. They will be able to make right decisions more often and produce artifacts that better suite the organization’s business goals.
Development Processes
The most direct way to influence code through people is to create, enhance and socialize your organization’s development processes. Examples on development processes are code reviews, design reviews and deployment procedures. You can also leave an outsized impact by automating a lot of these processes, plugging in static analysis tools to the team’s code reviews, or automating error-prone manual steps when deploying services or running them locally.
Being a senior engineer, you are well-positioned to make the calls on these processes as you have seen what works and what doesn’t through your knowledge in the code and architecture of your company’s software.
Being a source of truth for leadership
Having earned wisdom in your career you have a better eye for what works and what doesn’t. Pair that with the close-to-the-ground nature of your work, means that you are well-equipped to relay accurate and actionable information to your leadership. Through this, you can can affect staffing decisions and strategic calls. You’re also able set expectations for when the next business initiative can be delivered.
This not only gives your team a chance to get the funding to finally deprecate a service, or pay off some technical debt, but also gives your team breathing room to be able to deliver comfortably without having to create unnecessary tech debt.
Mentoring and developing junior talents
Make sure to position yourself as a helpful engineer. Be known for always providing support to people who need it. This puts you in a powerful position to educate and influence how team members approach problems and implement solutions.
This will also give you the chance to know what team members are working on and gives you an understanding of the activities taking place in your organization. You can use this information to steer the ship as discussed in the previous section.
Setting the bar for code quality
As a well-known, highly skilled, and senior engineer, the way you carry yourself is important. If you are cutting corners, so will the interns. You can enhance the level of quality of your entire team by operating at a high level of quality and showing people two things:
- That quality work can be achieved
- How quality work can be achieved
In a lot of environments, engineers will feel the pressure to deliver at the expense of quality. Being a successful engineer with much experience, you show the levels of quality that can be achieved within the constraints of your organization by delivering work of exceptional quality on time. This helps you showcase how and when compromises are taken. This helps inform your team on how to make similar decisions just by letting them observe how you work.
You can also take a more active role in setting the bar for code quality. You have an unofficial authority to influence parameters for code quality such as acceptable testing coverage, code review size..etc. Lead the charge in aligning with the rest of the team on these parameters and you can watch the quality of the code and the level of discourse around it improve.
How to actually end up writing more code
You may have been unsatisfied with the answers in this blog post, or you don’t have the desire to take on the added responsibilities. Don’t worry, there are still ways to get your coding time back.
Talk to your manager
The most direct answer is to talk to your manager. Make sure they understand the kind of work you’d rather be doing and align with them on steps to achieve that. Your manager might be thinking that they are providing you with an opportunity to grow in your role, but the opportunities may be too early, or they may be not as effective as expected for your career growth. Or you may just want more time to write more code.
An open and transparent communication channel between you and your manager is essential to achieve happiness in your role and growth into larger roles in the future. Make it a priority to create an atmosphere of common respect, understanding and honesty with your manager.
Use your influence to give yourself more coding opportunities
Chances are, you’re going to be given the opportunity to make decisions on behalf of the organization. You may find yourself able to give yourself these opportunities to write code. It may be in the shape of a design that requires a new implementation, or a task that requires someone to change code on the critical path in an area you’re most familiar with. As the owner of this project, you can assign yourself these opportunities.
Be careful not to take opportunities that would be easy for you, but would have been a good challenge for a junior engineer that they could use to grow. And make sure to use these coding opportunities to set the bar. Involve everyone in reviewing your code changes and have healthy discussions about what you are doing.
Give yourself time to code
You may have been given the green light by your manager to pick up more coding tasks, or you’ve found a way to further the organization’s goals while still getting some coding in. But you still find yourself drowning in emails, documents and meetings.
Programming needs large blocks of uninterrupted time (see: Maker’s Schedule, Manager’s Schedule). A 30 minute meeting in the middle of a 6 hour block has split this block in half. You end up with two less useful 3 and 2.5 hour blocks. You will need to block time for coding and defend it with your life.
You might find that you have already agreed to a lot of meetings that have fragmented your calendar. What you can do is write-off that week or sprint. Block your calendar 1 or 2 weeks in advance for the next sprint, instead. Block your calendar generously so that if you have to give away some of your coding time, you end up with a good chunk of it intact.
Conclusion
Writing and reading code is one of the biggest pleasures for a software engineer. However, good software engineers find themselves rewarded with tasks that detract them from interacting directly with code. These opportunities provide a chance for engineers to impact code at scale that is larger than their own individual contributions, making sure that the org as a whole is writing better code and delivering better value to the business.
Your problems may be about balancing those new responsibilities with the responsibility of writing code. You will need to become better at defending your time by declining meetings or setting expectations on email replies or documents to read or write. You may need to block your time weeks in advance to make sure you meet your current commitments while still setting the expectations for any new engagements in the future.