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.
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.
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
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 :)
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.)
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.
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.
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.
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.
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...
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?
> 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.
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.
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.sum += (x > 0 && y > 0 && x < x_limit && y < y_limit) ? a[y][x] : 0;And it doesn’t do what’s asked? Congrats.
oops doesn't count the edges. Take another minute.
-- joking -- :)
[dead]
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.
Computer science isn't about building CRUD apps or SQL queries. Just like mechanical engineering isn't about operating a milling machine.
[dead]
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.
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.
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.
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.
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”.
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 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 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:
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.
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.
>> 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’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.
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.
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 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.
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.
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.
> 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.
- [deleted]
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
> 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
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.
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
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.
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.)
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.
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".
>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.
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.