Post

What's my advice, as An Old SWE, given <all this>? As a Jr SWE, I think it is in fact, still useful to force yourself to learn good algorithms and data structures and how databases work (like really) and how to code an inverted index by hand and all Stuff Claude can just Do For You. even in: foOM!

why? well first, the caveat: if you don't want to be a SWE, you don't need this at all, just learn to get good answers out of the models. and: we may not need anywhere near as many high-powered (and high paid) SWEs, soon. I have a prediction that we'll have a highly bimodal SWE distribution:

a smaller (than now) number of absurdly paid software veterans who know the insides of the algorithms, the models, the hardware, and know where the bodies are buried. They will be paid 7fig+ a vastly larger (way more than now) number of slop-cannons, -janitors, and -plumbers, paid fine: 50-100k

why do I predict this: the "Expertise" paper I keep referring back to, by Autor and Thompson, which finds that Jevons Paradox plays out in multiple directions simultaneously in the same profession, as the automation changes what tasks it commoditizes. so *do* you want to be a SWE?

There of course might be more than 2 modes. We could see the rising of a new profession of slopsultancies who help anyone from mom&pop shops up through John Deere and the govt of East Timor get bespoke software shit down with AI, and they'll pay for it. so... be ready to work with *people*, too.

But it might not be terribly fun to work in software anymore, at many (most?) companies. It's an *absolute blast* (IMO) to build software *for fun* now, but being a journeyman SWE, being squeezed through a slop-cannon shaped tube? Doesn't sound super fun, to tell the truth.

I see this reaction a bunch and I find it kinda puzzling tbh — for devs who really deeply love the act of programming, that makes sense, but if programming is the means to an end (a product, a tool, etc), I personally tend to find more pleasure in designing the system vs the details of typing code.

i think this will get capped by token + compute and product acceptance - ”does the product do what I wished it would do”. (Because what people want and what they think they want is not the same). My Mini routinely uses codex to often drive 2-3 unrelated coding lanes in parallel.

I don’t do more because it’s harder to track. By adding a management level it can theoretically become 9. Second management level - 27. Third - 81. This is enough to light up on fire a small bag of money :-) and build a modestly large project in rather short time..

Ah, I understand better now. I don't have experience in big companies (I've basically only ever worked at my own <20 person company) so I haven't had to experience that dynamic. I would say I'm still conservative about how I use it, but gosh does it let me focus more on the parts I enjoy.

yeah, if you can go at your own pace, being able to think about a problem while walking your dog, open up your phone and tell Claude to prototype it, get notified of a link you can click on to try out, tell Claude to fix X, Y, Z, and put your phone back in your jacket while you play fetch? winning!

I'm so old-fashioned that I'm still at the "only programming while physically at the computer" stage 😆 (well, that and our product is macOS-only which makes it less suitable for remote coding). But yeah, since we're completely in control of the pace and the goals, there's so much upside.