NATE BAILEY

Tall Developer, probably not a unicorn
Seattle, Washington

        

Technical Shame

July 16, 2016

Technical debt is a normal part of the software development process. Sometimes you make the conscious decision to take it on in order to meet a goal, sometimes it just happens. When working solo I find that it doesn’t matter how it got there, technical debt turns into technical shame.

I’m in the middle of rebuilding the Sugar & Stamp store. It’s been extremely difficult to prioritize between freelancing, finding a job, and traveling. I’m finally getting close to wrapping it up… and I’m going to be rather ashamed of the final product. It’s going to be bulky, difficult to modify, difficult for future me to understand, and difficult to port. What matters is that the store will finally be live. I can make up for the technical debt later, the thing needs to be shipped.

Working with Javascript in 2016 inevitably comes with a constant sense that your stack is out of date as soon as you begin writing code. There’s always a better way to structure your app, a better build process, a better documentation style. I find that this causes me to feel a lot of technical shame as well. In reality, this isn’t truly technical debt. The recently open-sourced Apollo 11 guidance computer source code doesn’t have technical debt just because it’s old. It works and it’s (obviously) deprecated. Takeaway: pick your tools, write the app, and protect yourself with tests and deployment processes. That’s all you can do, the thing needs to be shipped.

Technical debt turns into technical shame when I’m working alone: with the validation of a team and a firm goal I’m able to avoid internalizing it. It’s a huge relief to collectively decide “yes, we will get back to that code and make it better” or “this app is well built with our chosen tools, we can be proud of it.”