5 ms·

3 Things Self-Taught Developers Missed

14 points by rco8786 14y ago

ricardobeat 14y ago
What does this have to do with being self-taught? Everyone knows CS graduates who suck at those three.
- prostoalex 14y ago
  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 14y ago
    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.
- deleted 14y ago
  [deleted]
- yen223 14y ago
  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] [0]http://en.wikipedia.org/wiki/There_are_known_knowns http://en.wikipedia.org/wiki/There_are_known_knowns
  - ricardobeat 14y ago
    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.
darkxanthos 14y ago
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.
sebcat 14y ago
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 14y ago
  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 14y ago
    >"I consider myself to be a self-taught programmer." Weird way of showing off his degree.
dave_sullivan 14y ago
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 14y ago
  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.
genuine 14y ago
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 14y ago
  > 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 14y ago
    Your HN user was created 1234 days ago. Happy 1234-day! http://www.youtube.com/watch?v=ABYnqp-bxvg 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.
fallous 14y ago
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 14y ago
  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 14y ago
    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.
toddan 14y ago
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 14y ago
  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.
joelhooks 14y ago
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.
naiquevin 14y ago
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.
SwearWord 14y ago
I'm better at all three of these things than my counter parts with degrees, who for the most part are totally clueless on these topics.
accidc 14y ago
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 :))

14 points by rco8786 14y ago

ricardobeat 14y ago

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

prostoalex 14y ago
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 14y ago
  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.
deleted 14y ago
[deleted]
yen223 14y ago
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] [0]http://en.wikipedia.org/wiki/There_are_known_knowns http://en.wikipedia.org/wiki/There_are_known_knowns
- ricardobeat 14y ago
  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.

darkxanthos 14y ago

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.

sebcat 14y ago

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 14y ago
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 14y ago
  >"I consider myself to be a self-taught programmer." Weird way of showing off his degree.

dave_sullivan 14y ago

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 14y ago
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.

genuine 14y ago

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 14y ago
> 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 14y ago
  Your HN user was created 1234 days ago. Happy 1234-day! http://www.youtube.com/watch?v=ABYnqp-bxvg 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.

fallous 14y ago

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 14y ago
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 14y ago
  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.

toddan 14y ago

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 14y ago
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.

joelhooks 14y ago

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.

naiquevin 14y ago

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.

SwearWord 14y ago

I'm better at all three of these things than my counter parts with degrees, who for the most part are totally clueless on these topics.

accidc 14y ago

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