3 Things Self-Taught Developers Missed
geekindex.wordpress.com
geekindex.wordpress.com
"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.
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.
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]
In either case, yawn.
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.
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.
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.
Weird way of showing off his degree.
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).
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 :))
All good things to learn, regardless of path.