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

    What does "solve problems" even mean

    We talk about how the goal of software engineering is to solve problems, not to write code. But what does that even mean? ๐Ÿค”

    It's a subtle change in perspective. The best way to explain is with an example or two.

    Teaching girlfriend's dad how to AI

    A few weeks ago my girlfriend's dad texts me: "Hey I need help with some Python. Got a minute?".

    He was a software engineer before he went into investing and we exchange about 3 texts per decade. This was unusual. Him asking me for help? ๐Ÿคจ

    We get on the phone and he explains:

    • slammed with work
    • needs to write a bunch of investment memos
    • wants to hire people to do this
    • not enough time
    • found blog where a guy did this with GPT-4
    • deadline in a week

    The ask: "Can you teach me enough python to cobble this together and meet my deadline?"

    What would you do?

    Here's what I did ๐Ÿ‘‰ย "I don't think you have enough time to learn this. Let's see if ChatGPT can do it natively through the web UI"

    It did!

    We fiddled around for an hour. Got pitch deck slides exported into a public HTML by abusing Google Docs, used ChatGPT browsing mode to read the content, and tried different prompt variations until we got a decent investment memo. The whole 5 pages of it. A week's worth of work done in a few minutes ๐Ÿคฉ

    Yes, you still need a person to read through and make sure all is well. But editing is easier than writing.

    By talking through this process on a screen share:

    • Girlfriend's Dad learned how to do it
    • understood the thinking behind what I'm doing
    • asked plenty of clarifying questions
    • had a rough recipe to follow

    He was at "Okay I just installed VSCode, how do I python?" when we started, and at "Wow, we did it!" when we stopped. No code required โœŒ๏ธ

    Unblocking 5 teams with 1 meeting

    At work I've been owning a vendor migration. It keeps teaching me that coding is the easy part ๐Ÿ˜…

    The latest in that saga is migrating our feature flag implementation.

    We have an internal wrapper library that scrubs PII before sending requests to the feature flag API. This is because we don't have a business associate agreement (BAA) in place. Means we can't send users' personal info to that vendor because we're a healthcare company.

    The platform team owns that wrapper. The product teams call a function and get flags. They don't care how it works.

    I, and a few PMs, want to migrate feature flags to this new vendor. So we made a plan: The platform team updates their library, migrates old feature flags over, product teams barely notice anything happened ๐Ÿ’ช

    "Ya okay that's a nice plan, we might be able to do it some time in September. That work for you?"

    That's in 4 months!

    After noodling for two weeks I called a short meeting with the platform team and our lead architect.

    Swiz: "Is the wrapper even valuable?"

    Them: "๐Ÿค” well we do have a BAA with the new vendor. But it makes migrations easier?"

    Swiz: "It's making migrations harder right now"

    Them: "Indeed ... so what do we do?"

    We move ownership to product teams, where it belongs.

    Throw away the wrapper library, let every team start using the new vendor with the official SDK on new projects, and slowly migrate at their leisure using their own product backlog. Make this an opportunity to clean up a bunch of old experiments.

    That way nobody is blocked, the platform team avoids extra work, and teams are empowered to move independently. Yay!

    The lesson

    There's a few lessons in here depending on the mood you woke up this morning.

    Swiz is lazy. This is true. I want to get things done, not "do work". There's even a tattoo about this.

    Code is expensive. Use when you're building an asset or it would take you, personally, less time to write the code than to do the work. Not every 10 minute task is worth automating.

    Don't be afraid to throw away work that isn't serving you anymore. Just because it exists, doesn't mean you need it.

    Focus on solving the problem, not doing the work.

    Cheers,
    ~Swizec

    Did you enjoy this article?

    Published on June 13th, 2023 in Software Engineering, Mindset,

    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 โค๏ธ