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
Continue reading about What does "solve problems" even mean
Semantically similar articles hand-picked by GPT-4
- Building software is a distraction
- What I learned from Software Engineering at Google
- The code is not the goal
- You can't side-quest a product
- Don't neglect your upgrades
Become a *true* Senior Engineer
Get promoted, earn a bigger salary, work for top companies
Getting that senior title is easy. Just stick around. Being a true senior takes a new way of thinking. Do you have it?
The Senior Minset email crash course
Get a free chapter from the Senior Engineer Mindset book and a sample audiobook chapter, followed by a Senior Mindset 101 email course.
You'll get insights to apply at your work right away.
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 ❤️