Self-taught engineers often outperform (2024)

I'll concede that most CS curricula are so far removed from practical development (intentionally) that it is not an immediate indicator of performance, but to suggest that 85% of CS grads can't figure out a problem in unfamiliar territory seems ridiculous.

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 yield traits you're describing (and described in the article). Some people who have that didn't study CS. A lot did.

This mirrors my experience of nearly 40 years in tech as well. In the past when I was in roles where I was hiring SWEs, 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.

Eventually figuring it out is not optimal in mega corp. If you are in eventually figure it out territory than you are using the wrong cog for the job. Find the right cog in the drawer and you will have the results faster in most cases

>The computer science graduate will generally not even try to figure out a problem in completely unfamiliar territory. Of course this varies by personality, so this is probably only true for about 85% of the computer science graduates. They cannot proceed in the face of high uncertainty.

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.

I want to ask just to ensure I'm not getting an unrepresentive sample; is it just me or are college educated developers often complete walkovers?

I've been in quite a few orgs now (and always the only self-taught) 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'm starting to wonder if academia also teaches compliance to hierarchy as part of the process.

I worked in a department of a fortune 500 org with a unsecured server where everyone was told to log in over http using basic with their org creds (i.e. the creds that give you access to everything in the org and are effectively your corporate identity) everyone merrily did this without question, except me.

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 allow me 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 (who did side with me) and then got shit-canned by 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 wearing pants, and it just baffles me that my demand to wear pants was framed as the problem.

> The reactive ingredient is passion, not the learning modality.

As a self-taught programmer I agree with this. I started teaching myself on 8 bit computers in the mid-80s and didn't go to university. By the time I got my first full-time programming job, at the age of 19, I'd already been programming for 9 years. By the time most people are leaving university I was already nearly 15 years into my programming journey. It's hard to ignore that kind of passion and drive.

I'm now four decades in and love it in the same way I did at the start. I'm a maker, I like making. I keep reading the papers and am constantly interested in where this thing is going ... and I write a lot of code!

However, I don't like the premise that self-taught engineers lack foundational concepts just because they didn't go the academic route. I think many of us find the academic aspects just as interesting -- it really depends on the field you're in I think. For sure, we don't normally have the time to do a deep dive of something, but by the time you're decades in you've probably got just as many if not more 'foundational chops' than someone who spent a few years at school.

Anecdotally, as someone who's hired and fired plenty over the years, I think there is something to the Self-Taught Engineers Outperform theory. But I think it's purely that they spend much more time doing. They do more in work and they do more in their free time. The passion brute-forces the learning.

Yeah, being lead to some water does not create dependence on being lead to all water.

If there is a consistent argument, it's that self-taught people have all demonstrated leading themselves to some water.

> The reactive ingredient is passion, not the learning modality.

Sure, but passion also drives self-teaching. It's less necessary in a classroom setting because there's always someone trying to keep you on track.

> Self-taught approaches tend to be goal oriented (I'm learning X because I want to do Y), which can overlook fundamentals that are important.

For some, understanding a system can be a goal in itself.

> When you don't know what you don't know, having someone to efficiently guide you can save a ton of time, and for some topics, that mentor is a great textbook or teacher.

A bit of a self insert, but I think you described the reality so well that I wanted to offer my own anecdote.

I'm somewhere between formally educated and self-taught. I did not complete higher level undergrad maths like discrete or linear. Because of this, my vocabulary is lacking. I don't even know what to google, even if I could teach myself!

Some subjects really benefit from instruction and direction. It's actually hard to find a math tutor to proof your vector math program in your late 30s. My colleagues either forgot or are using that energy elsewhere.

> mixture of formal and informal/self-taught

That's me. Took plenty of college classes, but never tested well, so never got a degree. I learned most everything on my own, but those classes were a foundation for what I taught myself, and I couldn't have done it without them (as quickly).

I wouldn't group boot camp graduates and self taught people together. I'm confident there's skilled people coming out of bootcamps, but the people I know personally saw it as a cheaper shortcut into the field because they couldn't teach themselves and would have otherwise gone to a university or chosen a different field.

Coding bootcamps weren't really around when I started, but I avoided online courses and traditional learning methods. I would have also avoided bootcamps for the same reasons. I wanted to create and solve problems that were exciting, rather than follow through a textbook and take tests.

I'm self-taught and learned C in my early teens because I really wanted to do something that I couldn't find any code or preexisting solutions for, and I knew C was really the best way (for me) to solve it. I didn't want to learn it but I wanted the cool thing more, so I struggled through forum browsing, reading documentation, and trial/error and successfully got what I wanted while gaining more skills that led to where I am today.

The desire and drive to learn something matters more than the method, in my opinion.

The culture of CS departments at some universities before the tech boom was also deliberately antithetical to almost all of the things that people now mention as being great about university.

* Courses designed to fail out many students * Courses designed to extremely theoretical and impractical because teachers found them fun to teach * Making the subject inaccessible to as many people as possible

When I went to uni in the UK I didn't study CS (now senior dev at a large US tech company) because of the above, the subject had the highest fail rate, had the most unpleasant faculty, and had the highest rate of unemployment after graduation of any subject (this was a top 5 CS uni that only took people with top grades).

It is great if people got something from their experience but this isn't how it goes for most people. And, from working with many people who have CS degrees, you do still see issues: poor communication skills, poor business understanding, often have significant trouble prioritizing work because of the previous two issues, etc. In other words, some can code (even there, grads come out...not great) but a CS course is usually not a comprehensive education to work anyway.

I am not sure what represents comfort zone more than the way most universities teach any subject.

This is gonna sound like an old man yell at clouds post but...

I also remember university being great. I built a compiler, a toy OS and interfaced with GPS.

But a few years ago I was invited to teach on another university and I was very disappointed. The curriculum was basically a modern bootcamp stretched over a few years with a lot of unrelated classes sprinkled in. (EDIT: I just checked it and: lots of business, management, humanities, chemistry, environment, entrepreneurship... and one e-sports class?).

Almost no fundamentals, except for an algorithms class, almost straight to React and a few backend frameworks that were popular in the startups in the area.

> University classes are great.

I don't think anybody denies that, but getting into and paying for a university is very much a financial and social class issue.

> When I was self taught I would never have pushed through learning the socket API in C, doing so many projects in bash

You speak only for yourself though. I'm largely self-taught and have done these things.

> I interview a lot of self taught people, or boot camp graduates

These are often two very different types of job candidates.

> they fall apart when you ask them about academic topics that are relevant for the job

Yes, I do tend to fall apart in audition-style job interviews. But I can solve the same problems when just left on my own, with nobody standing over my shoulder.

That's exactly what it is. Somebody who is self taught is _by design_ somebody who's extremely motivated and interested in the subject.

I fully agree with you, I have similar insights (deep technical texbooks are also great), but I have to say that the value you extract is not equal depending on how you approach it.

If what you are learning is purely theoretical and you see zero application, you likely won't be super invested, might skip a few things and will likely forget a lot of them soon.

However, if the problem is relevant for you, or even better if you are working on something related, all of the sudden it quickly moves from pure theory to a very applicable thing.

I think that's why people who tinkered for years before university if they keep the passion can build insane things during/shortly after the university.

So I think the answer is, theory is important.

However if you build things first, then study theory, you more clearly become aware of what the real insights are.

This. We had to write a multi-process 68K assembly OS as part of an undergrad course. This helped immensely in having an idea of what the Linux kernel is doing. Without that - how do you even get started writing a kernel, if you don't know what it is or what it does?

Self taught dev here, I completely agree you miss the boring details...at first. One day (hopefully early on) you realize algorithms, data structures, data alignment, etc. are actually pretty important when building larger or high performance systems, or when targeting underpowered hardware. At that point the self-teaching resumes and you pick up all these pieces too.

When I started tinkering with Ruby on Rails I never thought one day, in a different context, I would need to write a hardware-specific, custom binary (de)serialization protocol. Then it happened.

I think I am technically self-taught, originally. I only learned about the theory after I had already applied the principles in practice.

Started in the 80's with a C64, then progressed through computers and time until began my studies in the university ... for chemistry. Turns out my head doesn't work that way. Began working or a logistics software company on the side.

In 2001, I wrote at work a literal bin-packing algorithm without any formal background or real CS education. I only later learned that it's generally considered a pretty hard problem.

Some time after that, applied to officially change my major subject to CS. The department head was quoted from the meeting, "about time". One of the first mandatory courses I had to take after that one was on data structures and algorithms, which to me was a properly fun one. It was also enlightening: I realised that at work I had independently come up with Djikstra's greedy algorithm for the bin-packing problem.

Ever since then I've followed a simple rule of thumb in hiring - aptitude beats raw talent. Anyone who wants to learn because they are genuinely interested in the field and its problems is in high probability going to be a better hire than someone with talent and education but without the internal drive.

Am I biased? Yes. But am I unfairly so? I don't believe that. And I agree with other posters that self-taught are likely to get more out of theoretical education because they can map the lessons into things they have already done, or things they have done in the wrong way.

That was me. Self taught since I was 13ish. Landed a job on a team of "actual" engineers (think Stanford/MIT grads doing massive scale distributed systems in the 2010s) and became painfully aware of all I had missed in a CS degree. So I spent a year diving into CS fundamentals and whitepapers...turns out it was all just as interesting as learning to code itself.

This is exactly right.

I taught myself coding, but struggled through some of my CS computer science classes because I hadn't learned some (important) boring details. My peers who hadn't coded before, but were otherwise bright, excelled in these classes and have had impressive career trajectories after school.

Based on my personal experience, I don't believe prior experience with programming before college is that predictive of engineering talent.

I did full CS / Software Engineering curriculum. There was a lot that I taught myself because I was curious / passionate. I learned a lot about things not covered in classes. But the classes also taught the boring details of things like data structures that you can generally ignore until you hit some level of scale/success.

I've seen self-taught software engineers build great looking UIs and during the code review point out things like "data structure X" would work better. I get a response about "Premature Optimization," when in fact the right data structure would be less code and I have to show them.

I've also met self-taught engineers who read detailed research papers on topics on and sometimes made things perhaps more complicated than they ever needed to be.

passion & formal education definitely play interesting roles in what people produce.

I agree that the title can use a bit of work.

The author cites examples such as Linus and Margaret, but IIRC they studied CS and/or math as part of their educational upbringing... so I feel like they're almost counter examples of what the author is arguing for.

It seems like the author is really championing the "self-tinkering engineer" as the outperforming engineer.

Is your opinion about the latter because the self-taught may not stay on task?

As a self-taught person on a lot of different matters, I find myself exploring rabbit holes that expand my knowledge, but don't progress the task I originally started doing.

You could pick from many attributes and find that “many” people with that attribute do better.

Also, this (and other things I’ve read) always seems to argue against the strawman that “you need a formal education to do well in software “. I’ve never seen anyone say that (including during many years involved in hiring at big tech). The argument is that the pool of CS graduates are more likely to do well (and bigger and simpler to find) , so it makes sense to focus there if you need to hire a lot of people.

It could also be the case that you have to be better than average to even break into the industry as a self taught engineer.

There's probably some survivorship bias in here.

Those self-taught engineers who don't even perform aren't going to be engineers for long. So of course you'll see a lot of self-taught engineers in the outperforming category, it's necessary for survival.