Swizec Teller - a geek with a hatswizec.com

    Reader question: "When do you fix tech debt?"

    Long time reader Phil asks when do you fix the tech debt you used to ship faster

    How do you get business buy in for spending some time on the tech debt and the improvements that are hard to prioritise against the main objectives for the quarter that are linked to the overall business objective

    You can hope for a miracle. One day you'll win the lottery and that magic Tomorrow when you have time to do all the things will come.

    But you won't. The odds are never in your favor.

    Heroic efforts don't work

    You'll never have a feature freeze. Not even for a sprint. A good business never runs out of ideas.

    If you do have time to sit and fiddle with tech improvements for days and weeks, run away. You deserve to work for better business and product people than that.

    The Senior Mindset series

    Get a series of curated essays on the mindset of a senior software engineer. What it takes to get there, what should you do when you're there, how to change the way you think.

    it describes my days in a way I have not read before.

    This was a very enlightening article about being a senior engineer.

    Join over 10,000 engineers just like you already improving their careers with my letters, workshops, courses, and talks. ✌️

    Unless you're a small team focused on the tech inside a larger organisation. That's different. Lucky you!

    What you may get, once in a while, is a sprint that goes miraculously. The stars align and you find yourself with an extra day at the end 😍

    POUNCE my friend!

    Fix your favorite pet peeve. Improve your annoyingest repetitive process. Something. This is a rare opportunity and I hope you're ready with plenty of ideas and little annoyances.

    You pay off tech debt little by little

    Tech debt is a lot like real debt. You pay it off little by little over time.

    A constant mindset of gardening and tweaking. No heroic efforts.

    The approach that has worked best for me across different companies is to roll this gardening into your main work. Got a feature? See if there's a related story on the engineering backlog.

    Can you pay off tech debt without endangering the main story? Go for it!

    Can you fix a method or component while adding a feature? Do it!

    Can you rewrite a weird loop that makes no sense while trying to understand the code? Fix it!

    Can you leave that file a little better than you found it? Take out that trash!

    Little tweaks here and there. Fix a hairy condition chain, tie a branch to the tree, pull a bad leaf, pluck a weed, lovingly tend to your codebase like it's the best flower garden in the world.

    Not all debt is created equal

    Tech debt will overrun your garden, if you keep adding more faster than you can pluck the weeds.

    That's a recipe for disaster ... later.

    You have to be careful about which debt is worth taking on. In my Tech Debt is a Tool email I wrote about how we avoided writing code to ship a feature to fulfill a new legal requirement quickly.

    Code you don't write is good debt.

    When it's for a good reason, even better. You can always add a feature later when you understand the requirements better. Or there's a clear business need for that feature. Or there's more engineers available to work on it.

    All code is tech debt.

    Yes every line of code is a liability. Even the beautifulest perfectest code you can think of – it's already tech debt. You have to maintain that shit.

    Swizec Teller published ServerlessHandbook.dev avatarSwizec Teller published ServerlessHandbook.dev@Swizec
    Your code either dies a prototype or lives long enough to become that shit code you don't wanna deal with.

    Requirements will change and your beautiful perfectly designed wonderful code – it's trash. No longer fit for purpose, full of outdated idioms, hard to understand for people who don't think like you.

    That includes the You 3 months from now. Future You is a different person.

    An example of bad tech debt

    Examples of bad tech debt abound. Think of any code you've had to fix that was written by somebody else.

    Looked pretty bad huh?

    Dissing other's code is weaksauce. Here's when I personally fucked up on a former project:

    There was a UI I had to build that iterated over a list of questions and rendered them. Certain questions had sub-questions.

    I squinted and thought "This is a recursive problem but bet you can I do it linearly with a .map"

    And I did. Ho boy did I write the cleverest code in my life. I was so smart that the heavens opened and peppered my project full of bugs. The more bugs I fixed, the more it looked like I was reinventing recursion from scratch.

    With every bug my "keep track of things" data structure looked more like a stack. With every fix my gaggle of variables looked more like all the things compilers keep track of to make recursion work.

    All because I wanted to be clever. 💩

    An example of good tech debt

    How careful should you be of memory leaks on a missile?

    Clive Thompson avatarClive Thompson@pomeranian99
    Memory leaks on missiles don't matter, so long as the missile explodes before too much leaks. A 1995 memo:
    Tweet media

    I was once working with a customer producing on-board software for missiles. I pointed out that they had a number of memory leaks.

    "Of course it leaks" the CTO said

    He pointed out that they calculated how much memory would leak in the total possible flight time of the missile and doubled that number. They added this much additional hardware to "support" the leaks.

    Since the missile will explode when it hits its target, the ultimate garbage collection is performed without programmer intervention.

    Take on good debt and go gardening 🌷

    Cheers,
    ~Swizec

    PS: the afternoon after that big chunk of sprint ending/starting rituals is my favorite time to go gardening. Dazed from a day of meetings, no stories officially started. 👌

    Did you enjoy this article?

    Published on August 17th, 2021 in SeniorMindset, Mindset, Opinions

    Want to become a true senior engineer?

    Getting that senior title is easy. Just stick around. Being a true senior takes a new way of thinking. Do you have it?

    Leave your email and get the Senior Mindset series - a series of curated essays on the mindset of a senior software engineer. What it takes to get there, what should you do when you're there, how to change the way you think.

    The Senior Mindset series

    Get a series of curated essays on the mindset of a senior software engineer. What it takes to get there, what should you do when you're there, how to change the way you think.

    it describes my days in a way I have not read before.

    This was a very enlightening article about being a senior engineer.

    Join over 10,000 engineers just like you already improving their careers with my letters, workshops, courses, and talks. ✌️

    Have a burning question that you think I can answer? I don't have all of the answers, but I have some! Hit me up on twitter or book a 30min ama for in-depth help.

    Ready to Stop copy pasting D3 examples and create data visualizations of your own?  Learn how to build scalable dataviz components your whole team can understand with React for Data Visualization

    Curious about Serverless and the modern backend? Check out Serverless Handbook, modern backend for the frontend engineer.

    Ready to learn how it all fits together and build a modern webapp from scratch? Learn how to launch a webapp and make your first 💰 on the side with ServerlessReact.Dev

    Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com

    By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️

    Created bySwizecwith ❤️