Swizec Teller - a geek with a hatswizec.com

Senior Mindset Book

Get promoted, earn a bigger salary, work for top companies

Senior Engineer Mindset cover
Learn more

    You can't side-quest a product

    Here's a trap that talented engineers fall into all the time. It creates frustration, burnout, and the genre of tweets that read like "Why don't people care about the amazing work I'm doing".

    Solve the problem, not a different more difficult problem

    Jane, Joe, and Alice are faced with a challenge: They're building a project that looks like it might involve a series of web forms. The first one is simple, but then there's the next form and the next and the next one after that.

    They look at each other in the swarm meeting and sigh. This looks tedious.

    Joe speaks first: "Great, web forms. A bunch of them. It's been so long since we did anything interesting."

    "We could make it easier. Build a tool that spits these out ... 🤔" adds Alice.

    Jane gets a twinkle in her eye. "YES! And then we can make a basic JSON config for the forms that our stakeholders could use. They could even ask ChatGPT to write the config for them"

    Joe gets excited. "We'd never have to build a web form again! The stakeholders would be fully empowered to move on their own 🤩"

    They come back to Bob, the PM, with a revised estimate. He clears his throat and says "Did you say 2 weeks for a form?"

    "I know it's a lot Bob but think about how much time this will save down the line. This is gonna be epic", Alice says.

    Unconvinced, Bob lets the team experiment. He believes engineers should get us across the water, not just build a bridge.

    3 weeks later he gets a form, it mostly works. But priorities have shifted and the team is off to working on the marketing site. The pile of forms will have to wait.

    You can't side-quest a product

    I was once Jane, Joe, and Alice building a form generator framework. We had a new company direction that looked like lots of forms and a small dysfunctional team. The perfect breeding ground for solo technical initiatives that solve the wrong problem.

    Make APIs, not friends was our motto.

    The ask was to build the first form to start testing the new initiative. But I thought my approach to solve all forms forever was brilliant and forged ahead.

    After 2 weeks of excitement, I delivered the first one-page form. Nobody was impressed. Why did it take so long? Aren't you a senior engineer? 2 weeks for a basic form? It doesn't even look that good. The validations are wrong. Can we move these fields around?

    Making changes to our forms was unpredictable. One ask was effortless and easy, another similar ask meant hours of work to add new features to the framework. Other basic asks exposed interesting new bugs. This was frustrating to our PM because each new estimate felt like a surprise. "Are the engineers fucking with me? How do you plan a roadmap in this environment??"

    The worst part was that my framework made our forms tightly coupled. Because every form used the same core, you had to constantly test and re-test everything when making changes.

    There's more to product than code

    We didn't have automated testing of course. Or a proper development process for the framework itself. It was purely one engineer's (me) windmill tipping effort to solve forms in a systematic way.

    In a better-staffed company you'd solve this with a platform team of some sort. Or reserve a staff engineer's time to work on the framework. Leadership buy-in is key. They have to believe your thing brings value to the company and invest in your success.

    The framework needs to be somebody's product and get the full attention it deserves. You need:

    • a proper discovery process,
    • managing stakeholders (other engineers),
    • OKRs tied to the success of the framework,
    • proper testing and observability,
    • documentation,
    • release management,
    • time to offer help and support

    A framework or library is a product. It needs close to the same love and attention your main products get. The bigger the company, the more of this meta-love it's going to need. You cannot do this as an unsanctioned begrudgingly tolerated side quest.

    Without love, your framework will die

    Friends tell me that after I left the company, working with my frame builder was "super annoying". The abstraction was nice when it worked and basic forms were quick to build, but almost none of the forms they needed were basic. Every form had some exception they had to bang into place.

    The forms never changed frequently enough to warrant the "Just write this simple config, anyone can do it" approach I created. Business stakeholders never wanted to build and configure their own form, obviously. That's what the engineers are for.

    Soon the builder was scrapped and the team went back to building forms out of basic elements by hand. It was more work per form but quicker to build, easier to understand, simpler to ship, better for all the special cases, easier to estimate, and with fewer unexpected bugs across forms.

    You can't fix the wrong abstraction. You have to throw it out and start again. Like kicking a can.


    Published on July 3rd, 2024 in Engineering, Software Architecture, Complexity, Scaling Fast Book

    Did you enjoy this article?

    Continue reading about You can't side-quest a product

    Semantically similar articles hand-picked by GPT-4

    Senior Mindset Book

    Get promoted, earn a bigger salary, work for top companies

    Learn more

    Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.

    Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.

    Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.

    Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev

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

    Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections

    Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog

    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 by Swizec with ❤️