Lol while you're very correct dave, and describes exactly what I did as well, I think the main article is supposed to be just a self-reflection article written primarily to help himself clarify and understand what he went through but written in a way so that it can also provide useful advice for people in his somewhat uncommon situation.
There isn't a lot of advice flying around out there about the transition from self-taught to hired in production scenario. But then again, when I did it I had no information to go off of and I did just fine because of my self-taught nature as I was able to assimilate all of the new information incredibly fast.
Unit testing is software engineering, not Computer Science, so ironically one would know unit tests only if they went above and beyond requirements, i.e. be self-taught in addition to being enrolled in an academic program.
You do typically take a software engineering course in CS, although when I was in school (ten years ago) they basically just taught us Waterfall, "refactoring", etc. I imagine any respectable program teaches TDD now.
There are even more non-CS graduates who suck at those three!
Snark aside, the thing about being self-taught is that, it is easy to miss out on important concepts, simply because nobody told you about them. You won't seek out more knowledge about them, because you don't even know they exist! They are the "unknown unknowns" that Rumsfeld was talking about. [0]
Do you really believe it's that hard to come across TDD and design patterns? These come up 90% of the time on anything related to programming, and being self-taught means being very good at finding things by yourself.
3 things the author assumes self-taught programmers missed because either a) he "self-taught" via cargo-cult or b) his lack of experience in actual production makes him think these are big ideas.
I have my own ideas about what you call "big concepts that emerge from experience in actual production", but I'd be fascinated to find out about yours.
I don't know that I have a big bag of "big concepts that emerge from experience in actual production", but I can think of a few things that I still encounter with inexperienced coders I work with.
The mistake of coding as if a back-end web app is a run-once kind of thing. No memoizing for repeated pure function calls, repeated instantiation of connections that should be pooled, globals being crapped out everywhere and functions that depend on their existence vs being passed in.
Giant clots of if/then blocks for application "logic" and implicit state or action-at-a-distance fun lead to doom.
Failure to understand the cost of over-the-wire vs localized data calls.
Separating reads vs writes and/or immediately performing time-expensive tasks in-line. Granted the dark side of this can be premature optimization or complexity, but it's a lot easier to scale out when you've actually thought about how to do it while building things.
Tracking performance changes as a part of basic testing. Granted, it can be hard enough just to get them to build unit tests but simply demonstrating successful execution doesn't mean you haven't negatively affected the codebase by decreasing the performance.
Profile your damned code. Over the years you'll develop the sense of smell required to pre-detect poor design choices, but without a real insight into what the code is actually doing you'll be shooting arrows in the air trying to hit the real problem.
While premature optimization is a known-evil, premature complexity is also a real danger. You don't need a big OOP implementation for a simple function, and abstraction layers can run the real risk of becoming distraction layers making things much harder to debug or decipher when things inevitably go astray.
Self-taught developer here with getting close to 15 years experience and these were not really the things I missed.
Here's what I know I missed: a bunch of useless shit. Sorting algorhythms that I don't have to implement. Understanding of trees that I don't have to implement. Knowing what "NP hard" means.
That stuff gives you maybe 5 minutes of conversation with another comp sci major a year in many jobs- as those were the 5 minutes I cut to 10 seconds with a "whatever". Sure, some jobs require you to think like you just got a PhD in computer science. That's fine, but I worked with a PhD in computer science, and one with a masters. It made very little difference. I ended up managing the one with the PhD, not that it matters.
But to all of those guys and gals thinking "so I don't need a degree in CS" think again. What did matter was that I didn't apply for least 50% of the jobs I could have applied for, not because of my ability, but because of my lack of a CS degree that was in the job requirements (although that requirement is often bullshit). And when you have no experience then it really can keep you from getting your foot in the door. I got lucky- I had worked at a place that had a developer opening, so I was a known quantity and they knew I could pick it up. These days I think it would be easier to start off as a contractor writing Rails apps.
> Understanding of trees that I don't have to implement.
The main purpose of understanding 'of trees' is not to re-implement them (I have done that though) but in order to know how to use use them effectively. This is about knowing how your tools work. If it is hammer, well, it is hammer, but some of these tools are pretty complex and it is worth spending time understanding what trade-offs different data structures have.
You don't have to get a 4 year degree by any means to do that you can also learn that on your own.
> I ended up managing the one with the PhD, not that it matters.
So if it doesn't then why are you mentioning it. Maybe maturity and the ability to communicate should be #4 in the list?
I never, ever had to learn trees the way I understand that they were taught in comp sci. Sure, that knowledge is a tool, but I was fine without it.
> So if it doesn't then why are you mentioning it. Maybe maturity and the ability to communicate should be #4 in the list?
The point is not to manage, the point is to be happy with the work you do. I personally think it was sad that someone spent that much of their life getting a PhD and I didn't have a degree, and I was telling him what to do. I really shouldn't make fun of that, and I apologize. And there is a job I would have LOVED to have had that required a PhD, so in the end, I'm just as sad.
The main thing I think I got from the degree is that it took away all of my fear of The Stack. In Operating Systems class they just sat us (a bunch of barely Java programming ninnies) down and said "OK, you're going to write a MINIX clone in C and assembly. First assignment is boot." And you do it. It'll take putting your heads together with friends, dragging tips out of the professor, and lots of trial and error, but you do it. There's a support structure there so that you struggle, but you make progress.
Of course I don't remember a damn detail about what we did, but for a brief period in 2000 I felt like burgeoning kernel hacker.
In Programming Languages they're like "ok, you're going to write a program in ML". And you do it. PROLOG too. You just have the experience over and over of "that is some bizarre shit... oh, but now I learned it."
I went in thinking "I can hack together some HTML files and I can write some stuff in QBasic" and I left four years later thinking "I can attack problems at any level of the stack".
Now, you can definitely get the same experience outside of school. That's where I agree with you. You just have to self motivate. I will say, I don't know a whole lot of 18 year olds who really have the skills to self-motivate themselves to dig all the way down to Assembly. But those who do: I'm super impressed.
And of course, being fearless about the full software/hardware stack isn't everything. You really only need to understand a couple levels above and below your wheelhouse. But I do think it's a legit, valuable thing, that self-taught developers are more likely to miss.
And, of course, some of my classmates never got past The Fear either! They just retreated with passing grades back to Javaland and at this point are surely better paid than my broke bootstrapping ass.
Wow. This list seems like a set of things many self taught programmers know. Truly understanding data structures (everything is a graph!) was a big ah-ha to me as a self taught programmer.
A better title would have been '3 things self-taught developers should know/read'. Everything that the article mentions as 'missed' is fixable. As a self taught programmer, I admit that at various points in my programming career I was unfamiliar or didn't have a deep understanding of at least one these things. But I could fix it (and still trying to fix BTW) by reading up and taking open online courses. So as long as there is willingness to learn, no one has missed anything. OTOH, I feel that if there is anything I have missed because of not studying computer science in school, it's participating in things like Gsoc and internship opportunities while I was studying.
I guess that if you are a self taught rails or django developer you will miss these kinds of things.
But it also depends on how far you want to learn. I have a friend of mine that started with django and for a long time, only knew how to push data back and forth a database. But after a while he slowly got in to these kinds of things(Big Os and mathy things) and now he is better than me at algorithms and optimizations(not that I am any good at that).
Rails and Django both are vehicles for consistent design patterns and have "testing culture" surrounding them. Frameworks, good ones with solid community, can be an excellent vehicle for learning patterns and practices.
I found the article useful. As a self taught programmer who works in enterprise software using procedural programming, I was missing knowledge of design patterns and Big O.
Having dabbled in Java recently, I found myself struggling with design patterns. I realized a bit late that I should read up on design patterns.
This post hit home for me at least (although I do unit test :))
I chose an autodidactic approach to learning software development (via Flash/AS3) and 1 and 3 where (still are) primary areas of study. I'll admit to being fuzzy on 2, not unaware, just hasn't come up yet.
"Hey self-taught developer, here's some things you don't know because you're self taught"
"Great, I'm going to go teach myself these things now."
It's very liberating to not have to ask permission to learn valuable skills.