As a self taught developer who has spent most of their career in the big corporate world surrounded by computer science graduates my experience is this:
The self taught developer will eventually figure it out, if they are intelligent enough to approach the given problem.
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.
What that ultimately means is that the computer science graduate is way more compatible in the big corporate world where they are an interchangeable cog that can be replaced at any moment. They operate in a world on known patterns just like their peers. The self taught developer, however, is constantly innovating and doing things in somewhat original ways because they have learned to not waste their personal time on unnecessary repetition, and that cavalier lone gunman attitude scares the shit out of people. Yet, those self-taught people tend to deliver vastly superior results.
Most developers don’t seem to care about superior code. They care about retaining employment and lowering anxiety in the manner that emphasizes least disruption.
Plenty of formally educated engineers will try to solve new and unfamiliar problems.
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.
Maybe the perception is because of the larger percentage in each group.
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.
That's my experience as well. People came to CS because they love computers and want to learn how they work were so different than "I just want a job which makes money" people in every way even in the university years.
Curious people got high on the caffeine and code, and the other group just got high.
All I know is that if my coding ability had been measured through mandatory assignments that I would be force-fed without any immediate need, I would have been disgusted.
"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 also went through a very generalist CS course, that we call Computer Engineering, which covered from hardware to software plus math, physics, chemistry.
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.
This goes both ways. I think the vast majority of my colleagues who got into CS later post-college did it because they needed a job, and that's where jobs were.
> 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.
Well, I agree with both of you a bit. I'm mostly self-taught with a backing of a technical diploma and half a CS degree. The part I'd pull from the parent here is that I could not reconcile my level of curiosity and so on with the corporate world at all. I tried, it did not work, I just burnt out and resented programming for a while because what they actually valued was the thing other people were really good at, but what they thought they wanted were the qualities that make a scrappy startup great; namely showing up on time for the standup, wearing the right clothes, being tremendously dull with predictable ideas, endless meetings and low level risk mitigation, little agency over work.
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.
"It is curious vs complacent w/ a heavy sprinkle of hard work, creativity, and intelligence."
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.
Comparisons between software and structural engineering make no sense, ever.
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.
Completely agree on software engineering. Not sure if it shouldve been callled engineering ever, but calling it applied philosophy sounds even more pretentious, and while we try to pretend to be rigorous and structured, software engineering really shares a lot more with writing than with building bridges.
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.
"Completely agree on software engineering. …engineering really shares a lot more with writing than with building bridges."
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.
"Software projects are never ending, always chasing ever changing requirements."
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):
> 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.
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.
OK, so let's avoid elitism by doing away with standards altogether. No doubt, doing away with the ISO would bring joy to the treasurers of contributing member states. Whilst we're at it, why not do way with the Metric system which would bring cheers from Trump's backward America?
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.
I think you missed the point and have some misunderstanding that the self taught engineer doesn’t follow standards, which then points back to the elitism.
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.
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.
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.
> "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 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.
> Hell, I somehow have a computer science degree which I honestly do not deserve considering how little I understood (and still do not understand).
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…?
The thing you're missing here is that these two statements are not contradictory:
-- 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.)
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."
I have a degree in computer science, and I have been a professional full-stack developer for almost 9 years. I could probably not solve the problem in your first link in 25 minutes. I know exactly how I would solve it, conceptually and what data structures I would use, but I am not sure I'd get the adjacent mines part correct on the first attempt.
Then again, this is nothing like the type of problems I work on a daily basis.
(Not GP) After looking at the page and the problem description, I agree. The time limit of 25 minutes is way too short for this considering that the person may already be stressed and find it difficult to understand that big wall of requirements and implement it in this time span. It doesn’t matter if one is a self taught programmer or has a CS degree.
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.
It's a bit off the main topic of this thread, but the problem isn't designed to be finished in time. From the page:
> 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.
I don't think how far a candidate gets on this particular test determines if they're OK or if they're great. I posit that a great one could finish 2-3 steps and an OK one could finish 4-5.
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.
"Basically seeing if they can code" is the goal, yes.
> 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.
So as an applicant, I would be left with the nagging feeling that I didn't finish the problem, and knowing myself and seeing the time constraint I choose to avoid those interview processes.
Yeah, I don't think this thread is about the interview process. It's just for the self-taught developers to feel superior. Or maybe I became too cynic, who knows.
I respectfully disagree that this problem needs anywhere close to an hour; and having the problem already broken down into rather simple steps is a significant amount of handholding.
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?
I agree with your assessment of the problem. It’s already been broken out into discrete chunks that are all simply solvable in short order. Even finding neighbor squares is reasonably straightforward (generating all 8 candidates is basically trivial, then pass them through a filter for each of the four edges).
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.
I've solved plenty of hard problems at work, but none of them have ever looked like "count the grid squares adjacent to a given grid square while taking the grid's edges into account so the program doesn't blow up because you tried to access an invalid index."
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;
That took less than a minute of thought; or you could use a common technique in image and video processing, which is to make sure that the edges are always present but filled with appropriate values by defining your grid to be slightly bigger than the active area.
I just concentrated on what would be the hardest part, the "edge" cases (literally.) Wrapping that in a loop that goes through the appropriate indices is not much more work. There is a sibling dead comment to mine which has the rest.
> 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...
> 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?
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".
If you just had "implement mine sweeper" sure, but the page does tell you exactly how to implement it so you don't even have to think to solve it. Just write the 5 functions they tell you to write and done, each of those are a few lines.
I just gave it a shot; I would definitely need more than 25 minutes.
> 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.
Perhaps that is suited for candidates with image processing experience, because looking at surrounding pixels is a common pattern in image and video codecs. I suspect APL-family experience/thinking style will also help significantly (if you haven't seen it, I recommend watching this video: http://youtube.com/watch?v=a9xAKttWgP4 )
The floodfill part (the last one), on the other hand, is the one that stands out in difficulty compared to the previous parts.
Really? We had informal flood fill competitions in my high school... If you understand recursion, it's easy. If you don't... there's so many other things than flood fill you just can't do. And the generalization of saying "oh, that's just a work list" is easy and enables even more things.
> Then again, this is nothing like the type of problems I work on a daily basis.
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 :-)
It's results like this which put to rest the "myth" that "10x" programmers don't exist according to some people. In fact, it's been my experience that "100x" or even "1000x" programmers exist. (Fabrice Bellard is a prominent example of the latter.) For your given practice problem I'd probably spend more time reading it and writing the code than thinking, unless I'm asked to use something like an APL-family language in which case the majority of the time would be spent reading the problem description.
(Full-disclosure: mostly self-taught with several decades of experience.)
Compared to someone who's basically a zero in programming, any amount of knowledge pushes the ratio to infinity. The average CS graduate doesn't know shit because universities need volume to survive so basically once in, you are spitted out eventually. And faking projects and cheating on exams is rampant, with the complicit involvement of teaching stuff because they don't care and incentives are biased towards turning a blind eye.
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.
> 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.
Depends, maybe Its more a matter of description, but I would call the lowest quality engineer I've seen employed a "0.1x" engineer, before I would describe a good one as a 10x.
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.
Now take that good one and compare them to a guy like Thibault Duplessis (Lichess author), look at his GitHub and commit history for Lichess and you will quickly realize that even with your 0.1x starting point 1000x engineers are 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).
Your statement is meaningless, as you did not define what the x in 100x is and what being a "programmer" entails.
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.?
Where can I get more of these small programming challenges?
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.
That matches my experience: but it's to be expected as most CS degrees are applied Math not Software Engineering. You have to respect that.
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.
This was my first thought when i read the headline.
Many people were told to get CS degrees because they will get a job, not because they love it. The cost of quitting a degree or not using a "valuable" degree is relatively high, especially for people who are inclined to coast. Most people who start college also graduate, even if they aren't prepared or love their program, so we have lots of bad cs graduates.
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.
Most of my big corporate world experience comprises CRUD apps like these tasks:
* 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.
> 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.
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.
CS curricula being far removed from practical development implies that the coworkers you are sorrounded with who *are able to do practical development are all in fact self taught, whether they have CS degrees or not.
University teaches theory, practice is necessary for a well rounded engineer. Most students only do what's required. Good students do more than what's required.
I am not certain having a degree vs. being self-taught is the deciding factor in what is likely attributable to personality and motivational differences.
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.
The other way of looking at it is that some love for the craft is pretty much a prerequisite for the self-taught, whilst many graduates are there for the career.
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.
I have maybe N=5 of these people, but the one that comes to mind is the gent who was in my game programming classes who had already written his own direct x based game engine and was there to just expand on that knowledge.
It may be personality, but this self-taught developer focused on work ethic — that is, while I lacked seeing the "Big Picture" in technical terms (understanding how all the pieces fit together) I strove nonetheless to make up for it by being the most prolific engineer on the team.
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.
Self-taught and agree that everyone’s opinion and anecdotal evidence won’t answer whether CS degree/classes, code camp, or self-taught is better, because everyone is different and has different experience.
Agreed - my CS degree exposed me to a bunch of low level 'algorithms & data structures' type stuff + a bit of assembly, prolog etc + some math stuff all of which I likely wouldn't have gone out of my way to learn on my own unless it came up in a very obvious way in a problem I was trying to solve. But like 95% of the actual large scale software engineering type work (read: actually building useful software) I learned on my own by building unnecessarily over engineered side projects, or by building stuff while working.
(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 haven't dared even looking at any other Civilization game after the first one. I kept deleting it and it somehow found a way to sneak back when I wasn't looking through some sort of sentient magic undelete function.
Even a degree is self taught. The assessment is typically pretty decoupled from the content. You could say "people that have taught themselves a degree course have a better understanding than those that learnt just enough to pass the assessment".
Agreed. The effective difference between a degree and learning on your own comes down to structure, really. A college course gives you a decent enough structure to know that you do addition, then subtraction before you go trying to learn multiplication. I often find trying to learn things on my own I start from differential calculus in this example and try to work backwards.
> I often find trying to learn things on my own I start from differential calculus in this example and try to work backwards.
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.
> The computer science graduate will generally not even try to figure out a problem in completely unfamiliar territory
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.
> Attentive CS graduates have a structured pool of information to draw from
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.
> 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.
Well... Self-taught means that the person learned by their own initiative, "without formal instruction or training".
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.
Pretty myopic viewpoint. You wasted an afternoon figuring out graph-traversal & loop detection from first principles -- using and stretching your mental abilities -- rather than being spoonfed it? That's absurd. Utterly absurd.
I get no satisfaction from rediscovering CS concepts & algorithms first put to paper by the field's pioneers between 1940-1970s, though it sounds like you do.
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.
I believe GP's implicit point was that you also need to know even to ask the right question.
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.
The real issue is not making the choice itself but rather bringing the knowledge about what the decision space is in the first place. (But sometimes the "knowledge" is also a limiting form of preconception)
There’s also a huge difference between CS grads from 15+ years ago and newer CS grads. Older CS grads had computer labs, insane old profs who’d cut their teeth on the first computers, and negative stereotypes of computer geeks were still in play. So there was selection bias, most (or at least many) CS majors loved computers and couldn’t imagine doing anything else. These days—with CS the most popular major, which is mind-blowing—most CS majors are kids who would have been business majors 20 years ago. It’s not to say those that love computers don’t still major in CS, but I interview many many many CS college kids who “don’t want to program” and expect to get well-paying computer-related jobs.
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.
> The computer science graduate will generally not even try to figure out a problem in completely unfamiliar territory.
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.
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.
I also have a masters in CS but I still consider myself to be “self taught” to a degree. I didn’t really learn anything in lectures or from my professors. Most of my learning came from doing homework, reading textbooks, studying for tests, exploring the material, being curious, experimenting with side projects.
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.
Idk. I think some societies prize it more highly than others. What must it have been like to live in Athens when Plato was running the Academy? What got you permitted to be there wouldn't be SAT scores or grades, it would be curiosity and flexible thinking. When things like that have enough cachet, an entire society can orient itself in that direction rather than toward conformity or repetition. [edit: See also, modern Israel].
(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.******
Are you self-taught? The only people I've seen who think self-taught is better are the ones that are themselves self-taught. A degree is like extra experience plus mentorship under your belt... Self-taught individuals don't understand what they're missing, in most cases.
I gotta say I’ve heard this take a lot, and I find it regrettable because I think everyone doesn’t understand what they’re missing, this is a pretty human trait. It’s pretty impossible to just know it all and to not know it so much that you’re just miles from even realizing you aren’t even close.
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.
>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
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.
This!
When you are doing something simple (as in there are known best practices) you do want people to have the same formal education. They’ll talk the same language and everything will be smooth. Nobody wants a self taught surgeon or pilot on the team. There is a best practice for washing your hands and you want your surgeon to know it.
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.
It's safe to say that everyone you meet knows something you don't, regardless of background. But in the context of this discussion, it is pretty obvious that self-taught people on average have nowhere near the hundreds of hours of experience solving theoretical problems. Not having that background will actually set people back when it comes to solving hard problems that occasionally (or often) arise. Watching self-taught programmers talk smack about degreed professionals is like watching a couch potato make sweeping generalizations about how sedentary people who don't go to the gym are more physically capable than people who do, because the people who don't are not limited to performing certain exercises.
I gotta say still pretty regrettable take, if you will humor I am happy to explain why I say that.
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.
It does sound like you spent your time well and learned a lot, one of the rare cases. I wonder how much of the research papers you actually understand deeply given that you lack common background knowledge. It may surprise you how many research papers are actually ill-conceived, and it is hard to see how bad they are if you don't know enough about the state of the art. You are on the right track if you want to catch up on what you would have learned in school. Just about anything in CS can be self-taught given enough time and effort, though you may need to seek feedback from others if you can't figure some things out on your own.
>> it is pretty obvious that self-taught people on average have nowhere near the hundreds of hours of experience solving theoretical problems
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.
The more apt comparison seems to be somewhere closer to an athlete that played sports with his friends all day instead of weight training for that same sport and getting instruction.
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.
I’m not a developer. My roots were in hardware engineering (communication/networking) in the 80s-mid 90s, moving into departmental IT leadership roles at senior levels in the mid 90s till around 7 years ago. I sit in the product arena now as I move towards the sunset.
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.”
Given that you work in IT and not development, I should point out that IT is less intellectually demanding than software engineering. I am less skeptical of self-taught IT people because the nature of the work is almost entirely around familiarity with hardware that fits together like Legos, and proficiency with software tools that are designed for maintaining systems without much theoretical knowledge or mental reckoning required.
>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.
> I should point out that IT is less intellectually demanding than software engineering
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.
>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.
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.
> If two people are similar in almost every way but one has a relevant degree, the degree wins obviously.
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.
>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.”
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.
> Yes, my point is that the CS grad has done 4+ years more work in the field than a self-taught
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.
I assume this is meant to be an insult but it fails. Not everyone paid exorbitant prices for their tuition. By the way, student loan debt is the largest thing on the asset side of the Federal balance sheet. They won't let it go unless they figure out a new way to screw everyone over.
I started programming at age 8, and finally went to college for it at age 22 (although not an actual computer science degree). That was almost 30 years ago.
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.
This entire post smells like someone who's salty and trying not to face reality. I might not even disagree entirely with what's being stated here but the framing is just clearly wrong
Also as a self taught developer, I think this is less about academics and more about unsilo'd thinking. My personal conclusion is that I will hire anyone that has at least tried freelance or running a business. The ability to care about relationships to other peoples courts is key to being able to communicate with other people and contextualise the business as a whole.
Sadly, I've made the different observation that (in my country, where university is free and academic degrees are worth their weight in gold) most developers who never went to university think of themselves as the lone gunman while lacking basics after 7+ years of experience.
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.
This does not match my experience.
I believe that graduating or not does not matter compared to whether you really care and like the field.
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.
I consider myself being self-taught, but I'm also a graduate. I was teaching myself to do a lot of things before I even went to university, and continue to do so after graduating. The most significant difference before and after university is that now I'm more resourceful and more efficient in searching information that keeps me learning new things outside of academia. Put simply, university gave me better skills to learn, and opened new doors to resource materials i didn't know existed before.
From my experience, the high performance developers can’t be identified from how they learnt to build software. But I do feel there is some correlation with how much they enjoy solving problems.
I found the computer engineering paths to be more engaging from a mechanical sympathy perspective.
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.
Computer engineering will teach you that algorithmic complexity doesn’t mean squat if you can keep your data in CPU caches. The classic is any sort of connected node algorithm (linked list, graphs) which are stored sparsely in memory and therefore do not effectively utilize CPU caches.
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.
There is a definitely a phenomenon visible to anyone who has hired self-taught gunslingers versus companies stocked with highly educated CS grads. Part of it, I think, comes down to motivation and [needing to prove] self-worth when solving problems. This isn't just a phenomenon in code. My grandfather was a solo contractor, my dad was a solo lawyer (the first to graduate college in my family), I'm a solo and self-taught coder, 25 years in the industry (and the only of 4 brothers not to graduate college). There's a personality type that needs to prove something to themselves, has trouble with authority, isn't much of a team player, and never throws their hands up in defeat when faced with a challenge.
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.
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
This is what disconnected corporate people believe (whether they are themselves cogs or are the one operating the drawer), but the truth is that high-performing contributors are never cogs and progress is not measured in man-months or lines of code, etc.
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.
Sometimes, megacorp hits a problem and it doesn't have the right cog in the drawer. Maybe it's because no one in-house has the needed knowledge for it. Maybe because it's a genuinely hard problem. Maybe it's because everything's on fire.
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.
You managed to put some of my previous experiences into far better words than I ever could. Especially the part of my "solutions" that come with tons of "this works for now, but it will break here, here and here". I never worked at a megacorp though, mostly by choice, so it was less getting airdropped from up high and more accidentally being volunteered for a project. Somehow diving deep into an unknown code base and making either surgical changes or nuking good chunks of it, is something I enjoy and have become quite good at.
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.
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
That depends entirely on the business and the experience of the given developer. There is a false perception that inventing an original solution is high risk. Risk is accounted for by the prior practice of the person doing the work and the degree of testing upon that work. This common false perception is Invented Here Syndrome.
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.
Mega corp doesn’t care about quality of product for the most part. Shareholder value in the right quarter is the name of the game. Often that means predictable and low risk as opposed to better or cheaper
While I broadly agree with you, and am a self-taught (and occasionally mentored) software engineer, I have often thought that to “care about retaining employment and lowering anxiety” is by far the more rational approach in the corporate-dominated software world of today.
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 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.
There is no programming without emphasis on algorithms and data structures. All code is algorithms, and works on data stored in, you guessed it - structures.
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.
depends on the dev I guess, probably on both sides of this coin. It ain't like data structures can't be learned without the hand holding. In some cases having the bitter experience aids in realising the benefits of the data structure at the time of learning, making the subject less abstract.
> The self taught developer will eventually figure it out, if they are intelligent enough to approach the given problem.
> 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.
Self taught means you are self-motivated. You are not just looking at it as a job. That's why code quality is better. Interest is the most strong driving force for one to improve.
Could you share a little bit about your journey - how you got started, your motivations? (I’m trying to teach myself programming/development, hence the curiosity.)
Having taken all the college level CS coursework for CS degree (I skipped the math and got minors in education and English), I think a lot of folks vastly overestimate how much they learned in a CS degree. Assuming 50 CS credits required for a degree, 1 hour a week of class time per credit, 3 hours of homework per credit, for 15 weeks, that's only 3000 hours total. So about 18 months putting in 40 hours a week. Granted, you can learn a lot in 18 months full time. But this weird obsession that a person could only learn this material if lectured by a bored and overworked TA is silly.
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.
I’m self taught from a single digit age and yet I went and got a degree and it was eye opening. It was mostly a vocational thing with an absolute assgrind of a program that drops most of the students in the first 2 years, and just beats down into a pulp the remaining ones for the next 1-2. 16 hour days of nothing but projects, individual and team.
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.
It seems to me that the self-taught vs. CS degree distinction is missing the point: a point Peter Siebel made very clear in his chapter ordering for Coders at Work.
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.
This has been my experience as well, though I was somewhat self-taught before seeking the 'paper' qualifications other developers had. Best of both worlds in a way.
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 have a similar effect on consultant. It’s usually more on the “this isn’t that complicated guys”. I’ll riff off a high level list of things that need to be done, tell them I could do it in a day/week/month and then tell them I want a daily audit of their hours billed and progress made (I’m actually a finance guy but a self taught dev). They usually don’t want the micromanagement so instead they’ll take day to rethink it and come back with a “yes actually i think we were over engineering things a bit” but really we both know they were just planning to pad their hours. It’s a silly dance but usually makes a good working relationship that GSD at an acceptable pace.
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.
Fascinating, because as a consultant almost always my clients are either the sort to build a vast mess of microservices with eventually consistent enterprise service buses for an internal tool with two dozen users OR they are trying to figure out how to update their one windows server 2016 instance without taking down production.
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.
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 internally by my department 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.
I think all this focus on degrees in your response as well as the others is misguided. I think the real problem is just that they don't give a shit. Giving a shit is the first step towards becoming competent.
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.
I agree and I don't mean to discriminate, its just one particular unique demographic I have and I'm likely over fitting it as a lens. I've worked with plenty of degree educated engineers who are extremely competent but it just bugs me that they all seem to fold in an instant when encountering resistence up the chain. Perhaps it is simply survivorship bias.
wat. no. Higher education teaches you critical thought and how to engage deeply in analysis, dialogue and discussion. If your coworkers with degrees are not doing so, it means they are simply there to do the work and get a paycheck. Odds are, it is a signal that they are more engaged with the rest of their life than they are with their day jobs... so while you see their lack of caring as a lack of competence, odds are you can instead take it at face value -- they just don't care. Now, that is still be a legit complaint against them, but it is not a flaw created by having an education.
sure but I've seen degree educated people engage deeply in analysis, dialogue and discussion and then proceed to do wrong-headed, deceitful, cruel and even stupid things. I half wonder if an aspect of it is some ritualistic process to lull oneself into a false sense of security. I'm probably not describing higher education, but there's a thing, a sort of blithe unquestioning sleepwalking that I struggle to adequetely describe.
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".
Well, not having lived your life, it is hard to say... you might be the smartest person in the room but have trouble communicating with others in a way that makes them trust your take on things. Or you might not be the smartest person in the room and are not hearing the reasons why everyone else is doing things you disagree with. Either way, it sounds like there are communications problems acting as barriers within your teams. This is really common, so that isn't a diss in any way. But not having lived the same experiences you did, I can't say specifically what the problems are... all I can say is that the level of frustration you are sharing is often rooted in a lack of understanding between team members.
Except I'm pretty sure that I'm a good communicator. Background in sales and performing arts, mentoring and presenting are some of my strengths. I'm always immensely popular among my peers and I'm usually quite chill when it comes to horse trading and picking which hills to die on (isn't HTTPS one of those hills?). I appreciate that its probably a chip on my shoulder that's preventing self growth but I can't but feel a combination of youthful looks and lack of degree is the reason I seem to be constantly forced to prove myself again and again and again, despite often being one of the stronger technical members in the circle.
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.
The reactive ingredient is passion, not the learning modality. Low motivation is really limiting, no matter how you like to learn. Of course, this topic is hard to discuss in a quantitative way because the number of engineers you come across in your career is a minuscule fraction of the total. Hard to draw broad conclusions like this, but here are a few:
- Formal education is great for foundational concepts (math, hardware, operating systems, compilers, graphics, etc.). 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. 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.
- Most engineers I know would consider themselves a mixture of formal and informal/self-taught. Again, if you have passion for engineering then you probably like to learn and build, which means you're complementing any formal training with your own tinkering.
I've met and worked closely with amazing engineers and have never found their education style a distinguishing factor. Their passion however, was obvious.
Also, the examples given in the post (Linus, Margaret) were incredibly academic :-)
> 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.
I think that what most people mean is that with a self-taught engineer, you have no way of knowing whether they have the foundations. It's going to be much more common with self-taught engineers than with formally-educated ones to have areas of surpassing brilliance, and areas where they don't know their arse from their elbow, and no easy way to predict what those will be until you get to know the specific engineer.
With formally-educated software engineers, so long as the school they got their degree at is a reputable one with a decent program, you can be reasonably confident that they'll have a solid foundation, and if you're familiar with the institution you may even know what their strengths and weaknesses are likely to be.
> With formally-educated software engineers, so long as the school they got their degree at is a reputable one with a decent program, you can be reasonably confident that they'll have a solid foundation
Based on the 100s of candidates that I've interviewed over the years, I disagree. In fact I often wonder what on earth people are doing at these university courses, because they rarely seem to have even a basic grasp of computer science. I've had to personally mentor many (academic route) engineers over the years on what I would consider absolute basics.
Frankly, I don't consider a degree a useful barometer of quality at all. They're only useful if the candidate is applying for their first job out of university. After that, experience is much more important and I basically ignore the education part of a CV.
When I was hiring back in maybe 2020, I used a basic FizzBuzz test. Yep, the FizzBuzz test you've all read about. About half the people (all college grads) who took it could not pass in the allotted hour. Yup, an hour to do FizzBuzz. Whatever language you want. Whatever you want to Google. I'd say 40%-50% could not do it.
A common error was not being able to get the first number evaluated to be 1. They had written(copied) for loops as `for i:=0;i<100;i++` so many times that they couldn't understand that setting i to 1 was all they needed to do. They didn't see the code. Just the "loop line" and it wasn't doing it right. Then it was making it stop at 100 instead of 99. All that before even trying to test mod 5 and mod 3 first.
The people who did pass it would have written it before I'd even finished describing the problem and they would all but sneer (in a professional manner) at the rest of the code "challenges." We made offers to those people and they worked out great.
I've also seen this in coding interviews, but I will also add that when this happens and the line just doesn't work "as it should", a common reaction is to start changing things essentially at random (i.e. without trying to methodically deconstruct what the code does). And sometimes this random approach ends up working in the right direction, but because it requires more than one step to get there, the (correct) first step gets discarded because it didn't immediately produce the correct result.
In general, it feels like many students learn to program by rote memorization of patterns - i.e. they remember that putting those parts in this sequence gives this result, and putting them in a different sequence gives a different result, but they don't know why there is a difference; they just treat them as magic incantations, sort of.
It's kind of like if someone learned to write by memorizing entire words as is without learning the alphabet first. They can recognize or spell any word they already know, but give them a new word and they are completely stumped.
I have never seen a person who self taught even the basics of math, some think they did but they just learned some fractions of the first course past what they currently know. Like nobody self teaches the equivalent of a basic math degree.
Programming though, there are plenty of people who can self teach programming and algorithms, since the theory there is much shallower and hands on than math.
This used to be my experience with credentialed candidates, but I do think the programs universities have been putting together (which are from what I gather, extremely expensive tech school programs that optimize for FAANG acceptance) have made the hit rate for juniors that can actually hack slightly higher than what I remember.
Whether they actually are interested in the work still seems more important than the paper though.
I completely agree. Where I'm at right now, most of the brilliant engineers and admins don't have a degree at all. The ones with degrees are the do nothing look busy with meetings managers.
> .. they rarely seem to have even a basic grasp of computer science. I've had to personally mentor many (academic route) engineers over the years on what I would consider absolute basics.
This is kind of fascinating. Please give some examples.
> 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.
It was nice in my 20s when we traded labor for beer and weed. A style of collaboration and exchange is what I aimed to describe.
Now, all my peers have wisened up and can get the big bucks elsewhere. So definitely, if a student of any age has the money, they can get a tutor. But it's nice to find a young tutor who would gladly proof your work in exchange for tacos or help on their CS homework
As another commenter proposed, try getting a course book and going through it at your own pace. With your newfound determination and interest it wouldn't surprise me if you stuck with it this time.
Alternatively, if you prefer putting vector math into immediate practice, fields like graphics and game dev use it a LOT.
I've got them under my thumb now, and thank you! I've managed to muddle through linear and develop an ECS and prove it's in linear space and enough discrete to be pleasantly surprised by Noam Chomsky's many lives.
I used them as examples of when I transitioned back to CS and had to learn what to learn before I could learn. So to speak.
Anything on your own learning journey you'd like to share?
Quite a bit! MIT and Harvard open courses are great for aligning self-guided learning and finding vetted resources. My regex compiler would not be functional without those lecture series.
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).
This is a good point. I think the structured curricula can be the only way to learn many technical topics, even if you aren’t being formally taught. I also found my time at university to be invaluable for the equipment, facilities, and resources that were made available to me for learning that I could never have provided to myself.
University classes are great. They force you out of your comfort zones. When I was self taught I would never have pushed through learning the socket API in C, doing so many projects in bash, studying the academic side of distributed systems, data structures, common algorithms. Stuff like that.
I interview a lot of self taught people, or boot camp graduates, and their issues is often that they pigeonholes themsleves into a comfort zone, or they fall apart when you ask them about academic topics that are relevant for the job.
On the other hand, people who never taught themselves anything code related often suck at coding, or they've forgotten a lot of what they learned in college. Hell, for some of them, even while still in college they've forgotten a lot of what they were taught the years prior.
It's best to have done some code by yourself before university, so that you have faced the problems that arise naturally, and when the courses present you with clever solutions to them, you retain them. You don't just dismiss them as fancy theoretical stuff you need to know for the exam, then promptly forget. You've footgunned yourself with memory management enough times that it speaks to you when you get explained RAII.
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.
By the time I got to university I already knew C and the socket APIs and have been paid for delivering software that uses them. I had a friend who made a lot of money selling games he wrote in high school for the C64. Both of us were well ahead of new grads in terms of raw programming skills.
What I was missing were things like Calculus, Linear Algebra, Discrete Math (I knew parts having read TAOCP but had gaps). I knew data structures and algorithms but learnt some I didn't. I had some other random theoretical exposure but the CS program plugged some holes and I did learn random things I didn't know. I also learned more about how to learn.
I think the CS program made me more well rounded. I don't think it made me a better programmer. There was zero challenge for me in all the programming related courses. Where I had to work was on the math and theory side.
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.
Your criticism of the specific details rings true, but I also liked the overall thrust of the GP which is that two common failure modes for working software engineers are either being overly academic and not efficient at practical application of that knowledge, or else being too superficial and direct about solving the immediate problem in front of them without recognizing or even being aware of the theoretical knowledge and concepts that can greatly improve their local solutions.
I think it’s fair to say those failure modes tend to disproportionately accumulate university graduates and self taught developers respectively. As long as we don’t use it as some kind of litmus test then I don’t think it hurts to call that out.
I acknowledge that theory-oriented vs. problem-oriented would be a fair characterization. But I think the language of "comfort zones" and "pushing through" was unfortunate and unfair. It suggests that somehow self-taught developers are lazy, when in fact they often have to work harder than anyone else, because nothing is handed to them by a professor or university. (Not to mention that it can be a lot harder to get a job when you don't have any academic credentials.) I would say that teaching yourself a difficult, esoteric skill, with no outside help, is inherently breaking out of your comfort zone.
College being a huge expense is an anglo-centric issue
It's important for those concerned, but most people aren't, so I don't like to include it because then the entire "value of college" debate shifts on the economics of it.
>You speak only for yourself though. I'm largely self-taught and have done these things.
>I'm a bit confused here. I was referring to the first paragraph in your original post, whereas you seem to be referring to the second paragraph?
My point is, I think, that I would wager you are not the norm among the exclusively self-taught crowd
There's going to be a lot of people on Hackernews to debate me on this, but I'm going to go out on a limb there and say: There's already a selection bias if you're hanging on here.
Programmers who have an issue with the academic parts of CS (self taught or otherwise) probably wouldn't hang out on Hackernews to read such content as: "Writing a competitive BZip2 encoder in Ada from scratch in a few days (2024)".
It's hard being self taught and overcoming the comfort zone, it's hard to go out of your way to figure out what you should learn as you don't have the luxury of being forced to follow a curriculum drawn by experts of the field you're studying.
My thesis is that I disagree that "Self-Taught Engineers Often Outperform"
Formally trained engineers mostly outperform, with a few self-taught people that are going to stand out, but they are the visible part of the iceberg, and if you advise someone to go self-taught, most likely they'll end up underperforming compared to someone who's gone to university. And that's normal, because being self-taught is harder.
> I would wager you are not the norm among the exclusively self-taught crowd
What is the norm?
> the self-taught people I interview
That's another small and unrepresentative group, possibly much smaller than self-taught developers who visit HN. In total, how many self-taught people have you interviewed? Either way, there's selection bias.
> a few self-taught people that are going to stand out, but they are the visible part of the iceberg, and if you advise someone to go self-taught, most likely they'll end up underperforming compared to someone who's gone to university.
That's kind of the point, though. Who would advise someone to go self-taught? That would be strange advice. There's definitely survivorship bias in self-taught engineers who have managed to make it in the tech industry, which is exactly why you should pay attention to them: they've successfully overcome the odds and obstacles. The % of self-taught who get to that point is likely much smaller than the % of university-taught. As you say, "being self-taught is harder."
You are taking the average of two groups but there is no iceberg, the self-taught people who make it are the only ones in that group...the other people do other things. It is like including the people who drop out of college in your group. As you say, self-taught is harder so people who go through that are going to know more and will end up knowing more that is useful.
People who teach at university aren't the experts in the field. The situation of university is inherently artificial created to fulfill a wide range of objectives which are largely unrelated to utility for students (and certainly not, utility for employers). For most subjects, people who teach at university are going to be very far from the experts...if they were experts, they wouldn't be teaching.
> If you just want to ignore the United States, then fine, but in general, good luck trying to ignore the United States.
Sorry to disappoint you, but as a Canadian hiring mostly Canadians no I don't care about how expensive college is in the US on a day to day basis. It really is just a US problem. Canadian Universities are still expensive but not remotely in the same ballpark as the US. You can often pay the tuition by having a decent summer job.
Good luck supporting yourself as a full time student in Toronto or Vancouver if you don’t have family locally, or if your parents don’t have the money to help you out.
> I don't think anybody denies that, but getting into and paying for a university is very much a financial and social class issue.
I mean... Not really? I got a BS in Computer Science from a cheap, small university (plus a bunch of it at my local junior college, for even cheaper!), and the quality of the education was better than I've seen out of "excellent" schools. It was really cheap, too! Easily paid off after a few years at software engineer salaries.
Hell, with entry-level salaries at places like Google or Meta, you could probably pay the whole thing off in a year.
I think people focus far too heavily on "Ivy League" schools and the costs associated with them, and forget that things like junior colleges and small universities still exist, and are still relatively affordable.
With a "commodity" degree like CompSci, cost isn't really a problem.
Besides, no one gives a shit where you went to school after your first job in the field. That first job might be marginally harder to get, and you might have to settle for slightly lower pay, but you're going to be far from struggling with the debt unless you really overpaid for that degree
I actually do deny that university classes are great. Many are actively harmful. When I went to university, the intro level cs class was taught in c. It took me decades to unlearn.
The idea that having knowledge of C is harmful is possibly one of the most anti-intellectual things I've heard today. I guess you don't value education, so you wouldn't know, but your brain doesn't have some limit. Extra knowledge is at worst unused, but often helps in various subtle ways. Never does real knowledge "hurt."
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.
Were you teaching for a software engineering degree or a comp sci degree? Former is more focused on practical skills that are more “useful”, hence all those cross-discipline courses.
I’d argue that the core comp sci skill is more useful than learning how to use React or whatever. But I guess I’m another old man yelling at cloud.
It really depends on the university, and then also on the lecturer.
When I was self-taught, I learned the socket API in C because I needed it for what I was trying to do. This was long before college, and when I got to the latter, it turned out that the person teaching us networking only knew the absolute basics of the API, and I could already run circles around them, so it was the opposite of "out of my comfort zone" (which is "in the boring zone").
Totally agree that the sweet spot is a mix: struggle on your own first, hit walls, make a mess... then when the structured material shows up, it actually means something
Boot-camp grads are not self-taught, they went to a boot-camp. Boot-camp people are career opportunists. Nothing wrong with career opportunists, just saying that they are different than a self-taught dev.
They likely outperform for the same reason they are self-thought— i.e. it's most likely a confounder. If you have enough curiosity/pull, motivation, discipline to do it, you'll outperform in general, self-thought or not.
There's also a survivor bias at play, in the sense that the self-teaching attempts results that you see in professional environments are those that made it.
So, the true question is, for those that tried this path and failed, would have they been better off with proper teachers. Sometimes it may just be a matter of time - taking longer to learn because of various reasons, that wouldn't be the case in normal educational environment.
With this said, I went through CS and math school and enjoyed it, but I don’t think I’m compatible with the format and prefer self learning.
Seeing as no statistics were even presented, I don't think you need to worry about statistical fallacies. Often is just used as a weasel word in this case.
The amount of effort that people go to cope with the fact they lack education.
There are brilliant self-taughts and educated morons, that's obvious. Personally, I am mechanical engineer that got interested in simulations, then in writing simulation code, then in gritty details of implementing numerical methods on a real computers, and ended up writing a compiler and simulation runtime. But I am not trying to convince myself that having CS degree in addition to my ME degree would not help me in any way. Not only because CS in the end is not about coding.
This is a similar situation to car mechanics taking pride in often outperforming mechanical engineers in fixing oil leakages or punctured tires. That's probably true, but we don't teach mechanical engineers so they can fix our cars (though my first job was supervising some huge water chillers and compressors in a manufacturing plant, where I often did a dirty work because our technicians didn't know how, but it is a matter of personal traits and interests. I like to get dirty).
Not everyone can afford the education. This isn't about cope, it is about hunger, drive, and passion.
The article echoes what I've seen working in big corp with grads who were stellar at varsity and hopeless for any actual problem solving that wasn't first explained to them.
The tragic reality is that most companies filter out candidates who didn't go to a handful of universities, or worse anyone who doesn't have a CS degree.
As a professional software developer who also teaches CS at a university, my experience with successful engineers all comes down to interest and passion. Self-taught engineers are obviously interested in the subject, but among engineers with a degree, you have a mixed bag. Some of them have no interest whatsoever in the field other than a diploma, but they are familiar with the terms of the art, which makes it difficult to separate the good ones from the bad.
> Somebody who is self taught is _by design_ somebody who's extremely motivated and interested in the subject.
How so? I've self-taught myself plenty of things that I don't have an interest in. I dare say I even despised some of it.
It seems fair to say that motivation is necessary, however often the only motivation is a means to an end, not the endeavour into the subject itself. But motivation is always necessary. That is not limited to self-teaching. I am not sure that bit is actually additive.
I agree that passion and interest are key, but they don't always line up with what people studied or do for work and sometimes people outgrow what initially excited them on the job. Switching paths is tough once you've invested years. But I think when someone puts serious effort into their PAssion-INterest outside work and endures the PA-IN of self-study, they're more likely to succeed long-term because that extra drive really matters.
Everyone that goes through university learns within a pretty similar circle initially. That circle is surprisingly narrow in the broader field. Who has time to teach the dmc algorithm (used in all highest ratio data compression software) for example. Instead everyone's taught a pretty common curricula in all comp sci courses despite the field being much much larger than that.
Now some who go through university will go well beyond that circle of knowledge. These are the most amazing programmers you'll ever meet. They'll know algorithms that are mentioned in white papers, not taught in courses and they'll kick ass. Those who've been in the industry a while have met a few like this.
Likewise self-taught engineers. They may have humbling gaps in knowledge of that big circle of knowledge that everyone that went through a comp sci course was taught. This may be a constant source of imposter syndrome but also humbling motivation for them. What they'll also know is a whole lot of stuff outside any standard curricula. After all they have the same motivation that the super engineers who went through university and continued to self-teach had. Their circle of knowledge was organically created through passion and that passion is actually one of the best signals for performance in not just engineering but anything in life.
> Linus Torvalds built Linux by rewriting MINIX to scratch an itch.
Margaret Hamilton debugged Apollo guidance code on-the-fly, inventing modern software reliability.
Their very first examples are Engineers with formal training. Formal training gives you the mathematical and engineering maturity TO tinker.
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?
you can "accidentally" write a kernel, at least in my case.
I was doing some embedded stuff when i was at school. I needed to run some "functions" in parallel. Obvious choice would be using a RTOS, but i did not know the exist of RTOS, so i spun up some timer interrupt, a "queue" of function to run parallel, an isr that acts like "scheduler", some variables that act like "semaphore", etc.
Only few years later i realized i have invented a very simple "RTOS"
Margaret Hamilton (checks wikipedia) studied mathematics at the University of Michigan in 1955.
Back in 1955, "computer science" wasn't a thing yet. Computers were the domain of electrical engineering and math, the latter of which was what Margaret studied..
Recently, I've been trying to teach myself some numerical thing I don't have prior experience on (building a sparse LU solver, if you're curious). What I've found is that the single most useful resource I've found is not trying to build one myself (because where do you begin?) or by ripping apart the internals of existing solvers to see how they work. No, it's stumbling across the lecture notes of a course that covered that material, in no small part because by stepping up a level and looking at the other lectures, I can discover the other relevant things I didn't know were relevant. And this property has held true in my experience for other topics I've had to research on my own: the highest quality materials are invariably university lecture material.
If your main thesis is that university instruction isn't worth it, why is all the best material university instruction? Sure, there's an argument that learning how to build something is best done by actually building it... which is why university courses invariably have "build what we're teaching you to build" as a course project that is a significant portion of the grade.
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.
Linus Torvalds has a master degree in computer science
Margaret Hamilton studied mathematics than proceeded to work at MIT, computer science wasn't really a thing back then, but she had a close enough education.
Most of the big names in computing have some formal education in addition to being tinkerers. Purely self-taught yet outstanding engineers are the exception rather than the rule.
College teaches you things you probably won't see elsewhere, theoretical foundations, lesser known systems, etc... You won't see that elsewhere because it is hard work and you won't get immediate results. It is not particularly fun and employers won't pay you for this. But if opens up your skills and complements tinkering well, for example by recognizing that the problem you are trying to solve is a classic problem that many people have studied before you and there is a whole lot of information on it that you can miss if you don't have the right keywords.
> Two people are cited as example. [...] Linus Torvalds has a master degree in computer science
Technically it was accomplishments that were cited. And in the case of the accomplishment of building Linux, that was done so prior to Linus receiving his CS degree.
That said, university was noteworthy in his case as that is where he gained access to Unix systems — something a regular person at the time wouldn't normally have access to otherwise — which ultimately developed his interest in creating Linux. Access to machinery regular people don't normally have access to is the value-add.
Which is the contention around modern CS degrees. What machinery, as it pertains to CS, can't you reasonably access today without going to university? Even state of the art GPU/TPUs, which might be the closet thing analog to Unix boxes of Linus' time, can be rented at home for a tiny fraction of the cost of attending a university.
> Purely self-taught yet outstanding engineers are the exception rather than the rule.
There is probably no such thing as a purely self-taught engineer, at least not alive today. Formal educational resources have been so easy to access over the past many decades that there is no advantage to being purely self-taught.
Before the advent of the printing press, you probably had little choice but to be purely self-taught. Access to formal resources was reserved for the lucky few. But those days are long, long, long behind us. I don't suppose the distinction between "self-taught" and "not self-taught" is even real anymore.
I think one needs to be careful with statements like this. Is it the case that those who outperform tend to be self taught? Or that those who are self taught tend to outperform?
I can easily see why the former is true. The latter seems a lot less likely.
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.
> The author cites examples such as Linus and Margaret, but IIRC they studied CS and/or math as part of their educational upbringing...
What is studying if not self-teaching? But, semantics aside, Linus, at least, was programming long before he attended university, and his claim to fame was built early in his time at university. It is true that he "studied CS", but that came later. He is unquestionably self-taught in the area for which he is best known.
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.
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.
My reading is that the statement wasn't an opinion either way, rather it was questioning whether survivorship bias needs to be accounted for.
To your point though, I think it doesn't matter so long as you've learned to deliver business value. Application of broad and diverse skills may deliver value at a start-up for example, but wouldn't get too far at a ticket shop.
The point I was raising is that I don't think it's the self taught angle itself that is the causal factor. As an example, there's lots of things I'm self taught at but also terrible.
However, someone who already has the talent to be really good at something and who has the inner drive and motivation to push themselves is someone who is likely to excel. So if you find someone who is excellent at something and self taught, it's not a surprise. They probably combined natural talent with a strong work ethic, and lots of exploration of the entire search space.
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.
As a self-taught engineer who made it pretty far as a career, getting to work at CSIRO (Australia's Science and Technology Research Centre), I can say I definitely did not outperform my peers there. However, engineers at CSIRO felt I outperformed the average engineer.
I was occasionally brought in to interview new potential hires, and I don't think there was a significant difference between the self-taught or the classically trained (either software engineering or computer science).
I think the difference was first of all, did they just love building, and secondly, did they ask the right questions as they went through the development process.
I think I struggled in the 2nd half of that, and I could run off on some far-flung direction not because I didn't know what needed to be done, or the "right-way", but sometimes because I wanted to try to prove that I was as capable as my peers. But the plain fact is, I just wasn't, and I'm ok with that. It's kinda how I ended up as a CEO, I can understand and direct the product/technology from a high level, and particularly now that we're in neurotech, I'm not the right person to be writing C.
So if you want to be self-taught, you can go far. But when you get to the top, you're probably going to want a great mentor who won't necessarily be teaching details about coding, but more about the approaches to engineering.
I've not met anyone in the industry who wasn't self-taught. Nobody gets by in this line of work on just what they learned in computer science classes.
You simply will not sit next to someone who was lectured by someone else in detail on every aspect of the whole tech stack you are using.
To get through those CS classes themselves takes a lot of self-teaching. The lecturers are often terrible, and you have to rely on your own research to "get" the stuff enough to do the assignments and pass tests.
Yeah, this industry is by definition self-taught. Unless you're getting your boss to read you documentation and Google answers for you.
There are a lot of people who do a CS degree purely for money reasons, but I've found those people turn into PMs while the engineers have an actual interest in engineering. It's torturous to do a very mentally difficult job that you don't even want to do, and those people pivot to other adjacent careers.
Everyone is self taught. School can lead you to water, but it can't make you drink. Every piece of understanding in your head came from your own learning efforts, whether that be trial and error, reading a book, listening to a lecture, spending too much time on stack overflow, or typically all of the above. School provides structure which helps with discipline, which is a serious obstacle for many people's learning efforts, especially when they are young, as well as exposure to concepts that one may not find easily without both curiosity and good research skills. But ultimately school is never more than a foundation to build off of in one's lifelong pursuit of learning. The difference between high and low performance engineers is often entirely based on how much effort they put into continuing to grow.
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 basically had a grab bag of shell, python and ruby stuff that I learned how to do over my first 5 or 6 years in the industry and then saw an article about Haskell, tried to learn it and realized, I don't actually know _what programming is_, and then spent 10 years teaching myself all the computer science stuff that I missed from not having a degree.
I still don't know Haskell, but it was a valuable learning experience anyway.
I got hooked in a similar way. Wrote an Excel macro to automate an operational thing I did in my real job, and then asked myself, "Wait, how did that work?"
My experience as a self-taught dev too. I managed to get employed as an SE without a real computer science foundation, but then I just kept teaching myself details of networking, operating systems, memory architecture etc. and learned other topics as-needed.
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.
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.
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.
There's no real proof in this article that anyone out proforms anyone else. The author lists a few notable cases with a few notable people, but I have to ask.
Didn't those people get an education?
Didn't they go through school?
I did a quick search and linus has a masters in computer science.
What is a self taught engineer then?
I would expect that an article with this kind of claim in the title, would have some data about code quality, qualitative reivews from coworkers and managers, with different cohorts of devs, over some time frame.
This piece right now, just seems like an opinion without substance.
Additionally for what it's worth, I personally think of myself as a self taught engineer, so I'm biased to actually agree with the author. However I feel like this claim lacks substance.
Yeah, I find myself disagreeing as well. I think the whole thing also boils down to: If you're self taught and have no achievements, you have no job. So you're not comparing self-taught to academic, but the cream of the crop to the average.
All software engineers are essentially self-taught. Building non-trivial complex software requires the acquisition of enormous amounts of knowledge you didn’t learn at school. If you can’t teach yourself, you aren’t going to go very far.
I’ve never noticed much difference between the people with CS degrees and the ones that don’t. It is always people with relentless curiosity and stamina that have the elite skills. The only thing I might attribute to people without CS degrees is they seem more likely, in my experience, to come up with interesting ideas that actually work by taking unorthodox approaches to classic CS problems.
i really quite like the quality of vba code you can find in excel sheets in non-tech corporate environments, well, at least, the range of quality you find in there. there can be some incredible ones. code quality of matlab scripts and scientific code written by mathematicians and engineers can also be pretty eye opening.
when the only goal is a product that works, you get a lot of innovation and a lot of speed. when you don't have to worry about review, testing, and deployment, you strip out 80% of the overhead.
i heard the hedge fund renaissance technologies does not target hiring people with finance backgrounds. i wonder if you can build a tech company out of people who are just going to figure out javascript for the first time on their first day of work. when the performance hurdle is "learn something new on your own with minimal guidance", you immediately filter for a group of innovative people with initiative and drive.
But why is this surprising at all? Self-taught engineers most likely than not have the intrinsic motivation that CS graduates lack, who got into the field because of peer pressure or money.
And the raw talent too, that someone can master multiple disciplines is a sign of intellectual dexterity. Not too say CS graduates are not talented but self taught ones master more cognitive fields, which aid in their programming tasks because programming is a cognitively demanding job.
I was self taught from around age 12 with legit coding pre-ubiquitous internet and have a EE/CS degree. I was coding Mode X assembly demos in C, Pascal, and Assembly by 17. Most lower division courses were cake. I took 4 CS courses one time under a quarter system which is faster than a semester schedule. Many all-nighters, but got it done. The most important value of it is challenging your abilities and a common knowledge foundation. This is something self-taught only rarely or never receive. There are also too many people in STEM jobs to collect a paycheck while lacking passion.
Phrased differently: "people who have already displayed an aptitude for independently determining what is worth learning and learning it excel at tasks that require determining what is worth learning and learning it."
I'm going to go against the grain here and say that in my experience, self-taught engineers typically deliver worse products, and I say that as someone who is mostly self-taught, albeit lucky enough to have benefited from good mentoring. The best programmers I ever met all did software engineering or computer science, or were themselves mentored by others with a lot more experience.
I think the difference comes down to how you view programming. The self-taught programmers I've met typically see programming as a means to an end, and take "it runs on my machine" as the measure of success. Someone with more discipline will understand that that's the lowest bar and mostly a given for someone whose job is to write code. The real measure is can you come back to it in 6 months and know what you did? Can you easily expand on it to add new functionality? There's a craft there that isn't obvious unless you've done enough coding for long enough to run into the problems that software engineering is designed to solve. And if you're built like that, mentoring helps bridge that gap, because you understand why certain techniques exist. They're not just arbitrary patterns.
So I don't think it's being self-taught that makes the difference, but rather, being the kind of person who writes code that gets revisited. Even if you make a hash of it, it'll give you context so that when someone better than you comes along and points out a better strategy, you understand why it's an improvement. And I think that's true regardless of whether you're self taught, or you have a degree, it's just that having a degree in software gives you those strategies from the get-go, even if you don't necessarily have the context.
Those best programmers you ever met; Was their first introduction to programming in university?
The single very best programmer I've ever known was self taught. He went part way through a CS program and dropped out but that was after he was already the best I've ever met. Incredible skills. Software that worked. Incredible productivity. Across different languages and technologies.
Rarely have I met someone who didn't have interest in software and computers before university (e.g. as a kid or teenager) be a really great software engineer. I've met many who took CS or Engineering because it's a good profession, they can make money, and have no passion or particular aptitude.
In my opinion the best mix is a combination of self taught and some formal schooling. Passion, aptitude and education. You can learn the formal stuff on your own but it's harder to do.
All of us software engineers are self taught. The stuff we do is generally not taught in university. I have a CS degree but 99% of what I do is not that. That's not to say formal education in CS and various related areas is not useful. In some specific software engineering jobs perhaps more so than others.
This is such a weird article, the two examples it gives, Linus Torvalds and Margaret Hamilton did in fact study at University. Linus created Linux while studying for a Masters in CS and Margaret had a graduate degree in Mathematics, probably as close as you could come to CS in the 60s. So it seems if anything those two are counter examples?
I wonder how much this is personal bias. I'm self-taught but I have absolutely no idea how I perform on the bell-curve against formally trained software developers.
From personal experience I've had to spend time learning concepts that I "ran into" that others already knew about. I probably spent a lot of time thinking I was good and clever enough to solve challenging problems... but then realize that I had used inappropriate data structures and made things more complicated than they needed to be because... I hacked my way through the problem rather than think through it from solid principles.
While I personally think experimentation is great... I've come to the conclusion that a mix of the theoretical and the practical is best. Being able to go back and forth between the two extremes has been valuable to me.
As someone who was self-taught and then changed my degree to CS, I think one thing that shows that someone learned by themselves is that they thrive without formal deadlines.
I see some fresh grads struggling when going to a professional environment where no professor is saying "I want <product> done by <deadline date>".
I think this is why some undergrads also struggled a lot when our role became remote. Suddenly, no one went to their desks for check-ins to see how their work was doing. The code was rushed at the end of the sprint to make it to the "professor's deadline."
At the same time, self-taught people generally succeeded because they are more oriented towards a "delivering when possible" and "pushing myself to learn" mentality.
After 3 years of experience, I think this equals out, unless you talk about lower-level CS concepts like mutexes, big O, or something they generally don't need to know for their daily job.
I came from a Chemical Engineering and Math degree, but ended up teaching myself programming while I was in university. I saw my freshman year roommate getting offered more for an internship than chemical engineers were making after they graduated and put 2 and 2 together.
I think there is a huge benefit to having had some sort of extremely rigorous quantitative background. When I talk with people who are self taught who haven't come from a hard (where that is an extremely hand wavey concept) can get started in engineering and often can be productive, but really struggle when things break or get difficult. There's a sharpening of the mind that comes with extreme analytic rigour, and I think that's more important than whether you get it in a real analysis class or in a CS class.
The article is specific to software engineers, and perhaps it's accurate within that discipline. The field is incredibly broad—ranging from writing small support scripts to engineering massive distributed systems—so it's plausible that a self-taught engineer could excel in certain areas. However, I don't believe this holds true, or is even feasible, for other engineering disciplines. In those fields, earning an engineering degree is typically a prerequisite. After that, you're free to self-teach and explore further, but without that formal foundation, it's difficult to progress meaningfully.
Side note: I think the term self-taught is often misused. Very few people are truly self-taught in the sense of starting from a blank slate and independently mastering a subject without any guidance. What the article refers to as self-taught is really just informal education—learning through blogs, tutorials, bootcamps, or YouTube University.
the definition of self-taught: having knowledge or skills acquired by one's own efforts without formal instruction
I think you're engaging in some weird goal-post moving. The phrase exists to highlight the difference between "i had someone else tell me all the things I should know and let them give me that knowledge" (e.g. college or a boot camp) and "i went out and found resources and did experiments so that I could learn what to do without that guidance". It is not "i discovered everything for myself by first assuming some principles and then rebuilding the whole field for myself".
All of the best engineers I know but one did not graduate in software engineering nor computer science. None.
They are all people that were coding in their teens and had a massive interest for computers, technology and programming since very young.
Conversely some of the worst engineers I know were graduates who only went into SE or CS because of job opportunities.
I am not saying ST good, graduate bad, I have also examples of terrific developers with a proper formal education.
I think all in all what really matters is whether you really care or not, whether you want to learn and expand your knowledge or not. Other than that sky is the limit. I would still suggest people to graduate if they are young and it won't cost them too much, it's good to meet fellow students, do networking, study stuff you wouldn't otherwise etc.
> Linus Torvalds given as an example of self-taught engineers yet he has a masters degree in CS.
The example was Torvalds building Linux. Linux was written before he attained a CS degree.
> Higher education isn’t just about what you learn, it’s about learning how to study and learn.
You'd have to have screwed up your life pretty bad to not have already learned to study and learn before reaching the point of going to a place of higher learning. But that wasn't a problem for Torvalds anyway. It is well known that he was writing software since he was around 11 years old. He is unquestionably self-taught, as the term is normally used.
Higher education is about gaining access to machinery that mere mortals can't afford on their own. Linus' university story is significant because that was where he was first able to use Unix. It is unlikely that Linux would have come to be without that experience.
But that is also the contention around a modern CS degree. What is the "Unix" of our time that you can't reasonably access without going to university?
Sure, but with that argument I think you could say most people in software engineering are self taught. If you want to get a job as a SWE you probably need to learn a lot outside of the classes for a typical CS degree.
But I don’t think that’s as much of a black mark on formal higher education as the article suggests. Since the reality is, the vast majority of people aren’t organized, driven, and bright enough to learn all of the fundamentals taught in a CS degree on their own. That’s why I don’t think it’s smart advice to recommend spurning a CS degree in favor of being wholly self-taught.
To your last point, what can access at a university that you can’t get elsewhere? People. Namely, a community of like-minded peers, and personal relationships to experts in the field. Those relationships and mentorship opportunities are far more valuable than the content of the syllabus. For that, I agree it’s all available online.
> but with that argument I think you could say most people in software engineering are self taught.
When you get right down to it, I expect few, if any, people in software engineering are actually self-taught. You could theoretically pull it off, I'm sure, but people are pretty lazy and it in this day of age it is much easier to read a book/website or watch a YouTube video prepared by a teacher. That's not self-teaching by any stretch of the imagination.
> To your last point, what can access at a university that you can’t get elsewhere? People.
Deeming people to be the "Unix" of our time comes across as being quite bizarre. It is not like universities were void of people 35 years ago, so the fit you are trying to make is unclear. What is your thought process here?
> Namely, a community of like-minded peers, and personal relationships to experts in the field.
Did you, uh, not notice where you were when you said this? The like-minded peers and experts in the field are unquestionably present and here to mingle. If you are failing to build relationships with them — which I guess is what you are trying to say? — what makes you think you are going to fare better in university?
Maybe what you are trying to say is that you personally already established the connections that you want to have in university, and thus personally don't find need to do the same here? But what does that have to do with the next guy?
Or maybe what you are trying to say, which seems to be supported by the data, that as you get older, you become more closed off to new relationships and have somehow mistakenly conflated youth and university? Still, even if you are now old, what does that have to do with the next (young) guy?
I don't know. I gave my best to try and salvage your comment, but whatever it was that you were trying to get across in suggesting that people are modern day Unix analogs didn't make it.
I used to call myself self-taught because I never finished my CS degree, but the truth is I learned a lot of formal methods and techniques in college, and I wouldn't have been able to succeed without it.
Formal education is the beginning, not the end, but if you have the opportunity, why not take it?
Anecdote: I grew up in a poor family, that was single parent for my teenage years. I dropped out of high school when my son was born and I was 17. I never went to college. I was, however, a lifelong nerd and by mid-20s was able to get a foot-in-the-door job in IT. I'm 40 now and have been doing my dream job for almost 8 years. My current position was for a job that required a degree on paper. During my interview (all of them actually) I was honest about education, but also work experience and personal interest in the field, and got the position. That was 2.5 years ago and I hope to retire here.
I'm sure there was some luck involved, but just having a singular focus on computer adjacent fuckery, I managed to build a pretty successful career being 100% self taught.
It's not luck, I hire people on the regular, I'll pick a person with no degree but practical experience over a fresh out of college graduate every time.
I've found that there's greater range among CS graduate software engineers. Of course there are some truly excellent thinkers who know how to bring their training to bear on all kinds of problems. But some of them, well, you wonder how they even graduated college.
Among the self-taught, there's less variation. If they've managed to land a first job, they're usually at a pretty decent level of knowing how to learn new skills and apply them to solving problems. They were born in the "real world" instead of in the classroom, and it usually shows up in their sensibilities.
Just what I've observed from my own experience. (I'm self-taught myself.)
They also often underperform, especially when given a novel task.
One thing that Uni/College provides (hopefully; it did when I was there in the 80's) was a broad base upon which to build the specialty you're interested in. I don't do assembly, but I have done some. I don't do Ada, but I have done some. I don't do microcode kernel code, but I have done some. I don't do O(n) proofs, but I have done some.
I know a lot of bootcamp and self-taught developers "know a lot about things", which is good and we need those people. I pride myself on "knowing about a lot of things", which is also (IMO) good and we (hopefully) need these people too.
Well, "Case Studies of Tinker-Born Mastery" is a pretty LLM-sounding heading if ever I've encountered one, and that bulleted list of examples...
It's interesting to think through which of the LLM-produced texts that I've read recently have delivered value and which haven't. This one doesn't impress me, but there was one about social skills I thought was good – yet the comments there pointed to maybe that being because it was synthesizing some high-level points from a book. Getting the model to go fishing for ideas rarely seems to work out to anything that feels worth my time.
If you pair a self taught engineer with a classically trained engineer, the self taught will dramatically reap benefits from the collaboration but the reverse isn’t true.
A true 4 year CS curriculum is so theoretical you basically have to self teach to do anything practical once you leave the university. But due to the intuition you gain in university, your teaching process happens much faster and can hone in on specific correct paths, which contrasts with the pure self taught engineer who maybe stumble around longer or get trapped in local minimums.
Some self taught engineers may never truly grasp certain high theoretical concepts because they never occur often enough in the wild, but the CS degree holder will at least know these concepts exist and where they might apply. This is what can make the difference in a business’s competitive edge.
Nowadays though, I’m growing cynical of a lot of people trying to enter the industry as self taught, as many are simply chasing the high salary and easy lifestyle of the typical software engineer. You need to figure out quickly if you’re dealing with a true enthusiast or just someone chasing a good job. It’s safer to just go with the CS degree, but even there you have the same problem, the people entering the industry just aren’t built like they used to be.
I started hacking web projects and messing with Slackware in the mid90s as a self taught dev. Before that I was always building things on my computer it felt more like creative exploration or entreatment than academic discipline which is why I never pursued a CS degree.
Whats fascinating is how differently CS trained and self taught developers approach problems CS grads often bring systematic thinking and solid theoretical foundations they'll architect elegant solutions and consider edge cases upfront Self taught folks myself included tend to be more experimental willing to hack together quick prototypes and iterate rapidly
Ive found the magic happens in small teams that blend both approaches The CS trained developers provide structure while the self taught crowd brings creative problem-solving and isn't afraid to break conventional rules... sometimes there are no rules.
Has anyone else noticed this dynamic Im curious if others see different complementary strengths between these backgrounds or if this varies by company culture domain
Not to belittle folks with a comp sci degree, but is it not obvious that self taught folks would be worthy of more serious consideration instead of making them do leetcode puzzle that have no real-world value? Bc I am self taught, and having the discipline just get competent at writing code takes a ton of discipline and genuine interest.
Think of all the open source projects that have been created and/or maintained by self taught programmers - ruby on rails, vuejs, nextjs, nuxt django, laravel, nodejs, express, etc.
My experience lately has been the opposite. Now that the job market is tight, I get a cold reception when hiring managers find out I am self taught. Could just be my anecdotal experience, but I would not be surprised if a person with a comp sci degree would look down on person who does not have one, especially if they are making a hiring decision.
I have a CS undergrad and a MSc in Computing, did either really prepare me for industry? Not really. But I made a lot of friends, drank a million beers, and overall had a good time. They look good on a resume too.
Even when I was in school I knew that CS as a field wasn't one where you could just get a degree and get a job (well outside of 2021 maybe). After one internship I realized there was a great divide between school and work, and this was at a work place with pretty low code quality.
'Self-taught' engineers is a bit of a funny term for me because while I technically have a CS degree, everything applicable I had to learn myself. Especially for a DE job where outside of some basic SQL and the general idea of a relational database a post-secondary degree doesn't exactly prepare you for such a role.
An interesting confounding variable might be that self taught programmers are likely to be influenced by a background in some other field. For instance, my degree is in physics, so I'm likely to "think like a physicist," if that's a thing. And I've chosen my battles well. My job is in an industry where understanding the workings of a product often starts with physics.
Another variable may be that the training process and the people who go through it are perceptive of what matters to their careers. When I'm tempted to think that engineers "like" to do certain things, and not other things, it could be due to personal ability and preference, but it could also be an economic preference not to waste their time on things that I happen to "like."
As for the tinkering advice in TFA: While I wholeheartedly agree, as I grow older I find it progressively harder to force myself to start a new (and novel) project just because.
I still have personal projects, but they are very purpose driven and thus I mostly use what I know rather than exploring new tech.
Hmm - i'd like to see the proportion of self-taught engineers that quit before they became self-taught engineers. This feels like a classic WW2 bomber problem. More computer science grads end up graduating while despising computer science ( I knew many) because it's just a potential career track.
I think there's a bit of a survival bias within this, you aren't going to get data from self-taught people who now work in accounting because they tried to be self-taught but didn't really find passion.
Learning to learn efficiently is an incredibly useful skill that is required for survival in the self-taught path. Deciding what to learn next while making progress in your project in order to strategically unlock better decision-making at the right time before investing in the wrong path will compound over time and lead to increasingly improving skills like technical design, architecture, and project planning. The only major downside to this path in my experience is the increased probability of impostor syndrome which can be detrimental specially during the early years of your career and when you are trying to grow into the next level.
The issue here is not one of self-taught vs formal education.
Nor is it one of motivation/passion, although that plays a bigger part.
It's rather a matter of gifting. Some people "get it" when it comes to programming in ways that make them profoundly more competent than others. This is regardless of education.
The other big factor is whether or not they enjoy the frustration and successes of programming.
The best developers are those who are gifted and enjoy the fundamental challenges involved in programming. Formal education is at best tangential.
I'm probably easy to mistake me for being self-taught, considering I was programming as a kid, and never finished university, but I didn't really learn to program until I went to university. I wanted to, as a kid, but unlike my brother, I could never figure it out, until I got my hands on something better than Basic, and some good guidance and teaching.
I. Recent years I've only been getting more and more passionate about it, but that's probably mostly because I'm finally getting the opportunity to tackle some really hard and interesting problems.
Exceptionally smart people are more likely to effectively "self-teach", though exceptionally smart people often still use the same sorts of resources that classroom learners do (books, manuals, spec, consulting mentors, deliberate practice.
People who aren't smart and hardworking just don't effectively self-teach.
> Seems the same logic like looking at Bill Gates or Zuckerberg and claiming college dropouts get rich.
Gallup's report on the "top 1%" kind of backs up the idea, to be fair.
Sort of. It shows that having a degree is significant when it is an advanced degree that offers exclusive access to a market (think medical doctors, lawyers, etc.), enabling monopolistic capitalization. But dropouts are more likely to be in the top 1% than those with only a bachelor or other insignificant degree.
I didn't choose any particular direction. Your assertion that "college dropouts get rich" carries a lot of truth, though. However, buying access to a monopoly is hard to beat.
> but the consequence of being successful before the graduation.
It is unlikely they were all successful beforehand. Financial success typically comes later in life. More likely it suggests that those who chase degrees that aren't backed by monopoly are not prioritizing (financial) success. The hard truth in life is that it is hard to do well in something when you are distracted with something else!
The ruse when talking about financial success and college is that:
1. We typically lump "college degree or higher" into a single group, not differentiating between those who are buying access to a monopoly and those who are taking a vacation.
2. We don't like to recognize the spectrum of people. Someone with, say, severe autism, that limits their participation in the economy, isn't going to find an autism cure in graduating from college, but they are treated as if that is the case.
Which can lead some to think that college itself is somehow magically a key to success. Ask them to explain the magic and you'll get all kinds of bizarre, handwavvy explanations, but once someone believes in magic...
> This shows that dropouts have a lower income as graduates
Obviously. The aforementioned crippled autist doesn't have the ability to be a graduate. And will suffer economically because of the same life challenges. In other words, people aren't the same. But you are playing the same silly game colleges love to, pretending that all people are exactly the same, which is obviously not the case.
It is telling that you avoided presenting a report that breaks income down by equivalent (to the extent that is reasonably possible) people. The report you offer is valid for what it is, but doesn't support your claim as it is made within the context of this discussion.
> The dropouts in the top 1% are outliers.
To be in the top 1% requires being an outlier[1] full stop. The dropouts are disproportionately represented, though. There are surprisingly, on the surface, few "bachelor only" members in the top 1%. But when you think about it, it isn't all that surprising. It's hard to reach 1% status with other distractions going on in your life. There is only so much time in the day.
[1] Granted, the data suggests that the top 1% is more like 20% of the population. It does not require being the extreme outlier that it may originally seem. How can 20% be 1%? Time. The top 1% is not fixed membership.
Yea, true of many things. Anyone who has the drive and motivation to teach themself anything, usually do a good job.
Doesn't mean you'll always get everything right or that you'll be good at first or even as good as someone taught to do the thing, at first. But practice makes perfect and over time you can be as good or better than someone with training. There's absolutely no reason you can't train yourself on just about anything.
This is a strange dichotomy. N years post CS undergraduate the majority of what you know will be self-taught, but how you've put it together in your head will be different with a theoretical background than without.
A theoretical background is valuable. It distills hundreds of years of other people's learnings. Ceteris paribus, if you do not have it, you are at a disadvantage.
The analysis is wrong. The problem is most software development tasks are to software engineering as building a driveway is to building a bridge.
As in the civil engineering example, both involve concrete, labour, levels, project management, but the jobs are just too simple to require or reveal the knowledge held by the graduate civil engineer.
The main reason for this is because self-taught programmers FOCUS ON ONE LANGUAGE. I realized that I went through all the courses I needed to learn from university in different programming languages for some strange reason, and that just left me all over the place as a developer.
It is an easy fix, teach only one language for the 6 core areas of programming, namely:
1) Intro to programming (variables, loops, conditions etc. up to functions)
2) Complexity management, usually OOP
3) Building a GUI (it is not trivial and needs to be a course on its own)
4) Connecting to a database (also not trivial)
5) Data Structures and Algorithms
6) Compilers and programming languages (basically popping the hood of programming)
In school, after learning OOP in Java we switched to web dev and learned javascript and php. We completely abandoned learning GUI and DB for java.
Algorithms was taught by a visiting lecturer in C++ and after mid-sem we switched to Data Structures in java??
The universities are doing a fine job, but please just stick to one programming language for these core areas and everything will be great.
I came to this conclusion before AI took over. It will be interesting to see how AI changes the Computer Science curriculum in the years to come.
A degree is still a good proxy for good worker, because it guarantees that:
1. The employee was able to work on the boring matter he was assigned, and often disliked
2. The employee internalized some social norms, unlikely to be a weirdo
3. The employee knows what he doesn't know, and what things exist in the industry
Once I made a lecture on higher education, showing that it has many functions besides the core skills that everybody talks about. And that there's no replacement to it on the horizon. After my talk, a guy comes up: "such great lecture, just my thoughts. Why do they need a degree for bank clerks? A technikum* would be enough." (I spoke of exactly the opposite. And the test to his idea would be: come to the bank manager, tell them they should hire people without a degree, listen where he tells you to go.)
* technikum in post-soviet countries is 1-2 year vocational education, lower kind of degree than college or university.
As a mostly self-taught engineer, the reason is simple: after 5 or so years, the language, tools or architecture is going to be dramatically different and you have to learn on the fly. Heck, even how to learn has changed dramatically. When I started, I learned languages from printed books. Then docs and Google, then added StackOverflow, now AI.
I was actually talking about this with a dev this morning.I might reframe this away from self-taught and more towards on the job experience.
Obviously, I think it depends on the domain you're working in, but most comp sci majors really learn math and algorithms.
Math is great, of course, but the vast majority of app and web developers never use any of it. So at the end of the day, even with a proper technical background, everyone is really self-taught when it comes to Python or React programming when they get a real job.
This is a broad brush, but then you get data scientists with academic background who maybe learn R or Python for analysis, which again is great, but they don't necessarily learn OOP principles or exception handling and so their code quality is bad. Yet, they are often tasked with creating apps or doubling as a dev and so they too end up becoming self-taught to a degree.
> I might reframe this away from self-taught and more towards on the job experience.
At least with the devs I've known over the decades, they were self-taught but didn't learn "on the job".
In my view, the difference between self-taught devs and devs who learned it in school is passion. Self-taught devs are self-taught because they're passionate about software. Devs who learn it in school, generally speaking, do so not because of a deep passion for the subject, but rather as a means towards getting a job.
Totally agree. Passion is the key ingredient. For me, as a self-proclaimed self-taught dev, I learned the most on side projects because my main jobs didn't always offered job training or clear paths towards advancement or eventually the product went into maintenance mode and became boring. Maybe it's splitting hairs, but I still consider that on the job experience, even if it wasn't paid many times, and it gave me a deeper understanding of problem solving in addition to programming chops than tutorials or portfolio projects or bootcamps could provide.
Nah, you need both. A formal foundation in core concepts is the bedrock upon which to do self-study. The smartest engineers are the academics. They're the ones who design new algorithms for the rest of us to use and their achievements are built on deep knowledge-sets, which are mostly formal.
Probably the actual difference is what you are able to retain in your memory.
I know that the parts of computer science I learned on my own or while on the job, are far more sticky than anything I studied in university, even back then
Also there's a different in what you think you understand and what you actually understand
Because we have to. It's obviously survivorship bias. I don't have a single chance at interviewing against someone with a degree unless I can undeniably prove that I am head and shoulders above the pack. And so you grind and grind and grind in a way that someone with that piece of paper to rely on doesn't feel the need to, because the bar is that much higher.
It wasn't always this way; making it without a degree used to be a badge of pride in this industry. But the glut of CS grads these days has made it something of a handicap to be brushed around at this point.
In my experience it’s a huge “it depends on the person”.
Younger self taught engineers with a huge ego can be a real PITA. Some have tendency to question everything that has already been written, wasting time.
This is really obvious but good to see it validated. If you don't have firsthand experience discovering and playing with fundamentals, you are at a disadvantage.
Having been on both sides of the fence I can definitely speak to autodidacticism as having yielded some of the most durable and rewarding lessons of my lifetime spent programming, if only because I was really internally motivated to try my hand at game modding, or writing fun toy websites or mobile apps, or even learning Haskell. There are indeed some practical realities you will learn how to overcome that simply are not (and should not) be covered in a usual computer science curriculum (e.g. git, vim, basic shell fluency, etc.).
At the same time I feel that the self-taught dev or bootcamper from the 2010s is really a far cry from the geek culture of yesteryear. As opposed to misfits obsessed with computers, we now have grifters appropriating geek culture to make a buck off the industry. These people lack internal motivation; they are driven only by the external motivation of monetary reward. Consequently it's unlikely that they would delve into more of the esoterica of computing that, while interesting and fascinating to learn about, doesn't yield immediate monetary benefit.
In concrete terms what this amounts to is people "self-identifying" as "senior software engineers" who have never heard of the term `xor` in their life, and don't even understand what a truth table is when it's drawn out for them.
Even still, those who are highly internally motivated are still likely to have blindspots in their knowledge or not know that a field of study useful to them even exists, which is why having a more systematic and thorough review of the field's basics is useful.
Is knowledge of basic boolean logic, "advanced and impractical theoretical computer science," or merely, "table stakes?"
When anybody can identify as anything you eliminate the possibility of drawing meaningful distinctions and assessing qualifications.
Oops, Margaret Hamilton is a terrible example and immediately makes me lose respect for the rest of the article. She was famously mostly a manager who received the credit for the work of others. Read the book by Don Eyles and read between the lines.
1. There's heavy survivorship bias. Many, many self-taught folks are ineffective. The only ones you see in the wild are also talented--talented enough for management to ignore their lack of a credentials which is a little more talented than most.
2. There's even more selection bias: people who self-teach may have more self-confidence and drive. I will say, however, that today salaries seem to be a larger motivating factor. Do you really think the finance bros who switch careers care about the craft?
3. Self-taught != experience. Having "the intuition needed when the recipe breaks at 3 a.m. on prod", is not imparted until you actually deploy something to prod. 99% of self-taught folks haven't deployed anything to give them that exposure.
4. Self-taught does not often give exposure to "hard problems." Most self-taught folks can't do fundamental work on databases, operating systems, file systems, machine learning, or compilers: you know the hard math and CS they teach in schools. Most get trapped doing easy things, and in turn, most get trapped in full-stack roles.
5. Is self-taught really even self-taught anymore? Does Coursera count?
Clearly selection plays an enormous part here. The average engineering graduate is average, obviously. He did what was expected of him and he had enough drive and curiosity to carry himself through university.
To self teach an entire field takes enormous drive and curiosity. It takes struggling against adversity and ingenuity.
The idea that the latter path is generally superior is delusional. In all likelihood it involved far more effort, frustration and time. Comparing a self taught engineer and a graduate of the same skill level it will be clear that the graduate had a much easier time. He had the opportunity to build upon a solid theoretical foundation, when being forced to engage with practical problems, which every engineering program does.
Engineering is also a profession, not a competition. Average engineers aren't a problem, they are absolutely necessary and represent success,not failure.
I have been programming since I was 8 years old. In 1978 I touched my first computer, a Commodore Pet which had been added to the office of a friend of my family, who had no idea what to do with it.
I was immediately drawn into this world and that moment changed my life definitively.
I've since been around the world twice, have written software in a diverse array of markets, including realtime/embedded/safety-critical, professional audio, and scientific instrumentation fields.
I'm a highschool dropout, became a competent POSIX developer in the 80's, a competent cross-platform developer in the 90's, an embedded and safety critical developer in the 2000's, and for the past decade have been shipping products in the professional audio realm. I've also been involved in multiple startups - some huge and impactful, but most small and irrelevant.
I dropped out of high school in 1987.
Throughout this era I've been constantly challenged by academic-trained developers who say things are impossible/can't be done/etc., only to have my work demonstrate otherwise.
The key to this is, I am full of self-doubt, and double-check myself, repeatedly, in order to not wreck myself. Whereas, academically-oriented devs have had to eat humble pie, time and again. This is not to toot my own horn - just an observation that over-confidence (or indeed, radical under-confidence) is often the product of a huge investment in ones' education, especially if there are large debts involved (I have no student debt, but I do have 40 years of computer history sitting in my living room, having kept every single platform for which I've done some form of development ...)
For many years, I saw computer programmers graduate who could not program their way out of a sealed/wrapped box, and many, many times have had to teach them, myself, to get things done.
That said, I've also been humbled by the brilliance of the DSP and machine learning engineers I've worked with, who could not have established their competencies without having had the time to study.
I've done software dev projects in Japan, the USA, Australia, Germany, Serbia, Kosovo, Italy, the Netherlands .. with many of my projects still in use on a global scale.
I think with software development there is a self-study discipline which must be maintained in order to stay relevant - I was lucky to learn that skill at an early age and to use that discipline to gain more skills. I don't think this discipline is taught well enough in the various markets in which I've worked:
It's not what you know. Its that you know you don't know and know how to know.
Project workflow, debugging techniques, separation of concerns, and most important of all: proper analysis (identifying similarities/identities/differences in ontology). All generations of software developers have issues with this, and all of us can improve.
I think there’s an element of fear in the self-taught engineer? I am self taught and even after over a decade of experience impostor syndrome is still going strong!
At the same time I’ve been surprised by graduates when they come across something and say “I didn’t see that in school”, like, what!? I thought the job was mostly learning on the go!
As a self-taught software developer, yeah, it's kinda true. I've encountered developers that are older than me, have more experience as me, has multiple degrees, yet they're dumb as bricks when it comes to anything remotely related to problem solving (or not using genai to do all the work for them, which I think is absolutely disgusting).
I learnt everything I know about programming from buggering around, and just making cool stuff. Then you'll get annoyed how past-you wrote it, and then you'll rewrite it and you'll learn how to make better code & better projects. Most engineers/devs I know that was taught at a university or college can't really do that, and most I know take ages to make anything that can be used (or even shown off as a demo to your boss). Some of this could also just be that there's usually a higher chance for self-taught engineers/devs to be neurodivergent of some sort (adhd/autism), because I am myself and I know that my different perspective does give people a breath of fresh air when working on projects.
meh. There's a lot of really good self-taught engineers but this seems like a weird thing to bring up.
I worked with someone that was self-taught, them vs 2 of use with more formal education, we had a difference of opinion on how something should be be handled so our boss at the time basically posed a contest that whoever could get it done first would be what was implemented. Of course they outperformed and got it out faster.
1. That's a horrible way of deciding what gets pushed, pitting developers against each other.
2. The resulting code was awful to read and very procedural. Written by the same developer that made a god awful hero function.
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
As a self taught developer who has spent most of their career in the big corporate world surrounded by computer science graduates my experience is this:
The self taught developer will eventually figure it out, if they are intelligent enough to approach the given problem.
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.
What that ultimately means is that the computer science graduate is way more compatible in the big corporate world where they are an interchangeable cog that can be replaced at any moment. They operate in a world on known patterns just like their peers. The self taught developer, however, is constantly innovating and doing things in somewhat original ways because they have learned to not waste their personal time on unnecessary repetition, and that cavalier lone gunman attitude scares the shit out of people. Yet, those self-taught people tend to deliver vastly superior results.
Most developers don’t seem to care about superior code. They care about retaining employment and lowering anxiety in the manner that emphasizes least disruption.
Plenty of formally educated engineers will try to solve new and unfamiliar problems.
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.
Maybe the perception is because of the larger percentage in each group.
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.
That's my experience as well. People came to CS because they love computers and want to learn how they work were so different than "I just want a job which makes money" people in every way even in the university years.
Curious people got high on the caffeine and code, and the other group just got high.
All I know is that if my coding ability had been measured through mandatory assignments that I would be force-fed without any immediate need, I would have been disgusted.
"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 also went through a very generalist CS course, that we call Computer Engineering, which covered from hardware to software plus math, physics, chemistry.
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.
This goes both ways. I think the vast majority of my colleagues who got into CS later post-college did it because they needed a job, and that's where jobs were.
> 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.
not all self taught are curious, at least recent batches.
Ya, agreed. I even tried to allude to as much.
Well, I agree with both of you a bit. I'm mostly self-taught with a backing of a technical diploma and half a CS degree. The part I'd pull from the parent here is that I could not reconcile my level of curiosity and so on with the corporate world at all. I tried, it did not work, I just burnt out and resented programming for a while because what they actually valued was the thing other people were really good at, but what they thought they wanted were the qualities that make a scrappy startup great; namely showing up on time for the standup, wearing the right clothes, being tremendously dull with predictable ideas, endless meetings and low level risk mitigation, little agency over work.
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.
"It is curious vs complacent w/ a heavy sprinkle of hard work, creativity, and intelligence."
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.
Comparisons between software and structural engineering make no sense, ever.
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.
Completely agree on software engineering. Not sure if it shouldve been callled engineering ever, but calling it applied philosophy sounds even more pretentious, and while we try to pretend to be rigorous and structured, software engineering really shares a lot more with writing than with building bridges.
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.
"Completely agree on software engineering. …engineering really shares a lot more with writing than with building bridges."
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
"Software projects are never ending, always chasing ever changing requirements."
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?
Try this link (unfortunately it's without images and diagrams but is easily accessible): https://www.fceia.unr.edu.ar/asist/gibbs00.html
> 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.
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.
OK, so let's avoid elitism by doing away with standards altogether. No doubt, doing away with the ISO would bring joy to the treasurers of contributing member states. Whilst we're at it, why not do way with the Metric system which would bring cheers from Trump's backward America?
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.
I think you missed the point and have some misunderstanding that the self taught engineer doesn’t follow standards, which then points back to the elitism.
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.
> that must be known
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.
It sounds more like corporate culture selects for people who are rarely self taught because they will fall outside the "meritocracy" parade.
"We want you to be good, not better than us"
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.
> "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 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.
> Hell, I somehow have a computer science degree which I honestly do not deserve considering how little I understood (and still do not understand).
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…?
The thing you're missing here is that these two statements are not contradictory:
-- 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
> [1] https://www.otherbranch.com/shared/practice-coding-problem
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."
I have a degree in computer science, and I have been a professional full-stack developer for almost 9 years. I could probably not solve the problem in your first link in 25 minutes. I know exactly how I would solve it, conceptually and what data structures I would use, but I am not sure I'd get the adjacent mines part correct on the first attempt.
Then again, this is nothing like the type of problems I work on a daily basis.
(Not GP) After looking at the page and the problem description, I agree. The time limit of 25 minutes is way too short for this considering that the person may already be stressed and find it difficult to understand that big wall of requirements and implement it in this time span. It doesn’t matter if one is a self taught programmer or has a CS degree.
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.
It's a bit off the main topic of this thread, but the problem isn't designed to be finished in time. From the page:
> 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.
I don't think how far a candidate gets on this particular test determines if they're OK or if they're great. I posit that a great one could finish 2-3 steps and an OK one could finish 4-5.
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.
"Basically seeing if they can code" is the goal, yes.
> 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
So as an applicant, I would be left with the nagging feeling that I didn't finish the problem, and knowing myself and seeing the time constraint I choose to avoid those interview processes.
Yeah, I don't think this thread is about the interview process. It's just for the self-taught developers to feel superior. Or maybe I became too cynic, who knows.
I respectfully disagree that this problem needs anywhere close to an hour; and having the problem already broken down into rather simple steps is a significant amount of handholding.
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?
I agree with your assessment of the problem. It’s already been broken out into discrete chunks that are all simply solvable in short order. Even finding neighbor squares is reasonably straightforward (generating all 8 candidates is basically trivial, then pass them through a filter for each of the four edges).
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.
I've solved plenty of hard problems at work, but none of them have ever looked like "count the grid squares adjacent to a given grid square while taking the grid's edges into account so the program doesn't blow up because you tried to access an invalid index."
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.
And it doesn’t do what’s asked? Congrats.
I just concentrated on what would be the hardest part, the "edge" cases (literally.) Wrapping that in a loop that goes through the appropriate indices is not much more work. There is a sibling dead comment to mine which has the rest.
Should probably use
You're assuming closed instead of open intervals.
I was assuming zero-based arrays.
oops doesn't count the edges. Take another minute.
-- joking -- :)
> 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...
Not if the team expects you to pull your own weight, because they will be busy doing the same.
What, then, is gained by joining such a team? You're just taking a pointless pay cut.
> 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?
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".
If you just had "implement mine sweeper" sure, but the page does tell you exactly how to implement it so you don't even have to think to solve it. Just write the 5 functions they tell you to write and done, each of those are a few lines.
I just gave it a shot; I would definitely need more than 25 minutes.
> 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.
Perhaps that is suited for candidates with image processing experience, because looking at surrounding pixels is a common pattern in image and video codecs. I suspect APL-family experience/thinking style will also help significantly (if you haven't seen it, I recommend watching this video: http://youtube.com/watch?v=a9xAKttWgP4 )
The floodfill part (the last one), on the other hand, is the one that stands out in difficulty compared to the previous parts.
Really? We had informal flood fill competitions in my high school... If you understand recursion, it's easy. If you don't... there's so many other things than flood fill you just can't do. And the generalization of saying "oh, that's just a work list" is easy and enables even more things.
> Then again, this is nothing like the type of problems I work on a daily basis.
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 :-)
Most senior devs I know would rather take a clean, iterative approach than brute-force a perfect solution under a timer
It's results like this which put to rest the "myth" that "10x" programmers don't exist according to some people. In fact, it's been my experience that "100x" or even "1000x" programmers exist. (Fabrice Bellard is a prominent example of the latter.) For your given practice problem I'd probably spend more time reading it and writing the code than thinking, unless I'm asked to use something like an APL-family language in which case the majority of the time would be spent reading the problem description.
(Full-disclosure: mostly self-taught with several decades of experience.)
Compared to someone who's basically a zero in programming, any amount of knowledge pushes the ratio to infinity. The average CS graduate doesn't know shit because universities need volume to survive so basically once in, you are spitted out eventually. And faking projects and cheating on exams is rampant, with the complicit involvement of teaching stuff because they don't care and incentives are biased towards turning a blind eye.
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.
> universities need volume to survive so basically once in, you are spitted out eventually.
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.
> 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.
Depends, maybe Its more a matter of description, but I would call the lowest quality engineer I've seen employed a "0.1x" engineer, before I would describe a good one as a 10x.
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.
Now take that good one and compare them to a guy like Thibault Duplessis (Lichess author), look at his GitHub and commit history for Lichess and you will quickly realize that even with your 0.1x starting point 1000x engineers are 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).
Your statement is meaningless, as you did not define what the x in 100x is and what being a "programmer" entails.
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?
Where can I get more of these small programming challenges?
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!
That matches my experience: but it's to be expected as most CS degrees are applied Math not Software Engineering. You have to respect that.
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.
This was my first thought when i read the headline. Many people were told to get CS degrees because they will get a job, not because they love it. The cost of quitting a degree or not using a "valuable" degree is relatively high, especially for people who are inclined to coast. Most people who start college also graduate, even if they aren't prepared or love their program, so we have lots of bad cs graduates.
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.
Computer science isn't about building CRUD apps or SQL queries. Just like mechanical engineering isn't about operating a milling machine.
I wish I were home, so that I can code and time myself for the fun.
Alas, it’ll be a few weeks and by that time I’ll have forgotten :)
Most of my big corporate world experience comprises CRUD apps like these tasks:
* 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.
> 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.
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.
CS curricula being far removed from practical development implies that the coworkers you are sorrounded with who *are able to do practical development are all in fact self taught, whether they have CS degrees or not.
Yeah, I think that most CS graduates that are good at coding are also self-taught (and probably started in grade school.)
University teaches theory, practice is necessary for a well rounded engineer. Most students only do what's required. Good students do more than what's required.
I'm just curious: if you swap the arbitrary 85% out for a more generalized statement, would you agree or disagree with the OP's comment?
I am not certain having a degree vs. being self-taught is the deciding factor in what is likely attributable to personality and motivational differences.
The intellectual aptitude to get high marks is wildly different than the sort of type to solve problems.
In my experience:
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.
The other way of looking at it is that some love for the craft is pretty much a prerequisite for the self-taught, whilst many graduates are there for the career.
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.
I have maybe N=5 of these people, but the one that comes to mind is the gent who was in my game programming classes who had already written his own direct x based game engine and was there to just expand on that knowledge.
It may be personality, but this self-taught developer focused on work ethic — that is, while I lacked seeing the "Big Picture" in technical terms (understanding how all the pieces fit together) I strove nonetheless to make up for it by being the most prolific engineer on the team.
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.
Self-taught and agree that everyone’s opinion and anecdotal evidence won’t answer whether CS degree/classes, code camp, or self-taught is better, because everyone is different and has different experience.
Anyone that’s worth anything at all in this field is “self taught”, some of them just went to school first.
Agreed - my CS degree exposed me to a bunch of low level 'algorithms & data structures' type stuff + a bit of assembly, prolog etc + some math stuff all of which I likely wouldn't have gone out of my way to learn on my own unless it came up in a very obvious way in a problem I was trying to solve. But like 95% of the actual large scale software engineering type work (read: actually building useful software) I learned on my own by building unnecessarily over engineered side projects, or by building stuff while working.
(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 have a CS degree myself but most of the code I wrote/read during college wasn’t a part of any class.
I treated GLSL how others treat Civilization VI. “Just one more shader” - “Oh no it’s 4am”.
I haven't dared even looking at any other Civilization game after the first one. I kept deleting it and it somehow found a way to sneak back when I wasn't looking through some sort of sentient magic undelete function.
Even a degree is self taught. The assessment is typically pretty decoupled from the content. You could say "people that have taught themselves a degree course have a better understanding than those that learnt just enough to pass the assessment".
Agreed. The effective difference between a degree and learning on your own comes down to structure, really. A college course gives you a decent enough structure to know that you do addition, then subtraction before you go trying to learn multiplication. I often find trying to learn things on my own I start from differential calculus in this example and try to work backwards.
> I often find trying to learn things on my own I start from differential calculus in this example and try to work backwards.
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.
> The computer science graduate will generally not even try to figure out a problem in completely unfamiliar territory
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.
> Attentive CS graduates have a structured pool of information to draw from
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.
> 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.
Well... Self-taught means that the person learned by their own initiative, "without formal instruction or training".
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.
> 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?
Yes, but management at every level also anticipates it up front before the typical developer or developer team has the chance to get there.
Pretty myopic viewpoint. You wasted an afternoon figuring out graph-traversal & loop detection from first principles -- using and stretching your mental abilities -- rather than being spoonfed it? That's absurd. Utterly absurd.
I get no satisfaction from rediscovering CS concepts & algorithms first put to paper by the field's pioneers between 1940-1970s, though it sounds like you do.
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.
I'm insulted, but I won't drag this out.
>if had I taken DS&A class, it'd have taken me all of 2 seconds to choose between BFS and DFS
"Hey ChatGPT, explain me how BFS and DFS work, their differences, pros and cons, and which one fits my use case better."
A bit more than 2 seconds, but not an afternoon.
I believe GP's implicit point was that you also need to know even to ask the right question.
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.
The real issue is not making the choice itself but rather bringing the knowledge about what the decision space is in the first place. (But sometimes the "knowledge" is also a limiting form of preconception)
There’s also a huge difference between CS grads from 15+ years ago and newer CS grads. Older CS grads had computer labs, insane old profs who’d cut their teeth on the first computers, and negative stereotypes of computer geeks were still in play. So there was selection bias, most (or at least many) CS majors loved computers and couldn’t imagine doing anything else. These days—with CS the most popular major, which is mind-blowing—most CS majors are kids who would have been business majors 20 years ago. It’s not to say those that love computers don’t still major in CS, but I interview many many many CS college kids who “don’t want to program” and expect to get well-paying computer-related jobs.
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.
> The computer science graduate will generally not even try to figure out a problem in completely unfamiliar territory.
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.
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.
This mirrors my experience as well. I have a masters in CS, but I have to admit that self-taught devs usually exhibit more tenacity.
I also have a masters in CS but I still consider myself to be “self taught” to a degree. I didn’t really learn anything in lectures or from my professors. Most of my learning came from doing homework, reading textbooks, studying for tests, exploring the material, being curious, experimenting with side projects.
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?
"being curious" carries a lot of weight here.
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.
> To be intellectually curious is a rare thing these days
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.
Idk. I think some societies prize it more highly than others. What must it have been like to live in Athens when Plato was running the Academy? What got you permitted to be there wouldn't be SAT scores or grades, it would be curiosity and flexible thinking. When things like that have enough cachet, an entire society can orient itself in that direction rather than toward conformity or repetition. [edit: See also, modern Israel].
(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:
Are you self-taught? The only people I've seen who think self-taught is better are the ones that are themselves self-taught. A degree is like extra experience plus mentorship under your belt... Self-taught individuals don't understand what they're missing, in most cases.
I gotta say I’ve heard this take a lot, and I find it regrettable because I think everyone doesn’t understand what they’re missing, this is a pretty human trait. It’s pretty impossible to just know it all and to not know it so much that you’re just miles from even realizing you aren’t even close.
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.
>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
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.
This! When you are doing something simple (as in there are known best practices) you do want people to have the same formal education. They’ll talk the same language and everything will be smooth. Nobody wants a self taught surgeon or pilot on the team. There is a best practice for washing your hands and you want your surgeon to know it.
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.
It's safe to say that everyone you meet knows something you don't, regardless of background. But in the context of this discussion, it is pretty obvious that self-taught people on average have nowhere near the hundreds of hours of experience solving theoretical problems. Not having that background will actually set people back when it comes to solving hard problems that occasionally (or often) arise. Watching self-taught programmers talk smack about degreed professionals is like watching a couch potato make sweeping generalizations about how sedentary people who don't go to the gym are more physically capable than people who do, because the people who don't are not limited to performing certain exercises.
I gotta say still pretty regrettable take, if you will humor I am happy to explain why I say that.
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.
It does sound like you spent your time well and learned a lot, one of the rare cases. I wonder how much of the research papers you actually understand deeply given that you lack common background knowledge. It may surprise you how many research papers are actually ill-conceived, and it is hard to see how bad they are if you don't know enough about the state of the art. You are on the right track if you want to catch up on what you would have learned in school. Just about anything in CS can be self-taught given enough time and effort, though you may need to seek feedback from others if you can't figure some things out on your own.
>> it is pretty obvious that self-taught people on average have nowhere near the hundreds of hours of experience solving theoretical problems
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...
The more apt comparison seems to be somewhere closer to an athlete that played sports with his friends all day instead of weight training for that same sport and getting instruction.
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.
I’m not a developer. My roots were in hardware engineering (communication/networking) in the 80s-mid 90s, moving into departmental IT leadership roles at senior levels in the mid 90s till around 7 years ago. I sit in the product arena now as I move towards the sunset.
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.”
Given that you work in IT and not development, I should point out that IT is less intellectually demanding than software engineering. I am less skeptical of self-taught IT people because the nature of the work is almost entirely around familiarity with hardware that fits together like Legos, and proficiency with software tools that are designed for maintaining systems without much theoretical knowledge or mental reckoning required.
>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.
> I should point out that IT is less intellectually demanding than software engineering
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.
>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.
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.
> If two people are similar in almost every way but one has a relevant degree, the degree wins obviously.
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.
>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.”
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.
> Yes, my point is that the CS grad has done 4+ years more work in the field than a self-taught
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.
I do hope they eventually let you guys bankrupt out of your student loan debts.
I assume this is meant to be an insult but it fails. Not everyone paid exorbitant prices for their tuition. By the way, student loan debt is the largest thing on the asset side of the Federal balance sheet. They won't let it go unless they figure out a new way to screw everyone over.
I started programming at age 8, and finally went to college for it at age 22 (although not an actual computer science degree). That was almost 30 years ago.
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.
This entire post smells like someone who's salty and trying not to face reality. I might not even disagree entirely with what's being stated here but the framing is just clearly wrong
Also as a self taught developer, I think this is less about academics and more about unsilo'd thinking. My personal conclusion is that I will hire anyone that has at least tried freelance or running a business. The ability to care about relationships to other peoples courts is key to being able to communicate with other people and contextualise the business as a whole.
Sadly, I've made the different observation that (in my country, where university is free and academic degrees are worth their weight in gold) most developers who never went to university think of themselves as the lone gunman while lacking basics after 7+ years of experience.
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.
This does not match my experience. I believe that graduating or not does not matter compared to whether you really care and like the field.
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.
I consider myself being self-taught, but I'm also a graduate. I was teaching myself to do a lot of things before I even went to university, and continue to do so after graduating. The most significant difference before and after university is that now I'm more resourceful and more efficient in searching information that keeps me learning new things outside of academia. Put simply, university gave me better skills to learn, and opened new doors to resource materials i didn't know existed before.
From my experience, the high performance developers can’t be identified from how they learnt to build software. But I do feel there is some correlation with how much they enjoy solving problems.
I found the computer engineering paths to be more engaging from a mechanical sympathy perspective.
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.
Computer engineering will teach you that algorithmic complexity doesn’t mean squat if you can keep your data in CPU caches. The classic is any sort of connected node algorithm (linked list, graphs) which are stored sparsely in memory and therefore do not effectively utilize CPU caches.
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.
There is a definitely a phenomenon visible to anyone who has hired self-taught gunslingers versus companies stocked with highly educated CS grads. Part of it, I think, comes down to motivation and [needing to prove] self-worth when solving problems. This isn't just a phenomenon in code. My grandfather was a solo contractor, my dad was a solo lawyer (the first to graduate college in my family), I'm a solo and self-taught coder, 25 years in the industry (and the only of 4 brothers not to graduate college). There's a personality type that needs to prove something to themselves, has trouble with authority, isn't much of a team player, and never throws their hands up in defeat when faced with a challenge.
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.
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
This is what disconnected corporate people believe (whether they are themselves cogs or are the one operating the drawer), but the truth is that high-performing contributors are never cogs and progress is not measured in man-months or lines of code, etc.
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.
Sometimes, megacorp hits a problem and it doesn't have the right cog in the drawer. Maybe it's because no one in-house has the needed knowledge for it. Maybe because it's a genuinely hard problem. Maybe it's because everything's on fire.
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.
You managed to put some of my previous experiences into far better words than I ever could. Especially the part of my "solutions" that come with tons of "this works for now, but it will break here, here and here". I never worked at a megacorp though, mostly by choice, so it was less getting airdropped from up high and more accidentally being volunteered for a project. Somehow diving deep into an unknown code base and making either surgical changes or nuking good chunks of it, is something I enjoy and have become quite good at.
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.
> you will have the results faster in most cases
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
That depends entirely on the business and the experience of the given developer. There is a false perception that inventing an original solution is high risk. Risk is accounted for by the prior practice of the person doing the work and the degree of testing upon that work. This common false perception is Invented Here Syndrome.
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.
Mega corp doesn’t care about quality of product for the most part. Shareholder value in the right quarter is the name of the game. Often that means predictable and low risk as opposed to better or cheaper
While I broadly agree with you, and am a self-taught (and occasionally mentored) software engineer, I have often thought that to “care about retaining employment and lowering anxiety” is by far the more rational approach in the corporate-dominated software world of today.
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 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 guess it's entirely dependent on the type of programmer. Low-level work with a huge emphasis on data structures and algos, absolutely.
There is no programming without emphasis on algorithms and data structures. All code is algorithms, and works on data stored in, you guessed it - structures.
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.
depends on the dev I guess, probably on both sides of this coin. It ain't like data structures can't be learned without the hand holding. In some cases having the bitter experience aids in realising the benefits of the data structure at the time of learning, making the subject less abstract.
> The self taught developer will eventually figure it out, if they are intelligent enough to approach the given problem.
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.
> The self taught developer will eventually figure it out, if they are intelligent enough to approach the given problem.
> 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.
Self taught means you are self-motivated. You are not just looking at it as a job. That's why code quality is better. Interest is the most strong driving force for one to improve.
Could you share a little bit about your journey - how you got started, your motivations? (I’m trying to teach myself programming/development, hence the curiosity.)
I consider myself a self-taught software person; I merely used a university to assist me in my self-teaching, dohohoho.
Having taken all the college level CS coursework for CS degree (I skipped the math and got minors in education and English), I think a lot of folks vastly overestimate how much they learned in a CS degree. Assuming 50 CS credits required for a degree, 1 hour a week of class time per credit, 3 hours of homework per credit, for 15 weeks, that's only 3000 hours total. So about 18 months putting in 40 hours a week. Granted, you can learn a lot in 18 months full time. But this weird obsession that a person could only learn this material if lectured by a bored and overworked TA is silly.
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.
I’m self taught from a single digit age and yet I went and got a degree and it was eye opening. It was mostly a vocational thing with an absolute assgrind of a program that drops most of the students in the first 2 years, and just beats down into a pulp the remaining ones for the next 1-2. 16 hour days of nothing but projects, individual and team.
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.
It seems to me that the self-taught vs. CS degree distinction is missing the point: a point Peter Siebel made very clear in his chapter ordering for Coders at Work.
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.
It's less about pedigree and more about mindset: curiosity, resilience, and a tolerance for discomfort
This has been my experience as well, though I was somewhat self-taught before seeking the 'paper' qualifications other developers had. Best of both worlds in a way.
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 have a similar effect on consultant. It’s usually more on the “this isn’t that complicated guys”. I’ll riff off a high level list of things that need to be done, tell them I could do it in a day/week/month and then tell them I want a daily audit of their hours billed and progress made (I’m actually a finance guy but a self taught dev). They usually don’t want the micromanagement so instead they’ll take day to rethink it and come back with a “yes actually i think we were over engineering things a bit” but really we both know they were just planning to pad their hours. It’s a silly dance but usually makes a good working relationship that GSD at an acceptable pace.
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.
Fascinating, because as a consultant almost always my clients are either the sort to build a vast mess of microservices with eventually consistent enterprise service buses for an internal tool with two dozen users OR they are trying to figure out how to update their one windows server 2016 instance without taking down production.
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.
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 internally by my department 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.
I think all this focus on degrees in your response as well as the others is misguided. I think the real problem is just that they don't give a shit. Giving a shit is the first step towards becoming competent.
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.
I agree and I don't mean to discriminate, its just one particular unique demographic I have and I'm likely over fitting it as a lens. I've worked with plenty of degree educated engineers who are extremely competent but it just bugs me that they all seem to fold in an instant when encountering resistence up the chain. Perhaps it is simply survivorship bias.
wat. no. Higher education teaches you critical thought and how to engage deeply in analysis, dialogue and discussion. If your coworkers with degrees are not doing so, it means they are simply there to do the work and get a paycheck. Odds are, it is a signal that they are more engaged with the rest of their life than they are with their day jobs... so while you see their lack of caring as a lack of competence, odds are you can instead take it at face value -- they just don't care. Now, that is still be a legit complaint against them, but it is not a flaw created by having an education.
sure but I've seen degree educated people engage deeply in analysis, dialogue and discussion and then proceed to do wrong-headed, deceitful, cruel and even stupid things. I half wonder if an aspect of it is some ritualistic process to lull oneself into a false sense of security. I'm probably not describing higher education, but there's a thing, a sort of blithe unquestioning sleepwalking that I struggle to adequetely describe.
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".
Well, not having lived your life, it is hard to say... you might be the smartest person in the room but have trouble communicating with others in a way that makes them trust your take on things. Or you might not be the smartest person in the room and are not hearing the reasons why everyone else is doing things you disagree with. Either way, it sounds like there are communications problems acting as barriers within your teams. This is really common, so that isn't a diss in any way. But not having lived the same experiences you did, I can't say specifically what the problems are... all I can say is that the level of frustration you are sharing is often rooted in a lack of understanding between team members.
Except I'm pretty sure that I'm a good communicator. Background in sales and performing arts, mentoring and presenting are some of my strengths. I'm always immensely popular among my peers and I'm usually quite chill when it comes to horse trading and picking which hills to die on (isn't HTTPS one of those hills?). I appreciate that its probably a chip on my shoulder that's preventing self growth but I can't but feel a combination of youthful looks and lack of degree is the reason I seem to be constantly forced to prove myself again and again and again, despite often being one of the stronger technical members in the circle.
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.
The reactive ingredient is passion, not the learning modality. Low motivation is really limiting, no matter how you like to learn. Of course, this topic is hard to discuss in a quantitative way because the number of engineers you come across in your career is a minuscule fraction of the total. Hard to draw broad conclusions like this, but here are a few:
- Formal education is great for foundational concepts (math, hardware, operating systems, compilers, graphics, etc.). 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. 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.
- Most engineers I know would consider themselves a mixture of formal and informal/self-taught. Again, if you have passion for engineering then you probably like to learn and build, which means you're complementing any formal training with your own tinkering.
I've met and worked closely with amazing engineers and have never found their education style a distinguishing factor. Their passion however, was obvious.
Also, the examples given in the post (Linus, Margaret) were incredibly academic :-)
> 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.
I think that what most people mean is that with a self-taught engineer, you have no way of knowing whether they have the foundations. It's going to be much more common with self-taught engineers than with formally-educated ones to have areas of surpassing brilliance, and areas where they don't know their arse from their elbow, and no easy way to predict what those will be until you get to know the specific engineer.
With formally-educated software engineers, so long as the school they got their degree at is a reputable one with a decent program, you can be reasonably confident that they'll have a solid foundation, and if you're familiar with the institution you may even know what their strengths and weaknesses are likely to be.
> With formally-educated software engineers, so long as the school they got their degree at is a reputable one with a decent program, you can be reasonably confident that they'll have a solid foundation
Based on the 100s of candidates that I've interviewed over the years, I disagree. In fact I often wonder what on earth people are doing at these university courses, because they rarely seem to have even a basic grasp of computer science. I've had to personally mentor many (academic route) engineers over the years on what I would consider absolute basics.
Frankly, I don't consider a degree a useful barometer of quality at all. They're only useful if the candidate is applying for their first job out of university. After that, experience is much more important and I basically ignore the education part of a CV.
When I was hiring back in maybe 2020, I used a basic FizzBuzz test. Yep, the FizzBuzz test you've all read about. About half the people (all college grads) who took it could not pass in the allotted hour. Yup, an hour to do FizzBuzz. Whatever language you want. Whatever you want to Google. I'd say 40%-50% could not do it.
A common error was not being able to get the first number evaluated to be 1. They had written(copied) for loops as `for i:=0;i<100;i++` so many times that they couldn't understand that setting i to 1 was all they needed to do. They didn't see the code. Just the "loop line" and it wasn't doing it right. Then it was making it stop at 100 instead of 99. All that before even trying to test mod 5 and mod 3 first.
The people who did pass it would have written it before I'd even finished describing the problem and they would all but sneer (in a professional manner) at the rest of the code "challenges." We made offers to those people and they worked out great.
I've also seen this in coding interviews, but I will also add that when this happens and the line just doesn't work "as it should", a common reaction is to start changing things essentially at random (i.e. without trying to methodically deconstruct what the code does). And sometimes this random approach ends up working in the right direction, but because it requires more than one step to get there, the (correct) first step gets discarded because it didn't immediately produce the correct result.
In general, it feels like many students learn to program by rote memorization of patterns - i.e. they remember that putting those parts in this sequence gives this result, and putting them in a different sequence gives a different result, but they don't know why there is a difference; they just treat them as magic incantations, sort of.
It's kind of like if someone learned to write by memorizing entire words as is without learning the alphabet first. They can recognize or spell any word they already know, but give them a new word and they are completely stumped.
You gave the perfect description of an LLM.
I have never seen a person who self taught even the basics of math, some think they did but they just learned some fractions of the first course past what they currently know. Like nobody self teaches the equivalent of a basic math degree.
Programming though, there are plenty of people who can self teach programming and algorithms, since the theory there is much shallower and hands on than math.
This used to be my experience with credentialed candidates, but I do think the programs universities have been putting together (which are from what I gather, extremely expensive tech school programs that optimize for FAANG acceptance) have made the hit rate for juniors that can actually hack slightly higher than what I remember.
Whether they actually are interested in the work still seems more important than the paper though.
I completely agree. Where I'm at right now, most of the brilliant engineers and admins don't have a degree at all. The ones with degrees are the do nothing look busy with meetings managers.
> .. they rarely seem to have even a basic grasp of computer science. I've had to personally mentor many (academic route) engineers over the years on what I would consider absolute basics.
This is kind of fascinating. Please give some examples.
I find it's a crapshoot even with formally educated engineers whether they know what they have supposedly been educated in or not
> 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.
> It's actually hard to find a math tutor to proof your vector math program in your late 30s.
They exist, if you know where to look and are willing to pay (source: me, or generally and probably more affordably wyzant.com)
It was nice in my 20s when we traded labor for beer and weed. A style of collaboration and exchange is what I aimed to describe.
Now, all my peers have wisened up and can get the big bucks elsewhere. So definitely, if a student of any age has the money, they can get a tutor. But it's nice to find a young tutor who would gladly proof your work in exchange for tacos or help on their CS homework
As another commenter proposed, try getting a course book and going through it at your own pace. With your newfound determination and interest it wouldn't surprise me if you stuck with it this time. Alternatively, if you prefer putting vector math into immediate practice, fields like graphics and game dev use it a LOT.
I've got them under my thumb now, and thank you! I've managed to muddle through linear and develop an ECS and prove it's in linear space and enough discrete to be pleasantly surprised by Noam Chomsky's many lives.
I used them as examples of when I transitioned back to CS and had to learn what to learn before I could learn. So to speak.
Anything on your own learning journey you'd like to share?
Have you considered trying to acquire the language by reading a textbook alongside a lecture series?
Quite a bit! MIT and Harvard open courses are great for aligning self-guided learning and finding vetted resources. My regex compiler would not be functional without those lecture series.
> 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.
> 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).
This is a good point. I think the structured curricula can be the only way to learn many technical topics, even if you aren’t being formally taught. I also found my time at university to be invaluable for the equipment, facilities, and resources that were made available to me for learning that I could never have provided to myself.
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.
University classes are great. They force you out of your comfort zones. When I was self taught I would never have pushed through learning the socket API in C, doing so many projects in bash, studying the academic side of distributed systems, data structures, common algorithms. Stuff like that.
I interview a lot of self taught people, or boot camp graduates, and their issues is often that they pigeonholes themsleves into a comfort zone, or they fall apart when you ask them about academic topics that are relevant for the job.
On the other hand, people who never taught themselves anything code related often suck at coding, or they've forgotten a lot of what they learned in college. Hell, for some of them, even while still in college they've forgotten a lot of what they were taught the years prior.
It's best to have done some code by yourself before university, so that you have faced the problems that arise naturally, and when the courses present you with clever solutions to them, you retain them. You don't just dismiss them as fancy theoretical stuff you need to know for the exam, then promptly forget. You've footgunned yourself with memory management enough times that it speaks to you when you get explained RAII.
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.
By the time I got to university I already knew C and the socket APIs and have been paid for delivering software that uses them. I had a friend who made a lot of money selling games he wrote in high school for the C64. Both of us were well ahead of new grads in terms of raw programming skills.
What I was missing were things like Calculus, Linear Algebra, Discrete Math (I knew parts having read TAOCP but had gaps). I knew data structures and algorithms but learnt some I didn't. I had some other random theoretical exposure but the CS program plugged some holes and I did learn random things I didn't know. I also learned more about how to learn.
I think the CS program made me more well rounded. I don't think it made me a better programmer. There was zero challenge for me in all the programming related courses. Where I had to work was on the math and theory side.
> 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.
Your criticism of the specific details rings true, but I also liked the overall thrust of the GP which is that two common failure modes for working software engineers are either being overly academic and not efficient at practical application of that knowledge, or else being too superficial and direct about solving the immediate problem in front of them without recognizing or even being aware of the theoretical knowledge and concepts that can greatly improve their local solutions.
I think it’s fair to say those failure modes tend to disproportionately accumulate university graduates and self taught developers respectively. As long as we don’t use it as some kind of litmus test then I don’t think it hurts to call that out.
I acknowledge that theory-oriented vs. problem-oriented would be a fair characterization. But I think the language of "comfort zones" and "pushing through" was unfortunate and unfair. It suggests that somehow self-taught developers are lazy, when in fact they often have to work harder than anyone else, because nothing is handed to them by a professor or university. (Not to mention that it can be a lot harder to get a job when you don't have any academic credentials.) I would say that teaching yourself a difficult, esoteric skill, with no outside help, is inherently breaking out of your comfort zone.
College being a huge expense is an anglo-centric issue
It's important for those concerned, but most people aren't, so I don't like to include it because then the entire "value of college" debate shifts on the economics of it.
>You speak only for yourself though. I'm largely self-taught and have done these things.
I did say "often fall apart"
> College being a huge expense is an anglo-centric issue
Ok. Well, the tech industry itself is rather "anglo-centric", don't you think?
> It's important for those concerned, but most people aren't
If you just want to ignore the United States, then fine, but in general, good luck trying to ignore the United States.
>> You speak only for yourself though. I'm largely self-taught and have done these things.
> I did say "often fall apart"
I'm a bit confused here. I was referring to the first paragraph in your original post, whereas you seem to be referring to the second paragraph?
>I'm a bit confused here. I was referring to the first paragraph in your original post, whereas you seem to be referring to the second paragraph?
My point is, I think, that I would wager you are not the norm among the exclusively self-taught crowd
There's going to be a lot of people on Hackernews to debate me on this, but I'm going to go out on a limb there and say: There's already a selection bias if you're hanging on here.
Programmers who have an issue with the academic parts of CS (self taught or otherwise) probably wouldn't hang out on Hackernews to read such content as: "Writing a competitive BZip2 encoder in Ada from scratch in a few days (2024)".
It's hard being self taught and overcoming the comfort zone, it's hard to go out of your way to figure out what you should learn as you don't have the luxury of being forced to follow a curriculum drawn by experts of the field you're studying.
My thesis is that I disagree that "Self-Taught Engineers Often Outperform"
Formally trained engineers mostly outperform, with a few self-taught people that are going to stand out, but they are the visible part of the iceberg, and if you advise someone to go self-taught, most likely they'll end up underperforming compared to someone who's gone to university. And that's normal, because being self-taught is harder.
> I would wager you are not the norm among the exclusively self-taught crowd
What is the norm?
> the self-taught people I interview
That's another small and unrepresentative group, possibly much smaller than self-taught developers who visit HN. In total, how many self-taught people have you interviewed? Either way, there's selection bias.
> a few self-taught people that are going to stand out, but they are the visible part of the iceberg, and if you advise someone to go self-taught, most likely they'll end up underperforming compared to someone who's gone to university.
That's kind of the point, though. Who would advise someone to go self-taught? That would be strange advice. There's definitely survivorship bias in self-taught engineers who have managed to make it in the tech industry, which is exactly why you should pay attention to them: they've successfully overcome the odds and obstacles. The % of self-taught who get to that point is likely much smaller than the % of university-taught. As you say, "being self-taught is harder."
You are taking the average of two groups but there is no iceberg, the self-taught people who make it are the only ones in that group...the other people do other things. It is like including the people who drop out of college in your group. As you say, self-taught is harder so people who go through that are going to know more and will end up knowing more that is useful.
People who teach at university aren't the experts in the field. The situation of university is inherently artificial created to fulfill a wide range of objectives which are largely unrelated to utility for students (and certainly not, utility for employers). For most subjects, people who teach at university are going to be very far from the experts...if they were experts, they wouldn't be teaching.
> My thesis is that I disagree that "Self-Taught Engineers Often Outperform"
They do in FAANG.
> If you just want to ignore the United States, then fine, but in general, good luck trying to ignore the United States.
Sorry to disappoint you, but as a Canadian hiring mostly Canadians no I don't care about how expensive college is in the US on a day to day basis. It really is just a US problem. Canadian Universities are still expensive but not remotely in the same ballpark as the US. You can often pay the tuition by having a decent summer job.
Good luck supporting yourself as a full time student in Toronto or Vancouver if you don’t have family locally, or if your parents don’t have the money to help you out.
Most people at these schools do have family locally to be fair.
> I don't think anybody denies that, but getting into and paying for a university is very much a financial and social class issue.
I mean... Not really? I got a BS in Computer Science from a cheap, small university (plus a bunch of it at my local junior college, for even cheaper!), and the quality of the education was better than I've seen out of "excellent" schools. It was really cheap, too! Easily paid off after a few years at software engineer salaries.
Hell, with entry-level salaries at places like Google or Meta, you could probably pay the whole thing off in a year.
I think people focus far too heavily on "Ivy League" schools and the costs associated with them, and forget that things like junior colleges and small universities still exist, and are still relatively affordable.
With a "commodity" degree like CompSci, cost isn't really a problem.
Besides, no one gives a shit where you went to school after your first job in the field. That first job might be marginally harder to get, and you might have to settle for slightly lower pay, but you're going to be far from struggling with the debt unless you really overpaid for that degree
I actually do deny that university classes are great. Many are actively harmful. When I went to university, the intro level cs class was taught in c. It took me decades to unlearn.
The idea that having knowledge of C is harmful is possibly one of the most anti-intellectual things I've heard today. I guess you don't value education, so you wouldn't know, but your brain doesn't have some limit. Extra knowledge is at worst unused, but often helps in various subtle ways. Never does real knowledge "hurt."
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.
Were you teaching for a software engineering degree or a comp sci degree? Former is more focused on practical skills that are more “useful”, hence all those cross-discipline courses.
I’d argue that the core comp sci skill is more useful than learning how to use React or whatever. But I guess I’m another old man yelling at cloud.
Good point. It was Software Engineering, but I still expected to see more foundational classes there :(
And I'm totally ok with the React part, I just dislike the fact that React was the only real "meat" in the course.
It really depends on the university, and then also on the lecturer.
When I was self-taught, I learned the socket API in C because I needed it for what I was trying to do. This was long before college, and when I got to the latter, it turned out that the person teaching us networking only knew the absolute basics of the API, and I could already run circles around them, so it was the opposite of "out of my comfort zone" (which is "in the boring zone").
Totally agree that the sweet spot is a mix: struggle on your own first, hit walls, make a mess... then when the structured material shows up, it actually means something
Boot-camp grads are not self-taught, they went to a boot-camp. Boot-camp people are career opportunists. Nothing wrong with career opportunists, just saying that they are different than a self-taught dev.
They likely outperform for the same reason they are self-thought— i.e. it's most likely a confounder. If you have enough curiosity/pull, motivation, discipline to do it, you'll outperform in general, self-thought or not.
There's also a survivor bias at play, in the sense that the self-teaching attempts results that you see in professional environments are those that made it. So, the true question is, for those that tried this path and failed, would have they been better off with proper teachers. Sometimes it may just be a matter of time - taking longer to learn because of various reasons, that wouldn't be the case in normal educational environment.
With this said, I went through CS and math school and enjoyed it, but I don’t think I’m compatible with the format and prefer self learning.
Seeing as no statistics were even presented, I don't think you need to worry about statistical fallacies. Often is just used as a weasel word in this case.
The amount of effort that people go to cope with the fact they lack education.
There are brilliant self-taughts and educated morons, that's obvious. Personally, I am mechanical engineer that got interested in simulations, then in writing simulation code, then in gritty details of implementing numerical methods on a real computers, and ended up writing a compiler and simulation runtime. But I am not trying to convince myself that having CS degree in addition to my ME degree would not help me in any way. Not only because CS in the end is not about coding.
This is a similar situation to car mechanics taking pride in often outperforming mechanical engineers in fixing oil leakages or punctured tires. That's probably true, but we don't teach mechanical engineers so they can fix our cars (though my first job was supervising some huge water chillers and compressors in a manufacturing plant, where I often did a dirty work because our technicians didn't know how, but it is a matter of personal traits and interests. I like to get dirty).
"cope with the fact they lack education"
Not everyone can afford the education. This isn't about cope, it is about hunger, drive, and passion.
The article echoes what I've seen working in big corp with grads who were stellar at varsity and hopeless for any actual problem solving that wasn't first explained to them.
The tragic reality is that most companies filter out candidates who didn't go to a handful of universities, or worse anyone who doesn't have a CS degree.
As a professional software developer who also teaches CS at a university, my experience with successful engineers all comes down to interest and passion. Self-taught engineers are obviously interested in the subject, but among engineers with a degree, you have a mixed bag. Some of them have no interest whatsoever in the field other than a diploma, but they are familiar with the terms of the art, which makes it difficult to separate the good ones from the bad.
That's exactly what it is. Somebody who is self taught is _by design_ somebody who's extremely motivated and interested in the subject.
> Somebody who is self taught is _by design_ somebody who's extremely motivated and interested in the subject.
How so? I've self-taught myself plenty of things that I don't have an interest in. I dare say I even despised some of it.
It seems fair to say that motivation is necessary, however often the only motivation is a means to an end, not the endeavour into the subject itself. But motivation is always necessary. That is not limited to self-teaching. I am not sure that bit is actually additive.
I agree that passion and interest are key, but they don't always line up with what people studied or do for work and sometimes people outgrow what initially excited them on the job. Switching paths is tough once you've invested years. But I think when someone puts serious effort into their PAssion-INterest outside work and endures the PA-IN of self-study, they're more likely to succeed long-term because that extra drive really matters.
Think of knowledge as a circle on a board. https://matt.might.net/articles/phd-school-in-pictures/ is a great example.
Everyone that goes through university learns within a pretty similar circle initially. That circle is surprisingly narrow in the broader field. Who has time to teach the dmc algorithm (used in all highest ratio data compression software) for example. Instead everyone's taught a pretty common curricula in all comp sci courses despite the field being much much larger than that.
Now some who go through university will go well beyond that circle of knowledge. These are the most amazing programmers you'll ever meet. They'll know algorithms that are mentioned in white papers, not taught in courses and they'll kick ass. Those who've been in the industry a while have met a few like this.
Likewise self-taught engineers. They may have humbling gaps in knowledge of that big circle of knowledge that everyone that went through a comp sci course was taught. This may be a constant source of imposter syndrome but also humbling motivation for them. What they'll also know is a whole lot of stuff outside any standard curricula. After all they have the same motivation that the super engineers who went through university and continued to self-teach had. Their circle of knowledge was organically created through passion and that passion is actually one of the best signals for performance in not just engineering but anything in life.
> Linus Torvalds built Linux by rewriting MINIX to scratch an itch. Margaret Hamilton debugged Apollo guidance code on-the-fly, inventing modern software reliability.
Their very first examples are Engineers with formal training. Formal training gives you the mathematical and engineering maturity TO tinker.
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?
you can "accidentally" write a kernel, at least in my case.
I was doing some embedded stuff when i was at school. I needed to run some "functions" in parallel. Obvious choice would be using a RTOS, but i did not know the exist of RTOS, so i spun up some timer interrupt, a "queue" of function to run parallel, an isr that acts like "scheduler", some variables that act like "semaphore", etc.
Only few years later i realized i have invented a very simple "RTOS"
Margaret Hamilton (checks wikipedia) studied mathematics at the University of Michigan in 1955.
Back in 1955, "computer science" wasn't a thing yet. Computers were the domain of electrical engineering and math, the latter of which was what Margaret studied..
Computer Science is just applied math.
Torvalds had very little formal education in computer science when he released the first version of Linux in August 1991.
Recently, I've been trying to teach myself some numerical thing I don't have prior experience on (building a sparse LU solver, if you're curious). What I've found is that the single most useful resource I've found is not trying to build one myself (because where do you begin?) or by ripping apart the internals of existing solvers to see how they work. No, it's stumbling across the lecture notes of a course that covered that material, in no small part because by stepping up a level and looking at the other lectures, I can discover the other relevant things I didn't know were relevant. And this property has held true in my experience for other topics I've had to research on my own: the highest quality materials are invariably university lecture material.
If your main thesis is that university instruction isn't worth it, why is all the best material university instruction? Sure, there's an argument that learning how to build something is best done by actually building it... which is why university courses invariably have "build what we're teaching you to build" as a course project that is a significant portion of the grade.
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.
Two people are cited as example.
Linus Torvalds has a master degree in computer science
Margaret Hamilton studied mathematics than proceeded to work at MIT, computer science wasn't really a thing back then, but she had a close enough education.
Most of the big names in computing have some formal education in addition to being tinkerers. Purely self-taught yet outstanding engineers are the exception rather than the rule.
College teaches you things you probably won't see elsewhere, theoretical foundations, lesser known systems, etc... You won't see that elsewhere because it is hard work and you won't get immediate results. It is not particularly fun and employers won't pay you for this. But if opens up your skills and complements tinkering well, for example by recognizing that the problem you are trying to solve is a classic problem that many people have studied before you and there is a whole lot of information on it that you can miss if you don't have the right keywords.
> Two people are cited as example. [...] Linus Torvalds has a master degree in computer science
Technically it was accomplishments that were cited. And in the case of the accomplishment of building Linux, that was done so prior to Linus receiving his CS degree.
That said, university was noteworthy in his case as that is where he gained access to Unix systems — something a regular person at the time wouldn't normally have access to otherwise — which ultimately developed his interest in creating Linux. Access to machinery regular people don't normally have access to is the value-add.
Which is the contention around modern CS degrees. What machinery, as it pertains to CS, can't you reasonably access today without going to university? Even state of the art GPU/TPUs, which might be the closet thing analog to Unix boxes of Linus' time, can be rented at home for a tiny fraction of the cost of attending a university.
> Purely self-taught yet outstanding engineers are the exception rather than the rule.
There is probably no such thing as a purely self-taught engineer, at least not alive today. Formal educational resources have been so easy to access over the past many decades that there is no advantage to being purely self-taught.
Before the advent of the printing press, you probably had little choice but to be purely self-taught. Access to formal resources was reserved for the lucky few. But those days are long, long, long behind us. I don't suppose the distinction between "self-taught" and "not self-taught" is even real anymore.
I think one needs to be careful with statements like this. Is it the case that those who outperform tend to be self taught? Or that those who are self taught tend to outperform?
I can easily see why the former is true. The latter seems a lot less likely.
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.
> The author cites examples such as Linus and Margaret, but IIRC they studied CS and/or math as part of their educational upbringing...
What is studying if not self-teaching? But, semantics aside, Linus, at least, was programming long before he attended university, and his claim to fame was built early in his time at university. It is true that he "studied CS", but that came later. He is unquestionably self-taught in the area for which he is best known.
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.
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.
My reading is that the statement wasn't an opinion either way, rather it was questioning whether survivorship bias needs to be accounted for.
To your point though, I think it doesn't matter so long as you've learned to deliver business value. Application of broad and diverse skills may deliver value at a start-up for example, but wouldn't get too far at a ticket shop.
The point I was raising is that I don't think it's the self taught angle itself that is the causal factor. As an example, there's lots of things I'm self taught at but also terrible.
However, someone who already has the talent to be really good at something and who has the inner drive and motivation to push themselves is someone who is likely to excel. So if you find someone who is excellent at something and self taught, it's not a surprise. They probably combined natural talent with a strong work ethic, and lots of exploration of the entire search space.
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.
As a self-taught engineer who made it pretty far as a career, getting to work at CSIRO (Australia's Science and Technology Research Centre), I can say I definitely did not outperform my peers there. However, engineers at CSIRO felt I outperformed the average engineer.
I was occasionally brought in to interview new potential hires, and I don't think there was a significant difference between the self-taught or the classically trained (either software engineering or computer science).
I think the difference was first of all, did they just love building, and secondly, did they ask the right questions as they went through the development process.
I think I struggled in the 2nd half of that, and I could run off on some far-flung direction not because I didn't know what needed to be done, or the "right-way", but sometimes because I wanted to try to prove that I was as capable as my peers. But the plain fact is, I just wasn't, and I'm ok with that. It's kinda how I ended up as a CEO, I can understand and direct the product/technology from a high level, and particularly now that we're in neurotech, I'm not the right person to be writing C.
So if you want to be self-taught, you can go far. But when you get to the top, you're probably going to want a great mentor who won't necessarily be teaching details about coding, but more about the approaches to engineering.
I've not met anyone in the industry who wasn't self-taught. Nobody gets by in this line of work on just what they learned in computer science classes.
You simply will not sit next to someone who was lectured by someone else in detail on every aspect of the whole tech stack you are using.
To get through those CS classes themselves takes a lot of self-teaching. The lecturers are often terrible, and you have to rely on your own research to "get" the stuff enough to do the assignments and pass tests.
Yeah, this industry is by definition self-taught. Unless you're getting your boss to read you documentation and Google answers for you.
There are a lot of people who do a CS degree purely for money reasons, but I've found those people turn into PMs while the engineers have an actual interest in engineering. It's torturous to do a very mentally difficult job that you don't even want to do, and those people pivot to other adjacent careers.
Everyone is self taught. School can lead you to water, but it can't make you drink. Every piece of understanding in your head came from your own learning efforts, whether that be trial and error, reading a book, listening to a lecture, spending too much time on stack overflow, or typically all of the above. School provides structure which helps with discipline, which is a serious obstacle for many people's learning efforts, especially when they are young, as well as exposure to concepts that one may not find easily without both curiosity and good research skills. But ultimately school is never more than a foundation to build off of in one's lifelong pursuit of learning. The difference between high and low performance engineers is often entirely based on how much effort they put into continuing to grow.
Self-taught is a double edged sword.
It generally can't occur without some level of passion for the material. But you also tend to miss the boring details.
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 basically had a grab bag of shell, python and ruby stuff that I learned how to do over my first 5 or 6 years in the industry and then saw an article about Haskell, tried to learn it and realized, I don't actually know _what programming is_, and then spent 10 years teaching myself all the computer science stuff that I missed from not having a degree.
I still don't know Haskell, but it was a valuable learning experience anyway.
I got hooked in a similar way. Wrote an Excel macro to automate an operational thing I did in my real job, and then asked myself, "Wait, how did that work?"
My experience as a self-taught dev too. I managed to get employed as an SE without a real computer science foundation, but then I just kept teaching myself details of networking, operating systems, memory architecture etc. and learned other topics as-needed.
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.
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.
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.
"excelled in these classes and have had impressive career trajectories after school."
This also has to do with networking. I was a CS major and a friend of mine, who couldn't code and wasn't interested in coding, was also a CS major.
He joined a fraternity and after graduation, could have had a high-paying coding job with basically no interview, because of his network.
I learned too late that going to college is 10% learning and 90% getting into the right social/friend groups to help you with your career.
This is what self-taught coders (with no degree) usually miss completely and have to spend years working up the ladder of shitty companies.
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.
There's no real proof in this article that anyone out proforms anyone else. The author lists a few notable cases with a few notable people, but I have to ask.
Didn't those people get an education? Didn't they go through school?
I did a quick search and linus has a masters in computer science.
What is a self taught engineer then?
I would expect that an article with this kind of claim in the title, would have some data about code quality, qualitative reivews from coworkers and managers, with different cohorts of devs, over some time frame.
This piece right now, just seems like an opinion without substance.
Additionally for what it's worth, I personally think of myself as a self taught engineer, so I'm biased to actually agree with the author. However I feel like this claim lacks substance.
Yeah, I find myself disagreeing as well. I think the whole thing also boils down to: If you're self taught and have no achievements, you have no job. So you're not comparing self-taught to academic, but the cream of the crop to the average.
Would've been way stronger if it included actual studies
All software engineers are essentially self-taught. Building non-trivial complex software requires the acquisition of enormous amounts of knowledge you didn’t learn at school. If you can’t teach yourself, you aren’t going to go very far.
I’ve never noticed much difference between the people with CS degrees and the ones that don’t. It is always people with relentless curiosity and stamina that have the elite skills. The only thing I might attribute to people without CS degrees is they seem more likely, in my experience, to come up with interesting ideas that actually work by taking unorthodox approaches to classic CS problems.
i really quite like the quality of vba code you can find in excel sheets in non-tech corporate environments, well, at least, the range of quality you find in there. there can be some incredible ones. code quality of matlab scripts and scientific code written by mathematicians and engineers can also be pretty eye opening.
when the only goal is a product that works, you get a lot of innovation and a lot of speed. when you don't have to worry about review, testing, and deployment, you strip out 80% of the overhead.
i heard the hedge fund renaissance technologies does not target hiring people with finance backgrounds. i wonder if you can build a tech company out of people who are just going to figure out javascript for the first time on their first day of work. when the performance hurdle is "learn something new on your own with minimal guidance", you immediately filter for a group of innovative people with initiative and drive.
But why is this surprising at all? Self-taught engineers most likely than not have the intrinsic motivation that CS graduates lack, who got into the field because of peer pressure or money.
And the raw talent too, that someone can master multiple disciplines is a sign of intellectual dexterity. Not too say CS graduates are not talented but self taught ones master more cognitive fields, which aid in their programming tasks because programming is a cognitively demanding job.
I was self taught from around age 12 with legit coding pre-ubiquitous internet and have a EE/CS degree. I was coding Mode X assembly demos in C, Pascal, and Assembly by 17. Most lower division courses were cake. I took 4 CS courses one time under a quarter system which is faster than a semester schedule. Many all-nighters, but got it done. The most important value of it is challenging your abilities and a common knowledge foundation. This is something self-taught only rarely or never receive. There are also too many people in STEM jobs to collect a paycheck while lacking passion.
Phrased differently: "people who have already displayed an aptitude for independently determining what is worth learning and learning it excel at tasks that require determining what is worth learning and learning it."
I'm going to go against the grain here and say that in my experience, self-taught engineers typically deliver worse products, and I say that as someone who is mostly self-taught, albeit lucky enough to have benefited from good mentoring. The best programmers I ever met all did software engineering or computer science, or were themselves mentored by others with a lot more experience.
I think the difference comes down to how you view programming. The self-taught programmers I've met typically see programming as a means to an end, and take "it runs on my machine" as the measure of success. Someone with more discipline will understand that that's the lowest bar and mostly a given for someone whose job is to write code. The real measure is can you come back to it in 6 months and know what you did? Can you easily expand on it to add new functionality? There's a craft there that isn't obvious unless you've done enough coding for long enough to run into the problems that software engineering is designed to solve. And if you're built like that, mentoring helps bridge that gap, because you understand why certain techniques exist. They're not just arbitrary patterns.
So I don't think it's being self-taught that makes the difference, but rather, being the kind of person who writes code that gets revisited. Even if you make a hash of it, it'll give you context so that when someone better than you comes along and points out a better strategy, you understand why it's an improvement. And I think that's true regardless of whether you're self taught, or you have a degree, it's just that having a degree in software gives you those strategies from the get-go, even if you don't necessarily have the context.
Those best programmers you ever met; Was their first introduction to programming in university?
The single very best programmer I've ever known was self taught. He went part way through a CS program and dropped out but that was after he was already the best I've ever met. Incredible skills. Software that worked. Incredible productivity. Across different languages and technologies.
Rarely have I met someone who didn't have interest in software and computers before university (e.g. as a kid or teenager) be a really great software engineer. I've met many who took CS or Engineering because it's a good profession, they can make money, and have no passion or particular aptitude.
In my opinion the best mix is a combination of self taught and some formal schooling. Passion, aptitude and education. You can learn the formal stuff on your own but it's harder to do.
All of us software engineers are self taught. The stuff we do is generally not taught in university. I have a CS degree but 99% of what I do is not that. That's not to say formal education in CS and various related areas is not useful. In some specific software engineering jobs perhaps more so than others.
This is such a weird article, the two examples it gives, Linus Torvalds and Margaret Hamilton did in fact study at University. Linus created Linux while studying for a Masters in CS and Margaret had a graduate degree in Mathematics, probably as close as you could come to CS in the 60s. So it seems if anything those two are counter examples?
I wonder how much this is personal bias. I'm self-taught but I have absolutely no idea how I perform on the bell-curve against formally trained software developers.
From personal experience I've had to spend time learning concepts that I "ran into" that others already knew about. I probably spent a lot of time thinking I was good and clever enough to solve challenging problems... but then realize that I had used inappropriate data structures and made things more complicated than they needed to be because... I hacked my way through the problem rather than think through it from solid principles.
While I personally think experimentation is great... I've come to the conclusion that a mix of the theoretical and the practical is best. Being able to go back and forth between the two extremes has been valuable to me.
As someone who was self-taught and then changed my degree to CS, I think one thing that shows that someone learned by themselves is that they thrive without formal deadlines.
I see some fresh grads struggling when going to a professional environment where no professor is saying "I want <product> done by <deadline date>".
I think this is why some undergrads also struggled a lot when our role became remote. Suddenly, no one went to their desks for check-ins to see how their work was doing. The code was rushed at the end of the sprint to make it to the "professor's deadline."
At the same time, self-taught people generally succeeded because they are more oriented towards a "delivering when possible" and "pushing myself to learn" mentality.
After 3 years of experience, I think this equals out, unless you talk about lower-level CS concepts like mutexes, big O, or something they generally don't need to know for their daily job.
I came from a Chemical Engineering and Math degree, but ended up teaching myself programming while I was in university. I saw my freshman year roommate getting offered more for an internship than chemical engineers were making after they graduated and put 2 and 2 together.
I think there is a huge benefit to having had some sort of extremely rigorous quantitative background. When I talk with people who are self taught who haven't come from a hard (where that is an extremely hand wavey concept) can get started in engineering and often can be productive, but really struggle when things break or get difficult. There's a sharpening of the mind that comes with extreme analytic rigour, and I think that's more important than whether you get it in a real analysis class or in a CS class.
The article is specific to software engineers, and perhaps it's accurate within that discipline. The field is incredibly broad—ranging from writing small support scripts to engineering massive distributed systems—so it's plausible that a self-taught engineer could excel in certain areas. However, I don't believe this holds true, or is even feasible, for other engineering disciplines. In those fields, earning an engineering degree is typically a prerequisite. After that, you're free to self-teach and explore further, but without that formal foundation, it's difficult to progress meaningfully.
Side note: I think the term self-taught is often misused. Very few people are truly self-taught in the sense of starting from a blank slate and independently mastering a subject without any guidance. What the article refers to as self-taught is really just informal education—learning through blogs, tutorials, bootcamps, or YouTube University.
the definition of self-taught: having knowledge or skills acquired by one's own efforts without formal instruction
I think you're engaging in some weird goal-post moving. The phrase exists to highlight the difference between "i had someone else tell me all the things I should know and let them give me that knowledge" (e.g. college or a boot camp) and "i went out and found resources and did experiments so that I could learn what to do without that guidance". It is not "i discovered everything for myself by first assuming some principles and then rebuilding the whole field for myself".
All of the best engineers I know but one did not graduate in software engineering nor computer science. None.
They are all people that were coding in their teens and had a massive interest for computers, technology and programming since very young.
Conversely some of the worst engineers I know were graduates who only went into SE or CS because of job opportunities.
I am not saying ST good, graduate bad, I have also examples of terrific developers with a proper formal education.
I think all in all what really matters is whether you really care or not, whether you want to learn and expand your knowledge or not. Other than that sky is the limit. I would still suggest people to graduate if they are young and it won't cost them too much, it's good to meet fellow students, do networking, study stuff you wouldn't otherwise etc.
Linus Torvalds given as an example of self-taught engineers yet he has a masters degree in CS.
Higher education isn’t just about what you learn, it’s about learning how to study and learn.
> Linus Torvalds given as an example of self-taught engineers yet he has a masters degree in CS.
The example was Torvalds building Linux. Linux was written before he attained a CS degree.
> Higher education isn’t just about what you learn, it’s about learning how to study and learn.
You'd have to have screwed up your life pretty bad to not have already learned to study and learn before reaching the point of going to a place of higher learning. But that wasn't a problem for Torvalds anyway. It is well known that he was writing software since he was around 11 years old. He is unquestionably self-taught, as the term is normally used.
Higher education is about gaining access to machinery that mere mortals can't afford on their own. Linus' university story is significant because that was where he was first able to use Unix. It is unlikely that Linux would have come to be without that experience.
But that is also the contention around a modern CS degree. What is the "Unix" of our time that you can't reasonably access without going to university?
Sure, but with that argument I think you could say most people in software engineering are self taught. If you want to get a job as a SWE you probably need to learn a lot outside of the classes for a typical CS degree.
But I don’t think that’s as much of a black mark on formal higher education as the article suggests. Since the reality is, the vast majority of people aren’t organized, driven, and bright enough to learn all of the fundamentals taught in a CS degree on their own. That’s why I don’t think it’s smart advice to recommend spurning a CS degree in favor of being wholly self-taught.
To your last point, what can access at a university that you can’t get elsewhere? People. Namely, a community of like-minded peers, and personal relationships to experts in the field. Those relationships and mentorship opportunities are far more valuable than the content of the syllabus. For that, I agree it’s all available online.
> but with that argument I think you could say most people in software engineering are self taught.
When you get right down to it, I expect few, if any, people in software engineering are actually self-taught. You could theoretically pull it off, I'm sure, but people are pretty lazy and it in this day of age it is much easier to read a book/website or watch a YouTube video prepared by a teacher. That's not self-teaching by any stretch of the imagination.
> To your last point, what can access at a university that you can’t get elsewhere? People.
Deeming people to be the "Unix" of our time comes across as being quite bizarre. It is not like universities were void of people 35 years ago, so the fit you are trying to make is unclear. What is your thought process here?
> Namely, a community of like-minded peers, and personal relationships to experts in the field.
Did you, uh, not notice where you were when you said this? The like-minded peers and experts in the field are unquestionably present and here to mingle. If you are failing to build relationships with them — which I guess is what you are trying to say? — what makes you think you are going to fare better in university?
Maybe what you are trying to say is that you personally already established the connections that you want to have in university, and thus personally don't find need to do the same here? But what does that have to do with the next guy?
Or maybe what you are trying to say, which seems to be supported by the data, that as you get older, you become more closed off to new relationships and have somehow mistakenly conflated youth and university? Still, even if you are now old, what does that have to do with the next (young) guy?
I don't know. I gave my best to try and salvage your comment, but whatever it was that you were trying to get across in suggesting that people are modern day Unix analogs didn't make it.
I used to call myself self-taught because I never finished my CS degree, but the truth is I learned a lot of formal methods and techniques in college, and I wouldn't have been able to succeed without it.
Formal education is the beginning, not the end, but if you have the opportunity, why not take it?
Anecdote: I grew up in a poor family, that was single parent for my teenage years. I dropped out of high school when my son was born and I was 17. I never went to college. I was, however, a lifelong nerd and by mid-20s was able to get a foot-in-the-door job in IT. I'm 40 now and have been doing my dream job for almost 8 years. My current position was for a job that required a degree on paper. During my interview (all of them actually) I was honest about education, but also work experience and personal interest in the field, and got the position. That was 2.5 years ago and I hope to retire here.
I'm sure there was some luck involved, but just having a singular focus on computer adjacent fuckery, I managed to build a pretty successful career being 100% self taught.
It's not luck, I hire people on the regular, I'll pick a person with no degree but practical experience over a fresh out of college graduate every time.
I've found that there's greater range among CS graduate software engineers. Of course there are some truly excellent thinkers who know how to bring their training to bear on all kinds of problems. But some of them, well, you wonder how they even graduated college.
Among the self-taught, there's less variation. If they've managed to land a first job, they're usually at a pretty decent level of knowing how to learn new skills and apply them to solving problems. They were born in the "real world" instead of in the classroom, and it usually shows up in their sensibilities.
Just what I've observed from my own experience. (I'm self-taught myself.)
> Self-taught engineers often outperform
They also often underperform, especially when given a novel task.
One thing that Uni/College provides (hopefully; it did when I was there in the 80's) was a broad base upon which to build the specialty you're interested in. I don't do assembly, but I have done some. I don't do Ada, but I have done some. I don't do microcode kernel code, but I have done some. I don't do O(n) proofs, but I have done some.
I know a lot of bootcamp and self-taught developers "know a lot about things", which is good and we need those people. I pride myself on "knowing about a lot of things", which is also (IMO) good and we (hopefully) need these people too.
Well, "Case Studies of Tinker-Born Mastery" is a pretty LLM-sounding heading if ever I've encountered one, and that bulleted list of examples...
It's interesting to think through which of the LLM-produced texts that I've read recently have delivered value and which haven't. This one doesn't impress me, but there was one about social skills I thought was good – yet the comments there pointed to maybe that being because it was synthesizing some high-level points from a book. Getting the model to go fishing for ideas rarely seems to work out to anything that feels worth my time.
If you pair a self taught engineer with a classically trained engineer, the self taught will dramatically reap benefits from the collaboration but the reverse isn’t true.
A true 4 year CS curriculum is so theoretical you basically have to self teach to do anything practical once you leave the university. But due to the intuition you gain in university, your teaching process happens much faster and can hone in on specific correct paths, which contrasts with the pure self taught engineer who maybe stumble around longer or get trapped in local minimums.
Some self taught engineers may never truly grasp certain high theoretical concepts because they never occur often enough in the wild, but the CS degree holder will at least know these concepts exist and where they might apply. This is what can make the difference in a business’s competitive edge.
Nowadays though, I’m growing cynical of a lot of people trying to enter the industry as self taught, as many are simply chasing the high salary and easy lifestyle of the typical software engineer. You need to figure out quickly if you’re dealing with a true enthusiast or just someone chasing a good job. It’s safer to just go with the CS degree, but even there you have the same problem, the people entering the industry just aren’t built like they used to be.
Sorry if this is a little rambly, it’s late.
I started hacking web projects and messing with Slackware in the mid90s as a self taught dev. Before that I was always building things on my computer it felt more like creative exploration or entreatment than academic discipline which is why I never pursued a CS degree.
Whats fascinating is how differently CS trained and self taught developers approach problems CS grads often bring systematic thinking and solid theoretical foundations they'll architect elegant solutions and consider edge cases upfront Self taught folks myself included tend to be more experimental willing to hack together quick prototypes and iterate rapidly Ive found the magic happens in small teams that blend both approaches The CS trained developers provide structure while the self taught crowd brings creative problem-solving and isn't afraid to break conventional rules... sometimes there are no rules. Has anyone else noticed this dynamic Im curious if others see different complementary strengths between these backgrounds or if this varies by company culture domain
Not to belittle folks with a comp sci degree, but is it not obvious that self taught folks would be worthy of more serious consideration instead of making them do leetcode puzzle that have no real-world value? Bc I am self taught, and having the discipline just get competent at writing code takes a ton of discipline and genuine interest.
Think of all the open source projects that have been created and/or maintained by self taught programmers - ruby on rails, vuejs, nextjs, nuxt django, laravel, nodejs, express, etc.
My experience lately has been the opposite. Now that the job market is tight, I get a cold reception when hiring managers find out I am self taught. Could just be my anecdotal experience, but I would not be surprised if a person with a comp sci degree would look down on person who does not have one, especially if they are making a hiring decision.
Slightly misleading headline. This article is about programmers not licensed engineers.
I have a CS undergrad and a MSc in Computing, did either really prepare me for industry? Not really. But I made a lot of friends, drank a million beers, and overall had a good time. They look good on a resume too.
Even when I was in school I knew that CS as a field wasn't one where you could just get a degree and get a job (well outside of 2021 maybe). After one internship I realized there was a great divide between school and work, and this was at a work place with pretty low code quality.
'Self-taught' engineers is a bit of a funny term for me because while I technically have a CS degree, everything applicable I had to learn myself. Especially for a DE job where outside of some basic SQL and the general idea of a relational database a post-secondary degree doesn't exactly prepare you for such a role.
An interesting confounding variable might be that self taught programmers are likely to be influenced by a background in some other field. For instance, my degree is in physics, so I'm likely to "think like a physicist," if that's a thing. And I've chosen my battles well. My job is in an industry where understanding the workings of a product often starts with physics.
Another variable may be that the training process and the people who go through it are perceptive of what matters to their careers. When I'm tempted to think that engineers "like" to do certain things, and not other things, it could be due to personal ability and preference, but it could also be an economic preference not to waste their time on things that I happen to "like."
Being self-taught self-selects for those who enjoy it and those who enjoy it are way more likely to keep expanding their skill set.
As for the tinkering advice in TFA: While I wholeheartedly agree, as I grow older I find it progressively harder to force myself to start a new (and novel) project just because.
I still have personal projects, but they are very purpose driven and thus I mostly use what I know rather than exploring new tech.
I kind of wonder if these kinds of arguments are really:
"I didn't go to college, and I turned out fine".
I personally think:
#1 college pushes you to learn theory in a sort of "code coverage" for your brain. The tech doesn't really matter (outdated or soon so)
#2 industry is practice, practice, practice.
many sufficiently motivated folks can start off with #2 and fill in the #1 stuff, but I don't know if they bother.
Also, people who do #1 require #2 or face becoming almost worthlessly outdated.
"self-taught" from the start or not, lifelong learning is required by everyone to be decent.
Hmm - i'd like to see the proportion of self-taught engineers that quit before they became self-taught engineers. This feels like a classic WW2 bomber problem. More computer science grads end up graduating while despising computer science ( I knew many) because it's just a potential career track.
I think there's a bit of a survival bias within this, you aren't going to get data from self-taught people who now work in accounting because they tried to be self-taught but didn't really find passion.
Learning to learn efficiently is an incredibly useful skill that is required for survival in the self-taught path. Deciding what to learn next while making progress in your project in order to strategically unlock better decision-making at the right time before investing in the wrong path will compound over time and lead to increasingly improving skills like technical design, architecture, and project planning. The only major downside to this path in my experience is the increased probability of impostor syndrome which can be detrimental specially during the early years of your career and when you are trying to grow into the next level.
The issue here is not one of self-taught vs formal education.
Nor is it one of motivation/passion, although that plays a bigger part.
It's rather a matter of gifting. Some people "get it" when it comes to programming in ways that make them profoundly more competent than others. This is regardless of education.
The other big factor is whether or not they enjoy the frustration and successes of programming.
The best developers are those who are gifted and enjoy the fundamental challenges involved in programming. Formal education is at best tangential.
I'm probably easy to mistake me for being self-taught, considering I was programming as a kid, and never finished university, but I didn't really learn to program until I went to university. I wanted to, as a kid, but unlike my brother, I could never figure it out, until I got my hands on something better than Basic, and some good guidance and teaching.
I. Recent years I've only been getting more and more passionate about it, but that's probably mostly because I'm finally getting the opportunity to tackle some really hard and interesting problems.
Exceptionally smart people are more likely to effectively "self-teach", though exceptionally smart people often still use the same sorts of resources that classroom learners do (books, manuals, spec, consulting mentors, deliberate practice.
People who aren't smart and hardworking just don't effectively self-teach.
Isn’t that cherry picking? Do self-taught outperform others or are outperformers often self taught?
Seems the same logic like looking at Bill Gates or Zuckerberg and claiming college dropouts get rich.
> Seems the same logic like looking at Bill Gates or Zuckerberg and claiming college dropouts get rich.
Gallup's report on the "top 1%" kind of backs up the idea, to be fair.
Sort of. It shows that having a degree is significant when it is an advanced degree that offers exclusive access to a market (think medical doctors, lawyers, etc.), enabling monopolistic capitalization. But dropouts are more likely to be in the top 1% than those with only a bachelor or other insignificant degree.
You look at it the wrong way.
Not how many of top 1% are dropouts but how many dropouts are in the 1%.
Being a dropout isn’t the reason their are in the top 1% but the consequence of being successful before the graduation.
> You look at it the wrong way.
I didn't choose any particular direction. Your assertion that "college dropouts get rich" carries a lot of truth, though. However, buying access to a monopoly is hard to beat.
> but the consequence of being successful before the graduation.
It is unlikely they were all successful beforehand. Financial success typically comes later in life. More likely it suggests that those who chase degrees that aren't backed by monopoly are not prioritizing (financial) success. The hard truth in life is that it is hard to do well in something when you are distracted with something else!
The ruse when talking about financial success and college is that:
1. We typically lump "college degree or higher" into a single group, not differentiating between those who are buying access to a monopoly and those who are taking a vacation.
2. We don't like to recognize the spectrum of people. Someone with, say, severe autism, that limits their participation in the economy, isn't going to find an autism cure in graduating from college, but they are treated as if that is the case.
Which can lead some to think that college itself is somehow magically a key to success. Ask them to explain the magic and you'll get all kinds of bizarre, handwavvy explanations, but once someone believes in magic...
This shows that dropouts have a lower income as graduates
https://nces.ed.gov/programs/coe/indicator/cba/annual-earnin...
The dropouts in the top 1% are outliers.
You wouldn’t recommend to dropout of middle school to become a successful director just because Tarantino did.
> This shows that dropouts have a lower income as graduates
Obviously. The aforementioned crippled autist doesn't have the ability to be a graduate. And will suffer economically because of the same life challenges. In other words, people aren't the same. But you are playing the same silly game colleges love to, pretending that all people are exactly the same, which is obviously not the case.
It is telling that you avoided presenting a report that breaks income down by equivalent (to the extent that is reasonably possible) people. The report you offer is valid for what it is, but doesn't support your claim as it is made within the context of this discussion.
> The dropouts in the top 1% are outliers.
To be in the top 1% requires being an outlier[1] full stop. The dropouts are disproportionately represented, though. There are surprisingly, on the surface, few "bachelor only" members in the top 1%. But when you think about it, it isn't all that surprising. It's hard to reach 1% status with other distractions going on in your life. There is only so much time in the day.
[1] Granted, the data suggests that the top 1% is more like 20% of the population. It does not require being the extreme outlier that it may originally seem. How can 20% be 1%? Time. The top 1% is not fixed membership.
How do you define self taught?
Linus Torvalds was a CS student when he released the first version of linux...
I'd rather say you need both "breaking your teeth" on your own projects and some formal training on top of that.
Yea, true of many things. Anyone who has the drive and motivation to teach themself anything, usually do a good job.
Doesn't mean you'll always get everything right or that you'll be good at first or even as good as someone taught to do the thing, at first. But practice makes perfect and over time you can be as good or better than someone with training. There's absolutely no reason you can't train yourself on just about anything.
If I think of self-taught engineers who are my peers, they look great. But that’s selection bias.
If I think of every self-taught engineer that I’ve ever crossed paths with, there are some that engaged in unscientific magical thinking.
Also (solely) self-teaching seems to achieve good results in software more frequently than in other fields of engineering.
If the basic capabilities are present the thing that matters is motivation.
Self-taught naturally correlates with motivation (as well as a few other mixed traits).
It's neither a cause or guarantee of performance, but it can be very useful information to know about candidates when recruiting.
(as someone who is largely self-taught and done a bit of the recruiting and management thing)
Being self taught also selects for the ability to learn autonomously. Which is very important in software.
This is a strange dichotomy. N years post CS undergraduate the majority of what you know will be self-taught, but how you've put it together in your head will be different with a theoretical background than without.
A theoretical background is valuable. It distills hundreds of years of other people's learnings. Ceteris paribus, if you do not have it, you are at a disadvantage.
The analysis is wrong. The problem is most software development tasks are to software engineering as building a driveway is to building a bridge.
As in the civil engineering example, both involve concrete, labour, levels, project management, but the jobs are just too simple to require or reveal the knowledge held by the graduate civil engineer.
The main reason for this is because self-taught programmers FOCUS ON ONE LANGUAGE. I realized that I went through all the courses I needed to learn from university in different programming languages for some strange reason, and that just left me all over the place as a developer.
It is an easy fix, teach only one language for the 6 core areas of programming, namely:
1) Intro to programming (variables, loops, conditions etc. up to functions) 2) Complexity management, usually OOP 3) Building a GUI (it is not trivial and needs to be a course on its own) 4) Connecting to a database (also not trivial) 5) Data Structures and Algorithms 6) Compilers and programming languages (basically popping the hood of programming)
In school, after learning OOP in Java we switched to web dev and learned javascript and php. We completely abandoned learning GUI and DB for java.
Algorithms was taught by a visiting lecturer in C++ and after mid-sem we switched to Data Structures in java??
The universities are doing a fine job, but please just stick to one programming language for these core areas and everything will be great.
I came to this conclusion before AI took over. It will be interesting to see how AI changes the Computer Science curriculum in the years to come.
Yes, but it's a problem in hiring.
A degree is still a good proxy for good worker, because it guarantees that:
Once I made a lecture on higher education, showing that it has many functions besides the core skills that everybody talks about. And that there's no replacement to it on the horizon. After my talk, a guy comes up: "such great lecture, just my thoughts. Why do they need a degree for bank clerks? A technikum* would be enough." (I spoke of exactly the opposite. And the test to his idea would be: come to the bank manager, tell them they should hire people without a degree, listen where he tells you to go.)* technikum in post-soviet countries is 1-2 year vocational education, lower kind of degree than college or university.
As a mostly self-taught engineer, the reason is simple: after 5 or so years, the language, tools or architecture is going to be dramatically different and you have to learn on the fly. Heck, even how to learn has changed dramatically. When I started, I learned languages from printed books. Then docs and Google, then added StackOverflow, now AI.
While true, we often have a harder time getting in the door. So take that as you will. Orgs want paper degrees.
I was actually talking about this with a dev this morning.I might reframe this away from self-taught and more towards on the job experience.
Obviously, I think it depends on the domain you're working in, but most comp sci majors really learn math and algorithms.
Math is great, of course, but the vast majority of app and web developers never use any of it. So at the end of the day, even with a proper technical background, everyone is really self-taught when it comes to Python or React programming when they get a real job.
This is a broad brush, but then you get data scientists with academic background who maybe learn R or Python for analysis, which again is great, but they don't necessarily learn OOP principles or exception handling and so their code quality is bad. Yet, they are often tasked with creating apps or doubling as a dev and so they too end up becoming self-taught to a degree.
Just two cents
> I might reframe this away from self-taught and more towards on the job experience.
At least with the devs I've known over the decades, they were self-taught but didn't learn "on the job".
In my view, the difference between self-taught devs and devs who learned it in school is passion. Self-taught devs are self-taught because they're passionate about software. Devs who learn it in school, generally speaking, do so not because of a deep passion for the subject, but rather as a means towards getting a job.
Totally agree. Passion is the key ingredient. For me, as a self-proclaimed self-taught dev, I learned the most on side projects because my main jobs didn't always offered job training or clear paths towards advancement or eventually the product went into maintenance mode and became boring. Maybe it's splitting hairs, but I still consider that on the job experience, even if it wasn't paid many times, and it gave me a deeper understanding of problem solving in addition to programming chops than tutorials or portfolio projects or bootcamps could provide.
Nah, you need both. A formal foundation in core concepts is the bedrock upon which to do self-study. The smartest engineers are the academics. They're the ones who design new algorithms for the rest of us to use and their achievements are built on deep knowledge-sets, which are mostly formal.
> The smartest engineers are the academics
Citation needed.
Nobody here has any citations for anything, but he did give his reasoning. If you only you just extended your quote one more sentence! Rats!
Probably the actual difference is what you are able to retain in your memory.
I know that the parts of computer science I learned on my own or while on the job, are far more sticky than anything I studied in university, even back then
Also there's a different in what you think you understand and what you actually understand
Where is this non-self-taught engineer you speak of :)
Sure you can do Java 101 at uni and more Java on a course. But 90%+ knowledge is hard won. Even before you get a job.
There might be a flying analogy. The best pilots are the ones who have flown a real aeroplane!
Thanks for rare ego boost hn haha
I think the most interesting and cutting edge work in the corporate world is reserved for school graduates
There are alot of specialties that just feel out of reach for me. becasue I don't have credentials or a way in.
Because we have to. It's obviously survivorship bias. I don't have a single chance at interviewing against someone with a degree unless I can undeniably prove that I am head and shoulders above the pack. And so you grind and grind and grind in a way that someone with that piece of paper to rely on doesn't feel the need to, because the bar is that much higher.
It wasn't always this way; making it without a degree used to be a badge of pride in this industry. But the glut of CS grads these days has made it something of a handicap to be brushed around at this point.
As a self taught engineer who hasn't read the article or done any research I can confirm.
I think what my computer science degree taught me more than anything is historical context and good taste.
Of course you can develop those on the job. But it was a good shortcut I think.
In my experience it’s a huge “it depends on the person”.
Younger self taught engineers with a huge ego can be a real PITA. Some have tendency to question everything that has already been written, wasting time.
This is really obvious but good to see it validated. If you don't have firsthand experience discovering and playing with fundamentals, you are at a disadvantage.
Makes me think of this classic from Derek Sivers - There is no speed limit - https://sive.rs/kimo
That's an artificial division.
Many of us computer science graduates were selft-taught developers before we went to university :)
Having been on both sides of the fence I can definitely speak to autodidacticism as having yielded some of the most durable and rewarding lessons of my lifetime spent programming, if only because I was really internally motivated to try my hand at game modding, or writing fun toy websites or mobile apps, or even learning Haskell. There are indeed some practical realities you will learn how to overcome that simply are not (and should not) be covered in a usual computer science curriculum (e.g. git, vim, basic shell fluency, etc.).
At the same time I feel that the self-taught dev or bootcamper from the 2010s is really a far cry from the geek culture of yesteryear. As opposed to misfits obsessed with computers, we now have grifters appropriating geek culture to make a buck off the industry. These people lack internal motivation; they are driven only by the external motivation of monetary reward. Consequently it's unlikely that they would delve into more of the esoterica of computing that, while interesting and fascinating to learn about, doesn't yield immediate monetary benefit.
In concrete terms what this amounts to is people "self-identifying" as "senior software engineers" who have never heard of the term `xor` in their life, and don't even understand what a truth table is when it's drawn out for them.
Even still, those who are highly internally motivated are still likely to have blindspots in their knowledge or not know that a field of study useful to them even exists, which is why having a more systematic and thorough review of the field's basics is useful.
Is knowledge of basic boolean logic, "advanced and impractical theoretical computer science," or merely, "table stakes?"
When anybody can identify as anything you eliminate the possibility of drawing meaningful distinctions and assessing qualifications.
Self taught then got the paper degree from the daycare. Best combo. Ok to be fair the college did teach me a lot I didn’t get while self taught.
Oops, Margaret Hamilton is a terrible example and immediately makes me lose respect for the rest of the article. She was famously mostly a manager who received the credit for the work of others. Read the book by Don Eyles and read between the lines.
(uh oh here come the downvotes)
Linus Torvalds as an example of a self taught engineer is quite funny too as he wrote Linux while following a CS degree.
The article did in fact not make an attempt to demonstrate the claim in its title.
I'm self=taught, and I think this is nonsense.
1. There's heavy survivorship bias. Many, many self-taught folks are ineffective. The only ones you see in the wild are also talented--talented enough for management to ignore their lack of a credentials which is a little more talented than most.
2. There's even more selection bias: people who self-teach may have more self-confidence and drive. I will say, however, that today salaries seem to be a larger motivating factor. Do you really think the finance bros who switch careers care about the craft?
3. Self-taught != experience. Having "the intuition needed when the recipe breaks at 3 a.m. on prod", is not imparted until you actually deploy something to prod. 99% of self-taught folks haven't deployed anything to give them that exposure.
4. Self-taught does not often give exposure to "hard problems." Most self-taught folks can't do fundamental work on databases, operating systems, file systems, machine learning, or compilers: you know the hard math and CS they teach in schools. Most get trapped doing easy things, and in turn, most get trapped in full-stack roles.
5. Is self-taught really even self-taught anymore? Does Coursera count?
Clearly selection plays an enormous part here. The average engineering graduate is average, obviously. He did what was expected of him and he had enough drive and curiosity to carry himself through university.
To self teach an entire field takes enormous drive and curiosity. It takes struggling against adversity and ingenuity.
The idea that the latter path is generally superior is delusional. In all likelihood it involved far more effort, frustration and time. Comparing a self taught engineer and a graduate of the same skill level it will be clear that the graduate had a much easier time. He had the opportunity to build upon a solid theoretical foundation, when being forced to engage with practical problems, which every engineering program does.
Engineering is also a profession, not a competition. Average engineers aren't a problem, they are absolutely necessary and represent success,not failure.
Self taught or otherwise, Life is lived in the Arena
There's just something about learning through pain
I have been programming since I was 8 years old. In 1978 I touched my first computer, a Commodore Pet which had been added to the office of a friend of my family, who had no idea what to do with it.
I was immediately drawn into this world and that moment changed my life definitively.
I've since been around the world twice, have written software in a diverse array of markets, including realtime/embedded/safety-critical, professional audio, and scientific instrumentation fields.
I'm a highschool dropout, became a competent POSIX developer in the 80's, a competent cross-platform developer in the 90's, an embedded and safety critical developer in the 2000's, and for the past decade have been shipping products in the professional audio realm. I've also been involved in multiple startups - some huge and impactful, but most small and irrelevant.
I dropped out of high school in 1987.
Throughout this era I've been constantly challenged by academic-trained developers who say things are impossible/can't be done/etc., only to have my work demonstrate otherwise.
The key to this is, I am full of self-doubt, and double-check myself, repeatedly, in order to not wreck myself. Whereas, academically-oriented devs have had to eat humble pie, time and again. This is not to toot my own horn - just an observation that over-confidence (or indeed, radical under-confidence) is often the product of a huge investment in ones' education, especially if there are large debts involved (I have no student debt, but I do have 40 years of computer history sitting in my living room, having kept every single platform for which I've done some form of development ...)
For many years, I saw computer programmers graduate who could not program their way out of a sealed/wrapped box, and many, many times have had to teach them, myself, to get things done.
That said, I've also been humbled by the brilliance of the DSP and machine learning engineers I've worked with, who could not have established their competencies without having had the time to study.
I've done software dev projects in Japan, the USA, Australia, Germany, Serbia, Kosovo, Italy, the Netherlands .. with many of my projects still in use on a global scale.
I think with software development there is a self-study discipline which must be maintained in order to stay relevant - I was lucky to learn that skill at an early age and to use that discipline to gain more skills. I don't think this discipline is taught well enough in the various markets in which I've worked:
It's not what you know. Its that you know you don't know and know how to know.
Project workflow, debugging techniques, separation of concerns, and most important of all: proper analysis (identifying similarities/identities/differences in ontology). All generations of software developers have issues with this, and all of us can improve.
I think there’s an element of fear in the self-taught engineer? I am self taught and even after over a decade of experience impostor syndrome is still going strong!
At the same time I’ve been surprised by graduates when they come across something and say “I didn’t see that in school”, like, what!? I thought the job was mostly learning on the go!
As a self-taught software developer, yeah, it's kinda true. I've encountered developers that are older than me, have more experience as me, has multiple degrees, yet they're dumb as bricks when it comes to anything remotely related to problem solving (or not using genai to do all the work for them, which I think is absolutely disgusting).
I learnt everything I know about programming from buggering around, and just making cool stuff. Then you'll get annoyed how past-you wrote it, and then you'll rewrite it and you'll learn how to make better code & better projects. Most engineers/devs I know that was taught at a university or college can't really do that, and most I know take ages to make anything that can be used (or even shown off as a demo to your boss). Some of this could also just be that there's usually a higher chance for self-taught engineers/devs to be neurodivergent of some sort (adhd/autism), because I am myself and I know that my different perspective does give people a breath of fresh air when working on projects.
meh. There's a lot of really good self-taught engineers but this seems like a weird thing to bring up.
I worked with someone that was self-taught, them vs 2 of use with more formal education, we had a difference of opinion on how something should be be handled so our boss at the time basically posed a contest that whoever could get it done first would be what was implemented. Of course they outperformed and got it out faster.
1. That's a horrible way of deciding what gets pushed, pitting developers against each other. 2. The resulting code was awful to read and very procedural. Written by the same developer that made a god awful hero function.
...and self-taught statisticians often know about Berkson's paradox
[flagged]
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
https://news.ycombinator.com/newsguidelines.html
And without js it renders as a blank page. Less really is more.
down arrow key scrolls the modal for me
Down-arrow to scroll works for me on that blog (using Firefox). But I agree it's a questionable site design.