What is Needed

To me, ownership is taking responsibility for the past, present, and future developments of a codebase. All aspects of the project, good and bad, belong to you. Whether you decide to let it whittle away and die or water it to let it flourish into something greater is completely up to you. I don’t expect the code I write today to exist in 20 years. Or maybe even in 10 years. It will all either be heavily modified into something unrecognizable or completely rewritten. It may even be me that does it. Better paradigms are always being developed and old code will need to be refreshed to stay current. So, what matters in the present is that what you write now can be rewritten safely and effectively. But just like a garden takes consistent watering to be healthy and grow, so too do codebases.

The AI metaphor for this I suppose would be an automated irrigation system, and I’ll write a few words about this at the end, but we’re not completely there yet. We’re at a point where we ask it for water and it gives us a correct amount of water to apply to the garden, but it can’t water at its own discretion.

It’s why modularity is so popular. Since we know that everything will be replaced, it makes sense to write in smaller modules that can be replaced strategically. What I’m getting at here is there is an aspect of engineering where someone has take it upon themselves to maintain and nourish the code they own. And I’m calling this the what-is-needed work. What-is-needed often overlaps with dull, unrewarded work. In life, this could relate to things like planning details of a trip or preparing grocery lists for your vegetarian friends that are visiting. Now, I know some people who would think I am crazy for saying this is dull work. Planning is the best part! But for me, it is hard to motivate myself to doing them. I just want to… do. So, pretend these are placeholders and swap in your own examples. In my world of software engineering, the what-is-needed work falls into the following categories.

1. Maintenance

2. Code reviews

3. Helping others

Maintenance

Don’t bother ever mentioning to others that maintenance is something you need to do. Everyone kind of knows that this the case, but no one wants to hear you complain that we need to take time to clean up this flaky code. Just do it. And do it quietly in small chunks. Even if you have a tight-knit group of trusted colleagues, don’t burden them with this unless you really need their help. This work will go unrewarded because the gains for it are subtle. This is work you are doing for your future self. You are sacrificing time in the present to set yourself up for success in the future. Since the gains for this are subtle, make sure to recognize when you get a feature assignment and it is straightforward to integrate because of your thoughtful past architecture decisions. Even though the feature is the only thing going on your resume and it was going to be implemented whether you had made good maintenance decisions or not, your past-self set your future-self up for success. Your mind stayed clear of clutter and it gave you the confidence and vision to see the feature end-to-end. It gave you bandwidth to think through all of the edge cases and bake solutions for them early in your design. This is a discipline not all engineers will have. You’ll see lazy implementations just like you see a lack of unit tests. And that looks nice because its easy. But don’t get suckered into that nonsense. Set the bar. You’ll feel better when you go home at night and you won’t panic when shit hits the fan. What are some opportunities for maintenance?

• Unclear code routes that need to be rethought and rewritten

• Bad naming - if a good name doesn’t come to you at first, try again later

• Unresolved warnings and static analysis issues

• Missing code comments, especially for complex code

• READMEs out of date

• No trail of offline decisions

• Tools that are difficult to maintain and provide little value

• Deprecations

• Redundancy

These examples are usually smaller items, but there can be large maintenance items. As I mentioned earlier, break these down into small chunks and chip away.

Code Reviews

Most teams I’ve been on enforce some level of code review. Though, I have been at companies that didn’t apply this enforcement. Startups, for instance, may pass on this process because they take time and you need to move fast. But excluding it requires a lot of trust which can be difficult to gauge. For those who are managed by this process, however, you ultimately cannot ship your code if it isn’t reviewed and approved. The reality of that needs to sink in and each developer in a team environment needs to come to terms with it. If you are not reviewing code, then you are rejecting part of your engineering responsibilities. Apply yourself! But besides just helping your colleagues ship code, there are other benefits from doing so.

• The take aways

  • Staying updated with the latest code

  • Learning something new from your colleagues

• The contributions

  • Using your expertise to help improve the change

  • Adding another set of eyes broadens the coverage

If you find yourself burdened by this duty, figure out what it is that is really bothering you. Do you hate reading code, especially your colleagues? Does it pull you away from your own deadlines? Whatever it is, it will continue to eat away at you until you address the core problem. If you hate reading your colleagues code, consider it an opportunity to share your insight or even the start of a mentorship. If it’s a styling issue, use this as an opportunity to discuss code consistency and maintainability. If you are worried about your own deadlines, then start with trying to balance your schedule better. Plan your day the day before and set aside a block of time for reviewing. If it is more overwhelming than that, work with your manager to adjust your current deadlines. If your deadlines are locked in, then work overtime. Just kidding, but sometimes it may come to that until you get a handle on your estimates. When you plan your next feature work and you need to give milestones or dates, make sure to bake in the amount of time that you need to support your team. And also remember that it works both ways! Your team will be taking time out of their day to look at your code. So, bake that in as well. More experienced leadership will understand these costs. They don’t expect something simple that can be done in 1 hour to actually be shipped in 1 hour. So, if you say it will be shipped in 1 hour, don’t expect anyone to be impressed. Give relative times based on the urgency of the issue. Here is a matrix of examples of what to say:

The statements in this matrix do not making any time based promises. If you need to continue using times and dates in your reports, try changing your phrasing of “I can get it in today” to something like “Let me see if this is something we can get in today”. It acknowledges the urgency while considering your team’s time. If it slips to tomorrow, it softens the blow. I went off on a little bit, but the emphasis is on the team environment. Code reviews are a team responsibility and you should participate.

Helping Others

It isn’t just what you ship that determines your value. But what you can offer to others as well. And I mean beyond just answering questions that people ask. Which, by the way, if you do get a lot of simple questions, then maybe you should write these down in a shared location so you can direct people to this location. A wiki! Or, in a more considerate manner, give them an answer from your wiki and also point them to the page. Other times, you may get questions looking for your advice to solve a problem. This is a step-up. You can use your expertise from your career, your knowledge of the company, and your individual opinions to contribute to their solution. These may take time and energy, so only take them on if you have both to sacrifice. If not, ask them to come back later or give them a resource that will help them in their search. The next step-up would be to meet with people to chat about their work, build tooling to improve productivity on your team, or organize a brown bag. Whatever it is, do it for others. Like the other what-is-needed work, this isn’t really something that fits on a resume. But doing it shows your current leadership that they made the right choice hiring you. You lead by example and encourage a healthy, vibrant team environment. This can have a long lasting effect after you move teams or companies. Which is great! Being able to look back on your old teams and watch the seeds you planted grow can be quite rewarding! Just don’t shy away from helping others, but of course don’t overwhelm yourself doing it. Be smart and manage your time wisely.

Conclusion

More and more of the what-is-needed work will be automated in the future and we’re partially seeing it in practice today. We shouldn’t punish ourselves with this grind forever. So, we should look for ways a computer can handle these duties. There are a bunch of tools already that can help and here are a few popular ones:

• Integrated

  • Amazon CodeWhisperer

  • GitHub Copilot

  • PyCharm

  • Visual Studio IntelliCode

• LLM

  • ChatGPT

  • Claude

  • Gemini

  • Meta AI

  • Pi

These tools will be able to assist you with writing/evaluating code and generating documentation. It is your assistant and it can be put to work in your automations. It has tons of uses today and will have plenty more tomorrow. So look for opportunities to leverage these technologies whenever and wherever you can, but for the areas that aren’t covered yet, we will need engineers to step up and do what is needed. I’ll say it again, this isn’t glamorous work. You won’t be recognized for it. But you give yourself and your team a better chance of success if you do.