That's an interesting perspective. It's hard for me to relate to it because I haven't worked in a job where I just have to ship code 'for work' in so long. Being a more or less one-man software company, all my work projects, but especially our products, feel like personal projects.
However, if I were just having to do things for the man, I might have a rather different take on all this.
Yup, I can definitely imagine that it's different if you're working directly for customers and have the freedom to do things however you want to do them as long as you still make a living.
I don't think that is true. If you have the creative control, and LLMs suck the joy out of programming, then you and I have very different ideas about what that joy was in the first place. I enjoy programming both on a very high and a very low level, and both are more fun with LLMs. On the low-level, you can use that to create the building blocks that the LLM then just has to combine. And on the high-level, you can use that to steer the design in a way the LLM would never be able to, but with the help of the LLM you can connect that high-level design much faster to the low-level building blocks.
Maybe try using them differently (I tend to use them like static analyzers I can yell at/argue with, and honestly less straining than trying to parse a Coverity report), or just avoid them.
Mental health is more important than 20% gain or loss (depending on which study supports your prejudices) in productivity.
In 2017, I wrote a blog post expressing some scepticism about the stampede toward remote work. This was well before the pandemic and before things hit a watershed with it. It occurred to me, then, that this would disrupt the pipeline for junior employees:
Having descended from a humanities social background and blundered into professional programming rather incidentally, a lot of this resonates with me.
I've frequently been credited as a person who can really string all the disparate elements of tacit knowledge together into a unified fabric in our particular subdomain, and helped a lot of people plug Swiss cheese gaps in their knowledge that way and come away with the feeling that it's all been tied together theoretically.
However, it's not immediately obvious to me how, in our LLM psychosis cultural moment, this facility shoots to the top of the value chain.
In theory, it's because we're going to be better at steering an LLM in some ways. A lot of the friction and hold up in building comes in the communication between people/departments/organization. If you eliminate that by holding the knowledge in one person/department, you see an efficiency gain.
What they're not saying is that they think we're more valuable because they think we'll be cheaper. They think they can have us do 2 jobs and pay us for 1: probably less than a decent SDE made in 2019.
Personally, I think it's likely to be a shitshow and backfire if that's how companies decide to try to go that route (especially the largest ones). First, if we wanted to be devs, we would be (like you). Most people with the knack for programming and thinking in systems know they have that knack, and if they haven't jumped ship to SDE before now, there's a reason. I could definitely hack a junior SDE role, skill wise, but I don't want to. Second, finding people like us is difficult. The hiring process (which is becoming more and more Gilliamesque by the day) is really bad at identifying us. There aren't credentials, and this sort of work tends to reside in the gaps, as you identified. It's harder for it to show up on a resume. Hiring is optimizing for exact matches and experience, and that's the opposite of how this skill set actually functions. I've found these skills are best developed by being placed in a room where you know very little about what's going on and forcing you to develop heuristics and approaches over time for getting that context. Thirdly, I can't speak for you, but I've developed this perspective over decades and if people want it, they're going to pay appropriately. If they think I'm going to do any of this at my current salary level, they're deranged. And lastly, while most people in our position might roll our eyes at some techie discussions and culture, we do fundamentally like techies/devs and we tend towards placing a greater value on things like relationships than a pure SDE does. (Just speaking in generalities). So 'is willing to replace and/or toss out a category of people I like and respect' is a hint to us to start out assuming this is a hostile negotiation. (Whereas SDEs as a cohort over the last 20 years extended a lot of goodwill at first). We're far more likely to work somewhere, get enough domain knowledge, and then bounce to start our own thing, especially since as a population we're more likely to have devs who will work with us as non-technical founders. Someone who's decent at marketing/sales/the stupid 'people stuff', understands a domain, and understands when a proper dev tells them what is and isn't possible and can even help with some of the most boring, rote parts of the technical side if needed/in crunch is an excellent non-technical founder, and as a group we're also more likely to have access to the technical connections that we'd need if we wanted to build something beyond our ability.
This is an underappreciated bit of insight and perspective, and I thank you for sharing it.
Thoughts that really stood out for congruence with my own experience:
> Most people with the knack for programming and thinking in systems know they have that knack
> Hiring is optimizing for exact matches and experience, and that's the opposite of how this skill set actually functions.
> I've found these skills are best developed by being placed in a room where you know very little about what's going on and forcing you to develop heuristics and approaches over time for getting that context.
> We're far more likely to work somewhere, get enough domain knowledge, and then bounce to start our own thing
> many, many humans derive a significant chunk of their self-worth and life's purpose from their jobs.
Men, or women?
Not trying to raise gender role controversies. It's just been my observation, throughout my life experience, that men, as the primary public-sphere producers and providers, are much more tethered to public-sphere occupational identity than women. This seems validated in the experience of the structurally unemployed, e.g. in the former industrial regions.
As women are 50% of the population, give or take, I expect the politics of this might flow differently for them than for men, as a bloc.
I get local models to drive applications through MCP (e.g. Google Chrome DevTools) via OpenCode all the time, and do things that would otherwise be very token-intensive and result in pointless meatspin. This is totally possible, and will become more so.
The real reason you pay for Claude _is_ in the models. The locally runnable models are impressive for what they are, but simply will not accomplish the task as effectively, incisively or quickly enough. I have to be willing to let OpenCode run in agentic loop on "download my bank statements"[1] for an hour and just walk away, and take a low-ish but profoundly nonzero chance that it will just fail. Claude can do it in 5 minutes, if I let it (I have), and it will not fail. Both are driving the browser via MCP and performing the same task.
[1] One of those difficult-to-use, modal-rich JavaScript-laden banking portals that seems quite intentionally designed to prevent this sort of downloading, or I wouldn't bother letting an agent loose on it in the first place.
There has never yet been a new model which actually improved over the previous ones. They suck just as much, and in the same ways, as the models of 3 years ago.
reply