If there is a virtue to CS degrees, it's that most engineering tracks require an immense amount of coursework in hard sciences that require a high intellectual aptitude to complete.

I'm really struggling to believe that a majority of people can work through that material and then can't do the type of work that most developers do. And in the most difficult realms of development, I think you'd find a majority of the developers have advanced degrees in CS.

I think having a deep interest in software is more likely to traits you're describing (and described in the article). Some people who have that didn't study CS. A lot did.

* query a database

* run a web server, typically spring boot or a C# equivalent

* run some ridiculously large browser framework like Angular or React

Typically the end goal was just put text on screen and you need an entire army of developers to do it. Any suggestions that deviate from common patterns were met with hostility by other developers and ignored by product owners. The name of the game was hiring and firing.

Almost no corporate developers were doing anything that could be called engineering. Most of the people that were interested in actual engineering were writing open source outside of work.

-- CS grads are, on average, better programmers than non-CS-grads.

-- The average CS grad is not a very good programmer.

My company does a standardized interview with a straightforward coding problem that is only a few steps above fizzbuzz level. In just the past few weeks, we've had candidates who:

-- Had to look up basic syntax (defining a function) in the language they chose.

-- Duplicated a reference a few minutes in and could not figure out the problem in the remaining twenty minutes.

-- Couldn't extract the 2nd element of an array of five elements.

These same candidates, on other portions of the interview:

-- Knew nothing about common data structures (something that at the very least a CS degree should help with)

-- Couldn't handle an intermediate SQL query fix involving a simple normalized schema

-- Couldn't tell you anything about internals or security, and

-- Didn't seem able to describe how they'd build a CRUD app.

All of these candidates had CS degrees from respectable-to-good universities.

Anecdotes are not data, but high-level data says the same thing. Our coding problem is very similar to the practice problem shown at [1] (though slightly harder). It doesn't require any tricky lateral thinking, deep language features, esoteric algorithms, dynamic programming, weird race conditions, or any of the other usual trivia BS - it's as straightforward a task as we could design.

And if you look at how much progress people make (see [2]), it's not much. The vast majority of people we interview have CS degrees, and two-thirds of them still get ~nowhere.

Meanwhile, the best interview we've done this month was with a guy who has been the sole developer for an ag business in rural Arkansas for the past decade. He has no degree and his previous two jobs were a sandwich shop and running a website for his church.

(Specific details slightly fudged for the sake of candidate anonymity, but not in a way that materially affects the point.)

[1] https://www.otherbranch.com/shared/practice-coding-problem

[2] https://ibb.co/CpznhK8m

(Full-disclosure: mostly self-taught with several decades of experience.)

Just because it's a kind of visualisation of a distribution, the elite are not that far ahead of the competent, but there is a very long tail of shitters out there.

The guy single handedly created the best online chess site out there outperforming whole commercial teams in every area (performance, interface, features, whatever you choose). His work ethic is legendary and he pays himself below entry level salary (for US standards).

So 90% of CS graduates are useless, which it why, thank God, the inflationary pressure towards programmer jobs is far lower than the droves of new arrivals would suggest.

Therefore the top 10% are 100x by default compared to the middle because the middle is really a liberal arts graduate, not a computer programmer.

This just isn't true, I mean, my university has a graduation rate around ~65%

People who know the least amount universities talk the the most confidently about them.

Well, duh. Nobody is going to waste their time talking about something they know well. What would be the point? They already know about it. Anywhere you find people talking about a subject, you know they have limited understanding. That's why they are talking about it — seeking more information to expand their understanding.

Is x the average?

Is a programmer someone who just implements the requested features, or, like bluecalm commented below, someone like the Lichess creator who apparently does all of "performance, interface, features,", etc.?

What metric are we using here? Revenue?

Then again, this is nothing like the type of problems I work on a daily basis.

I don’t know if they’re looking for superheroes or people who can put in the work.

If the GP is reading this, I’d suggest increasing the timer a lot more (like one hour, what’s the big deal anyway?) and splitting the requirement and steps into smaller chunks. The “optimize for speed” remark in the instructions is also a bit confusing.

As for being stressed -- if this is too much, how will you do when asked to solve even harder problems with tight schedules and/or demanding customers?

Isn't the whole reason you are joining a team is so that you have a support network when such situations arise? The period of acting alone to join that team is a temporary aberration and is to be recognized as such.

You may as well be the business selling to those demanding customers if you have what it takes to handle going at it alone. It will be far more profitable. But if you don't have it...

And if I did have to do something like that at work, I promise my manager would give me more than 25 minutes to do it.

    sum += (x > 0 && y > 0 && x < x_limit && y < y_limit) ? a[y][x] : 0;

  >=

-- joking -- :)

But your take on the stress component of an interview is way off base. There’s a huge difference in having stress on you to deal with other people’s problems vs. your own. An interview candidate may be in financial trouble and may have been struggling for months to find employment in a terrible job market. This is existential stress on a completely different level than a customer wanting a feature yesterday.

There's no such single "stress". It's all different. Being yelled at by mom is "stress", and so is being held at gunpoint. Not the same kind of stress.

Making the slightest mistake or wrong impression during an interview pretty much ends it right there and by extension kills your chances of employment. Your entire future career and financial stability for the next 5-10 years hangs in the balance at all times during an interview.

Not comparable in any way to "the customer is being annoying today".

> Very few people will finish the full problem. You do not need to complete every step to pass our interview.

A problem that an average candidate completes doesn't have a lot of differentiating power on the high end, whereas a problem where an OK candidate finishes 2-3 steps and a great one finishes 4-5 carries a lot more information.

Because like many people have stated, this is just a hand holding test. You're basically seeing if they can code. So you're testing how fast someone can take a list of 5 steps someone else gives you and translate it into code in under 30 minutes.

And I'll tell you, I've never, in my life, worked on code with a series of 5 requirements and submitted it for review after 30 minutes. That would be bonkers, because I'd probably spend at least an hour sussing out all the ambiguities and contradictions.

> I don't think how far a candidate gets on this particular test determines if they're OK or if they're great.

It doesn't with certainty, but measurement of this kind is always subject to some degree of error. The point of interviewing (especially at the early stage where this interview is applied) is signal, not certainty, and we do seem to be picking up on signal:

-- # of steps completed on the coding task is the strongest single signal of success at later final interview rounds. Candidates who have gotten offers (not from us, to be clear, so this is uncorrelated error) average ~1.1 more steps completed on our coding problem than candidates who don't. That's after we filtered a lot of the weaker results out, so it's sampling biased in slower candidates' favor. This is a larger gap between offers and non-offers than any of the other nineteen individual internal scores we record for each interview, iirc.

-- # of steps completed correlates with results on the rest of the interview in a way that is aligned with reasonable psychometric measures of quality, same as most of the other parts of the interview (see e.g. [1]).

If your point here is just that interviews involve somewhat artificial work and are prone to error - well, yes. Everyone involved in testing as a field already knows that and is working around it.

To use your concrete example, creating a problem involving "sussing out all the ambiguities and contradictions" for an hour would be asking a lot more work from candidates. If we did that, I bet we'd have people complaining about the lengthy workload of doing an interview (or simply not doing it, which would be fatal to us as a business). I would also worry that that's a much fuzzier skill to measure, particularly in a cross-organizational way. It's not that, in isolation, you could never create an interview to test ambiguity-resolution, it's that (at least in my judgment), it would be impractical for us to do so given what we are trying to do.

And finally, to this:

> I posit that a great one could finish 2-3 steps and an OK one could finish 4-5.

See [2].

-------

[1] https://bsky.app/profile/otherbranch.bsky.social/post/3lpcdl...

[2] https://news.ycombinator.com/item?id=43006330

> I am not sure I'd get the adjacent mines part correct on the first attempt

Yeah, getting to that point was easy. Solving that problem is where I got stuck. I'm sure I'd get it eventually, but getting to that point and figuring that out in 25 minutes is asking a bit too much.

The floodfill part (the last one), on the other hand, is the one that stands out in difficulty compared to the previous parts.

I thought it'd be fun to take a stab at it in Python, which I haven't used in a while, but only barely still remembered that I could accept command-line input with the built in `input` function, something I don't think I ever used after writing my first lines of code 15 years ago. Then I figured I'd use just lists instead of a numpy array but had forgotten that [[0] * 4] * 4 would just create 4 references to the same list. And that pretty much derailed the whole thing for me, even though I was sure I'd get it done in 25 minutes or under :-)

Alas, it’ll be a few weeks and by that time I’ll have forgotten :)

Minesweeper?

Huh.

No wonder the PhD candidate who was supervising us was surprised I did that as a fun little side project in my first or second year at university.

Still, I'm not absolutely sure I'd have gotten to the end of step 5 (correctly working flood-fill) within 25 minutes despite having implemented the whole game in Java, REALBasic, and JavaScript over the years.

On the other hand, that's probably good. 25 minute coding challenge where you're not even expected to get to the end as per the instructions* is much better than "take this, do it over the next week, might take you 8 hours, we'll spend an hour talking about it" as I've been seeing.

* "Very few people will finish the full problem. You do not need to complete every step to pass our interview."

The thing which makes SEs good is being smart and having passion. Self-taught selects for that. For young people, take a smart young person and put them through a CS degree whilst working. They'll be instantly productive and with a little guidance can be successful. Over time they become exceptional.

That was my path.

On the other hand, most people I know have at least dabbled in learning to code. In this case the cost of quitting is very low and the cost of getting good is reasonably high, so it self-selects for people who excel at it and love it.

That said, if you only compare people with similar aptitudes, my experience is that people with formal training are better.

tl;dr: The most important thing to me is comparing past work, interview and personality. If you have a CS degree with no personal projects, you won't get a job offer. If you don't have a degree but have active projects with good code then I don't care if you have a degree. That said, I have been getting hundreds of applications for every entry level job I post so I can normally find someone who has both.

I love small problems like this. I couldn't get all the steps in 25 minutes, but I think I was not that bad. (I was in stage 4 before time ended, got distracted about taking input with Rust, heh)

I think, working with these small problems would give my ADHD brain a boost before I start my daily works. If more detailed problem, I would spend the whole day on it, smaller would not give me much push.

This was just right!

I do not disagree with you at heart, but I think there are so many pervasive issues with modern education that I am not certain a high level of intellectual aptitude is necessary anymore. Hell, I somehow have a computer science degree which I honestly do not deserve considering how little I understood (and still do not understand). Then again, I didn't go to some prestigious university for the astute either, so take it for what it is worth.

Nevertheless, I feel like I learned a lot of information and was exposed to many topics at a surface level of understanding. However, there is little I learned that I couldn't have learned by just reading the textbook. In fact, most of my assignments and tests came directly from textbook or were similar enough.

I was trying to brush up on data structures and algorithms last year. Not because I was looking for a job, but because I always wished I understood DS&A on a more fundamental/mathematical level. I like details and understanding the 'why' or 'how' more than the 'what.'

I remember watching lectures of a professor on Youtube (Dr. Skiena at Stony Brook University). All I could think was how there is likely a slim chance in Hell that I would have made it through his class nor Stony Brook.

Overall, I think most of the difference is down to desire and motivation. Many of my fellow students at the time, cared little about computer science or programming. Most did just enough to get the piece of paper so they could start making 'real money' as they often would say. If one is capable enough to teach themselves how to program, then I do not doubt those individuals are capable of learning computer science to a level equivalent to me. Sure, they might not obtain a PhD level of understanding, but then again, the vast majority of bachelor degrees do not either.

I still take on faith that a kernel is some black box, some thing that just … works. It seems to manage memory, threads to some degree, the file system…?

> I'm really struggling to believe that a majority of people can work through that material and then can't do the type of work that most developers do.

In practice, the way maths and sciences are taught to CS students is without demand for any ingenuity. Most of the time, students don’t prove theorems, they only perform rote calculations according to an algorithm. The few proofs that do show up are things like a few very basic proofs by induction, where students are basically given the algorithm how to solve such a problem beforehand. Statistics, same story – fit a problem to one of the template solutions you were given earlier. Physics, same story.

That’s what for me explains why in my experience maths graduates have been better programmers than CS graduates (as work colleagues). And why some people in this industry hold it as a badge of honour that they can’t invert a binary tree.

I've been in quite a few orgs now where business run roughshod over dev and people are seemingly unwilling to stand up for the big picture even just stand up for basic best practice. The absolute insanity of code I've seen, all maintained by degree educated engineers who don't seem to care that much about the long-term future of what they work on.

I worked in a business unit of a fortune 500 org with a unsecured build server where everyone was told to log in over http with their org creds (i.e. the creds that give you access to everything in the org and are effectively your corporate identity). Granted, it was on the internal network but they had that setup for YEARS, with a privilege escalation just out there waiting to be discovered. I had a workaround but that expired due to some network changes, so it came to a head, they refused to give me access to install a cert myself and then I was the only one putting my foot down about it. I got put on disciplinery and was then forced to reach out to the Corpo HQ security team and then got shit-canned in my business unit as a result. I still cannot fathom how people in more senior positions than me, with apparently better educations than me, square that one in their head, like I was the problem. To me, its like the technological equivalent of not having any toilet paper in the bathrooms or something and thinking it isn't a problem.

This isn't really surprising and can hardly be unique to our industry. I think you can ask anyone in any industry if they have to deal with chronically incompetent colleagues who, despite of all external indicators (degree, education, background, etc) saying they shouldn't, still just suck at their job. They will all reply that of course they have to deal with such people.

For a lot of people, this industry is just a job like any other. They and their brain clock out at 5 immediately and do not think about programming or software engineering at all until the moment they are forced to.

And obviously, that's fine. I can't rewire their brain. I just wish I didn't have to work with them.

Thinking back to early on in my career, there was one place I worked that was a complete mess, its pertinent because the first time I applied I was rejected immediately because of the lack of degree but the second time they interviewed me and I joined.

A representative example of the mess: They did waterfall and they'd analysed, discussed and dialogued about a "transaction service", they produced beautiful documents and UML. But it was garbage, it wasn't transactional, it slowly wrote to an xml file, in-situ over the course of an hour long workflow and had an unparsable xml file with a handle open for 99.9% of its lifecyle. This was an embedded environment for industry and the reality of power management and pre-smartphone battery tech resulted in crippling "corruption" issues that were obvious at the design phase which I had to fix later on (but even then, I wasn't allowed to radically alter "the design"). I had as much luck convincing them to use sqlite as intermediary and then producing xml at the end, as I did the other guys installing a cert on their server.

What am I describing here exactly? Normalcy bias? Just "bad" devs, idk? I've spent my entire career grappling with senior staff ignoring the valid concerns I raise and end up feeling like I'm the problem because I'm the only one stepping out of line to demand better, with zero support from my peers. Tbf the guy at that place at least admitted later on that "yeah sorry for not taking your advice, I always seem to regret ignoring it about six months later".

Maybe I've just got to do a better job of seeding ideas, so people think the ideas are theirs and accept them better. Maybe give them the ingredients of a very obvious sandwich instead of making it for them. Idk, I just can't help but feel discriminated against somehow because it doesn't make any sense to me to; not installing a cert on a server and rather forcing people to send their creds over clear; being vehemently opposed to using Sqlite (in more than one org!) when its an extremely appropriate option (in embedded or as an MSAccess replacement). Maybe on that http issue I should have followed my first thought and collected and sent that guy his own password to demonstrate the issue.

I’ve definitely first hand seen a lot of FAANG engineers (yes even them, some with PHDs) not realize something I had learned from experience during my first year working with computers and I’m certain I was missing things they learned early in university. In the end, together we solved some hard problems in spite of the unknown unknowns that each of us carried.

Most people excell with guidance and instruction but there are plenty of people who excel on their own and occasionally, because they don't know any better, end up doing something nobody ever thought to do or were taught was impossible.

What makes you think that? Simple example: I'm self-taught. Failed pre-Calculus in high school, twice. Ten years in as a freelance programmer, I decided to build the first Bitcoin poker room, and therefore had to write my own poker hand evaluator. I had no example to work from. No logic flow-chart. I had to come up with the logic to parse, rank and show winning odds on anything from 5- to 7-card stud, hold'em and omaha hands. I had to dive deep into Monte Carlo methods, statistics, etc. Meanwhile, I'm writing a HUD for Star Citizen. I'm reading and learning about avionics, working out my own procedural generators in mixed 2D/3D. And this was just one year of my life as a developer. Working 16 hours a day, 7 days a week. Couch potato? Forget about the fact that I was getting paid, not paying tuition to sit in a classroom. These were problems I had to solve, and the work output was immediately in production, and the results were immediately visible.

Talk about sweeping generalizations...

First let me say I definitely value the hundreds of hours you would have spent on hard theoretical problems and while I wasn’t exposed to your curriculum, I regret I don’t have that.

However, I myself have definitely spent a substantial number of hours on distributed algorithms that were only available as published research (didn’t have a choice and that understanding I gained has been proven out), and my extended family is filled with PhDs, so I’ve been casually reading research papers since I was in my teens, this didn’t seem weird. A lot of my peers with and without degrees didn’t engage in this practice.

To explain further, I’ve also spent I can’t even tell you how much time on benchmarking and establishing performance bottlenecks and near as I can tell, no one has in university, or at least they’re not teaching it well enough, because it is shocking how badly this part of performance is understood. Let’s call it applied practical performance enhancement of software deployments.

In the end, I just can’t fully be in board with what you’re saying. Yes I wish I had that degree nowadays and I wish I could take 4 years out and go back and do it again. But I seriously did gain a lot of valuable experience that was hard won with that extra time and near as I can tell is super duper rare, especially because people keep hiring me for it.

I have a close friend that's the smartest person that anyone who meets him knows, no question about it. He's got a PhD in Physics and has also contributed a huge technical achievement to a FAANG company, that everyone uses every day. He's great at a lot of stuff, but not everything. We work on side-projects sometimes, and I'm the self-taught guy in this scenario. I know that I bring just as much to the table as he does, just in different ways. If either one of us tried to do the things we do together, alone, the result would be less than 1/2 as good. Recognizing this and letting each other shine has served us well.

I can only think that teams made up of a mixture of people with different backgrounds would do better than a team of all CS graduates, or a team of all self-taught developers.

But when you are in the complex domain (as in there are no known good practices), what you want is many different viewpoints on the team. So getting people with different backgrounds (different academic background, tinkerers, different cultures, different work experience etc) together is the way to go.

Same with the discussion about remote work. People do not seem to get that they’re no best way but it depends on the type of work. If it’s simple or complicated, let people stay at home to concentrate. If it is complex, give them the opportunity, and the knowledge it’s good, meet up by a whiteboard. And what’s best may of course differ from day to day.

In a general sense, I find the self taught to be simply more inventive problem solvers. What you are using as a critique— “Self-taught individuals don’t understand what they’re missing” —I would say that can be a strength. However, you should perhaps think of it instead as “Because they are not prejudiced by what they were taught by others as ‘what is possible/impossible or ‘the best way’ they are often willing to try ans do the things that a degreed person won’t even attempt.”

>In a general sense, I find the self taught to be simply more inventive problem solvers. What you are using as a critique— “Self-taught individuals don’t understand what they’re missing” —I would say that can be a strength.

It is true that an outside perspective can be useful sometimes. However, more knowledge tends to be a net benefit. If you don't have a certain amount of training, this ingorance-driven "inventiveness" overwhelmingly turns into reinventing wheels and spending major effort on naive approaches to problems that are known to be intractible.

I think it is easier for a trained individual to learn to be creative, than it is for a self-taught individual to learn to not mess things up.

In those roles I lead development teams that were producing software products used both for internal and external customers. In my current role which sits product-side, I work directly with SWEs to produce a successful complex software product.

I am pretty sure I understand the complexities of software engineering and can speak to my experience with different developers from different educational paths considering it’s been a big part of my vocational journey for the last 27 years.

You may not have chosen a self-taught path and that’s ok for you. You may not be bound by a pattern bias because of educational rigidity like some others, but watch out that you don’t fall into elitism.

So, there is a difference between "leading" teams and having actual deep competency in the thing. I could hire a civil engineer or architect and "lead" them by giving them requirements and feedback, and I might even know the rudiments of what they do. That does not make me a civil engineer or architect.

>I am pretty sure I understand the complexities of software engineering and can speak to my experience with different developers from different educational paths considering it’s been a big part of my vocational journey for the last 27 years.

With all due respect I've met people with decades of experience on their resumes who could not write a lick of code. These people were overconfident in their abilities to figure things out by searching Google. I'm not saying you are in that category. But appealing to experience is hardly better than appealing to educational background. At least there is an actual accreditation process for CS degrees.

>You may not have chosen a self-taught path and that’s ok for you. You may not be bound by a pattern bias because of educational rigidity like some others, but watch out that you don’t fall into elitism.

I am reasonably open-minded. But certifications such as college degrees are labor saving devices. If two people are similar in almost every way but one has a relevant degree, the degree wins obviously. It takes some of the guesswork out of hiring. Of course, even people with degrees also have to contend with elitism against them, whether it is the type of crap in this article ("no degree is better actually!") or someone nit picking about the rank of your university or even your GPA, or how many degrees you got, or the title of your program... My point remains, this article is wrong. Most training undertaken at reasonable expense is worth it, especially the standard bachelor's in CS degree.

In my original comment I said this: “I would have definitely given an advantage to a self-taught dev over a CS grad provided that they were generally equivalent in all other aspects for the role.”

…and I stand by that wholeheartedly. I get that you are trying to justify (likely your own) education here, but what you characterize as obvious simply does not jive with my experience. My education provided knowledge value that lasted about 4 years into my career before tech evolved enough to make it effectively obsolete. Your CS degree will have about as much functional longevity considering how fast things are moving nowadays too. You get beyond 10 years out of school, the stuff you did in the last 3 years will have more bearing on your current than anything you did in university.

Perhaps you are in a position now or will be in the future and you can use your own logic in your hiring criteria. I hope it works for you. My logic was certainly successful for me.

Yes, my point is that the CS grad has done 4+ years more work in the field than a self-taught individual. Unless you are assuming identical skill or knowledge as if the self-taught guy had more experience or something to make up for not having a degree (thus not identical in the straightforward way).

> My education provided knowledge value that lasted about 4 years into my career before tech evolved enough to make it effectively obsolete.

I very much doubt that. Software engineering and even hardware resemble the stuff that existed 50 years ago. Some of the same languages are still in use. When there are new innovations, they are rarely reinventing the way we do things in such a drastic way. Your background knowledge will help you learn new things easier.

>You get beyond 10 years out of school, the stuff you did in the last 3 years will have more bearing on your current than anything you did in university.

Ironically I am doing advanced work in the same languages I learned first in university, 20 years ago. There are some innovations I've had to keep up with of course, but I think my education served me very well. Could I have done it without going to college? Maybe, but it's doubtful because college is literally taking years off of full-time employment to dedicate yourself to study. Would anyone have given me a chance and suffered my blunders as I tried to learn on the job? I doubt it, even though I know people who have made it without a degree. In this market, I have to say that the bar for anyone not having an appropriate degree is high. I'm certainly not giving preference to people with no degree. At best I would consider expect them to have to compensate for not doing what everyone else does.

I’d say it’s the opposite. Self-taught folks I know and have hired started their careers earlier than 22 and have had more practical, “actual” experience than their university graduate counterparts at the same age. Also, a university grad with a CS bachelor degree is not going to have anywhere near 4+ years of more field work unless they have been in school for 6 years and have moved slower through the program. As I said, “generally equivalent in all other aspects of the role” sort of assumes equal knowledge or experience anyway. My distinction is more around the tendency of self-taught towards creativity and inventiveness in problem solving outside of learned patterns from their education. They don’t rely on those crutches

We will obviously never agree on this-your theory and arguments simply don’t jive with my lived experience. Good luck.

This whole discussion is fraught with problems. I posit that for those people who feel that they need to sell the fact they have no education, they also lack sufficient experience to be marketable. Certainly, for people with little experience, the person with a degree is objectively more credible than the person without. There may be some self-taught individuals who are amazing in some way, but I think the only reason you ever meet these people to begin with is because the less interesting ones get filtered out. In other words, if you are looking for guidance, not going to university is a bad idea. If the bias against education picks up steam, then you might do even better to go to university then pretend to be self-taught after you have a bit of experience lol. As absurd as that sounds, it jives with what you and the article are claiming.

However, I’ll admit I have a bias based on my experience, and that certainly results in my assuming more inventiveness of the self-taught. Perhaps I have been lucky on that front. Reality has been that not every self-taught dev has been great and not every CS grad has been bad. However, if I lay it on a balance, the balance for me leans a specific direction when it comes to the best people that I have worked with over the years. Perhaps you are right and I have just been lucky.

>There are assumptions on both sides. I would say that a big one on your part is just assuming that everyone with a CS degree is by default a competent and capable developer because of their education.

I would never assume such a thing. But for sure, the odds are good.

>Every CS program, professor, and student are not the same and that variance eliminates any self evidence of credibility of a CS degree.

Well, every accredited program passes certain criteria evaluated on a regular basis. Any student who graduates from one meets the minimum requirements. What are the minimum requirements to claim to be self-taught? There literally aren't any. You just have to bullshit your way into the job. We could potentially accept a lot of self-taught people in other fields. Do you want to drive on a bridge made by a self-taught civil engineer, have your blood drawn by a self-taught nurse, or deal with self-taught drivers on your way to work in the morning? We have credentials for good reasons, even if it may not be strictly necessary to do the job on a logical level.

I am beginning to think that your good luck with self-taught colleagues is potentially evidence that only adequately talented self-taught people can make it in the field, in the long run. And software is far more welcoming of self-taught people than just about any other field, certainly among the hard technical fields. People in the arts are very often self-taught, of course.

I’d accept that, certainly the ones competing for positions against CS grads are going to be the more capable and confident (more than just in bullshit to get the job) where the less capable self-sorted out of the vocation.

> And software is far more welcoming of self-taught people than just about any other field, certainly among the hard technical fields. People in the arts are very often self-taught, of course.

In a way this kind of speaks to my point. Software development has both a technical and a creative component, perhaps not in equal parts, but different problems in our space might be a different mix of each. Most of the projects I have been involved with probably leaned towards requiring a a more creative mind and perhaps this has colored my opinion.

I’m sure my education was more structured than a developer who didn’t go to school, but I don’t feel like there’s a huge fundamental difference.

Like if you’re only “learning” from what people teach you then how are you going to be successful in software?

I mean, I was so curious, I started coding as a kid and got a tech job right out of high school. But I quit it at 19 because it didn't answer any of my questions about life. I moved to another city, waited tables, bartended, joined a band, drove a taxi, wrote a few novels, and started making indie games on the side. Eventually, the thing I found that I was most curious about was actually the intersection of code and art, and the way those things could be made to play off each other. That was the language in which I could best express myself and do truly original things.

To be intellectually curious is a rare thing these days. It's the main deciding factor if I'm hiring someone. Or going on a date.

Absence of intellectual curiosity has always been the default state of humanity. I don’t think there has ever been a time when it wasn’t rare.

(Funnily enough, I asked GPT-4o just now what the requirements were for joining Plato's Academy, and it said this, exactly):

The requirements for joining Plato's Academy were not formally codified, but there were some general expectations and practices:

    Intellectual Curiosity: Prospective students were expected to have a strong desire to learn and engage in philosophical discussions.

    Age and Background: While there were no strict age limits, most students were young men, often from affluent families, who could afford the time and resources for education.

    Philosophical Training: It was beneficial for students to have some prior knowledge of philosophy or related subjects, as the discussions at the Academy were advanced and complex.

    Commitment to Dialogue: Students were expected to participate actively in dialogues and debates, reflecting the Socratic method that Plato valued.

    Moral Character: A commitment to ethical living and the pursuit of virtue was important, as the Academy emphasized the development of the whole person, not just intellectual capabilities.******

In some cases it makes more sense to the business to approach an original solution as determined by external constraints in the project, such as eliminating dependencies, achieving a superior performance target, or unique security constraints.

Usually the primary concern in the big corporate world is hiring and firing, everything else be damned.

I'm a hybrid of self-taught and formally trained developer, with a chaotic twist. Most of the time, I do normal work. Sometimes, the megacorp hits a problem that it cannot solve; when that happens, I'm summoned from high-up, summarily briefed and then air-dropped like a paratrooper into unknown territory.

I'm the one called in when there's no one else left to call. There's nothing I can't seem to solve under these conditions, but I tend to deliver Faustian solutions: I'll save the day, but it will cost you. I won't go into details here, but some of my unholy and heretical contraptions I've produced in those situations took years to subsequently defuse.

Interestingly enough, I share the same hybrid of self-taught with some formal education. And after checking your blog, we also share interests in some fairly low level, niche fields, even if we choose totally different things to focus on.

Even in "non skilled" positions if you carelessly or too-frequently restructure or lay off, if you create too many silos you're going to damage the situation of unique humans and unique tasks where the contributors seek out tasks or adapt themselves to their work in order to be productive and comfortable.

I don't understand (despite being familiar with the propaganda required to create the situation) how it persists that folks can realize the need for product-market fit and differentiation, that the personalities and individual nature and skills of executives are valuable, that we need to foster a mutually-respectful relationship between charismatic B2B sales and purchasing teams but labor? Pshhhh. Just a drawer of cogs.

You will have “results,” sure. The code is merged and deployed, tickets are closed, launch announcements are made, and attaboys are issued in semi-annual reviews. Those “results” were never quite right though. Now as that feature slowly gains adoption it begins to haunt the team, literally keeping them up at night. It’s already entrenched now though, and will be an absolute nightmare to correct. You shouldn’t let the perfect be the enemy of the good, but you also should not let the dubiously okay be the enemy of the good either. “The first draft of anything is shit” — Hemmingway

Generally, self-taught programmers make shit like this up to feel good about themselves. What are the odds that the article is also written by a self-taught programmer?

The truth is, most self-taught programmers don't actually learn enough to make it in industry. The ones that do make it pass at least some threshold of knowledge at some point to be able to stick with it.

There may be occasional gaps in "practical skills" like using particular tools and libraries among college grads. But these skills are easy to pick up on the job. The advanced stuff that really benefits from a bit of handholding is taught in school, which self-taught programmers skip entirely.

Every single person who writes code frequently will be better with a solid understanding of DSA, doesn't matter if you work with mainframe systems written in cobol or SPAs written in react.

I scare the living shit out of consultants, because a lot of them made the mistake of assuming I'm just a dumb firie - the uniform means I don't look like my corporate IT peers at all - but quickly recoil and backtrack when I ask direct technical questions they don't expect and should know the answer to, or call them out on their misleading (if not outright false) statements.

My supervisor loves me, even though he doesn't love the disruption as much, because it leads to better outcomes for the organisation.

I hire consultants from a big corporate and I think they’re used to clients having no idea how to ascertain their projects in terms of reasonable effort to accomplish the set goals.

I'm usually trying to rein in the chaos of an over-engineered mess or explain docker containers and CI servers. Definitely makes for an interesting day switching between the two types of clients!

That being said, I prefer to work with smaller companies. I'm usually the only consultant, and I'm a freelancer not part of a larger consultancy. This probably significantly changes the types of teams I meet.

Self taught people are naturally filtered. The ones that arent able to come up with a solution in unfamiliar territory arent employed.

People who come up through regular education channels arent bad but arent great either.

People who worked everything out themselves, and then undertook tertiary study to ensure that not only are they doing things well, but are doing them correctly, are absolute power houses and cannot be stopped.

N=1. I remember showing an incredibly competent CS colleague something I'd knocked-up one evening for fun.

They were super-impressed that I did _any_ coding out of hours, and suggested I try and sell it. Totally different worlds.

(as an aside: "don't overengineer things" is great advice when your goal is to actually finish creating something useful, but imo if you're coding to learn then horrendously overengineering everything is super valuable to the learning process - you should totally set up a full custom CI pipeline, design your own networking protocol, write a parser for a DSL etc etc in service of your dumb little tic tac toe game or whatever you're making - you will learn things)

I treated GLSL how others treat Civilization VI. “Just one more shader” - “Oh no it’s 4am”.

Doesn't everyone who has learned how to learn? Learning is way more efficient when you already have forward context for why you are learning something. Nebulously studying addition and subtraction without being able to see that it leads to multiplication (to stay with your example) is an absolutely horrid situation to find yourself in.

In fact, I suspect that's exactly what the article is really trying to get at: Those who "learn backwards", which happens to be a trait commonly associated with self-teaching, outperform.

And that doesn't even touch on the fact that most professors have absolutely no clue how modern software engineering is done. The courses are planned by even more out of touch heads of departments. And the quality of most of these student's projects is atrocious. How could they know better? They've just got a tiny micro assignment to do, and maybe 50-100 lines of code per assignment.

I'm not trying to be too pessimistic, but let's be real here and say a modern CS degree is a terrible way to be trained to be a modern software engineer. You'd be just as likely to succeed with a degree in mech engineering, biology, chemistry, physics, math, philosophy, or accounting. Or spending a year or two working on an open source with some mentors.

Granted there's also a huge range of quality of degree programs. I regularly hire Drexel students who shock me with how good they are, but that's a 5 year degree with 18 months of on job required training. That's a degree made for turning out quality software engineers.

My coursework to finish all my classes had me write a grand total of under 4k lines of code. And I finished those courses with high marks. That's such a small amount of code, I remember graduating and still being confused what a function was. It's unbelievable I paid almost 6 figures and spent 4 years to not even learn what a function was. I think that I'm not alone in this.

By the time I landed my first job I think i worked harder on personal projects than I ever have at work. I also ended up tutoring proper CS nerds in things like graph theory and functional programming concepts.

So, YMMV.

One thing I have learned is that it’s not enough for a junior/intermediate programmer to practice practice practice. They also must read. I respect self-taught devs (I am one), but self-taught devs who don’t read books plateau quickly.

Yes, there is something to learning in your own way, in the "play" explorative style that humans are so very well adapted to.

However, there is definitely something to be said for proper training by a professional. A big part of my early career involved unlearning bad habits, learning the compsci tools that my peers already had, and learning to think holistically.

It's a lot like learning guitar. You can learn it yourself, and some people can even really excel that way. But maaaaaan, when you've been trained by a professional, the effort required to play well goes WAY down thanks to the centuries of knowledge, skills, and techniques you're taught. All the bad habits you DON'T pick up are so worth it.

There will be talented, creative people coming from both paths; professional instruction isn't going to diminish that. All it does is amplify what you already have.

In my computer architecture class, there was a lab/test where you were expected to implement strlen() in SPARC assembly. It was open-doc, but they intentionally hadn't taught some of the opcodes you'd need to inspect a single byte. Maybe 25% of the class poked around the docs and found something, but the rest floundered and were quite angry at how "unfair" it was.

But I'd like to add that that's not really why I do this job. I do it because I find it vastly entertaining. Maybe you're right that CS grads are averse to unknown areas, and work better as team players ("cogs" is a bit harsh), and it's true that autodidacts try to save ourselves time instead of doing things twice. Sure, I hate boilerplate and drudgery. But for me the thing is, I love when I get a fresh problem to solve, that causes me to learn new techniques along the way. That's what makes my work feel like a joy, like a hobby, something I'm excited to wake up and do, and spend all night teasing out. And because of that, I self-select for the jobs that will give me that feeling, and I turn down the jobs that feel repetitious. After all, I should get something out of it more than money, and I can't sleep on improving my skills, right? So in those tasks, I'm doubly motivated and I'm probably far more productive for that reason than even needing to prove something, or because I'm aware that I'm being relied on as an irreplaceable part.

I guess this is a roundabout way of saying that once you decide to drop out, go independent, and live a certain way, the stakes are a lot higher, and the people who make it in that arena are people who will always put in a lot more effort. Giving up the 9-5 didn't mean I started choosing my own hours. It meant I became on-call 24/7 to my clients, for decades. And yet I wouldn't give up the freedom of being able to do that from any country in the world, or being able to choose my own projects and choose how I'd implement new ones. Dirty secret: A lot of times with a new project, I know how to do it with an existing technology, but I use it as an excuse to learn something completely new and implement it in a way I never would have. I don't charge extra time for my learning or trial and error, but I consider it a gift that I have the freedom to do that while I work.

Bonus points if most of their experience is in nebulous freelancing. One of them admitted once that they didn't earn anything in his 2 years of "freelancing" on his CV.

Of course, your mileage may vary. Good engineers are exceedingly hard to find in my country, much more so than in California.

You're gonna find lots of crap devs in both camps, and 100x devs in both, in fact some of the worst I know where all graduates who only went into CS or SE for the job prospects, but never gave two damns and suck hard at coding or problem solving.

But I don't think that it's true what you say, maybe you simply haven't met the exceptional graduates because they went in companies different than yours.

Hard disagree, as someone who had a stint as self taught before getting a CS degree. Once, I wasted a whole afternoon figuring out graph-traversal & loop detection from first principles[0] -if had I taken DS&A class, it'd have taken me all of 2 seconds to choose between BFS and DFS. Attentive CS graduates have a structured pool of information to draw from, as well as the language to describe the issue when they have to dig deeper.

> The computer science graduate will generally not even try to figure out a problem in completely unfamiliar territory

Do your colleagues actually do this? I'm curious about the mechanics- they just say "Sorry, that can't be done" and everyone moves on? Passing the buck feels to me more of a junior/mid-level/senior concern, rather than self-taught vs graduates. Juniors have the latitude to make challenges someone else's problem, and ownership grows with seniority.

0. For a C-program stack analyzer, it has to parse C code, generate a call-graph, and spit out worst-case stack-memory usage.

"Hey ChatGPT, explain me how BFS and DFS work, their differences, pros and cons, and which one fits my use case better."

Granted, an autodidact programmer might have encountered the concepts, but a CS graduate must have.

In my case, I was an autodidact well before I went in for Electronics Engineering. Because of personal interest, I put in a lot of time into these things, and did get to know them, but didn't really hear once about them in EE.

I guess if one engages long and deeply enough, they'll get to a high enough level - they'll acquire "sufficient expertise", per PG's turn of phrase. Conversely, no amount of CS courses will get one any wiser if they don't pay attention.

Everything always depends.

Yes, but a self-taught Developer also has their own pool of information to draw from. That could be prior experience, but it can also overlap with the CS graduates' pool of information.

You don't need to take a DSA class to learn DSA. There is a wealth of information out there for self-taught developers to learn these kinds of things. From textbooks to YouTube videos, it is all readily available for anyone.

Self-taught does not mean you need to invent everything from first principles.

It does imply lack of access to formal resources, though. Learning from a textbook or an educationally-minded Youtube channel is no more self-taught than sitting through a lecture in college.

It is ultimately a distinction without a difference. Historically, when information was siloed, there was a difference. Self-taught meant something when you couldn't look something up on a whim. But those days are long behind us.

Going to the library or buying and reading books is not formal instruction, and neither is watching Videos. There is no one to guide, help, or check on progress.

I could watch the entire MIT Intro to Algorithms Course on YouTube and still be self-taught, because watching that does not make me an MIT Student and it does not make Dr. Jason Ku my instructor.

Yes, but management at every level also anticipates it up front before the typical developer or developer team has the chance to get there.

Some wood (or metal) workers take pride in making their own tools, and others, who are like me, buy off the shelf tools and use them to make actual things that people buy.

As would someone with a CS degree and "are intelligent" in the sense you describe. Early hackers who gave us fine software were computer scientists.

What you're describing isn't self-taught vs. formally educated. It is curious vs complacent w/ a heavy sprinkle of hard work, creativity, and intelligence.

Both groups can have those traits. Self-taught can ONLY work well if you have those traits, so maybe you more obviously see it in that group since it's a requirement to succeed when self taught, whereas a classically trained engineer without those traits will probably still "make it". An engineer with those traits and the formal education will do better than either category most of the time.

Self Taught -> Already is curious, be default, so 99%-100% are curious. Just by the nature of going out of the way to learn something.

Educated -> Also has a curious % in the group, but also has the large group of complacent "i heard software makes money so i'm hear to learn it, but i don't know what i'm doing". So when you do find complacent, they mostly came from the educated path.

Curious people got high on the caffeine and code, and the other group just got high.

"Locking-in" on some esoteric topics just because one wants to is probably the best way to improve in my opinion.

On the other hand I have been through a pretty generalist undergrad education in engineering and it helped in acquiring general math, physics, chemistry knowledge.

I was already a nerd when I was attending the university. My chance was my instructors and professors let me roam free and convert every assignment to a rabbit hole. Poisoned by demoscene earlier, I was already an elegance/performance freak before even I got graduated, and this made me dive into unknown territory head-on instead of being afraid of it.

I have written a compression algorithm from scratch for graduation, then written a multi-agent trading system for M.Sc. project. For Ph.D. I have written a BEM based material simulation which was able to saturate the system very effectively, reaching practical IPC limits of the processors it ran on.

> Self Taught -> Already is curious, be default, so 99%-100% are curious.

There is some of this but IME that % is half your estimate, if not lower.

It could be different in today's market because CS IS NOT where a lot of jobs are, and my observations are based on when it was very very hot, so there's that.

But, no matter what you or I say anecdata is not data, but in my 30+ years of doing this, I find these broad generalizations mostly wrong.

I've since realized that it might have been the easiest job ever if I didn't have any curiosity, and didn't overcomplicate things or care about quality, because nobody did. I don't think that's the difference between a CS grad and a self-taught person, but it might be what drives a self-taught person to pursue it at all, whereas I've met many in CS who are just there because they were capable at math or made the call to do that degree instead of something else, and some of them really panic when faced with ambiguity. For me, if there's no ambiguity or no aspect of creativity, I just get bored and zone out (yes adhd). Just different alignments in some cases.

Formal training brings with it information that others have shown to be vital knowledge that must be known. No doubt many self taught people master a profession better than those who've gone through formal training with a complacent attitude but it's the latter's training that guarantees students master certain points that the self-taught might put less emphasis on.

I'd be much happier crossing a bridge built by a structural engineer who has had certain rules (safety margins, etc.) drummed into him ad nauseam.

That sounds rather foolish. That must have knowledge often becomes a layer of vanity concerns to cloak the ignorance lying beneath as defined by comfort and not utility.

For example if developers are formally educated in the style of OOP with classes for inheritance then for most of those people all programming must resemble that style even when it does not apply and costs more to use. Any attempt to deviate from such familiarity often results in purely emotional responses. This such nonsense becomes frustrating when it unnecessarily limits work progression.

> a bridge built by a structural engineer

Civil engineers are qualified by license while software developers are not. That distinction is monumental.

Structures are one-and-done projects with engineers having access to concrete data on material strength, load calculations, etc.

Software projects are never ending, always chasing ever changing requirements. There are no comforting rules of math and physics to fall back on. There are no "load and safety" calculations that another software engineer can perform on a program to verify its integrity.

Exactly, and that's the problem. Writing software isn't engineering (it ought to be—my opinion and that of many others). Read this (things are actually worse since it was written):

www.researchgate.net/profile/Wayt-Gibbs/publication/247573088_Software%27s_Chronic_Crisis/links/0046353b4cb57cc197000000/Softwares-Chronic-Crisis.pdf?

That said, I think we sometimes tend to overestimate how structured projects like bridges are, and that almost everything we have discovered about software projects applies there too, just to a less extend - delays, changing requirements, unrealistic planning, last moment extra requests etc. etc.

OK, so what happens when the weak link in the chain in building a bridge or other critical structure like a plane is the software that helped design it?

So-called software engineers want their cake and eat it too. They aren't prepared for the rigors and discipline of real engineering yet they expect to take equal part (and claim credit) in engineering projects.

That's how we get disasters such as the 737Max and I'd bet London to a brick it won't be the last.

I'm not alone in holding this view: https://www.fceia.unr.edu.ar/asist/gibbs00.html

If the bridge passes inspection and is considered safe then your attitude would be a form of elitism no? The point from some of your parents is that they can do just a good of a job or better.

What I said has absolutely nothing to do with elitism. Your point is a circular argument that spirals inward and ends up going nowhere.

Professionalism and excellence not only have to be learned but also require diligence and persistence under the guidance of skilled professional educators, it's why we have universities.

It's nonsense to suggest that parents can do a better job than professional eductors/training. Perhaps that notion comes from only-in-America homeschooling.

Where I come from we'd never entertain the idea for a moment.

To put it more simply, you have a misunderstanding that going to school means your better in an age when every bit of knowledge is available online for free.

I’ve worked with so many engineers with degrees that just churn out code. None of them seemed to care about maintainability or anything other than checking the boxes for the next promotion. A self taught engineer cares so much about the craft to teach it to themselves. The knowledge gained is the same, and syllabuses from major colleges are available online for free. The only thing missing is passing the tests for the piece of paper that says you passed the tests. That’s it. I’ve also found that most people with a degree only care so much about the craft as they care about not having to go back to school to learn a new one, or to put it another way, they are only financially invested.

> Where I come from we'd never entertain the idea for a moment.

Where exactly is this so I know not to visit? I’m one of those degenerates that are self taught so you should let me know so I stay out and don’t offend you.

I'm not saying it's the better approach but I would often prototype two or three designs (in a few days) to a point where we could evaluate their shortcomings, test performance, etc.

Engineers with a CS degree were more likely to spend that time white-boarding and write the code once. Since I cannot remember a time when the two approaches were taken on the same task, I cannot say whether the final product was better in one case vs. the other. To my (pragmatic) mind though, my approach was already battle-tested to some degree. (Or rather it was battle-tested against other approaches that ultimately lost out — the CS approach was simple understood to be the ideal approach.)

But let me also be clear: I benefited and learned a great deal by working with CS majors. Fortunately there were a few engineers I worked with that were happy to mentor me (starting with you, David).

I think though, perhaps after ten years in the field, experience ends up erasing any real differences in how any engineer might have begun their career. In time I was more likely to take the Right Approach on the first go and the CS major too would give the whiteboard only a passing thought as they too might go straight to the approach that they now "intuitively" knew was the Right One.

I'm likely generalizing though — and perhaps my impressions are also colored by what I want to believe is true (so romanticizing a bit as well). Perhaps others will chime in to refute or echo my sentiments.

Starting from pure abstractions and then maybe dipping into hardware level concerns in later courses seems completely backward to me. Certainly, you can become a very useful employee without any hardware background, but there is a particular spider sense you will not have when presented with scenarios that a hardware person will feel in their bones. The most common manifestation of this is disrespect for memory heirarchy and latency of computational elements relative to each other.

The CS course material became deeply interesting to me only after I encountered specific problems where digging into the theoretical min/max of different algorithms started to produce value in actual projects. When looking at things from the perspective of upper bounds, you will typically find that N is small enough to not matter. Only when it becomes large do the fancy abstractions make any difference at all on actual machines. If your working set fits in L1, O(N^2) scaling probably won't be something you notice in your profiler.

I don’t know how it is elsewhere, but computer engineering here is regulated by the local engineering board — as the graduate can continue to become a professional engineer — and has much higher standards than the CS programs.

I still don’t think computer engineering programs teach anything that you cannot learn yourself, but the base bar of what is required to get a degree is higher than cs where I am.

Over a long enough career I think we all see that a high percentage of interchangeable cogs at the BigCos end up with a lot of wealth and very little job-induced stress. Whereas among those who chafe at cogdom and “care about the code,” a tiny fraction make it big while most carry more stress than they should, shoulder more day-to-day responsibility for making things work, and do it for less reward.

I don’t regret being wired for creativity, but the boring people are doing great in this business. Maybe AI changes all that soon, but I wouldn’t dare to bet on which direction it splits.

The people who outperform are people who love computers and hacking on them. Some such meet programming at University, more and more anyone who loves it will already know that before starting classes.

The range on skill and experience in this field is too big to be near the top if it's just a job. It's fine to have it be a job, but that's a different persuit than aspiring to be a top hacker.

> The computer science graduate will generally not even try to figure out a problem in completely unfamiliar territory.

This is interesting because I have seen the exact opposite. It could be different circles we run in, but I've seen a lot of self-taught people who are in it for the money and couldn't care less about doing anything novel. Where a lot of my college colleagues (mind you, this is from the 1980's) were in it because they loved it, and look for new stuff to learn.

I suspect the distinction here is not self-taught vs. college, but rather do it at least partially for passion vs. the job benefits.

I'd bet we both have confirmation bias to our own backgrounds here.