I think the answer is in the second sentence of the article. The most valuable person in this new world (using the author's own phrasing from the penultimate paragraph) is the one who is good at "building a working model of the domain in [their] head".
Depending on the domain, this may either be the domain expert themselves, or someone else trained in formal logic, data structures and organizing information into coherent hierarchies. If this is neither the domain expert nor the programmer, then it must be someone in between. In the old world, this role was called "business analyst".
Working model suitable for an electronic computer.
I'm this person, and I do find AI to be quite helpful, though I'm mostly just playing around at this point.
I'm the daughter and granddaughter of programmers, and I learned the basics of how to code as a kid. I'm good at it and have a knack for it, but I didn't want to do it for 8+ hours a day and then spend my nights on it as well, so I didn't pursue it as a career. I did an undergraduate degree in Linguistics, which has been really helpful for having an intuitive sense for what 'language as data' can accomplish and for a strong understanding of the difference between language as data and language as meaning. I studied formal logic systems. Then I did a graduate degree in Library Science and worked in libraries for a decade and a half.
I can organize and define systems very well, and I'm trained in how to wheedle information people don't consciously know out of them without them knowing I'm doing it. I've spent enough time around actual devs to understand where my limitations are and when to loop in someone who knows more to check my work, and when it's important for the work to be super accurate versus when I can learn by fucking around. (Front end and design? Fuck around! Database structure? Fuck around but with an exceptionally robust backup system kept outside of the AI tools' purview + don't fuck around in prod. Storing credentials and people's information? Ask someone.)
The problem companies are going to have is I'm very disinclined to work for them doing this, particularly if they want us because they think we're going to be cheaper. Most people who are in this category a.) could be devs and opted not to, and there's a reason for that and/or b.) are the children, cousins, etc. of programmers. We're not stupid: we know we're just as disposable as they're trying to make devs.
> which has been really helpful for having an intuitive sense for what 'language as data' can accomplish and for a strong understanding of the difference between language as data and language as meaning.
100%. I think, intuitively, software developers understand that there's a strong connection here, but most fail to translate that into practice. It always amuses me when someone comments on the triviality of creating CRUD apps. Setting aside the fact that people usually get the mechanics of it wrong (despite it being a solved problem), they overlook the difficulty of producing a good information design.I've developed software in a variety of industries, and I would say maybe 5% of the designs I inherit are well-done and represent the concepts they're trying to model in an elegant, parsimonious way. Rather, most examples are replete with ambiguity, orthogonal concepts smashed together into single elements, and misleading naming and relationships.
This is so true.
And even when there is a well laid out information design, it often is laid out from the wrong point of view. Elegant information design should create a pattern subconsciously enabling people to build a mental model of the tool they're using without realizing they're doing it. But software whose information design works wonderfully from the point of view of a SDE is not going to be approachable to the average user. There are so many tools I've used where I can very clearly see the reasoning behind the decisions and the design and use it well and also be aware I could never explain how they work to the average person.
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