It’s all over the place:
As a software engineer your job isn’t to write code, but to solve problems.
It’s BS. I don’t disagree with it, you can’t really disagree with something so uselessly broad. This quote is basically true of every role in any organization, especially on the product side. “As a firefighter, your job isn’t to put out fires but to solve problems.” Well, true… but specifically, the very particular problem of a house being on fire. Likewise, a software engineer’s job is to solve specific business problems via creating and editing software.
The platitude doesn’t tell us anything we didn’t already know, but it does sound nice.
Who is this advice actually for?
I think the people sharing this quote usually have one of two goals:
Address AI anxiety
With the gist of their post being something like: “Don’t worry about being replaced, you’re not just a ‘code typer’, you’re a problem solver!” Or maybe better: “Make sure you’re not behaving like a ‘code typer’, but as a problem solver, so that you cannot be easily be replaced.”
I just don’t see who needs to hear this - especially if you’re the type of dev reading about tech on literally any forum or taking any interest in the craft outside of work at all.
Of course, I don’t disagree that AI can type code pretty well at this point, especially with careful instruction. We should embrace AI tools. They can make us way faster and more efficient. But I also think we should turn them off sometimes…(but I digress, more later).
It’s possible that I’m showing my bias from working at a small company where the same handful of people handle R&D, tech sales / support, dev, and testing, in that case it’s nearly impossible to not build context. Even considering a large org though, I find it hard to believe that the average developer works with zero understanding or care about the context and actual business behind their software and instead just pops tickets off the queue and blindly implements verbatim.
Understanding your customers / business
Yeah of course, but again…who needs to hear it? Is someone who cares enough to be reading these things, really going to be the type to be just checking the boxes / typing in code to get a paycheck?
I’ll be the first to admit that my first hand experience is limited here. I’ve only spent a short time at a large company as an intern. Even though people were specialized and siloed there, they still understood what was happening and the larger picture. They were skilled and focused on problem-solving using their domain knowledge, not just crossing off TODOs to get to Friday.
I’m not so naive as to imagine that some people don’t have this sort of outlook; but by definition if one had that outlook they wouldn’t care about this advice (or any other non-mandated advice).
I suppose it might take more time to turnover at a big place, maybe some of them can slip through the cracks. But this type of person would drags down any team; at a small company, it’s painfully and pretty immediately obvious.
A People Problem
This motive for the quote is usually something along the lines of: “You’re job isn’t to physically write code - you’re going to need soft skill to get things done and get promoted, etc.” I don’t disagree with this take at all, you definitely need to able to understand and communicate the tradeoff of different approaches, get buy in, etc. I would still argue that this falls under the umbrella of solving a business problem though software.
Better Advice (maybe?)
Here’s what might actually help:
- Talk to your customers directly when possible. Engineers should do support at least sometimes. For example, at FarSounder - the engineering team is the support team, so all have a good understanding of the product and common issues, etc. I understand that this won’t scale or be possible everywhere, but one way or another some version of this could be implemented.
- Ship early versions / demos / POCs they can actually use and play with when
it’s possible so you can iterate based on their feedback. I use this approach
with client work whenever I can. If it’s possible, I aim to deploy something in
the first day or two, even if it’s just the bones. For example, I’m working on
an app to allow fisheries scientists to few photos of fish from a sampler and
annotate them (species, etc) so that stats about the region can be calculated.
The first day, I deployed a demo app with a gallery view of images and dummy
data so that the client could start to be involved and give feedback.
- Caveat: this doesn’t work with every type of client, you need to feel it out a bit. Less technical clients might need to see something a bit more polished at each iteration.
- Understand their actual problem, not just the solution they think they need to solve that problem. IMO this works great with the last point.
- Don’t be too principled to use LLMs to make you faster. But also don’t let
them rob you of understanding and learning.
- Turn off completions sometimes and make sure you can still think. Do some Advent of Code, coding challenges, side projects, etc, w/e floats your boat.
None of this fits in a cute, shareable catchphrase though.
The main thing I realized writing this: my complaining about this useless advice is probably just as useless as the advice itself. But at least now I got it out of my system and I can stop turning it over in my head. Congrats, it’s your problem now!