Hacker News Reader

Comment by overgard | Hacker News Reader

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.

View on HN

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.

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?

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.

> 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.

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

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.

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.

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

-John Cook

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.

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.

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.

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.

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" 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.

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.

“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.

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.

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

> 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.

> 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.

> 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.

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.

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

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?

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.

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.

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

Reply on news.ycombinator.com