

3 Things Self-Taught Developers Missed - rco8786
http://geekindex.wordpress.com/2012/11/14/3-things-self-taught-developers-missed/

======
dave_sullivan
Other than being a huge generalization, it's kind of a moot point.

"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.

~~~
dromidas
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.

------
ricardobeat
What does this have to do with being self-taught? Everyone knows CS graduates
who suck at those three.

~~~
prostoalex
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.

~~~
erikpukinskis
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.

------
fallous
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.

In either case, _yawn_.

~~~
Toshio
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.

~~~
fallous
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.

------
genuine
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.

~~~
rdtsc
> 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?

~~~
genuine
Your HN user was created 1234 days ago. Happy 1234-day!
<http://www.youtube.com/watch?v=ABYnqp-bxvg>

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.

------
sebcat
Might be more related to Web dev? I'm a self taught C dev, and I consider
those points to be a bare minimum of required knowledge for my kind of work.

~~~
mylittlepony
I'm a web dev (main language: php) and I knew all three. The author probably
just wants to remember everyone that he has a degree or something.

~~~
yen223
>"I consider myself to be a self-taught programmer."

Weird way of showing off his degree.

------
darkxanthos
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.

------
naiquevin
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.

------
toddan
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).

~~~
joelhooks
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.

------
accidc
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 :))

------
joelhooks
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.

All good things to learn, regardless of path.

