Hey everyone!
It’s been quite a while since my reflective blog post earlier in the year and oh my goodness— A LOT has changed! Most of it has indeed been for the better, but with change in this industry, comes the process of handing off and letting go. Which, for many people, is tougher than initially thought. For many programmers, handing off code or projects is quite scary! Programmers hand off works that they may have spent years, countless nights, and many (many) frustrations going through the ups and downs that comes with any development project. However, this trepidation is one of the exact reasons why proper handoffs are so important. You’ve already been through the toughest parts of the projects and know the ins and outs. It’s always better to ensure others don’t run into the same issues you already did. And who knows? You’ll likely get to know more through the process itself!
Poor Handoffs == More Problems
A poor handoff will lead to more problems for the team down the line. We all have had our fair share of nightmare legacy code. Something that takes a few days to even get a base understanding of what’s going on. Of course, this is more prevalent in bigger projects with more contributors, but this issue of understanding can easily happen with solo projects as time goes on.
I’ll use an example of a project I recently handed off to a developer who needed a portfolio piece: ignite-boost. On the page, you can see the difference between the older version and the one the new developer created. It’s much cleaner and the code is much, much more maintainable. Through this handoff process, we collaborated on what would need to be adjusted in the code, as the code I had written originally was from over 10 years ago. Obviously, with that amount of time and with the experience I gained, I would do many things differently (honestly, probably even using a different tech stack). Guiding my friend through the decisions I made and what I would do differently prevented not only a bottleneck occurring from being stuck in the learning phase, but deepened both of our understanding of the code that we now maintain together.
”What I Would Do Next”
I mentioned briefly with ignite-boost that I discussed things I would do differently. Now, I want to discuss an important aspect of handing off: Explaining what should be done in the future. What you were planning to implement or re-factor. I recently stepped down as a co-founder from a startup I spend a majority of the year with last year. During my last tech meeting, I essentially went down the list of what I would start with next and why. The “why” here is critical when communicating handoffs. Ensuring that whoever is receiving the legacy code has the context of the intention opens the door for them to either follow through with your vision as close as they can or take the project in a new direction with that context. Going through the list of what you would do in terms of implementation or re-factoring can be a gamechanger in not only the future team’s efficiency but also preventing mistakes that you have already worked through yourself.
Reduce “Only You” Knowledge
This is an unspoken favorite among many developers. At least, it used to be before AI coding agents has started turning everyone into more software architects than coders. A lot of programmers (to be honest, people in general) like to be the primary point of context when it comes to their proprietary work. As stated earlier, for developers, we spend countless hours on projects. Often with little reward if it’s outside of work. So, it’s natural to be defensive and guarded over your work even in a professional setting. However, when it comes to the handoff, this “Only You” knowledge can create significant challenges.
When I decided to pursue other opportunities in my career, I made sure to document the processes and code of projects that I exclusively was on as I had that “Only You” knowledge. Keeping the proprietary knowledge with you before the handoff will create a bottleneck for future work to get done. Ultimately, though, you don’t want to stay as the “glue person” i.e. “Only x knows how to read the code/fix production. Leave it to them.” While this is a very comfortable spot to be in, nobody grows this way. Of course, we’re all about growth on this site!
Change Is… Kinda Scary!
Handing off projects in general is scary, but that’s because change in and of itself is scary. There are a lot of “what-ifs” and things that potentially get left on the table. However, as we grow in our journey, we must make sure that we lay a good path for the people who will continue our legacy (albeit in a small way) in the code without having to face the same challenges that we did. Really, it’s all about the mindset shift from a builder to an advocate as you hand off projects.
Always leave the place better than you found it.