Hacker News Reader

Comment by Syntaf | Hacker News Reader

> bad engineers were always a liability

This part of the article hits home for me. With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization. The most egregious of these cases for me is often long tenured engineers who have lost interest in the craft, creating a dangerous combination of having enough merit to ship but not enough interest to make what they ship _good_.

I am still a firm believer in garbage in -> garbage out, AI is only as good as the abstractions and contracts you put in place for it. I don't subscribe to the idea that AI generated code is fundamentally bad, just that people lack the right skills today to wrangle agents into writing good code.

Earlier in the year I put together a talk for my company on what the future of architecture & design means for us in the career, I'm very proud of it and will share here in case folks have their own thoughts to share on the topic: https://youtu.be/SIZrt9Rt05Q?si=W57eirniWmoSFeBu

View on HN

I kind of think the whole "Learn to Code" push of the 2010s was one of the worst things that happened to our industry. Call me a gatekeeper if you want but, we ended up with a lot of people that just can't do the job. The problem is our industry mostly doesn't have any sort of reasonable mentorship or apprenticeship culture, so we've always left it to the engineers to teach themselves. Sink or swim. The problem is that worked when the industry was mostly composed of people that were implicitly interested in this stuff, but the people that just got in it for a paycheck don't have that motivation, and we don't have a good culture of getting them up to speed. So now we have seniors that can barely write a function, much less reason about a complex system.

I remember people used to debate all the time about if there were "10x" engineers or whatever. A few I'm sure, but I think the real problem is we have a lot of 0.1x engineers or worse.

Or it’s just the largely self-taught intrinsically curious autodidact developers and engineers have always been 10x and the “average” person in it for the paycheck is really what a 1xer has always actually been.

I think the industry highly skewed towards the former back in the 90s (and earlier!) when I first entered it. There certainly were vast differences between the best and the worst, but nothing like the gigantic gulf there is today between say a competent kernel driver developer who can get code mainstreamed into Linux vs. a boot camp style disinterested frontend dev who leet coded and brute forced themselves into a FAANG job.

Working closely with other white collar “generic” jobs and the folks who just show up each day and are not interested in the fundamentals at all make me believe this is kind of the baseline for most industries.

Most folks are in it for the money and are happy to just be good enough to not be fired. Since most middle management is utterly incompetent at performance management the results tend to not be great for pretty much the entire corporate white collar industries. A stellar manager though really stands out in such situations, but they are so rare many won’t work for or with one their entire career.

I also have a suspicion that people’s microdistributions of talents is underappreciated. Some people are good architects and average at algorithms. Some people are unusually good at debugging or QA. Some can spin out whole systems at an impressive speed that may not be a great long term fit for the larger system.

And most businesses aren’t managed in a way that’s interested in adapting to the microshapes of personnel.

I think this is one of the beauties of AI -- filling in the gaps to help people make their microtalents shine.

nah, as someone who's driving Claude daily by corporate mandate, AI just shits acceptable mediocrity over everything, and my microtalents don't fit into the org anywhere anymore.

They've been replaced by Markdown files asking Claude to burn tokens on doing something deterministic tools already do faster and better, like checking variable names for typoes (I wish I was making this up).

Who said anything about a corporate context? :)

I'm very much a curious autodidact and there are still people who easily 10x me or more. Someone like Fabrice Bellard is an obvious, extreme example.

In my previous job the entire DevOps team were terminators from the gym. I don't know when or how they were attracted to software, and why. There's so many other jobs they could spend time on and be successful rather than writing yamls.

"One bad programmer can easily create two new jobs a year."

-John Cook

The whole "learn to code" and software bootcamp craze always baffled me. Like what other profession markets themselves as "Hey, our job is so easy that any schmuck off the street can enter the career with 4 months of training." Practically every other job I can think of at a similar salary level has entrance requirements (e.g. grad school admissions exams), extensive and expensive training, a lengthy apprenticeship period and follow on licensure exams.

And more directly, I believe good software engineering is really hard. I think it takes a certain mindset to begin with that many people just do not and will never possess, and it takes years of experience to get a good sense of what works and what doesn't, especially with respect to the entire relationship between code, business, people and teams. Yet we constantly see all this devaluation of the practice of software engineering ("code was always the easy part" - bull-fucking-shit), often times by our own practitioners of the craft.

I mean, the obvious thing is that the "learn to code quick, code bootcamps!" drive was driven by connected people who were, as they are now, attempting to drive down the cost of software development.

Management types really really really loathe software developers for making good money, and have spent decades now jumping at any advertisement that suggests it can undercut the salary of your current crop of engineers.

Devaluing software developers has always been the point. Whether you take the cynical view of "They resent us for being expensive" or the apathetic view of "Capitalism simply wants to eliminate any and every cost by definition"

Exactly this. And now it is AI - I can't wait to see what they will be paying in a few years to those who will be able to clean up the LLM mess.

> Management types really really really loathe software developers for making good money

Of course. I bet you loathe having to spend $70,000 to buy a nice car, too!

> Capitalism simply wants to eliminate any and every cost by definition

You could look up what life was like under Soviet communism. Me, I prefer capitalism.

The irony is that Soviets are famous for falling behind in computing because their 5 year plans failed to appreciate the importance.

And yet the Chinese with their 5 year plans are not falling behind in computing.

Advances in computing can not be pinned just to planned economy/capitalist economy. For example the West Germany computer industry, French computer industry, UK computer industry (with exception of ARM), Japanese computer industry have fallen behind.

I do not believe what the world is calling either of those things (communism or capitalism) now is anything like it was when the USSR was existent in the 1970s.

> Like what other profession markets themselves as "Hey, our job is so easy that any schmuck off the street can enter the career with 4 months of training."

For one, the industry never did professionalize to begin with, certainly not in the way accountants, lawyers etc did. We never had any real body that could certify proficiency, which is what contributed to companies having to resort to leetcode and other such styles of interviewing.

Additionally, it wasn't software engineers doing this, but people looking to cash in on students looking to get a 6-figure job. They were business people, not software engineers.

> We never had any real body that could certify proficiency

Good!

> having to resort to leetcode and other such styles of interviewing

Such test filter out the obvious frauds.

> Such test filter out the obvious frauds.

if you need garbage like leetcode to filter out "obvious frauds" you got a whole lot of problems in your company/team/...

A colleague of mine came to me for advice. He wanted one of those high dollar jobs at a well-known MegaCorp. He knew a leetcode test was used by them. I suggested that his top priority was to study the leetcode books for the next 3 weeks. I told him those three weeks would be the best ROI he'd ever make.

He did so. He aced the test. He got the job with a huge offer. He agreed that the ROI was out of the park!

P.S. I'm curious what your test is for obvious frauds?

> He did so. He aced the test. He got the job with a huge offer. He agreed that the ROI was out of the park!

...and everybody clapped?

I have news for you: passing an online leetcode is now so easy that an AI can do it. If you think you're catching the cheaters, you're just wrong.

Leetcode was always a stupid test of competence, but it was cheap and it had a high true-negative rate, which filtered the riff-raff. That isn't true anymore.

He went in for a monitored taking of the test.

Sure, sure. So now we have the worst of all possible worlds: an expensive interview process where the candidate has to be onsite, and a stupid evaluation mechanism that doesn't at all reflect real-world job requirements. And in exchange for the inconvenience of an in-person interview, the candidate gets treated like a number and is met with a stupid memorization gauntlet that tests a skill that quite literally will never be used again now that we have AI. Sounds great.

Man, there are times when I really hate this industry.

> Man, there are times when I really hate this industry.

Or as I'd like to call it - Wednesday :)

> an expensive interview process where the candidate has to be onsite

I'm sorry, but if I'm doing the hiring, the person who isn't willing to come on site to do an interview will be one of the first people off the list to hire (I mean, unless it is a remote job, and the person is nowhere near the employer, obvious exceptions would apply).

In-person interviewing can be extremely valuable. Will it filter out every bad candidate? No, some people excel at faking it. However it can be a big help in finding a good candidate.

> I'm sorry, but if I'm doing the hiring, the person who isn't willing to come on site to do an interview will be one of the first people off the list to hire

Nobody said anything about not coming on site. That's how we used to do it, in the ancient pre-history of 2019. What I said was that if you bring someone on site only to leetcode them, you deserve not to hire anyone.

The downside, of course, is that you don't have the cheap, dumb pre-filter of a memorization test anymore, so you'll have to figure out a better way to winnow down the applicant pool whom you're willing to pay to bring on site.

Maybe finally software engineering will achieve a level of interview maturity seen in other professional fields...but I doubt it.

If you're willing to travel to be on site, you should be willing to study for the leetcode test.

So if it’s just a shit-test to see if the applicant has enough grit to grind through an arbitrary filter, and not to measure their aptitude, why not use Minecraft or something? Come into our office and show us how long it takes you to kill the End Dragon.

Factorio is a much better test of your design and programming and refectoring ability than Minecraft.

Just fly everyone out in a group and have a big rock-paper-scissors tournament. You can save on airfare.

The only job application process I've ever walked out on in the middle of was 25 years ago, when I was taking a proctored computer skills test and it dinged me for pressing the Windows key rather than moving the cursor to the Start button and clicking it.

So this is a new presentation of an old problem, I guess is the takeaway there.

Doesn't this imply that, had your friend not taken your advice, he would have failed and thus been an "obvious fraud", but a mere 3 weeks transformed him from fraud to competent programmer?

No it means he fooled the interviewers

I don't think he "fooled the interviewers." The point of the story is that he focussed down on what the company's culture decided was important.

It's like cramming for an exam. Yes you can get enough information in your short term memory to pass, even do well. But a year later (or a month) it's all gone. You never really knew it.

True, but it shows a willingness and ability to do the work.

Such recruiting selects for KPI hunters. It is probably bad for an org to select for people that game it rather than doing "what is right".

A dice throw and some chitchat would be better recruiting.

These arguments all sound familiar to the "high stakes testing" debate about the SATs. The tests were unfair, did not measure college readiness, could be gamed, etc.

Then universities dropped the SAT requirements. Even MIT was suckered into dropping them. It was a disaster. It turns out the SATs were a very strong predictor of college success. MIT and others reinstated the SATs.

Ways SAT is more reasonable than typical leetcode interview:

  - you can take it ~3 times and most colleges will give you the best score without penalty
  - you can use your result to apply as many times as you want
  - if you feel stuck you can still get a good score by moving on to the other problems
  - it's administered uniformly across the world
  - you don't need to narrate your thinking while you're still processing information
  - you get an objective score instead of a pass/fail that may be subjective

All true, but still the arguments presented here sound the same as the arguments against SATs and "high stakes testing". I checked a bunch of major software companies, and all of them used leetcode as a screening device. (Google, Microsoft, Nvidia, Meta, Apple, Anthropic)

Cargo cult nonsense.

That's the point we all see, but from context, the story teller apparently thought it shows that leetcode is an effective way to filter frauds.

And it is an effective way.

It's memorization, not understanding. It is not effective.

Memorizing is the first step to understanding. In grade school, one memorizes the alphabet for a good reason.

The leetcode test is just a screening device. Passing it means you then go through the real interviews.

Also, if someone is unwilling to do the work to pass the leetcode test, they likely don't have the ambition to get the high pressure jobs.

If a good candidate can do it in 3 weeks, then a middling one can do it in 10 weeks, and a bad one in 6 months of memorizing. They all pass the screen, but two are lower-quality, and the bad candidate is about as much of a waste of the "real" interview as a total fraud would be.

If the bar is that low, just use an accredited degree, certification, references, or a proctored quiz with questions like "define a linked list in < 3 sentences," and it would be just as effective at filtering the very lowest, while more pleasant for everyone involved and maybe cheaper. Crammable puzzles that don't represent real software engineering don't provide much more value than those filters would.

As if these were high pressure jobs ... or had any rational reason to be high pressure jobs.

High pressure jobs correspond with higher pay.

> they likely don't have the ambition to get the high pressure jobs.

What absolute drivel. I've done plenty of leetcodes. I don't care about writing a qsort algorithm, I know the trade-offs, unless you're working for a FAANG or FAANG-adjacent company, the need to write your own sorting algorithm implementation is probably zero or near zero.

> I don't care about writing a qsort algorithm

That wasn't the point. Would you wash your car before picking up your date for the first time? A dirty car would drive just as well, but your date will figure you don't care about the date going well.

There is difference between being a tidy, kept person and having ambitions. You're conflating the two.

(Edit: Perhaps I should have written in my original comment: I'm nobody's code-producing monkey, I'm not dancing for money or peanuts)

I'm confused. Your example contradicts your point. How is it a good filter for fraud if it can be aced by only studying for 3 weeks?

The frauds and incompetents don't want to do the work.

No but they want the money, so they'll do the bare minimum to get in that door.

All this proves is that BigCo puts a lot of value in these idiotic leetcode tests. It doesn’t imply at all that it gets rid of “obvious frauds”, and in fact seems to suggest the opposite given that someone was able to “ace” the test just by buying a book and studying it for three weeks.

Your friend does not sound like an obvious fraud. He sounds like someone talented and capable of learning.

Let's assume that instead of leetcode, the company had decided that the qualifying test for programmers would be sketching a vase of flowers (about as relevant as leetcode for commercial programming).

Your friend would have spent three weeks practicing their sketching, right? And they would have made a decent drawing at the interview. And that would have the exact same ROI as spending those weeks on practicing leetcode.

The point is not that studying leetcode is good ROI. The point is that large orgs are testing for something that isn't relevant to commercial coding.

What do you use to narrow down 100 candidates to 2?

Well, in this case, sketching a vase of flowers.

This is classic Streetlight Effect [0]. Just because it's easy to test leetcode, and it appears to have something vaguely to do with coding, it gets used.

Like I said in other posts, I would use the "pick a bug and fix it" method. But I'd also screen down from 100 candidates to ~20 or so before getting into technical interviews.

And, again, I don't think leetcode will scale well to 100 interviews either. You need technical staff in that interview room, and if you subject your team to 100 technical interviews using leetcode they're not going to be happy about it.

[0] https://en.wikipedia.org/wiki/Streetlight_effect

> P.S. I'm curious what your test is for obvious frauds?

I interview them and ask questions! Seems good so far.

We pull in everyone from the Team who is available at interview time into a room with a big a$$ whiteboard and we talked to the candidate. We work through the problem, either current one we are working on or recent one that we completed or we have few "golden ones" we like to have a chat about. Afterwards the Team decides whether or not they want to continue solving problems with this candidate or not.

Exactly what we do on day-to-day basis is what we do when we are trying to grow the team. I would guess that 85% of my team would fail leetcode-style screening right now (which is good cause it is garbage)

I took an online technical interview recently where there was a check-box they made you click before every section, promising you would not use AI to solve the test for you.

After they rejected me I had to point out that their test is selecting for the cheaters.

I would view skeptically any testee who turned in a perfect score.

When you check in at the airport, the machine asks you to certify you are not carrying banned items. Of course, one wanting to break the law and carry banned items would certify it. The purpose is that if you get caught with the banned items, and you certified you did not, it's an extra charge they can paste you with.

Once we carried dangerous (not banned) items and selected yes and the first action by the attendant was to come over and say we selected yes by mistake and she selected no for us

Honestly this is purely because time is money. Its a blunt instrument that is surprisingly effective. Unfortunately, it also removes a fair amount of competent people too, that simply don't think/operate in a leetcode mindset.

I'm a little hesitant to accept the notion that people are really great engineers but cannot handle basic algorithms and data structures.

> Such test filter out the obvious frauds.

I know everyone says that, but I really don't think that they do a good job filtering out shitty engineers. I have worked with plenty of incompetent people who managed to get past the leetcode challenge but are wholly unable to do anything useful involving software.

I feel like what leetcode primarily tests is "does this person know how to use a hashmap in a way that you shouldn't actually use it because you lose cache locality", and that's literally all they test.

You might be surprised at how incompetent some engineers are. They get filtered out with the leetcode test. Of course, it doesn't filter them all out, and that's why there's a followup interview round.

I have given dozens of interviews at big companies and small companies and medium companies so I am not speaking out of my ass. These leetcode tests are not good filters, nothing is “surprising” me.

Generally they are just wanky bullshit from some middle manager’s slightly-incorrect recollection of their first “data structures and algorithms” class, and the solution is almost invariably “use a hashmap” or “use a minheap”, even though the scope of these problems is usually so small that in a real implementation you would probably do in a more naive big-O-unfriendly fashion because constant factors are going to matter more. Let’s ignore the fact that most of the people who are designing these leetcode problems haven’t actually done any actual optimization and optimization is virtually never part of the job you’re interviewing for.

I don’t know what the “correct” way to interview is, but I am fairly certain that the masturbatory leetcode problem is not correct.

Agree 100%. The problem is that leetcode problems are nothing like the actual practice of writing commercial code. Writing good commercial code is about keeping things as simple as possible, as clean as possible, as readable as possible. Use libraries for the complex stuff, don't invent complex solutions. And, as you say, use standard data structures whenever possible. Don't optimise early. Don't fix performance bottlenecks unless you actually know they're causing a problem in production. And even then, throwing more hardware at the problem is often better than making the codebase more complex. None of this is anywhere near what leetcode tests.

The best interview method I've seen is getting the candidate to work for a day or two alongside the team. The second-best was picking a bug from the current repo and working it out together with the candidate, getting them (or in this case, me) to work out why the bug was happening, work out a solution, code up the solution, and commit it back to the repo as a PR.

> The best interview method I've seen is getting the candidate to work for a day or two alongside the team.

That doesn't scale - what if you have 100 applicants? The leetcode will narrow down the field.

Yeah, I've only seen it work for the last few applicants, but it did work really well.

The "pick a bug and fix it" scales better, though still not to 100 applicants.

Though I'd say putting 100 people through leetcode interviews would still break a talent acquisition process. I've been part of this kind of process before (though with arbitrary code problems not leetcode) and it was hell for the entire team going through it. Nothing got done for weeks while they were dragged into endless tech interviews.

I haven't heard of any interview method that wasn't roundly condemned on HN.

> the solution is almost invariably “use a hashmap” or “use a minheap”

And you wouldn't be wasting your time on candidates who:

1. don't know what a hashmap or minheap is

2. didn't bother to study up before the interview

> I haven't heard of any interview method that wasn't roundly condemned on HN.

Sure, but none have been more thoroughly condemned (and correctly) than the idiotic leetcode whiteboard challenges.

> And you wouldn't be wasting your time on candidates who: 1. don't know what a hashmap or minheap is 2. didn't bother to study up before the interview

OR, and hear me out, you actively filter out people who know how stupid these problems are and know that big-O is misleading for a lot of these problems. You're selection-biasing towards people who are going to regurgitate bad answers, and the middle manager conducting the interviews is usually too incompetent to understand what a "constant factor" is.

I've been rejected for jobs specifically because I mention that using a hashmap for these things will likely be slower than a naive implementation, even when the I get the problem "right" in the way that they wanted it.

Now we could argue that I'm a bad candidate in general, but (at the risk of sounding cocky) I likely do understand data structures and algorithms better than most mediocre engineers conducting the interview, but because most engineers are pretty uninspired and have never asked "why" for anything in their lives, they will "correct" me. They will assume that me providing nuance is a lack of understanding on my end.

> A quick check shows that Google, Microsoft, Nvidia, Meta, Apple, Anthropic all do leetcode testing.

Yep, can confirm. I've worked at a FAANG, and they did indeed leetcode testing for the interview. It turns out that big corporations are fully capable of doing stupid things in perpetuity.

I appreciate that, but my whole life I've heard again and again and again that "high stakes testing" does not work. I've heard all the arguments. But the bottom line is the testing is an effective filter.

After all, would you get on a jetliner piloted by a handsome fellow with a firm handshake who failed to pass all the written tests, but really knows how to fly?

It's not that hard to study the leetcode books. Doesn't the prize of a top shelf salary make it worthwhile? It's a good investment in your career.

Person that can fly every time - Diana Barnato Walker flew 80 types of aircraft before finally getting a commercial flying licence.

I'm sure she passed the written tests.

My dad flew 23 airplane types - single engine, multi engine, 2 wings, 1 wing, bombers, fighters, jets, and piston engines. In his papers I found some of the written exams he had to pass to get certified to fly them. Just "knowing how to fly" is a good way to get yourself killed.

There was one incident where his F-86 Saber jet had its engine quit. He was faced with the choice of bailing out or gliding back to base. Having passed the written test, he knew how to calculate the best gliding angle, the best velocity, the best configuration of the airplane, took into account the wind, the altitude, and the weight, and figured he could bring the bird in. Which he did, safely.

All that boring stuff that requires study and it has to reside in your brain.

> It's not that hard to study the leetcode books. Doesn't the prize of a top shelf salary make it worthwhile? It's a good investment in your career

You are arguing two different points here.

I am, generally speaking, reasonably good at the leetcode stuff, because I agree that it’s not that hard to get good at it. As a practical thing for society as it currently is, sure, studying up on the idiotic leetcode stuff is a relatively good investment.

But that pays little bearing on whether leetcode is a good test, and whether it should be something that we are using as a metric. I am arguing that it’s a dumb test and we should stop doing it at a systemic level.

> But that pays little bearing on whether leetcode is a good test, and whether it should be something that we are using as a metric. I am arguing that it’s a dumb test and we should stop doing it at a systemic level.

Would you feel differently if you owned the company, and you'd be paying the salary for months for someone who talked a good game but was incompetent?

We are at an impasse here, because I do not accept the premise that the leetcode tests realistically gauge competency or serve as an effective filter.

In your hypothetical the implication is that the leetcode would be effective at removing people who “talked a big game but are incompetent”. I disagree with that.

I could be wrong about leetcode, but for me to realistically engage with your argument would be a tacit agreement with the premise, and I cannot engage with that in good faith.

Not really. I'm typically less concerned with how much someone costs than I am with how much time they'll wind up wasting, but I'll admit that this perspective is colored by my experience having run a kitchen in a restaurant.

The secondary challenge in the kitchen (beyond the challenge of hiring someone who'll simply show up when scheduled, ha) is hiring someone who has a genuine interest in cooking as a craft. It's true that being a line cook isn't especially glamorous work, but I absolutely need someone who has enough love for it that they're proud to show off what they can cook when it isn't my menu.

I interviewed someone who made nothing but scrambled eggs, hash browns, and grits, but they were cooked and seasoned to absolute perfection. This individual was one of my slower line cooks starting out, but the fact they had the drive to learn this level of cooking was good enough for me to invest time in them to improve that speed.

I look for the same love for the craft in software. Literally everyone who's worth their salt has something they've worked on that they will happily show off, or some technique (like, e.g., abusing generics to implement monads in Ada and why this is more interesting than the typical approach using interfaces), or some pet data structure (e.g., critical bit trees and what their pathologies look like vis-à-vis hash tables) that they try to shoehorn into everything, or some bit of code they've read (e.g., SQLite and the Tcl interpreter) that left a lasting impression on their practice.

There's a snag though: being worth one's salt only starts at being able to cut code. I need to witness a candidate write about and walk me through that very technical aspect of the craft that they want to show off.

Assessing craft requires interviewers who understand craft, and the literal only reasons I can see for using LeetCode are when the interviewer is themselves not an expert in the domain (perhaps for reasons of scale, among others), the interviewer cannot (or will not) engage in heavily technical conversation with a candidate, or the job is plainly not about writing software that works.

The trouble with untrained craftsmen is they are not aware of what they do not know about the craft. For example, I recall working on a codebase where the craftsman used bubblesorts in multiple places, evidently unaware of qsort(). I fixed that, and the program got a lot faster.

The role of an engineering degree is to teach you the things you should know about engineering. And an engineer should understand data structures and algorithms.

Forgive me. Did I advocate for not understanding data structures and algorithms?

This is a "better watch what you ask for" situation.

Accountants and lawyers effectively controlled their customers. You can't use accounting or legal work for business purposes without those things coming from licensed practitioners. And they have no other use than to work with regulatory agencies (loosely speaking such as courts, IRS, etc).

If you lock down software development too hard, people will write their own. It's easier to hack something together that solves a specific problem than to write general purpose software that can be sold. And eventually the licensed programmers will break their own rules, for instance by using un-approved computers, languages, and development tools, in order to compete with software smuggled in from overseas.

> For one, the industry never did professionalize to begin with, certainly not in the way accountants, lawyers etc did.

"Professionalize" is an interesting way to frame this. As Milton Friedman argued, occupational licensure is almost always pursued by the practitioners rather than consumers. The licensing boards are mostly run by practicing lawyers and CPAs, so you have practicing lawyers and CPAs determining who can compete with them. So what you get are cartel-like bodies.

Most people don't know the histories of how these professions came to be what they are today in the US. If you take 15 minutes to read up on it, it leaves little doubt what the intentions are and how much consumers have been screwed.

> We never had any real body that could certify proficiency, which is what contributed to companies having to resort to leetcode and other such styles of interviewing.

Except that basically everyone in the industry knows that leetcode doesn't test real-world proficiency. It's equally dubious to believe that some sort of body (ostensibly run by practicing software developers) would be able to come up with a means to certify proficiency.

Incidentally, many of the outfits "looking to cash in on students looking to get a 6-figure job" placed a heavy emphasis on teaching their students how to interview, not how to be proficient.

I, for one, am extremely happy that electricians and plumbers have to be licensed.

Sure, but are you happy about the requirements of that licensing? Requirements that have continually expanded to require more "experience" over the years. I know in my state it was originally 1 year of experience or completion of a tech diploma and then you had to take the licensing exam. Now it is 5 years of experience and a diploma can count for one of those years. Which of course has pushed prices to insane levels.

Are you happy that the license is much less a license to do the work and much more of a license to hire unlicensed people to do all the work.

And lastly are you happy that private equity can "hire" the licensed professional to hire 100s more unlicensed people to run a huge company with a catchy slogan?

These are valid things to be unhappy about and should be corrected. But if the implication is 'licensing has issues so we'd be better off without' then I'm not on board. It reads like one of those 'if we can't have a 100% perfect solution, then we should do nothing' arguments. Licensing does have merits and I think currently they outweigh the drawbacks. If we can make licensing better by fixing some issues, then absolutely let's do that.

What would you propose as an alternative? Some concerns I have are: 1) my house not burning down due to electrical fire and 2) not exploding due to natural gas leak.

Milton Friedman was a libertarian crank. I'm a consumer and I'm quite happy that doctors and lawyers are licensed.

What advantage do you, the consumer, see to licensing over certification?

Liability for the professional that knows if they botch a job in horrendous fashion that they could lose the ability to continue practicing their profession.

What's the practical difference between that and certificate revocation? Maybe you can still technically do the job, but who is going to work with you when you are not certified?

But it's not certain you would even be able to continue to do the job if you botched things in a horrendous fashion. There is precedent for individuals being barred from working in certain industries if it is considered necessary to protect the public, even when those industries are unlicensed. Granted, it is rare and a lot more complicated than where licenses are found, but if you've botched things in a horrendous fashion anything is possible.

Au contraire, mon frere. Milton Friedman looks prophetic in 2026, especially his book "Free to Choose."

You can have a regime that regulates who can practice medicine and law without having it run through private organizations that function like a cartel.

It's a little more-complicated in that one of the major bottlenecks comes not from the private organizations per se, but from Congress--though I wouldn't want to underestimate the effect of lobbying.

> In the Balanced Budget Act of 1997, Congress capped the number of residency positions that Medicare would fund at each teaching hospital at 1996 levels.

https://thehill.com/opinion/healthcare/5550556-residency-cap...

Yes, and the AMA, along with other associations, supported the cap, issuing a statement that claimed "compelling evidence that the United States is on the verge of a serious oversupply of physicians."

You can also buy from companies that hire licensed software engineers if you want to? The main thing that would stop people patronising licensed individuals is if there was no obvious skill gap between a licensed and unlicensed practitioner that justifies the price gap.

People don't need a government body to tell them to check for credentials. If people care they can ask (I had to give a copy of my degree certificate thingo to my employer a job or two ago, they cared that I was qualified). The whole and only point of mandating licensing is to raise prices for consumers.

EDIT

Just while I'm thinking about it, the law is expected to be easy enough for everyone to follow while simultaneously there is is an absurd legal fiction that only a licensed professional can talk sensibly about the law. It is internally inconsistent that lawyers would require a license.

That's the absurd libertarian logic. I'm supposed to be able to assess the credibility of whatever credentials I'm shown? Despite having no expertise in the field?

The government can sponsor a credential if that helps you? The libertarian position isn't that the government can't have a position on what the standard should be, just that people who think there is a more cost-effective standard should be allowed to use them.

Much like how you can hire a programmer based on that you think their work is good or they made a lot of money programming, rather than just limiting yourself to the people who went to some fancy university. If you don't feel competent at assessing programmer quality then you can exclusively hire ex-Google or MIT programmers or what have you and pay an absurd premium for the most credentialed US developers. But most people don't need to do that.

I'm getting work experience to become a licensed software engineer, which is possible in my jurisdiction (Ontario).

Rarely does anybody care. I heard it's useful for safety-critical stuff but have never met anyone who has made use of the designation.

> Milton Friedman was a libertarian crank.

That's not an argument.

> I'm quite happy that doctors and lawyers are licensed.

But you're not happy that you have to pay for 10 years of medical or law school for a broken bone or employment contract.

The government could license a gradient of qualifications to better match skills with services. (as they reluctantly started to do in medicine due to pressure to economize MDs.)

> It's equally dubious to believe that some sort of body (ostensibly run by practicing software developers) would be able to come up with a means to certify proficiency.

I very much mostly agree with you, but I did take the Google Cloud Associate exam a year and a half ago and honestly it felt like a pretty rigorous exam. I definitely could not have passed that exam if I was incompetent in my knowledge of cloud and IT. Exams like these, I think, might become more mainstream in certifying developers in my opinion. (Though whether this is desirable is another question.)

The question is whether you then want there to be a legal licensing requirement that requires an individual to hold certification to work as a software developer.

Maybe treat it like other professions and have a specific title be protected?

Is it really possible to do that? I think if we were to go down this avenue we would need to consider titles other than software engineer.

yes, it's possible. That's why there's no Software "Engineers" without degrees in Quebec.

Maybe I wasn’t clear enough. The engineering requirements to be a competent software engineer in HFT a Genomics vary wildly. If completing a computer science degree and maybe a Msc in computer science is the answer fair enough, but I don’t think those credentials are enough to label someone a competent Software Engineer.

What could be a generic framework? Do you have any reference to standards?

the requirements to be a dentist are vastly different than that of a brain surgeon.

Yet, both have to have medical degrees in order to be called doctors.

That you specialise after the fact doesn't really mean what you imply, not everyone who becomes a doctor can do brain surgery.

But in this case the title is irrelevant. The purpose of licensing is to define who is allowed to offer their services and actually practice.

If I can build you a web application as a "web developer" but not "software engineer", you haven't accomplished anything by restricting a title. It's basically certification, similar to the Project Management Professional (PMP) title, which you can only use if you've achieved PMB certification. But people without this certification can still work in project management roles.

Companies don't care about proficiency, the only qualities which matter are ambition, presentation, flexibility, and marketability. Customers and investors buy a good story, not a functional product.

> Like what other profession markets themselves as "Hey, our job is so easy that any schmuck off the street can enter the career with 4 months of training."

- Submarines.[1]

- Homeland Security [2]

[1] https://www.buildsubmarines.com/

[2] https://www.dhs.gov/homeland-security-careers

Ok, but consider if we had professionalized in, say, the late 90s.

Would we be insisting everyone writes bad 90s style OO code because that's the professional standard? How do you have standards when the field is still figuring itself out?

“The good thing about standards is that there’s so many to choose from”.

It also changes every year or two. Plumbing, for instance, hasn't changed much in decades.

Have we solidified a little, though? I don't want to overindex on my particular biases given my particular age, but I feel like we ironed out the problems with object-oriented programming and reached a rough consensus about a functional/object-oriented hybrid where nobody likes too much inheritance.

Are we at a stable spot now or am I just overindexing on my personal understanding?

> I feel like we ironed out the problems with object-oriented programming and reached a rough consensus about a functional/object-oriented hybrid where nobody likes too much inheritance.

Python and NodeJS are some of your most popular tools and newborn programmers just started checks watch today and don't know what OOP is. They can write hello world if they download 500MB of packages first. Good luck.

Oh look, a new electron app!

I’m pretty sure that the IEEE tried that, and it never took off.

Regulatory bodies generally need a raison d’etre to exist (like people will die, or go to jail, if we screw up). They also need to provide clear benefits (to the licensees), like medical practice, or CPA licenses.

I don’t think that ever worked, for software. Companies have been hiring anyone that can spell “algorithm,” for a couple of decades, and making money, hand over fist.

In my case, I’m sort of grateful. I have no “on paper” qualifications (high school dropout, with a GED), yet managed to have a long career, working with some pretty heavy-duty pros.

Good code apparent doesn't matter. Most software doesn't have real repurcussions for being bad. You just get a shittier oncall which doesn't seem to matter to some people

The people who have to fix the mess and the people who created it are two different groups of people.

And both are well compensated for their work.

Not necessarily...

It's called suicidal empathy. It manifests in many domains.

Four MONTHS?!

Most of the dolts I interviewed in the UK had a 6 week bootcamp behind them and called themselves "JavaScript Experts". No joke.

I was once commissioned to teach such a "bootcamp". It was a 4-months duration but 1 day a week. So something like 2-4 weeks total duration. I found out that the students were promised that this was enough to get them a job doing software development and were disappointed when I told them it wasn't. So towards the end, I took some time to explain what was missing and why it will take MUCH longer to even just learn the basics. The organizers were not happy at all that I did that.

To be fair, there were a bunch of students that did listen and worked hard on their assignments and projects and went on to integrate what they learned into their chosen profession and progressed in their jobs. I was very proud of that bunch.

Surprisingly, I wasn't asked by the organizers to teach again. It also didn't help that midway I was asked to switch from teaching web development to machine learning and they didn't really like it when I said "but those are two very different things".

Yes the whole bootcamp ring was a con job. Shame on them.

A large amount of programmers are hired just building crud apps. Display data from a database and write it back with a validation. Etc.

There is very little innovation going on. And most companies do everything they can to stick to standard patterns, technologies etc where all the risk is removed and known in advance.

Often "good" programmers are worse - they over complicate the architecture, go off on tangents, try to solve problems the business didn't ask for either etc.

So bootcamps filled a need.

Out of every single reason given for why the bootcamp era was justified the only one I believe is that there was so much focus on it because bigger players wanted to flood the market with cheap supply and drive salaries downward.

This is not any different with offshoring before, and AI now.

You say it like it's a bad thing.

True, and the explanations about "solving big problems" are each engineer's personal brand and justification for having a job. I'm sure some of those people exist, but they probably aren't the ones doing it rote on forums.

> they over complicate the architecture, go off on tangents, try to solve problems the business didn't ask for either etc.

because they've been bitten plenty times before by business telling them that certain requirements are not needed, just to be told 2 weeks later that they are...

I've said "code was always the easy part" recently so I should probably explain where I'm coming from. I think the practice of software engineering includes that "understanding of the relationship between code, business, people and teams" you mention, which essentially boils down to the ability to skillfully design a system - regardless of whether it's a big cloud-based web application or a tiny cli tool for use within a team.

To me, the difficult parts of software engineering are in the design. That's where you're defining the problem you're trying to solve, picking what technology to build upon, what kind of architecture you're planning on implementing, ruling out what does/doesn't make sense, taking input from stakeholders, and finding the balance between price and performance. Once all that is covered I generally have a good high-level mental map of a system's structure, and actually writing the code to bring those ideas to life truly is the easier part.

That being said, I still believe writing good code is a skill that is only learned through experience/the practice of actually writing code. And that experience is necessary for reviewing code - regardless of whether the code you're reviewing was written by humans or AI.

Kind of like baking. Putting it in the oven was always the easy part. But combining the right ingredients in the right ratios is necessary, and much more difficult than the putting-it-in-the-oven part. And even then, it takes experience to know when something needs to be pulled early or left in longer. Because ovens are non-deterministic.

> To me, the difficult parts of software engineering are in the design. That's where you're defining the problem you're trying to solve, picking what technology to build upon, what kind of architecture you're planning on implementing, ruling out what does/doesn't make sense, taking input from stakeholders, and finding the balance between price and performance.

This is exactly why I became a PM [1]. I wanted to do "harder" things that had bigger scope than I could do as "just an engineer", and the kind of roles that offer that scope within engineering end up being thin on the ground. Unfortunately, what I've generally found is that being a technical PM is a good way to have people try to knife you constantly. Most PMs are technically illiterate MBA types, and carry a deep grudge against anyone who gives the technology any consideration. They're also good at politics, and want you to die. On the other side of the coin, because most PMs are technically illiterate, engineers often instinctively reject you like a tumor. To overcome this, you need to appeal to the technology, which puts more of a target on your back from the other PMs...

Anyway, my point is that this is all very sad, because you're describing is exactly what a PM does -- but with technical competence. And because of the way the industry is structured, the people who can do that either get shuffled into people management, or reach a rapid career ceiling when so-called "architecture" roles aren't available.

There's this pervasive myth that you cannot be good at technology while also prioritizing the business needs, but usually what this really means is that the "business types" bias in one direction exclusively, and treat the technology as the enemy. It's why so many companies are AI-maxxing now -- the promise of replacing the expensive nerds is the eternal flame for the MBA.

[1] well, that, plus after being a founder, people were suddenly willing to hire me to be a PM...

"Product Manager, your job is to find the mix of features which is fast and cheap and good, and then browbeat the Engineers into implementing them. Don't just parrot me their excuses, fix it!"

Sure, I'm not saying design is easy either, but even if you have detailed user requirements, a fully spec'ed out UI, and some general technical requirements, translating that to (working) code is still really, really difficult.

I used to do a lot of interviews in my previous career, and I can't tell you the number of times I'd be interviewing someone who could talk a good game, but the second it got to writing code, if the world depended on them being able to write a simple correct loop, we'd all be dead. I know everyone shits on Lee code, and I agree the "brain teaser-y" nature of it doesn't often match real world development, but often times I'd tell folks almost exactly what the code needed to do, in English, and they still couldn't translate that to sensible code.

Last side note, when this topic comes up I feel some folks are really biking it down to the absurd "typing was never the hard part". Well, yeah, sure. But actually writing correct, maintainable, well-structured code is (was?) very much at least one of the hard parts.

> Last side note, when this topic comes up I feel some folks are really biking it down to the absurd "typing was never the hard part

Compared to the other parts. If you can do the problem solving part and the design part,code is easy. If you can't write code, I strongly doubt your ability to do the first two.

People talking good game always try to keep it high level and full of jargon. Once you ask them to explain part of the design, you'll see the inconsistency and holes of what they are saying very easily.

"Talk is cheap, show me the code" - Linus

Your analogy to baking makes no sense. At best, compiling would be like putting a cake in the oven. Making the cake is coding.

> ovens are non-deterministic

Uhhh… no? Modulo calibration drift, they will get to and hold a commanded temperature for as long as you tell them to. The ambient humidity and temperature in your house / bakery may differ - which can absolutely affect some foods - but ovens are pretty binary.

the people with the hiring and budget aren't technical people, usually are not engineers or have that background, and are incentivized to cut costs. It's not that complex, good engineering is expensive and somewhat of a cost center.

It's the same behavior around consulting firms, code boot camps, and now AI.

My experience:

You can learn a new language, in a couple of weeks, if you’re experienced.

But you’re gonna have a heavy accent.

Learning the language without an accent, takes years, no matter how good you are.

There’s always stories of apocryphal John Henry types, but I’ve never actually met one, and I’ve worked with some pretty sharp characters.

> The whole "learn to code" and software bootcamp craze always baffled me.

Why? While the rest of your comment explains why the plan failed, it seems like it should be pretty obvious why business would try to attract an increased supply. Hint: It puts downward pressure on price. Same reason they are trying again with AI.

> every other job I can think of at a similar salary level has entrance requirements'

Yes, the artificial restrictions on supply is how those careers have similar salaries. Other occupations moved to have restrictions so that they could have high salaries. Software never felt the need to do the same because the natural market propped up salaries just the same, but we'll see how long that lasts now before software practitioners panic and clammer for restrictions to prop salaries back up like the others. AI does actually seem to be making inroads where "learn to code" failed.

Granted, like as suggested at the top of this, the upper class of software engineers who have the necessary reputation and prestige to drive software towards being a licensed profession are not feeling the same pinch that the middle class is feeling, so that is going to make it hard to see restrictions come to fruition even now. When the upper class of software engineers start becoming afraid of shrinking incomes, that's when software engineering will start needing a license.

> Hint: It puts downward pressure on price. Same reason they are trying again with AI.

You say it like it's a bad thing.

About occupational licensing for software: it's also a uniquely global market, so I'm not sure how any one economy moving ahead with occupational licensing would work, unless they also restricted what software you can import or use in the cloud.

> About occupational licensing for software: it's also a uniquely global market, so I'm not sure how any one economy moving ahead with occupational licensing would work, unless they also restricted what software you can import or use in the cloud.

Relatively easily, tbh. Just create a regulation that requires either the country's standards or equivalent ones to be used in the creation of any software sold to people/businesses in the country/region.

Want to get standards-compliant garbage? That's how you get standards-compliant garbage.

I don't really, but at least there would be standards. Like, the massive amount of hacks and breaches we've seen in the past ten years indicate that something needs to happen.

There are plenty of standards. For example, the GDPR is a well known one (mostly because everyone is tired of pressing "Accept cookies" buttons).

But standards are always going to be slow to react. Even in mature industries like construction the standards are still trying to find completeness. The standards today are way different than they were a decade ago and they'll be way different ten years from now.

And building construction is something that we've been doing for almost as long as humans have existed. Those standards have been built up over centuries and millennia. Software is gaining some maturity, but still a young pup in the grand scheme of things, so it hasn't had much time to even get through the easy standards.

> You say it like it's a bad thing.

What to you suggests it is said as a bad thing? It reads neutrally to me.

A shit load of jobs could be taught to a useful level with a 4 month bootcamp. It's just that it's very easy to set up, scale, and monitor results for coding. It's the same with AI, AI isn't particularly good at coding compared to how good it could be at other tasks. It's just that by nature coding is easy to iterate, test, and verify. I've certainly seen AI produce impressive code that works but the actual quality of the code is abysmal.

> Practically every other job I can think of at a similar salary level has entrance requirements (e.g. grad school admissions exams), extensive and expensive training, a lengthy apprenticeship period and follow on licensure exams.

It's the great strength of software engineering as a profession that formal barriers to entry are so low.

You are right that good engineering is hard, and many people who went to these bootcamps didn't make it. But that doesn't mean we need more bureaucracy and paperwork to keep people out.

> Like what other profession markets themselves as "Hey, our job is so easy that any schmuck off the street can enter the career with 4 months of training."

Any profession with scammers, con artists, and snake-oil sellers?

It might generalize to tech rather just engineering. The same pitch was made for marketing and SEO roles, designers, product managers to varying degrees.

> Yet we constantly see all this devaluation of the practice of software engineering ("code was always the easy part" - bull-fucking-shit)

Whenever I've used this phrase or seen other people use this phrase it's never been in the context of software engineering. It's always been in the context of literally just spitting out code that a compiler will accept. Believe it or not, a lot of students in CS cohorts have significant struggles fighting the compiler because they just don't understand the language they're programming in and are slow to become proficient (if they ever do). Thus, a lot of people have this idea that writing code, and I mean literally just spitting out something that compiles and runs is hard.

Doing that is indeed quite easy today. That's what we mean by "coding was always the easy part".

Writing code that actually scales into something bigger and is constructed in a way that meets requirements and is flexible? That's a whole different ball game. That's software engineering.

I use a variation of it. "Typing the code in was never the hard part. The work is in figuring out what you want to describe"

> And more directly, I believe good software engineering is really hard.

It really is, if there's one sentiment that's remained consistent in me over time it's awe at how harsh of a mistress software is. As good as coding agents are, it still routinely dismantles them in astonishing ways. It's like complexity is the natural state to which all systems want to settle.

Software is a machine with thousands or millions of moving parts. It's always complicated, and complexity is the natural state of complicated things.

> Call me a gatekeeper if you want but, we ended up with a lot of people that just can't do the job.

Increasingly I am of the opinion that software engineering aught to be a licensed profession, similar to civil engineers, medical professionals, or lawyers. A board of peers to hold you accountable and a licence that can be revoked at any time. Additionally, legislation could be written to require such licensed individuals in safety critical roles.

I suspect the debate around AI assistance tools would be quite different if there was greater accountability for programmers and a constant threat of losing a licence.

If you brick millions of machines impacting hospitals and airports, you should probably never be trusted to write code again.

https://en.wikipedia.org/wiki/2024_CrowdStrike-related_IT_ou...

> software engineering aught to be a licensed profession

Only in certain industries, where outcomes can hurt people in any way. There's opportunity to engineer software in just about every industry, but I don't think a widget vendor that wants to connect to a WMS should be compelled to hire licensed anything. Of course, licensed engineers should cost more too.

It's not licensed per se, but in certain areas of the defense industry, one is restricted to using the 'DOD approved' subset of C++. Coders that know how to be productive within those constraints (and can pass clearance) are much more rare than your average code monkey

Some pieces of software are classified as a "medical device" and require certain processes to be in place.

Credentialing lowers the skill floor and increase every other kind of friction.

Civil engineering or medicine is hardly a desirable career model to follow.

Btw doctors make mistakes that kill people all the time. It’s a top 3 cause of death in the US AND they often keep their jobs.

>>doctors make mistakes that kill people all the time

Yes, but they make a lot FEWER such mistakes than would people who could not pass the exams and maintain a license.

The standard is not perfection; the standard is as good as practical and better than if nothing were done. Medical licensing definitely meets both of those criteria. Unless you are arguing that anyone who takes a ten-week "Medical Bootcamp" is ready to be a surgeon you would trust to operate on you or your children?

Would you also be happy to commute to work over a bridge designed by someone with a 10-wk bootcamp in civil engineering?

You have it exactly backwards — Credentialing RAISES the skill floor. It does not raise it to perfection, and "Certificates" in the computing industry are a joke, but real medical or engineering credentials certainly raise the floor higher than the software floor

> they make a lot FEWER such mistakes than would people who could not pass the exams and maintain a license.

I don’t know if that’s true. More schooling does not mean more trustworthy or careful doctors. And I suspect some negative trait selection.

Milton Friedman wrote a PhD dissertation on the topic of medicine that I invite you to take a look at.

> than if nothing were done.

The alternative is not to invite people who have no experience to build bridges or perform surgeries.

There are no credentials to work at Google. But you’ll find very skilled and capable people running large projects.

Investors want capable people. Those people are vetted through their reputation in their professional circles.

> Would you also be happy to commute to work over a bridge designed by someone with a 10-wk bootcamp in civil engineering?

No. But I would like to drive over bridges from people with 30 years of bridge building experience over a 4-7 year degree.

If you live in Europe you drive over bridges built without credentials all the time.

> Credentialing RAISES the skill floor.

Correct. That’s my mistake.

The point is if cut off the bottom 20th percentile the field doesn’t get much better. Those people aren’t trusted leaders anyway.

You do however lose a significant amount of upside. Including countless top performers from non traditional backgrounds, which is characteristic of computer hackers.

You can maybe argue that the general public, unlike a corporation is not capable of vetting their own doctor, so the government classified those options for them. And that’s reasonable. But that does not apply at all to software engineers who don’t solicit public work.

I have all the traditional credentials and this is not a projection of my own career.

> The alternative is not to invite people who have no experience to build bridges or perform surgeries.

You state this so confidently, like every person who walks through the door to interview will be 100% honest about their level of experience.

Have you ever interviewed? Nobody _wants_ a software engineer on their team who is awful.

Sometimes they slip through the cracks for a variety of reasons.

Cold call job interviews are primarily for people early in their career to get established in the field. You don’t hire someone that way to lead the Golden Gate Bridge.

How do you think companies hire for key roles like CEOs?

I appreciate your positivity. However it is difficult to reconcile your argument with the reality that executives at tech companies frequently behave in ways that satisfy the investors but clearly do not produce good results for the people using their technology. Indeed in numerous cases today the technology is openly hostile to its own users' interests. The regulations are there to protect the users (or customers or clients or patients). If anything they are there to prevent protecting the profit margins of the businesses - because hiring people to pump up the profits is often in conflict with the other objective.

What would credentialing software engineers do to curtail leadership incentive problems?

Hardware technology jobs have some of these credentials and are part of that system.

What would credentialing software engineers do to curtail leadership incentive problems?

The same as in other regulated professions. It would give the people on the front line who can see the consequences of the corner cutting an effective right to say "No, we're not doing this user hostile thing". This would be a significant barrier because it wouldn't be legal to ship software without the required professional approval and the professionals would be heavily incentivised not to sign off any corner cutting because they would be personally and professionally responsible for any adverse consequences if they did.

That’s not how these systems work in reality. I’m actually an extreme pessimist.

What actually happens is that you as an engineer become paid to frame the desired leadership goals in compliant terms.

It’s similar to how lawyers and regulatory compliance rarely change the product. They change how the product is talked about and framed for the purpose of regulation.

This skill among engineers is highly sought after in large companies with political organizations and greater encouraging it changes the composition of the workforce.

Top civil engineers don’t design buildings.

In the physical engineering teams I've worked with the culture you just described is not what happens at all. There are always some people who seemingly live to circumvent the intention of rules lurking around the edges of regulated industries. But my own experience has been that real engineers very much value real engineering - it's often why they got into the field in the first place - and will push back hard against and if necessary refuse to sign off anything they consider inappropriate for the job. They won't be impressed at all by someone's big title and even bigger budget while they're exercising that professional judgement either. Some of these people have had pretty stellar careers so I think it's safe to say their professional conduct hasn't damaged them with their employers or clients.

> They won't be impressed at all by someone's big title and even bigger budget while they're exercising that professional judgement either. Some of these people have had pretty stellar careers so I think it's safe to say their professional conduct hasn't damaged them with their employers or clients.

It really depends on the status of the profession in society and the company. I'd expect lots of software organisations to fire a bunch of people looking for people pleasers until this becomes an accepted part of the business approach.

I'd expect lots of software organisations to fire a bunch of people looking for people pleasers until this becomes an accepted part of the business approach.

No doubt. Imposing this kind of professional standards to regulate an industry as rich as tech would never work unless the penalties for cutting corners involved making the offending organisations significantly less rich very quickly. They would need to be taught a very clear lesson that hiring people pleasers had become an expensive mistake.

As I commented elsewhere - the problem then becomes who gets to define what the proper path is. For example destroying companies because they chose not to follow the latest sage advice from anyone who once signed the Agile Manifesto does not seem like a good way to promote better quality software to me. And yet it seems highly likely that those are the kinds of people who would initially be engaged as "experts" by those seeking to establish the regulatory environment.

I don't want people like them. I want the quiet, unassuming developer you've never heard of because they're the principal engineer of a team you've also never heard of that has been developing life saving medical equipment without a single significant failure in a live environment for the 15 years since their first device went into use at a local hospital. Get me those people to write the rules - starting with what is acceptable practice when developing software that really needs to work and letting the people who know how to achieve the most challenging results figure out how to tone everything down for applications where imperfections might be more acceptable - and then we can talk about whether regulating software development effectively is now a viable proposition.

> As I commented elsewhere - the problem then becomes who gets to define what the proper path is. For example destroying companies because they chose not to follow the latest sage advice from anyone who once signed the Agile Manifesto does not seem like a good way to promote better quality software to me. And yet it seems highly likely that those are the kinds of people who would initially be engaged as "experts" by those seeking to establish the regulatory environment.

This is why any such regulation is likely to end up in a much better state if it's driven by actual practitioners. However, given how many software people are wildly against this, it seems unlikely to happen and so we'll end up in the less good state you note above.

It looks like we agree here. I too think any useful regulation should be specified primarily by experienced practitioners who have been achieving demonstrably good outcomes. And I too think that in reality it would mostly likely be a very different type of person who got to write the rules - which is why I don't think our industry is ready for that kind of regulation and I believe introducing it now would be counterproductive.

> circumvent the intention of rules lurking around the edges of regulated industries

That’s not what I said,

For every human activity there is an underlying reality and there is a social component of how it’s framed or talked about.

Regulatory compliance is 90% social and 10% reality.

So a focus on compliance means engineers spend less of their time on reality.

> They won't be impressed at all by someone's big title and even bigger budget while they're exercising that professional judgement either

Correct. But they do care about their management chain.

Imagine a new grad telling their boss “we aren’t going to build it like that because I learned X in school”. They have the same credentials!

Regulatory compliance is 90% social and 10% reality.

Again our experiences are on opposite ends of the spectrum. For safety issues in particular getting an engineer to sign off some plan when they will be accountable for that authority later is often easiest if you simply design the thing properly.

I have certainly seen compliance become a box-ticking exercise in other contexts but usually this seems to happen when the professionals involved were not personally responsible for their own decisions.

Imagine a new grad telling their boss “we aren’t going to build it like that because I learned X in school”. They have the same credentials!

We appear to live in different realities on this one too. In my reality new grads are not the people signing off major decisions in regulated industries and no-one would seriously suggest that a new grad's degree was an equivalent credential to the years of demonstrable professional experience and peer review that are typically required to reach a level of professional qualification where someone does have the authority to sign off those big decisions. Getting an undergraduate degree in a subject like engineering or medicine or law is just a foot in the door. The real work starts afterwards.

I think we are in full agreement!

> For safety issues in particular getting an engineer to sign off some plan when they will be accountable for that authority later is often easiest if you simply design the thing properly.

That's exactly right. An engineer aims to build a safe and reliable product (not because the credentials tell him to)! The regulatory myth is that all products are death machines until being redeemed.

That's why I say it's 90% social. The engineer builds a reasonable product. With regulation they do the same, but now they need to do work to frame that same work in regulatory terms.

Real fixes are made. The value isn't 0, but it comes at that cost.

> no-one would seriously suggest that a new grad's degree was an equivalent credential to the years of demonstrable professional experience

That's exactly what I'm saying! Professional experience and reputation within the field is what:

1. gives someone influence and credibility. 2. results in safe and reliable engineering projects.

And note that those are actually informal defined qualifications. It's NOT the credential!

So trying to add credentials to software is an attempt to bump the quality of new grads and has little to no impact on the quality of engineering leadership. As you said, the recent undergrads already lack power and influence, and the credential is simply the bare minimum to participate.

> It’s similar to how lawyers and regulatory compliance rarely change the product. They change how the product is talked about and framed for the purpose of regulation.

This is true, and basically what tends to happen is that if the Head of some compliance function (e.g. internal audit) is causing problems for the business, then they are replaced with someone who won't cause such problems.

It's still better than nothing. Like, software basically runs our society now, so either software professionals get together on this, or regulations will be imposed on us, and they will be much worse than what we'd get in the first option.

> It's still better than nothing.

Once again the alternative is not nothing. The most important factor is that they are stakeholders in a project with influence. That is the reality right now, even without credentials.

> Once again the alternative is not nothing.

Can you help me understand what the alternative is?

Yes the framing above is “business people don’t listen to engineers but if they had a credential they would legally be forced to”.

And I think both are false.

The top engineers on a project are collaborators with leaders in other areas like marketing, sales, IT, legal, etc. And all those have influence on a project. A business person who says “fuck what my engineer says” is not a good leader and won’t have that group’s trust or support. They all want to work together.

So by that process engineering has a seat of influence.

That exists without credentials, and credentials are not what gets you in that seat. Reputation and experience are.

Business leaders don’t do everything engineering says. They also don’t do everything the lawyers say! And having an additional legal backing would change some of these engineering conversation, but not fundamentally.

More credentialing and requirements would do plenty to curtail leadership incentive problems. First, as the sibling points out, it gives the licensed engineer a solid ground to stand on when refusing a stupid leadership order — "I'm not going to lose my license for that stupid idea", and a serious incentive to do so, as well as solid job prospects if he does get canned for it (because there's a limited pool of credentialed engineers).

You glibly say "More schooling does not mean more trustworthy or careful doctors.". Yet the schooling and credentialing clearly cuts off huge numbers of would-be doctors who never pass the exams, never graduate med school, or never even get into med school, or decide it is too difficult in the first place. In the software realm, those people just go to some boot camp and they're off to the races...

Another huge aspect of credentialing is required ongoing education, which REQUIRES physicians and engineers to take updated continuing education just to maintain their license. This again continuously improves the talent pool.

And, if your main concern is that they be "more trustworthy or careful", credentialing also helps that by finding the worst, least trustworthy and careful and cancelling their license, so they are NOT doctors anymore. The untrustworthy or careless SWE just gets a new job to ruin stuff elsewhere, probably taking one from the actual good engineer because their talent is not engineering, but bullshitting.

> it gives the licensed engineer a solid ground to stand on when refusing a stupid leadership order

I disagree to the extent to which this is real leverage. It changes the language and approach, but not the outcome, Ask a civil engineer the degree to which they can fight their leadership on these grounds.

> clearly cuts off huge numbers of would-be doctors who never pass the exams

Yes the fallacy is that more exclusive is better. You don’t understand the traits you select for.

> those people just go to some boot camp and they're off to the races

I don’t see any kids who just got off a boot camp running large software projects. Does this happen at your workplace? Why not?

> This again continuously improves the talent pool.

I just disagree to the extent to which the talent actually increases.

The people who excel already learn and study all time.

This slightly raises the floor by forcing the least curious person to be exposed to some PowerPoints and videos.

> The untrustworthy or careless SWE just gets a new job to ruin stuff elsewhere

They can only ruin the extent of responsibility and scope given to a new hire with no reputation.

> least trustworthy and careful and cancelling their license

Once again you assume the system works as stated. I think it actually selects against those who are bad at avoiding responsibility and not legally savvy.

The image that comes to mind is someone who made a mistake, cares a ton about medicine, and hates the organizational administration.

Wow you have a relentlessly unrealistic view of things.

>>Ask a civil engineer the degree to which they can fight their leadership on these grounds. Both civil engineers and doctors both can and absolutely do refuse to sign off on unsafe situations.

That does not mean they detect them 100% of the time, or never cave to pressure, but they absolutely do. We just never hear about the incidents that didn't happen because a doctor or engineer forced the right solution or no action — precisely because nothing newsworthy happened. We DO hear about the ones that did happen, Therac-25, Mars Climate Orbiter loss, Cloudflare outage, it is endless

>>I think it actually selects against those who are bad at avoiding responsibility and not legally savvy.

You might think that, but clearly you have never read even the summaries of cases where doctors lost their licenses. Hint: it was not some mistake that could have been covered up by better schmoozing. If anything, the system is too lenient.

The rest isn't even worth the bytes to respond; just handwaving an attitude. There are very good arguments to not have licensing on software engineering but you are not making them

> Wow you have a relentlessly unrealistic view of things.

I noticed from your response that you didn’t really refute the claims, but that suggesting that systems don’t achieve their stated goal gives you a distasteful feeling.

> We just never hear about the incidents that didn't happen because a doctor or engineer forced the right solution or no action

And the same is true of software. I and my peers tell my bosses ideas are bad all the time. We don’t need a credential to do that. And the credential is not what gave us trust with that decision maker.

> If anything, the system is too lenient.

Correct. Bad doctors continue to keep their jobs all their time.

So that’s my point. What is the criteria that distinguishes those cases? Both doctors made a medical error. Which one gets off and which one gets fired? The doctor who is more focused on medicine is likely the one less skilled at navigating the legal problem.

The doctors making mistakes and keeping their jobs are a pathological minority that is reinforced by their credential giving them authority to operate.

> I don’t know if that’s true. More schooling does not mean more trustworthy or careful doctors. And I suspect some negative trait selection.

The medical boards are well aware of this, which is why the standards are far more than just about having more schooling.

I am familiar with Friendman's dissertation, and while the economic claims it makes are solid, it isn't a take down about the medical impact of the boards. It really doesn't say one thing or another about them. Let's put it this way: if you are going to inflate the cost of a service, it's hard if the quality of the service is terrible and easily replicated by someone else.

The problem with making programming a regulated profession is who gets to define the regulations. You are probably imagining that it would be expert developers with a track record of success. I would bet on it being the people who write lots of blog posts and books about programming and give lots of conference keynotes - whether or not those people have any evidence base to support their advocated policies or any personal track record of delivering good software.

> You are probably imagining that it would be expert developers with a track record of success.

I'll admit I am unsure how such individuals would be chosen. I imagine it would be prudent to learn what processes are used by other licensed professions when choosing such individuals.

> who write lots of blog posts and books about programming and give lots of conference keynotes

I do not think people who write blog posts and give conference keynotes should be awarded with roles that regulate the profession because they write blog posts and give keynotes. I would hope that any regulation is evidence driven.

> I would hope that any regulation is evidence driven.

Have you found existing regulation in any field that's evidence-driven?

My impression is that regulation is not made in a way that has much to do with evidence, but I would be delighted to be shown evidence I'm wrong.

Aviation comes to mind. Most aviation regulations exist because people died.

It's hardly a perfect system, but the problem is mostly that it's too conservative and risk aware, making it difficult to impossible to innovate and ignoring the risk this creates. (The world's most popular light aircraft is the 1950s-vintage Cessna 172, mostly because it's impossibly slow and costly to get a reasonably priced modern competitor certified.)

Thank you for the data point. I guess I had overlooked that.

Have you never heard the adage that regulations are written in blood?

Plenty of regulations in many many fields are evidence based.

Sure, many are not.

But to make such a blanket statement is absurd.

> I'll admit I am unsure how such individuals would be chosen. I imagine it would be prudent to learn what processes are used by other licensed professions when choosing such individuals.

Licensing organizations disproportionately attract people who enjoy "administrating" over "doing."

Other those who prioritize profits over providing good customer service.

People who enjoy administrating rarely think you’re the “customer” lol.

What you have to remember is that the people who decide who to appoint into these roles are another step removed from the problem domain. They will have no programming experience, or the ability to evaluate programming experience. They will try and rely on metrics or some "data-driven" approach to deciding who to appoint.

What kind of data will they look towards? Here, we have a precedent from frantically points to absolutely everywhere around us. So the people with "engagement" and "reputation", i.e. they gushed on their blog and farmed engagement, will be exactly who gets appointed to make the decisions.

The important part of the professional certification like PE or MD is the liability that comes with it, which means that the professional has a lot more agency. A construction firm or hospital can't really force their professionals to do anything because the consequence is criminal prosecution (and a lot of legal liability for the employer).

Bring a software engineer into a courtroom as an expert witness, and the jury's eyes will glaze over. Bring in the PE who told their firm not to cut that corner, and the hammer comes down hard.

Even if the certification for software engineers starts as barebones as knowing what WASP is, it still provides an avenue for the feedback mechanism to work (the rules "written in blood"), so that the entire industry can study and learn from what happened, instead of this mess we have now, the peak of which is postmortem blog posts. Even now we have plenty of examples of regulatory frameworks where the regulations adapt to the field like the FDA where you've got a huge spectrum ranging from diagnostics to medical devices of which where are many classes, and drugs where every clinical trial can be tailored to the exact nature of the disease.

I have been a professional software developer for decades and worked in several roles where quality and security were at a premium but I have no idea what you mean by WASP. And yet you described it as "barebones" - an interesting illustration of the problem here. Real engineers have many years seeing the hard way what actually works. In software we don't have that kind of consistency and shared understanding of how to reliably get good results yet.

In my experience, good software engineers are often better "engineers" than those working in more physical disciplines, because they get a lot more practice. But traditional engineers have a far better culture when it comes to testing and validation. Since the cycle time is longer, and the cost of mistakes is higher, analysis and testing are generally baked in from the beginning. In software, it's easier to skip that stuff. But software engineers who do get indoctrinated into that culture learn most of the same lessons that traditional engineers do (i.e. how can a component be tested and maintained? what makes for a good design?) and the speed of development means they get more exposure to those types of challenges in general.

In my experience this works both ways too. Good engineers working on physical projects have picked up on some of the useful practices that good software developers have adopted for maintaining progress in the face of ambiguous requirements until they can be clarified and allowing as much flexibility as possible without necessarily compromising quality in the meantime. I believe these relationships can be summarised as something like "Good people keep open minds and learn from what has worked well for others".

The problem for regulating software development is still who gets to formally determine who the "good" people are. This kind of thing should clearly be objective and evidence-based but what useful evidence do we have available?

In physical engineering disciplines there are often clearly evident problems if something was built without being adequately specified by the responsible engineers. In a disastrous case a bridge might literally fall down but you're also going to see that a bridge wasn't designed properly if it's distorting in ways it shouldn't under loads that it should be able to support. There are lots of experienced engineers who have proven records specifying buildings or planes or ships that need to not break using established and peer reviewed techniques.

In software we can all agree catastrophic failures that result in loss of life or half the Internet going down are obviously bad. For something controlling a life-saving medical device or the launch authorisation system for the nuclear missiles we can probably all agree that the answer to what quality level we want in the software is "the best quality we can achieve". But those systems have unusually serious consequences if anything ever goes wrong and probably also very high development budgets that can justify such an extreme position on quality. In general we don't have clearly defined levels of software where different trade-offs between cost and risks and other factors might be considered reasonable and acceptable. Nor do we have well tested and universally accepted standards for how to reliably achieve a specified quality level.

> The problem for regulating software development is still who gets to formally determine who the "good" people are. This kind of thing should clearly be objective and evidence-based but what useful evidence do we have available?

There is zero useful evidence because there is no one to collect it.

The Institution of Civil Engineers was founded in 1818, after decades of random civil engineering societies in Britain doing the exact same thing we are now (running around like chickens with their heads cut off). It wasn't until after the ICE's Royal Charter a decade later that civil engineering began to get really systematized into the "real engineering" we know today and that charter effectively established them as a regulatory body that allowed that to happen.

There is zero useful evidence because there is no one to collect it.

I'm not sure that is entirely true. There have certainly been a few people who have attempted to study what did or didn't work in industrial settings - either pure academics or people working in industrial research labs. But I agree that currently we have nowhere near enough data to form robust conclusions about almost anything in this field and I think this is the strongest argument that the industry is not ready for any kind of licensing and regulation regime.

Wasp the defunct PL group from washington.edu or wasp as in owasp or something else entirely?

Once I was talking about a video game and mentioned a global variable holding a reference to the player character and got the eyes wide open horrified look.

Those people would be writing the regulations.

I am a FP nerd and I approve this message

This sounds like a terrible idea. Do people need license to draw a picture or write a song? Why would we restrict other creative work in this way?

>Why would we restrict other creative work in this way?

Because it isn't creative work. Software underpins payment processors, medical services, emergency alerts, infrastructure. In the UK not long ago a ransomware attack took the healthcare system offline and surgeries had to be postponed. in 2021 the Colonial Pipeline attack took 50% of the US East Coast's oil supply offline. The entire German train system died a few weeks ago for half a day because of a software bug.

People's entire communication is in digital services, all of their private data, the economy grinds to a halt or national security is impacted monthly now by either deliberate attacks or just bugs.

Then license healthcare systems, payment processors, etc. Not humans

you license both. When you go in for surgery your hospital is accredited and the surgeon who operates on you is licensed. I don't even understand what you're trying to argue, you're okay with being operated on by a guy they found on craigslist as long as the hospital has a license? We should bridges let bridges be built by engineers who took a few courses on Khan Academy?

Of course professionals themselves need to be licensed, how else is any company supposed to have any confidence in who they employ or any legal security?

We weren't talking about doctors, but about coders writing utility apps being a different thing than payment processors

People doing "mechanical engineering" in their garage don't need licenses either. I don't love the licensing idea either, but that's not a good argument.

> software engineering aught to be a licensed profession, similar to civil engineers, medical professionals, or lawyers.

My experience with civil engineers and lawyers is many of them aren't worth spit. Licensing is not a magical cert that proves competence.

BTW, if you hire a lawyer in WA state, be sure to ask if they passed the bar. The state has been licensing lawyers who don't pass it.

Competence is tangential. They're happy to allow the idiots, so long as they aren't so stupid it makes the organization or the government look bad.

The way licensing fundamentally works is industry basically strikes a bargain with government to it's benefit. Government lets the licensing organization run a supply cartel and collect protection money (dues, test fees, whatever) so long as they promise to enforce (low) minimum standards along the way. Government gives licensees favorable treatment in court (statutory limits to liability, licensed professionals opinions are more equal than average peasants, etc, etc), etc. And all this stands so long as they do whatever the government's rules say (to the detriment of the customers). And of course the professionals make money hand over fist (or at least more than they're worth) in the process because the licensing organization constrains supply.

Society gets just enough scraps to provide the political will to get it done and keep it rolling (the low minimum standards).

...or you wind up with people that know the same answers to the same questions; great for a job repeatedly answering the same questions, pointless for jobs requiring original approaches, beyond a certain point. In law, you'd better know the law... but there are so many ways to work in tech, many with no appropriate titles, many pockets of it which would not survive a certification path.

It's probably worth distinguishing software engineering from the ability to program. Programming is a skill that is similar to reading and writing in that it's a type of literacy, and it shares a common theme with literacy in that even though most of us can read and write, not everyone is good at it. Professions that leverage that unit of literacy build on top of it, and take literacy as a given.

For instance, a lawyer spends most of their time reading and writing, but no one would ever say "you can read and write? Have a crack on our legal team". It's a particular type of writing, and the writing is really a means to an end. This is a distinction that is lost in software development. Every engineering discipline now learns programming, but the ability to write code shouldn't be a license to write software in the same way that knowing how to read and write doesn't just grant you the ability to join a legal team and start writing contracts.

I think a more effective way of enforcing the licensing would be adding a cyber insurance requirement to sell software or internet services commercially to some threshold of users. Insurers could give a prime rate to licensed developers and offer a service to have their own engineers certify software from firms without credentials for a higher rate.

Direct licensing requirements from the state are prone to abuse via regulatory capture. Big or entrenched players can give to politicians who’ll change the rules in their favor, setting who needs a license and who can get one.

The profit maximizing incentive for insurance is a double edged sword, but if there’s a government backed insurer that just does the prime rate for licensed developers, the commercial market can build off that and fill in the gaps.

If you need a special license and insurance to drive a commercial truck on public roadways, why not the same for commercial traffic on the public internet? A good way to drive adoption from nontechnical folks could be something like the lock icon in the browser for TLS. Issue a domain cert for certified software, you can go to their website and confirm they are compliant right away. People are free to publish and use non-certified apps, they just won’t unless they have a reason to trust them.

Licensing is not a substitute for hiring competent people that actually care about the quality of their work, and then giving them the time, resources, and support they actually need to do it.

Government involvement almost always just makes the problem worse, not better. There is a place for control in some areas (medical, military applications, etc), but I think broad-sweeping regulation would do far more damage than good.

Eh, I've never been a fan of licensing simply because software engineering is a vast field with huge differences in the impact your work might have.

Like sure, if you're writing software for medical professionals, or lawyers, or aviation companies then I can see that being something you'd want people licensed for. A major bug in a pacemaker or plane's autopilot system is a huge deal that could injure or kill a lot of people.

At the same time though, a lot of software engineering/programming work is extremely low stakes, and I think expecting that to be licensed would be kinda ridiculous. Having someone need to be licensed to create a small business WordPress site, or local desktop software to solve a personal need, or most video games in general feels kind of absurd. Do people need to be licensed to make say, Minecraft mods or hack a game from the 80s?

The difference with the legal and medical industry is that if someone is incompetent or screws up in those fields, there are almost certainly going to be negative, if not dire consequences for those involved. If someone screws up in tech, then there may be dire consequences in some industries/sub-fields, or no/positive consequences in others.

But how many of those bootcamp people actually went on to get software jobs? One of the big criticisms of that whole phenomenon that I recall is that people were graduating them and then were unable or unprepared to actually get a job in the industry?

So how many people "learned to code" and then ended up back on non-software related careers?

I think that changed around the time COVID hit and offer was highly surpassed by demand. Lots of overhiring during those days.

Just because you CAN code doesn’t mean you SHOULD code.

I tried to get a job back then but never could. Its wild to read to me that it was 'sink or swim' back then. Nobody wanted to hire a junior. So I never became a SWE and it was my passion since 14. Now I just don't care and too much time has passed.

When? The specific years and locations matter greatly, there's always been a boom and bust aspect to it.

I understand your point and ultimately agree with the systemic problems here.

And, as a "Learn to Code" guy who's had a successful and interesting career filled with self-study and continual improvement, I'll call you a gatekeeper.

I'm a bootcamp graduate, 10 years of experience. My mentor is a bootcamp graduate. I've worked with him for most of my career and he is a very experienced systems engineer, often mentoring and coaching folks with masters degrees in CS. Together, with a lot of other team members of course, with him being the principal engineer, we've exited multiple companies. We were both fortunate to have mentors earlier in our careers.

I've interviewed many bootcamp graduates. You're right. Many of them can't do the job. We don't hire those guys. But that begs the question - what companies are hiring incompetent people?

If compensation for software devs was in line with other profession there wouldn't be bootcamps. The problem is it's an easy job that gets paid a ton of money

> we ended up with a lot of people that just can't do the job

I don't think this is attributable to the 'learn to code' push; I know many fine engineers who came through boot camps, and many, many poor ones who came in the 'official' way.

The problem is that we trained too many people, many of them without the aptitude, not how we trained them.

Maybe you weren't around in the 2000 dot com bubble burst era, but the same thing happened then. Companies hired anyone they could because talent was scarce. A friend of mine who was a substitute teacher got a job as a sysadmin, and he was texting me constantly because he had no clue how to do his job, asking me all kinds of questions. That pretty much ended our friendship when I told him I wasn't going to do his job for him.

There was a time before "learn to code" when it was even more wide open. My mom taught programming at a community college in the early 80s, after learning it herself a year prior. Many of her students were working manufacturing or clerical jobs. They were able to get programming jobs at Ford's or GM after a year of my mom's class. (At first, they taught PL/1 because it was what they used at Ford's, then switched to Pascal in line with the colleges in the area). My mom did try to teach good practices, but there's only so much you can do in a year.

At my workplace, the earliest programmers were a combination of self-taught and people with real CS degrees. The CS people wrote the OS and languages for an in house minicomputer. The apps were written by people with app experience, mostly scientists. And there were a few odd characters like the secretary who learned programming because it was quicker to fix bugs herself than get clarification from the engineers.

Learn to code wasn't just about careers though. It was also about individual empowerment. Everything goes through computers, and having the power to understand that domain increases agency.

For a lot of people, they have no need to ship production grade software that scales to babel. But a custom script that solves an immediate business need is a common thing.

I think that aim is more important than the harm learn to code might have caused our profession. And for similar reasons, I feel the agency AI brings to individuals is something that shouldn't be discounted either. No idea what the total calculus on cost benefits turns out to be, but I would hope this benefit is not missed.

"Programming is too important to be left to the programmers." -- apologies to Clemenceau

This.

For a certain class of professionals, slowness is a kind of superpower able to restrain their damage. LLMs have turned off those guardrails.

On one hand, I'm not fully surprised -- LLMs are powerful tools, but of course they can be misused. On the other hand, I'm impressed by how fast things are deteriorating in some shops. At my job they got encouraged, over-confident even, to finally do some long-awaited major overhaul in the code base. I'm genuinely concerned about our ability to continue maintaining this mess in the mid and long-term.

I agree completely and have said similar. Yet this is what happens when supply tries to catch up to demand. There were not enough software chefs to keep up with the patrons appetites. We started minting more cooks. Instead of Culinary Institute of America candidates and autodidacts, we got what the customers wanted: people who would just churn out more.

Blame the patrons for demanding more with little care to the quality.

I mostly gave up on software development roles in business when the vast majority of developers and, particularly management and executives, made clear that they couldn't give a fuck about craftsmanship. It was just about shipping, good, bad or otherwise.

AI in software development predates on that appetite for MORE at any cost. When the business doesn't really care about quality, because, let's be honest, most don't, this is what you get. You get massive volumes of garbage.

Is the problem the self taught programmers or the people who would have gone the finance or law route in university doing CS and then not caring?

> The problem is that worked when the industry was mostly composed of people that were implicitly interested in this stuff, but the people that just got in it for a paycheck don't have that motivation

That is a problem whenever people do things for money. It suggests that a big problem with our society is people are encouraged (in some cases effectively forced) to want money too much.

Eh, not all software engineering is made equal.

To work on engineering real time communications systems, banking systems, or transit systems and low level infrastructure, you definitely need some chops. To design and build out core network infra at the web giants, chops also certainly required.

To build out a basic crud app, pwa, or the next feature in the massive products that major companies ship? Yes you need some understanding but it really isn't that difficult or onerous. TBH if you ask me the profession always had a problem where the term "engineer" was a tad over applied. The boot camps are mostly churning out people who can write basic apps, not (hopefully) anyone being placed into a a senior IC and systems design role.

As someone who works in fintech, I assumed the same; alas, I was wrong.

Previously it felt like there was a lot more nerds who were in it for the interest instead of today for the career path and fast track higher salaries.

2010’s was when more traditional CS courses also started moving from traditional languages and content to JS etc…following industry demand.

A lot of tech conferences were pure tech. Now a lot of them are agile, soft skills based, introverted nerds pushed out.

It’s certainly a different place from the 2010’s.

I've uncovered some -2x engineers recently - who cause long-term problems with their changes that more than one person has to unravel. It's usually comes as a surprise, some going back to look at who approved MRs, and loud ranting and cursing as you find a murder trail of laziness or incompetence. It's breathtaking. I'd trust some people with AI as much as I'd trust myself operating a machete - a tool best left to someone else.

> whole "Learn to Code" push of the 2010s was one of the worst things that happened to our industry

I would also throw in the toxic positivity and gas lighting sorrounding that. We got a lot of churn on "we have to be nice to everyone" and fears that people weren't "being included." I'm not saying you have to go all Linus on everyone, but it really catered to those who didn't want to learn a lot of the details or were resistent to testing their own code.

One thing is for certain... the "learn to code" movement was a smug, pompous, and deeply unsympathetic response by privileged knowledge workers toward blue collar workers who experienced mass unemployment a couple times in the last decade, beginning in 2008, and it really pissed off a lot of the people it was directed at. I know a lot of people who did move out of trade and service jobs and learn to code, but very very few who made it far enough to keep those jobs. The guys in the trades are having the last laugh now, and there's no sympathy for coders whose jobs are being taken by AI... largely as a result of the attutide that came with that prescription.

I have yet to know anyone who’s lost their job to AI. On the contrary, because juniors are being hired less, the ladder on a well-paying job in knowledge work is essentially being pulled up (by the Csuite mind you).

So unfortunately, for those like me who spent a decade in the trades, saw that it could destroy your body by your 40s and decided I’d like to not have that happen to me the number of exits into knowledge work is shrinking.

Not to sound bleak, but you're describing what things looked like to me 18 months ago. The C-suite's gonna keep pulling that ladder up until the loss of layers of knowledge come back to bite them in the ass in six years. If it ever does.

I'm not the best person to talk to, because I'm not a salaried programmer for some corporation, and I'm not looking for a job from a startup or something. I'm in a unique position where I wrote a suite of proprietary software that clients pay for that they would have a hard time replicating or migrating away from, even if AI helped them. Lucky me, I happened to get into a specialized industry and start writing code for it 20 years ago, and I kept all the data and code logic in my own silos and never shared anything with anyone. So I am somewhat protected because it would cost 3x more to replace what I wrote than to just pay me for the rest of my life to maintain what I built.

By the way, I started this software in my 20s when my body was already being destroyed by physical jobs. I started it while I was driving a taxi and waiting tables at the same time. I learned by reading books in my cab. I don't think that's an option for people anymore.

My best friend worked for a massive multinational similar to Salesforce and he ran a team of 60 people under him until last year. He was not AI-proof. They laid off everyone on his team except for him and 3 helpers, and told him to use AI to do everything else. After awhile, they laid him off too. After interviewing for a couple months, he found a new job, and his job is to manage two people running AIs. It was a 30% pay cut and he feels lucky to have it.

Under any external hierarchy, where I didn't have this lifetime of private code and clients in my pocket, his job would have been way, way above mine. I would have been one of the 60 people laid off.

Okay, so I'm going to say something about this "knowledge work" thing because I've known a lot of people who took courses and transitioned to it from the trades. Almost all of them did not get decent jobs. One of them was a bartender who just somehow got it. This was around 2018. Her husband works in construction. She just sat down and it clicked, she learned to write javascript in 3 months. I'd sit at her bar and tell her what to improve and she'd write it down and memorize it. In six months she was writing like a native, and she got a job at [huge multinational retail company] working on their website. And somehow she survived round after round of layoffs to keep going and become the only person left on her team. I'm immensely proud of her. And she will still probably lose her job in the next six months.

But my ex-girlfriend tried to learn to code at exactly the same time, and it went nowhere. Just didn't make sense to her.

So that's why I wouldn't recommend it. Honestly, if I didn't have the little pile of code I was sitting on that pays my bills, I would go to school to be a plumber or air conditioning specialist, or to repair helicopters or be a car mechanic. That's basically what I do anyway, I just do it in code instead of parts. At one time, what I did was equivalent to building custom cars and engines, only in code. At this point, fixing a car would be more satisfying. No one's paying to build their hot rod in code anymore, that's all being thrown at AI. And the rest of the jobs suck.

I've seen a lot of Wordpress theme jockies in my country call themselves engineers and demand very high fees.. yet half of them do not know how the db works, when/how/when not to use queues, do not care about security ("the client will pay us to upgrade the site to be more secure"), do not know anything about real compilers, type safety etc. In my mind they were a scourge because we are not at the same level at all yet some of them earned more money/status than my peers. Some cases they have caused harm but nothing ever happened to them. So yeah, good the frog is being boiled now. Same with consultancies. They've been milking the system for 20 years, selling "dev hours". They are all getting eaten alive and I'm here for it.

“learn to code- everyone should code-“ pushes always seemed like a way of trying to suppress wages for tech workers.

I’m not in it for the money, and that I can make a good (better than most) living from it is just pure luck and I am genuinely thankful.

But there are lots of people in it only for the money, and they will be very disappointed when it dries up, because the #1 thing these bosses want is for us to have less leverage.. They want it even more than they want revenue.

The issue was that it was "learn to code" and not "learn to program", as if the only thing you needed was a month of training and then you were just as good as someone with 20 years of experience.

It's similar to why there's hundreds of books about learning the basics of a language, but comparatively few books about good software architecture/design

> Call me a gatekeeper if you want but, we ended up with a lot of people that just can't do the job.

The vast majority! I think I've come across 1 or 2 competent engineers in 20+ years. It's a miracle that software works, ever. Increasingly, it doesn't.

"learn to code" is just learning to read and write in a software language. But the industry expected those with basic literacy to perform any specialised task related to reading and writing.

Meanwhile, software engineering courses taught it as abstractions and algorithms, and electronic engineering taught control flow on bare metal.

No one, it appears, is taught design or system architecture outside the context of operating systems. Even requirements engineer is a rare job title.

As more complexity has fallen into the domain of software, nobody has been given responsibility for it. The way we treat junior developers now would be like expecting a carpenter or bricklayer to figure out building architechure and structural engineering, without formal training.

This 100%. I just requested a hackathon for performance improvement (might be wasted effort).

We are pushing tons of code and now our CPU usage has grown exponentially over the past year because the bad engineers just ship whatever Claude gives them and do not think about the consequences.

Our biggest consumer of CPU right now is HTTP connection churn because engineers are creating new clients every request we handle. If the engineers would just think for a second, push back on Claude, even Claude would tell them this is bad. But they don't... Platform engineering is now 10x harder with terrible engineers and unlimited code machines.

Don't even get me started on ffmpeg usage, engineers act like the resources are unlimited.

Exactly. For most of my career, bad engineers (or juniors who were earnestly learning) would struggle to even create output that compiled, let alone ran. And it would take them a long time to implement something poorly. So the blast radius from their incompetence would be limited. Today, a bad engineer can churn out ten thousand lines of garbage that actually compiles and runs, before my first cup of coffee. If not on a tight leash, they'll sink the whole codebase or inundate every senior person with garbage code review requests. The blast radius is unlimited!

> Today, a bad engineer can churn out ten thousand lines of garbage that actually compiles and runs, before my first cup of coffee. If not on a tight leash, they'll sink the whole codebase or inundate every senior person with garbage code review requests. The blast radius is unlimited!

The term for that is "10x AI engineer." Anyone who has anything negative to say about such people is just jealous of their insane productivity and speed.

If your company has bad engineers cranking out 10,000 line PRs your engineering culture and product was already bad, I guarantee it.

It's not the whole culture and product, it's specific teams that do it. And trying to push back on teams that are "producing" is not a simple task.

Sadly AI also amplifies both the good and the bad managers and tech leads. If you have managers who fail to set a clear direction or tech leads who fail to define a good framework for developers to operate within then AI just means the poorly directed developer effort goes further in the wrong direction faster. Meanwhile teams with well-specified goals and better structure and processes can exploit the benefits of AI tools much more effectively.

In the before times, a small dedicated team could hold back against bad engineering culture and intentional enshittification. Now the balance has changed.

> or most of my career, bad engineers (or juniors who were earnestly learning) would struggle to even create output that compiled, let alone ran

Really? I have never seen that. The expectation was that you could create the code that compiled on day one.

> We are pushing tons of code and now our CPU usage has grown exponentially over the past year because the bad engineers just ship whatever Claude gives them and do not think about the consequences.

Sometimes this can be a death by a thousand cuts. Any individual change may not impact performance to a noticeable degree but when they're pumping out a 10x increase in commits it can be a slow decline.

Just look at how they're merging ~300 commits a week into bun.

https://github.com/oven-sh/bun/graphs/commit-activity

That really sounds like the kind of people who will complain in university about being forced to study calculus.

Natural consequence: Then they never grasped the concept of computational complexity.

O(n) Vs O(n²)? They have n, what's the difference? Python is fast enough. The only thing that matters is shipping features fast! Features! Our competitor will have this next week, we need to write code fast, everything else is a matter of adding more compute, which we will pay with revenue!

computational complexity was never part of calculus. Calculus is the math of continuous change.

I should add that text to the rant at my last paragraph!

You don’t learn Big-O in Calculus because it requires CS algorithmic concepts.

But the core question of “how does this behave as N -> \infty?” is asymptotic behavior (ie: limits) which were developed for calculus and are very much part of the foundational calculus canon.

> You don’t learn Big-O in Calculus because it requires CS algorithmic concepts

Big O notation was invented in 1894.

Big O notation predates Computational Complexity. It was originally used to guesstimate asymptotic behavior (limits as they approach infinity). The related Little o notation (even more specifically limits of already large values as they approach infinity) is directly related to early attempts at defining differentiation and differentiability and still sometimes show up in Calculus next to derivatives to explain how derivatives work.

The visual interpretation/intuition of Big O notation can be a useful way to build a visual intuition of what a function's derivative and integral "shapes" may look like, so some Calculus books teach Big O notation, too.

As a side note; There is plenty of useful math that many people need (or would benefit from) in the real world. Much math curricula is arguably poorly aligned to needs, as it emerged from various historical flukes of design-by-committee. Popular math curricula is not perfect by any means. I recommend looking at high school or college textbooks and considering whether it is well prioritized.

In principle I agree with you.

The missing part of mathematics education, IMO, would be to focus more into developing the intuition of what something means, instead of the current focus on getting some (numeric) results.

That was one of the biggest changes that happened with common core. Common core itself didn't really mandate this, but it took a reset of the curriculum to insert the new ideas like an emphasis on intuition rather than rote arithmetic.

The problem with common core is that it replaced building arithmetic fluency with less rigorous ways of building intuition, leading to a generation of kids who never gained the basic math skills that are foundational to actually understanding the intuition.

You can't just skip arithmetic drills in favor of intuition and still come out with students who are prepared for further study in math. There's a reason Kumon etc are so popular - parents are replacing the lack of mathematics drills in schools with after school options, leaving behind all of the kids whose parents can't afford it.

After school stuff like Kumon was popular before the switch to common core.

And there still are arithmetic drills, it's just not the only focus in early math education.

Montessori. My kids’ school has kindergarteners solving trinomials [0]. My kids learned multiplication and division by 3rd grade. They’ve also memorized powers of 2 up to 2^20, but that was more me telling them about exponents one day, and then giving those as examples. However, they did learn binary trees (and binary) from their school.

Kids can absolutely learn complex concepts early, they just may not be able to formally write them out until a few years later. But they’re kids, so who cares? By the time they need to be able to write out math equations, they’ll understand the underlying concepts on such a deep level that it doesn’t matter how long you make it, they’ll plow through it.

I was a skeptic, and am aware that I sound like a cultist, but damn if Montessori isn’t something special. I highly recommend it.

0: https://www.montessori-theory.com/montessori-trinomial-cube/

If your company has sketchy process and minimal checks on the software quality, of course it naturally follows that they hire bad engineers as well. fortunately, that also opens up an opportunity to be a emergency leader with an eye towards promotion.

> If your company has sketchy process and minimal checks on the software quality, of course it naturally follows that they hire bad engineers as well. fortunately, that also opens up an opportunity to be a emergency leader with an eye towards promotion.

AI disease is encouraging "sketchy process and minimal checks on the software quality." QA has been eliminated from my team, and the QA engineers that are left have been declared to be developers now.

Gotta move fast, and I guess making sure the stuff we ship works was "slowing us down."

More like developers are now testers and nobody is doing QA.

The bigger issue (I find) is that the pipeline for finding those engineers is completely fucked.

Hiring pipelines that tested the wrong thing have existed for years but the problem is magnified 10x when you test for something that weakly correlates with ability at best which an AI can do better than a human.

This is leading to stuff like incompetent junior-level engineers being hired as principals.

My company's hiring process is basically: Can you code a product quickly with AI? Can you understand the generated code?

That's basically it. It is surprising hard to find people that can do both, but engineers are becoming much, much better at the first gate while flaming out on the second.

>be a emergency leader with an eye towards promotion..

You assume those people haven't already left, been kicked out, or were hired to begin with. We're not in a rational job market right now.

> a emergency leader with an eye towards promotion

i've gone this route a few times in my career, it's very stressful and involves angry/panicked people and many all nighters. Also, the glory fades fast. would not recommend.

Also you don't get the money. Why pay for a job already done

The handling of backpressure is such a good example to distinguish bad from good engineering. A good implementation even presents all the typical "clean" code indicators: DRY, KISS etc.

Sounds like bad management to me

My company got rid of line management. I now report to a director with over 20 reports and barely any time for career development. Our performance reviews are AI generated and we’re losing engineers. The industry has gone completely insane.

This has less to do with bad engineers than bad policies and procedures. You don't performance test before shipping to prod? you get what you get.

Startups have limited resources, we prioritize the best we can. As a staff engineer it's my responsibility to bring this to my company, but it's not an overnight process.

why wouldn't you use those limited resources to test things before they go to production, instead of creating more crappy things that go to production?

What do you test? How much time/effort do you spend testing each of those things? How do you know those will be performance issues?

There's only so much you can do -- making reasonable assumptions, choosing suitable data structures, database indices, testing various workloads, etc. -- in a limited test environment.

You may spend a week optimizing a feature that only 10 people use or that never gets to the point where it becomes an issue. Or you may have something that can't easily be tested at scale, such as various counts or other dynamic data that are determined by complex queries that you may (likely) find you need to cache but don't necessarily know which values will become issues until you start using the system.

We have a test team that runs various test suites(automated) and manual testers that test functionality. They spend their entire working day, every day testing.

From this argument, it sounds like your company is making a rational choice to go with what you’re seeing. Even if you don’t like it.

To a first approximation, basically no one in the industry does. Users regularly report performance regressions in basically every major piece of software, most of which would have been caught by performance testing.

It can sometimes be difficult to predict what will cause performance regressions when developing an application or web server with test data. So you do your best with what you know at the time of release, and then deal with performance issues when you know what is causing regressions (e.g. saved searches) and can then make measurements and profiling to see what exactly is causing the issue.

Likewise, improving performance pushes the limit at which performance regressions happen allowing more data (documents, triangles/pixels, etc.) to be processed. This allows things like more complex game graphics. That in turn makes it harder to improve performance for the next round (more advanced triangle/face culling and pre-processing).

There can also be trade-offs with things like data layout, memory usage (caching and memoization), or implementation. For example, when processing XML/HTML data you could use DOM (more memory and upfront parsing, but easier to perform complex queries across the data), SAX (less memory, but more complex to process due to tracking state), or reader API (similar to SAX but a different processing model).

There can be challenges with various features, such as type checking with higher-order generic types. Others add various levels of overhead, such as parsing a program, constructing an AST (Abstract Syntax Tree), generating an IR (Intermediate Representation), the optimization passes and final code generation.

JavaScript evaluation for example is complex. Before Chrome the approach was to use a slow interpreter. IIRC, Chrome was the first browser to introduce JIT (Just-in-Time) compilation, leading to faster JavaScript and eventually more complex applications running in that language. Modern browser JavaScript pipelines are complex in order to achieve and maintain performance:

1. start interpreting the code on the AST so it is run immediately (or only rely on (2));

2. generate a machine code equivalent of that interpreted code (for faster baseline performance);

3. run more aggressive optimizations on known types based on profiling/analysis for even faster performance, including special handling of things like asm.js.

[1] https://v8.dev/blog/ignition-interpreter

[2] https://benediktmeurer.de/2016/11/25/v8-behind-the-scenes-no...

[3] https://www.cs.cornell.edu/courses/cs6120/2020fa/blog/tracem...

[4] https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/

When I worked at a particular fruit company in Cupertino, my boss had been asked repeatedly by the developer teams to provide a tour of the data center we'd recently finished building out, which housed the servers their code ran on.

He gave them a lengthy, grueling, hyper-detailed tour of the entire facility, encompassing the HVAC systems, electrical systems, network and computing systems, finishing with about 20 minutes where he had them stand inside a hot aisle that he was just outside of, giving a fantastic soliloquy on the importance of code efficiency, and the consequences of ignoring it. It was hilarious to watch from the comfort of the cold aisle, knowing full well what he was doing.

What did the software engineers hope to learn from this tour?

The scale of a cloud datacenter is pretty awesome to witness. I had the opportunity to visit a large cloud company’s data center years ago, it was immense in scale and (mostly) very well thought out.

You just reminded me of this video from Google which toured one of their data centers back in 2009: https://www.youtube.com/watch?v=zRwPSFpLX8I

Because hardware is cool.

I’m personally of the opinion that everyone who works in software should have to rack a server and bootstrap it. Physically mount it, cable it, and get the *nix distribution of your choice running on it, serving Hello, World.

Everywhere I’ve worked, there is a marked difference in the quality of engineers who had played with hardware - even those who merely had expressed interest in it, and maybe had an RPi - and those who had not. There is something about physically touching the thing that runs your code that makes you better at it. Maybe it’s a correlation between “wants to play with something unnecessary but adjacent” and “curious enough to ask why more frequently,” but I swear, it exists.

I think it maps to the proclivity of the engineer to want to understand the multiple layers that apply to whatever they're working on. The more curious, the more likely that engineer is to gain a better understanding of the whole, and therefore presumably be able to do better engineering.

What was he doing? Showing them that bad code will make them feel hotter?

Maybe he got PTSD from being a former tour guide and this was his time for vengeance.

He was showing how complex and expensive a data center is and giving them real-world visceral experience that inefficient code has real-world implications.

Busy servers generate more heat. Inefficient code makes servers busier. There’s a real physical outcome for bad performance code at scale.

But you don’t really want lots of idle or underused servers, aside from burst capacity management. So if they universally and consistently wrote more efficient code I’d expect a smaller datacenter. Full of still busy servers but just less of them.

Mind sharing where you're at?

A hackathon for performance improvement screams to me "you'll be re-interviewing for your own job." I don't foresee this going well for the company. Best case scenario: you wildfire churn all the chaff engineers which limits the company's throughput until they're rehired... with no expectation the new hires will be any better. You also lose A LOT of domain experience and are self-inflicting brain drain.

I'd try and push for some "lunch and learn" meeting where the engineers get lunch catered and in exchange sit in on a meeting where you explain your point of view. Without monetary incentive it'll be hard to change the culture, but not impossible (and food goes a long way in greasing the wheels).

they meant application performance

> A hackathon for performance improvement screams to me "you'll be re-interviewing for your own job."

Not necessarily, great engineers do also ship temporary code they didn't have the time to trim.

Our process is of 1) make it work, 2) make it right and 3) make it fast; not necessarily that engineer had time for the 3rd step.

The older I get, the more I feel that #3 should be "make it work well". Where the definition of "well" can be situationally interpreted.

Do you have SLO/SLAs defined? Are you monitoring performance? CPU usage? Cost increases?

You should have plenty of data to review regularly and push back on any teams that are causing problems. That's a process problem and you need a process for it.

Trace the increase back to specific deployments, call out those teams, and make them fix their shit.

Yes to all, but it's just me responsible for monitoring performance/cost. I either push back or fix it myself, but I am behind. So this is an attempt to give/push more ownership to the teams.

The actual issue is not the "bad" engineers but the bad organization. While people are allowed to push and merge whatever crap is generated there is no point to do otherwise. Even if you do care about performance, "good" code your teammates don't and close more tickets and are better by many metrics.

If you are closing one ticket per week with "good" code but your teammate does three with "bad" code - it's actually you are a bad employee. Also they may say you are a toxic one.

It means the company is measuring the wrong thing.

I would much rather have someone on my team who ships less but whose work I can trust than someone much faster whose changes leave me wondering what problems we’re going to discover later.

And when production breaks (and it will), I need the person who made the change to actually understand it well enough to help fix it, instead of showing up with no idea what is going on.

You can obviously be an asshole about how you do it but I don’t think pushing back makes someone toxic.

You need to be flexible and compromise when the business trade-off makes sense. But you also need a backbone. If you think something is going to cause real problems, bringing it up is part of the job.

>>I would much rather have someone on my team who ships less but whose work I can trust

Me too, but it is not what happening across the industry. Instead they are pushing for more LLM usage as well as more features. And faster, faster!

> With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization.

It's even worse than that. We've got a CEO who has suddenly learned how to vibe code and the stuff he's coming up with is... kind of horrendous. He's coming up with new "products" and proclaiming them the next big thing for us to work on and we're kind of over here scratching our heads asking who would want this? Who would pay for it? I mean, he was able to put together a kind of a cool web app (with 0 web app knowledge) that's supposedly going to let users design thingys with AI, but it just seems like he re-invented a harness/IDE. I suggested that maybe what he wants is a VS Code plugin like Cline or KiloCode... but he hadn't used VS Code.

It would be funny but sadly our CEO is also vibe coding all days (with AI I have so much free time!), forcing everyone in the company to use his vibe coded product.

Oh and he's altering course from the previous "AI only where it makes sense" to "everyone should code, even the sellers" and "AI is not optional, we're an AI first company".

Talk about drinking the Kool-Aid...

> > bad engineers were always a liability

> With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization.

Yup, and that's going to be the comeuppance for a decade of aggresive overhiring.

There are so many "bad engineers" filling the ranks now that in many teams and divisions there's not even anyone left around who can recognize them as such.

This was already manifesting as a rapid decline in software quality and worsening practices, and the amplification effect of AI is mostly going to make everything worse for a while as we wait for all these declining projects to buckle under their weight.

If you are a good engineer, it's a good time to work on small teams with other good engineers and rigorous practices. You can be using AI to amplify what you do (and probably should), but you need to be rigorously considering your processes and guarding yourself from seduction by blind-leading-blind hype you see on social media or in iconference talks.

It's all about the process and the organization. No one is pushing for quality, everyone needs more features.

>>a rapid decline in software quality

It's hard to expect anything else if budget for QA teams is reallocated to cover llm bills.

> The most egregious of these cases for me is often long tenured engineers who have lost interest in the craft, creating a dangerous combination of having enough merit to ship but not enough interest to make what they ship _good_.

I wouldn't be so quick to judge the long tenured engineers. They probably realized that moving business forward is more important than writing artisan code.

You always have some young hotshot who comes in and wants to rewrite your old boring Java monolith into a micro services disaster for "better architecture".

The greybeards learned the life lessons the hard way.

The other aspect to consider is this: stay in this industry long enough and it will beat the soul out of you.

I agree. Why is everyone so hard on everyone else? Look at the outages Anthropic and OpenAI have had. They aren't hiring stupid people but they can't seem to go a week without major platform instability. And you can't even argue that it's because of high load because all of these engineers have worked at Facebook, Meta, etc. They are seasoned veterans that should be able to build resilient systems.

> They aren't hiring stupid people but they can't seem to go a week without major platform instability.

All those smart people are probably using genAI to generate their codebases.

So far, that does not seem to have resulted in a robust, stable system.

Certainly no better than the results the hyperscalers got doing things by hand, and arguably worse.

Either they believe their own hype and their reliability is a reflection of the real weaknesses of AI coding, or they're complete liars and doing far more traditional SWE than they claim. I think the former case is far more likely and that while they may have hired plenty of senior people from big companies, there's definitely a self-selection for "true believers" in AI coding baked into that hiring process.

I think this point gets lost on people. A frequent argument I see in favor of vibecoding is: “well there’s also bad engineers”. In other words, bad code is already being written, so who cares if the LLM is wrong sometimes?

The issue is that with no reins, the LLM is a fire hose of bad code compared to the garden hose of bad code orgs had before. A good engineer, with a good model and harness will produce great stuff. A bad engineer with a good model and harness will produce something faster, but it will be worse.

> A good engineer, with a good model and harness will produce great stuff. A bad engineer with a good model and harness will produce something faster, but it will be worse.

A good engineer, without LLM assistance, will still produce great stuff.

Yes, but much more slowly. And if they realize halfway through implementation that there is a better way to do it, but they are under pressure to deliver, they wont have time to rewrite it and will live with the consequences of that decision forever

> And if they realize halfway through implementation that there is a better way to do it, but they are under pressure to deliver, they wont have time to rewrite it and will live with the consequences of that decision forever

I've never really seen that. What I've seen is the much pragmatic take of marking the source code with a few comments to highlight the problematic areas and then goes on with the implementation. Refactoring can always be done later when the first batch of value has been extracted.

There's always tradeoffs to balance and perfection is something you inch towards, not something you get done in one go.

"Slow is smooth, smooth is fast."

...as Mickey Mouse was fond of telling me as I waiting for the ride at Disney World. Or it was my drill instructor. can't remember which.

Speed doesn’t matter.

it does if you are writing the checks, it doesn’t if you cashing the checks

I genuinely doubt it. Amdahl’s law will always reign supreme.

I take it you're not working at a startup?

I’ve worked at plenty of startups. It still does not matter, it never has.

For beings with finite lifespans, time is precious

> A good engineer, without LLM assistance, will still produce great stuff.

Not fast enough to keep their job these days.

Time was always the limiting factor to code quality, good engineers satisfied the classic "good", "fast" but not "cheap" selection of those three classic options.

I very sincerely doubt it is possible for even an incredible engineer to keep up with the delivery schedules required to ship products now. Not to mention that frontier models do ship pretty consistently good code. By far the biggest source of issues I see is not "poorly coded" but "problem poorly specified". We still need good engineers, because they can understand how to do decompose problems well, but I don't know anyone who writes code by and anymore (other than for fun).

> I very sincerely doubt it is possible for even an incredible engineer to keep up with the delivery schedules required to ship products now.

What's the current delivery rates? From my past experience, any feature can take several weeks from idea to be in a somewhat usable shape for production. While the actual coding is often less than a few days. A lot of time is spent on gathering requirements and resolving conflicts between them.

I believe most current improvement in speed is just moving from idea to demo in a few days, then spend several months fighting bugs. While the customer can't really use said feature.

> I believe most current improvement in speed is just moving from idea to demo in a few days

This is an outdated view.

Current timelines I'm facing are to be going from "thought", through customer trials and being fully live in the product and ready for sales in ~3 weeks (from kick off to live in app is a bit more than a week). This is for a full product feature that could easily be standalone. In 2023 I would say the timeline for a similarly shaped feature at another startup was around ~3 months (and the team at the time agreed that was an aggressive timeline). Bug rates are not noticeably different than other teams I've been on in the past 20 years.

Nobody I know working in startups is still building demos with AI like they were a year or more ago (for work), that's seen as largely a waste of time since you can just ship the feature and be experimenting with customers much faster.

On top of that everyone working in startup land knows that SaaS's days are numbered, so you need to be shipping working software fast enough you can get ahead of the curve to navigate where things are going next.

> Current timelines I'm facing are to be going from "thought", through customer trials and being fully live in the product and ready for sales in ~3 weeks (from kick off to live in app is a bit more than a week). This is for a full product feature that could easily be standalone. In 2023 I would say the timeline for a similarly shaped feature at another startup was around ~3 months (and the team at the time agreed that was an aggressive timeline). Bug rates are not noticeably different than other teams I've been on in the past 20 years.

My issue with these kind of numbers is that they never contrasted them with a NO_LLM practice while keeping everything the same. It's always perfectly fine to YOLO generated code straight into prod, but if you handwrite it, you need to fill several forms in triplicate to even make it to the review phase. Then someone claims they are 10X-ing their productivity with AI.

> you can just ship the feature and be experimenting with customers much faster.

That's basically what I said. Instead of shipping something that have some value to the customer/user from the get go, which may takes one or two months, you spend one or two weeks on it, ship it, then frustrate your customers/users when things aren't working or keep shifting around.

For all of AI being touted as the best thing since sliced bread, there's been little to no value for humanity as a whole.

> YOLO generated code straight into prod

Most of my team's time is spend carefully reviewing PRs and iterating on improving new ways we can ensure the product works well, the product is hardly "YOLO'd"

> then frustrate your customers/users when things aren't working or keep shifting around.

All of these products come at the request of customers and they are generally quite delighted with the results and equally delighted with how fast we can deliver.

> For all of AI being touted as the best thing since sliced bread

I don't think it's the best thing since sliced bread, but I am telling you that your understanding is weirdly out of touch. I know HN doesn't have people working startups anymore but what I'm experiencing at work is a lot of serious engineering work and discussion around delivering quality products rapidly (as well as improving process so we can get ahead of transformations in what a 'product' is).

It sounds like you have a view of the world and want to stick to it, in which case there's not much point in arguing. If you search my comment history you can easily find around 8 months ago I would have largely agreed with you, which is why I opened mentioned that your view is "outdated". This space has changed dramatically in the last year, and continues to change in ways that surprise me.

The easiest way is to actually review the prompt input, put it through a LLM to catch the typical missing steps and automatically forward the result as review comment to the MR.

Let the LLM wars start!

A single bad dev with AI can overwhelm multiple good devs trying to hold back the tidal wave of slop.

Tell me how to paradigm shift careers and I'll get out of your hair and stop shipping uninspired features.

But, right now I'm paralyzed with fear in how to make a successful career switch without starting from literally "new grad level." I have wisdom, so it doesn't feel like I should have to start at the bottom rung again. Egotistically, I don't even mind, it's just the salary hit that would be the main issue.

Maybe it's not even a paradigm shift (though, I've always wanted to work on film productions). I've sort of lost the passion for being an IC, but how can I make a transition to management without any management experience? Should I just apply for a managerial role and in the cover letter state management is my intended path for growth?

>> Egotistically, I don't even mind, it's just the salary hit that would be the main issue.

This is whare I am right now. Even senior positions have dropped 50-60K in range so I've effectively priced myself out of a lateral move because I would be taking a massive hit in salary for the same role I'm doing now. I'm currently at a company that continues to lay people off in lieu of offshore talent and AI. I'm stuck in a weird state of purgatory.

>> Should I just apply for a managerial role and in the cover letter state management is my intended path for growth?

I know many of my friends in senior dev roles have put their resume in Claude and said they were interested in moving into a management role and had Claude revamp their resume into something that was more management focused. Three of them were hired quite quickly not only based on their dev backgrounds with mentoring, training and light management of junior devs, but having enough emerging AI skills they said helped them close the deal.

Interesting. Thanks for that last anecdote. I feel you on the weird state of purgatory. I'm confident we'll find a path forward, though. Gotta keep your head up

I've decided to take that salary hit. I want to stay an IC and work somewhere that doesn't effectively require a 996 schedule to keep up with openclaw slop for PR count stack ranking purposes. It really depends on your financial situations, but I've seen the human cost of very high compensation jobs on myself and some things are worth more than money.

Same man. I hate everything about this career path right now, but even real (civil, structural) engineers get paid massively less. I think I’ve just come to a realization that software engineering salaries are just massively inflated, especially for those of us that just do the programming part and not the actual engineering part.

It just seems like there’s a reckoning coming for our field. I’m going to keep doing it, I don’t see any other choice right now.

Rather than good or bad engineers, I'd focus on the quality of the idea. Every software engineer has good and bad ideas. Historically, bad ideas were kept in check by the effort it would take to code the implementation. With that barrier nearly gone, there's no friction - a bad idea in the morning gets deployed to prod in the afternoon. No thinking required!

So yes, garbage in -> garbage out, but framed in a way that makes it clear what is garbage. The ideas, not the engineer themselves :-)

This suggests we need to be doing more designing and planning; introducing that friction intentionally to make sure bad ideas get culled, viable ideas get refined. Critical thinking becomes the bottleneck; the quality of the idea becomes the deciding factor in success.

i think i fall into this bucket. our "leaders" and executives have told us they dont care about 'shipping good' . we are simply responding to incentives.

They’ll care when nothing works, nobody seems able to fix it, building new features takes forever and every change breaks something somewhere else.

This was already happening before. But now, a lot more companies that previously might have taken many years to reach an unmaintainable state can now get there in just a few months.

My coworkers and I give it 12-24 months before we have a total collapse due to unmaintainable slop and good people leaving. Generally there's a feeling that this will sink a lot of bigger companies.

pretty good presentation.

my take is everyone in the industry should read grog-brained developer, & no silver bullet before working as a professional.

the other is a mindset change - the best working code is code that's never written as it doesn't have bugs or suffer technical debt. Agentic coding doesn't solve that. Human taste does, which means our job is to reduce the amount of lines we write. agents etc are useful for the filler or bullshit part of our jobs e.g generating tests.

but ultimately I think the whole spec-driven development & agents spitting 100000s of lines era will be looked upon as mass psychosis.

last thing to give an analogy - you don't carve a David statue by gluing together pieces of marble - but you carve it by cutting pieces of a huge block of marble.

> With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization.

I think the real pain though is that AI also often removes the feedback loop between "good" engineers and "bad" engineers. A lot of "good" engineers started as "bad" engineers that learned, sometimes the hard way and sometimes with patient mentorship, how to be better engineers. Patient mentorship becomes harder as code reviews become less personal. "The Hard Way" becomes harder when the consequences get divorced from actions. For a bad engineer it becomes "Claude broke Production" more often than "I broke Production" and learning mostly ceases.

We're starting to recognize how many junior developers AI is replacing, making the pipeline to senior developers harder (if not disappearing), but we also maybe aren't focusing enough on how much we are also losing the pipeline from "bad" to "good" engineers.

The analogy I have heard is that LLMs are a force multiplier, so if you were a 2x engineer before you are now a 10x engineer, and if you were a -2x engineer you are now a -10x engineer.

This is me to a tee. I think I'm a fairly good software engineer, and I loved building software and mentoring more junior engineers who I thought had both ability and a good attitude. I also think I was a pretty pragmatic engineer (I was not an "architecture astronaut"), but I did enjoy the craft of getting into the nitty gritty details of software.

The past 5-10 years or so saw me pretty beaten down though with software engineering, and AI was the final nail in the coffin that caused me to leave the profession in later middle age. I thought software as a business had "lost its way" from building great products with attention to detail to "how do we addict as many people as possible as quickly as possible". Think about the degradation in Apple software from say the "it just works" era to now.

With respect to AI, I'm not really against it, and I find it extremely valuable in my personal projects. I just feel in a large group/enterprise context that it's replaced a lot of tasks I actually enjoy doing with becoming an editor for what feels like a slightly inebriated junior developer. Or maybe it's better to say a junior developer on a mild amount of meth, because as you say this developer can churn out semi-but-not-fully-working code at an astonishing rate, and then I feel like it's often my job to mop the slop off the floor. Pass, not interested.

I feel lucky to have had my career during what I consider the golden age of software engineering, but I'd note I don't think that golden age lasted even a full career of one person.

In retrospect, the golden age was the pre-internet era. Some rose-colored glasses maybe, but as I remember it:

Paying for software was the norm, so it was more clear what the "product" was, and software writers had a direct incentive to write better software.

Updates could not be pushed out so you had to be pretty sure your code worked before you shipped it. Having to ship physical media to all your customers for a bug fix was very expensive. Any new release was a big deal, so you had to put some real thought into what features it should contain.

Significant amounts of your development time were not spent trying to work around browser bugs, or differences in browsers, or supporting random old browsers that your customers still use for <reasons>.

Stack churn was much slower. The feeling of constantly trying to keep up with a treadmill was much less.

Users, while often not technology experts, were a much more competent slice of people than the general public who showed up when they got internet service and a computer at home.

The only ads were in print in trade magazines or publications like Computer Shopper. Yes, people actually used to buy a magazine that was nothing but ads.

You're right about those things, but you're forgetting that we had no source control, and almost all software was closed source. You took what you were given and you liked it, and you developed strong attachments to particular versions of software which you clung to well beyond its use-by date (like Python 2.7). MS-DOS 3.3 forever!

We had version control in the 70s with SCSS and then RCS. They were primitive, but a lot of software were only a few files.

In the 80s, source control was like networking. Yes some orgs had it (mostly academia) but the rest of us just had a precious floppy that we copied the known-good source onto.

We had an own good-releases directory in our svn repository! That's when you realize old habits are hard to change.

I started using SCCS in the late 80s, then RCS, then CSV, then subversion, and finally git.

Going to CompUSA and looking at the back of the box for not only video games, but spreadsheet and translation software, too; was awesome. As a kid I always wondered about the adults who needed such software as the back of the Deus Ex or Shogun Total War boxes captured my imagination.

Since it sounds like you built software during that era, thanks. Thanks for the memories.

In thinking about it more, I think you're totally correct.

For the vast part of my career I worked for good companies that I thought were comparatively very well managed, and I was especially fortunate that overall I think I had excellent bosses. But the reality of the Internet age and CICD in particular is that speed is much more important than quality. I don't even really disagree with the business imperative of "ship, ship, ship", but for people who really value their craft, it can be discouraging shipping stuff you know is always kinda half baked. I was definitely not a "gold plater" either, and time pressure was certainly a thing pre-Internet, but as you say mistakes were a lot more expensive then so there was more business rationale to ensure quality before a release.

I also consider myself a fairly good pragmatic software engineer. I have led small (3 engineers), medium (15), and large (100+) teams.

To me, the best time was late 90s, early 2000s. We had a lot of autonomy. People would just trusted that we knew what and how to build it. I could focus on building a great product. Overtime, we lost control, to the point that we now work based on jira tickets made by managers or product owners with one tenth of the experience that we have.

I definitely hear about segments of the industry being like that, but FAANG and adjacent generally isn't. Engineers are expected to display ownership of a problem space (scope depending on seniority), navigate ambiguity, and manage their own time.

> The past 5-10 years or so saw me pretty beaten down though with software engineering, and AI was the final nail in the coffin that caused me to leave the profession in later middle age.

What year did you leave? And what are you doing now?

This is right on the money. It's not that we have way more bad engineers than before; it's that the damage they do is out of all proportion to their numbers.

I've seen a subtler variant of that. Since 2025 winter model improvements, low quality developers can now commit somehow decent stuff more regularly, but as before, they still don't own the solution space independently. LLM output is now larger than what they can envision and cracks will simply happen further away, only to be discovered by someone else later. It's strange everything changes so nothing changes phenomenon.

Most vibeslop these days is superficially good in that it has unit tests, compiles, passes the style guide, but it's bad on a macro level in that it makes the system more complicated, ignores the wider design of the app, implements what the prompter asked for and not what the app actually needed, etc.

I'm seeing a bad pattern of vibeslop being used to solve the immediate complaint of the user without stepping back and reconsidering things from a product perspective. Just add another conditional statement to make this very specific scenario the user complained about work the way they want.

>With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization.

I would expand this even further and say that the worst problem for people in the trenches isn't even just that this is happening, it's the it creates a situation where managers are held to some expectations (their team shipping product features) that incentivize not looking too carefully at what their team members are putting out. It makes it really hard to tell a boss "we need to stop and spend a few days reviewing and rewriting because one of my teammates likes to one-shot everything with poorly thought out Claude prompts making multithousand line PRs" when their own bosses are breathing down their neck.

It's the same struggle we face to get refactor work prioritized, just at a much more frequent cadence. "It's working so why do we need to spend another sprint on it?"

> but not enough interest to make what they ship _good_

I'm having the impression business decisions always win, time is always reduced and requirements always changed half-way during a project, having a much greater impact than any bored old engineer.

"Okay. I'll create a loop and goal so it doesn't stop until it's checked that everything works."

This is where the quality magnification seems to be occurring.

Goal-driven loops can make good code great, or bad code worse.

Part of the problem is self confidence bias. Everyone things they're the good engineer, while dunning Krueger would say maybe you are the bad engineer.

Prove who's good and bad.

And you can't really, because there's always tradeoffs you're making as an engineer. The really self confident ones think their tradeoffs win, and maybe they do, though often they don't and these people are just self aggrandizing and stroking their large egos. Are you a better engineer just because you made a big talk and had the confidence to share it with lots of people?

I'm not sure if it's replacing the middle class of software engineering, but I do feel it's generally true that the static approaches to middle class software engineering are evolving quicker than people are keeping up.

Hopefully when there's bad devs, there's a bit less making a mess where someone doesn't know better and as a result some amount of average or general best practices start happening.

This can be true not just for software development, but making a mess in anything, including a spreadsheet.

Despite the title this article doesn't seem to be saying anything about the "middle class".

But sooner or later for AI to reach its true potential we need to have HOTL ie Human Out of the Loop. Meta prompting or using AI to develop the prompt by coaxing it to ask relevant questions , creating specs and going through multiple loops with LLMs - things like this can be a good start towards the final goal. Final means the over abundance of goods and services like the men of the millenium are suggesting us mere mortals will reach one day,. .. and work will be optional.

Alternatively, cutting out labor just results in mass poverty except for the moneyed few, and a new era of technofeudalism.

It seems pretty clear that the current crop of executives strongly prefer the latter scenario.

Pretty big assumptions that we will get a UBI that everyone can live comfortably on, that there will be optional jobs for anyone who wants to work, and even given the first two, that there won't be massive wealth and power accumulation at the top, even more than today.

> Final means the over abundance of goods and services like the men of the millenium are suggesting us mere mortals will reach one day,. .. and work will be optional.

Yeah, that sure sounds like paperclip maximizing hypercapitalists. Real big on sharing, not so big on minding the cost, but they just can't show their love for us all while employee labor still has some value to them. Once that's out of the way and they've taken or mulched everything of value from others, that's... that's when they'll start giving it all back, yeah.

I know the sarcasm isn't helpful. But goddamn I can't understand this take, I don't know why people believe people-shaped entities like [your favorite wealthy sociopath's name here] will become society's mommy if given the power, and it's incredibly fscking frustrating. Like people who think once their home and everything is burned to the ground, the fire will rebuild everything, but better.

> people lack the right skills today to wrangle agents into writing good code.

It's actually this that leaves me feeling optimistic. We're definitely bad at this today, but will we always be bad at this into the foreseeable future? I'd like to think not. I'd like to think that we'll get better at working with agents in the future and eventually develop better practices around this new weird technology once it's better understood.

seems a lot of comments below with disdain for "bad" coworkers. every industry has them, but if theyre objectively bad why not get rid of them? surely some periodic review would do that. how did they get hired in the first place? perhaps hiring managers are the "bad" employees.. or managers that let them go on not performing are "bad". or maybe your expectations arent aligned with reality? who knows? the worlds a complicated place.

Good talk, thanks for sharing! I’m trying something similar for personal project I’m hacking on.

Specifically, I’m spending a lot of time on the first few instances of a pattern that I hope to have the AI scale out for me. My thought is that I can provide an opinionated project structure, feel it out myself, then point the AI to those working examples in the future. Until then, I’m mostly just using ai as fancy autocomplete + domain research.

Bad engineers simply don't care about good engineering. They aren't even trying. LLMs have made these engineers super "productive".

I think the parallels with AI art are uncanny - nowadays people with zero artistic skill, vision or effort invested are capable of creating stuff that would've previously taken a master artist a solid week of work - doesn't mean any of that is good, but it does mean that the logic of 'if it works and looks good, it's good' is completely broken now.

> With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization.

and

> I don't subscribe to the idea that AI generated code is fundamentally bad, just that people lack the right skills today to wrangle agents into writing good code.

those people who lack the right skills today – are they the bad engineers you'd mentioned previously?

> not enough interest to make what they ship _good_.

I know this happens, but don’t really understand it.

In my experience, quality hits usually resulted from external pressure (bad managers, trade show-driven schedules, etc.). I always wanted to do better.

Now that I’m retired, I take the time to really get Quality right. LLMs have helped (but they need close watching).

> With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization.

This is why I don't have any patience for the people who say "but AI is so powerful! we can do so much!" It amplifies the bad stuff more than the good stuff, so it's a net negative.

This is why my theory is LLMs are self defeating in large orgs. Or worse terminal for the organisation.

For everyone adding value with LLMs there will be way more destroying value. If you roll a critical failure a mediocre LLM enhanced VP convinces the org to sail aggressively in the wrong direction.

Ironically, AI mitigates bad developers quite a bit. The architecture/design is coming from above bad devs (in a functional org), and AI tends to write less sloppy code than bad devs, and test/validate it more rigorously.

Jury is still out here

AI is very good at making the bad dev's PR look plausible and be green in CI. And thus, merged.

> AI tends to write less sloppy code than bad devs, and test/validate it more rigorously

I've often had it test and benchmark against the wrong things = no test.

It also writes over-engineered code. So yes sort, maybe.

Strong disagree. A lot of AI development still requires good engineers to keep tight leash on it so I'm seeing more bad developers create a feature until we need to iterate on said feature and we find AI did such a bad job that it becomes extremely difficult to do so.

I don't agree here. Yes Claude is great at following patterns, and for very standard tasks (e.g. "add this HTTP handler" which can copy existing patterns for database transaction management, session management, authentication, etc etc) it does great! The problem is that when you do something that doesn't quite fit int an existing pattern, Claude will optimize for solving the task at hand, producing code that doesn't use a sensible architecture. Doing things like checking user credentials or establishing a database connection deep in domain logic.

If you're a good dev, you can totally prompt Claude to not do this and correct itself, that's not an issue. The issue is that bad devs won't even notice this is happening in the first place.

Less sloppy in that it's clean and consistent looking but much more sloppy in the AI good looking non-sense way.

Just like compiler-generated machine code, then.

no, not like that at all.

A bad developer with any current frontier model will happily produce syntactically correct code that is unreadable, in a spaghetti architecture, and write an elaborate test suite that tests all of the wrong things.

If those bad engineers are in a very well defined box. Give bad engineers greenfield and watch it implode

It can but you need to be careful.

At my org we use Github Copilot as our AI tool for devs, both internally and for vendors (Including a WITCH =/).

Where it gets ugly, is that we have a -lot- of WITCH provided code already in our systems, and as a result GHCP winds up often preferring the existing (terrible) patterns.

I've done some things to help mitigate at least; Adding instruction/skill/agent files, tossing in some LLM-built .NET analyzers to catch the worst anti-patterns to warn on build and error on CI, and making sure to call out when the vendor people are obviously not even reviewing what the LLM generated for them [0]

[0] - Simplest case being, EF Core mappings where the datatypes do not even exist in the target DB...

Maybe those engineers that don't care about making their solution _good_ are actually the good engineers, have you ever thought about that??? There are exceptions where quality really matters but most software shops build CRUD web apps where it's not really a good characteristic to obsess over the cleanest and most elegant details, instead you need to get the stuff the customer wants done!

I for one tend to care less about the minutiae of solutions implemented by AI as long as it gets the job done, I do care about architecture and design decisions and correctness and I have ways to steer and verify these when working with LLMs but I couldn't care less about it writing "good" code. Bad engineers also produce better results with AI at least when they're working in established frameworks, AI doesn't really need a lot of high level architecture input when designing or building a web app with a common stack, so as long as you're not working on something that's completely novel I don't think it will make a strong difference.

Maybe designers think the same way about the AI generated web designs I have Claude Code do for me but to be honest I don't care, I just know that before this tool existed it would have taken me weeks or months to come up with a good design and I would have to rely on prefabricated UI libraries and stuff like that or pay a designer tens of thousands of USD to make one for me, now I can get a (for me and my customers) perfectly acceptable and professional design within a few hours. So maybe I'm also a bad designer that amplifies my bad design taste 10x in my company, but the fact is the stuff ships and makes money and the customer is happy! And I can tell you customers or users don't give a shit about how good your code is, they only care if the software works and does what they want!

This is a great point. I find myself in the middle, where I appreciate and look up to past coworkers who were way better than me at attention-to-detail, but I have a tendency to focus on delivering actual results quickly with maintainable and easy to read code. A lot of engineering teams go into their own world on adhering to best practices with no eye on inefficiencies in the process that causes days of delay because it makes them feel better. I definitely believe in shift-left (findings bugs early saves a lot more time than finding them in production). I believe in balancing fast delivery with quality/process.

Totally agree with your framing here, but that is also what I fundamentally consider "good" code -- it's code that solves the problem that your customers/business needs without making it _harder_ to solve the next problem.

There are valid situations where the best code you can write is code you never look at and throw out the next month; there are equally valid situations where the best code is well thought through and reasoned abstractions for an area you expect to become core to the business in the near future.

Thanks for the wording on your first sentence there. I've been trying to figure out a way to get that thought expressed succinctly.

I think with AI coding, what we call "good" code changes. Lots of abstractions really only exist to help load the context into the human brain so that they can solve the next problem. If an agent can just search and find all the places to make a change, or to duplicate code with small changes for the next problem, is that bad? Does is just feel bad because that's not what we're used to?

We use structured looping instead of gotos because that makes sense to us, but the compiler still turns it into jumps in assembly. If our interaction is now at a higher layer, do we need good "code" or do we just need good "architecture"?

I don't know, but it's just something I've been thinking about lately.

Using context always means there's less for something else, whether you're a human or a machine. Abstractions that localize reasoning and help load the context into a human brain are ideal for machines and humans alike.

If you're writing CRUD, there's no excuse not to write it competently since you're not solving a new problem

In my experience, those that can’t understand design in the small (code level) don’t understand it in the large (sw or systems architecture) either.

Doing the right thing for the customer is independent from good design and good code. It’s a problem of requirements and project management. This is an excuse some poor programmers use, that they can’t write good code, but at least they fulfilled the customer requirements :D

I tend to find that this perspective comes from people working on relatively small or isolated projects.

On a large system, the customer being happy today isn’t enough. You need other engineers to be able to understand the system.

Have you ever been on call and been woken up in the middle of the night to fix a production incident in a system you didn’t write?

If everything you build is small, isolated and easy to replace (basically fire-and-forget), then yeah... who cares? Ship the ugly thing, get paid and move on.

If you’re going to be working on something for the next 5+ years, you should definitely spend some time thinking about what you’re doing.

I have found this to some degree (even though I work with amazing people day to day).

It's much easier for people to pump out absolute garbage, you know the kind of "just get it done fast" slop that management types cry out for. And then they wonder why everything end ups broken, not being maintained etc.

And I think the contrast between good and bad code output is much more impactful. Someone can pump out 10x the bad code they used to before, never test it never read through it just push push push baby. And then for good code, sure it's increased my output for slop tasks like repetitive unit tests, but a lot of TLC and review is required for good code and I'd say I've had maybe a 2-3x speed up on a lot of things. But not 10x; you only get that when you don't give a fuck.

Not all industries require good software engineering tho.

one good swe out of ten with high authority may be enough in most organisation

> The most egregious of these cases for me is often long tenured engineers who have lost interest in the craft...

Which is an incentive problem, they have likely reached an equilibrium with their company. Genuinely few companies provide any incentive and critically, the space, to ship good code.

Because frankly it doesn't matter in the middle grounds. Which is where 90% of developers are.

I wish we all had fulfilling edge of our seat projects to work on, that challenged us just right, mattered to our community etc. AI is absolutely poised to disrupt the middle 80% of development because the middle 80% of dev is not that important or hard.

It's just a shame for all of us who loved the craft, and didn't mind being in the middle making a living. That's a totally noble place to be, and it could get taken away from many of us.

> I am still a firm believer in garbage in -> garbage out, AI is only as good as the abstractions and contracts you put in place for it.

Absolutely on point. I just completed the port of a industrial application written in Python using a sophisticated console-based UI to C# and Avalonia UI. This is my second major coding project using Codex.

The one salient element of the experience has been that, as I keep saying to anyone who will listen, AI still does not understand anything it is doing. It presents an amazing simulation of it, but, no, it does not.

Here's a simple example: The original application had a clean communications protocol implementation. A single file with a class that implemented every single command you could have the industrial controller issue to the hardware. Codex was explicitly told to replicate that in C#. It did, at first, but then it started to duplicate command processor code in the individual functional blocks throughout the application. Which means that, when a bug surfaced, you had to fix it in five different places.

Another example: The application has a highly customized table view. Once again, it was told to make that a component to reuse throughout the application. It did, at first, and then weird bugs started to surface that made it clear that it had reimplemented the table control in different areas of the application.

If you don't know what you are doing you will probably not pick-up or even care about some of these things. It is easier to whack-a-mole bugs with AI than to worry about code structure, efficiency, maintainability, future-proofing, scalability, etc.

I purposely decided not to look or touch a single line of code during this project to see what's possible and where the issues might be. I learned a lot and continue to learn. I think the next step is some sort of an agentic approach, maybe using OpenClaw (or whatever, I don't really know right now) to create a team with coding, supervisory and testing agents.

While the project got done significantly faster than it would have without AI (four weeks instead of probably 4 to 6 months), the process was just as intense as coding, just operating at a different level, micromanaging architecture and implementation.

Bad engineers. Like bad wine, bad pizza and bad exes are impossible to guess till you taste it. Changes you forever. Changed me. You know its bad and good lord! dont bother explain it someone else who will not taste it themselves.

There's different kinds of bad too, some justified. The senior that made their way boot licking and being at the right place and time. The junior that just got there. The senior that does not care anymore for being left out of promo two years ago and having to report to the person they despised as being a bad engineer.

AI isn't making human behavior better. In any way.

Life is too short for all this, keep doing the good stuff, filter in the good, keep the bad out that you can, ignore the rest. Have the self reflection to know when things aren't working out, and when its worth getting out. Build the wisdom to not repeat the same mistakes. Believe that there's a lot of good work to be done in the world and contribute in any way possible.

What is A&D? Shouldn't it have been defined in your comment?

Fair point! I edited my comment, A&D -> Architecture & Design

What about the video's title?

Why is there no transcript for that video?

This is great.

We now need to talk about the 10xBad engineer.

Great talk

My team is currently developing our 3rd product this year where 99% of the code is written by an agent. One thing I've definitely noticed is our problem solving hasn't stopped, it just moved up the stack to the "agent layer".

A big part of this is ensuring that a "bad" engineers can still write solid code and also investing in systems that make it easier for us to review code.

When it comes to writing code, we have this entire library of coding standards that we've moved from one project to another. It describes, sometimes in excruciating detail, exactly how we want our code structured, antipatterns, best practices, etc.

On the review side we have invested equally into skills that split up code into readable chunks, take screenshots of any UI changes for quick validation, and a whole battery of tests to ensure that we're not generating slop.

If you were to look at just our development process, you would conclude that we're very lazy engineers. We seldom write code by hand, we seldom ask for corrections and our reviews are more of a cursory look at the PR rather than a deep review.

But the real work is not in the "development layer", it's now in the "agent layer". Making sure the agent knows how to write solid code so we don't need to write code by hand, making sure it doesn't make dumb mistakes so we don't have to correct it, and structuring our review process in such a way where an engineer only has to take a cursory look at the code.

The key difference we noticed between the "old way" and the "new way" is the "new way" is way more scalable and we're able to move way faster than we ever could before.

What you’ve described solves a different problem. You’ve put a lot of effort into making sure generated code conforms to your standards. That’s all good.

But do the people still understand what the system is doing and why?

You can have code that perfectly follows every standard and passes every test while gradually building a system nobody has a mental model of.

> an engineer only has to take a cursory look at the code

If that means you’ve automated away checking syntax and implementation, great. But we already had that before. If it means nobody needs to understand the change anymore, then this is exactly the risk I'm talking about in the article.

I think for senior devs, some of us are legitimately jaded, especially if have been facing the same or boring problems.

I am just tired of typing and looking up syntax for every line of code.

This, however, is a slippery slope, and one has to be mindful of falling into cognitive surrender.

To everyone complaining about "slop" and "+20000 PRs," what kind of systematic quality assurance, test plans, and tech debt reductions were you doing before the "LLMpocalypse?"

Were you only relying on the difficulty of producing "working" from replacement skill/rate "software engineers" and their level of disinterest being the only real circuit breaker?

We had a dedicated QA team and an extensive test base... which we fired to reduce headcount, and we've trimmed back because we don't have the hardware resources to run those tests sufficiently expeditiously.

Secondarily, the business itself is also driving the throughput increases by demanding more volume, but there is no accountability to them for asking for throughput at the expense of quality. They may also deny the engineering time to work on things that would stabilize quality that supports faster delivery because features earn money more directly than developing quality processes.

This isn't coming solely from engineers wanting to produce more stuff faster.

Trust actually does work that way though, the implicit and collective fuzzy agreement of “having my name on it”. Of course that ambiguity needs enforced automated checks, but reputation and one’s own integrity is not for nothing.

Generative AI breaks that agreement. It took me over a year to realize my previous CTO actually didn’t care too much about the system design he shipped . And the expectation was actually to just throw it away, have AI reimplement “what wasn’t working”. Use AI to ship, AI to learn what shipped, and AI to fix what shipped.

I quit because of it. Hell is working on other people’s AI code.

At different times in recent history, you could have also said:

> Hell is working on other people's NoSQL code.

> Hell is working on other people's Python slop code.

> Hell is working on other people's enterprise Java code.

> Hell is working on other people's Windows Forms/GUI Builder code.

To quote Jean-Paul Sartre: Hell is other people.

Quality assurance and test plans don't catch slop. They just test your code. It can't prove the absence of bugs.

In general, the way we still do it is: some basic static analysis finding anti-patterns, but the meat of it is, and always will be, code review. Except you can't review code at the pace AI generates it.

Where I work someone is still responsible for the output. We expect developers to examine the code the LLM produces before burdening someone else with it.

The difficulty of producing code WAS one of the circuit breakers.

We had tests, CI, code review, QA, architectural reviews, etc. None of those disappeared. But they were designed for a world where producing such a large amount of change was impossible.

Tests don’t solve that. Tests can tell you that the behaviours you thought to test still work. How many times have you had a completely green CI with 100% coverage and still shipped a bug?

Reply on news.ycombinator.com