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