3 Things Self-Taught Developers Missed
Author’s Note – The headline seems to have ruffled a few feathers because it comes off as a generalization(not meant to be). If you read this and find your panties in a wad, please pretend that I had named this post “3 Things That I Wish I Knew When I First Become a Programmer”.
I consider myself to be a self-taught programmer. I have a degree in Computer Information Systems…but it is a far cry from a traditional CS degree. Had I not self-taught myself actual programming I would not be where I am today. In fact I would probably not even be a programmer. I started writing code around age 12 and, for reasons only hindsight can explain, chose CIS instead of CS when college came around. For those who aren’t familiar, CIS is a B.B.A. that focuses on a variety of computer/tech related fields, but core classes are from the business school. Even though my “focus track” was software development, the code I wrote outside of class for fun was more involved than my school assignments, which were a couple steps above “Hello World”.
Over the last several years working as a developer I’ve identified 3 key things that self-taught devs may have missed out on by not studying CS(and should make a point to familiarize themselves with).
Disclaimer: You die-hards out there will probably have 100 other things that you learned from your CS degree you consider invaluable. These are just the three that I’ve found most advantageous during my career as a web developer.
1. Design Patterns
Get your collective “ugh”s out of the way now. Ok? Good.
Remember when you got your first job as a developer how excited you were? Holy crap, you thought, “I did it, I’m gonna be a programmer!”. Then on your first day you got setup with the company’s code. You saw a solution that was over 1,000 lines of code(like, way over) and immediately went a little sick to your stomach. “It’s ok, I’ll learn it all. I can do this.”
Then you started to explore a little bit. “Why are there so many classes?”. “Why is this written this way?”. “What is this code even doing?”. You thought you would never be able to follow the code, or at least I did. Eventually though, after a few weeks or a few months, you got more comfortable. You could easily follow the path from UI to the database and back, and soon after you could hold all of the information in your head necessary to make meaningful changes to the codebase. But you still didn’t understand why half of it was written the way it was.
Had you had a grasp of design patterns you probably would not have been so shocked at what you saw day 1, and you probably would have picked up the codebase a great deal quicker.
What is it?
Simply put, they are patterns of writing code that *can* be used to extract or model certain behaviors.
What it’s not
A framework that all code needs to be forced in to. Patterns have their uses but when used incorrectly or over-used can lead to all sorts of maintenance problems down the road.
This post is not meant to dive into patterns themselves, but rather point you in the direction of resources for you to reference:
http://ayende.com/blog/tags/design-patterns-test-of-time
2. Big O
Your code functioning is the most important aspect of your job, right? Well, yes..and no. Does it count as functioning if it works on your local box and then the page takes a full minute to load in production? I would say not.
“I don’t understand, everything was super fast on my machine.” you say. Forgetting that your copy of the database is a stunted version and that table your script queries 1500 times is actually 1,000,000+ rows in production.
Big O is a pain in the butt if you don’t have a solid math background. But learning it, or at least having a solid grasp of the concepts will save you a lot of performance related heartache in the future.
What is it?
A mathematical solution to assigning complexity or measuring expected performance of a piece of code/algorithm.
What it’s not
It’s not something you need to memorize front to back, nor is it necessary to calculate O(x) every time you write a for loop or hit the database. A general understanding will go a long way.
Go. Learn, and write fast code:
http://rob-bell.net/2009/06/a-beginners-guide-to-big-o-notation/
http://www.perlmonks.org/?node_id=573138
3. Unit Testing
Ok, so this one probably isn’t taught in most CS programs and chances are if you’re reading this you already have a grasp of it. But oh well, it doesn’t hurt to brush up because most likely are you’re not doing it very well(guilty).
If you find yourself saying “This worked yesterday.” a lot, chances are a unit test or 10 could have saved your butt.
A large reason that the most successful dev shops in the world are so damn good is because they not only write unit tests, they embrace unit tests as an integral part of the development process. For instance, the Google Chrome team will reject a feature check-in if the unit test code has a smaller footprint than the code itself. They do not run pure Test Driven Development, but every line of code is covered by a unit test. The result? They don’t have or need a dedicated QA team…the code comes out that clean(aside from the team being made up of some of the most talented devs out there). The product managers can focus on the product, the developers can focus on building it.
What is it?
A unit test is a method/function that calls another “unit” of code and tests the result for proper functionality. It is tertiary to the application code itself.
What it’s not
Unit tests are not an excuse to ignore testing actual functionality of the application. They are not a silver bullet to bug free web sites.
When I was first learning unit testing, it was described to me as something that “you just need to do it…and then you get it”. This person was correct. If you don’t do it now, take an hour or two to learn it and try it with your team for a month. You will “get it”.
A basic guide to unit testing, or how not to write unit tests
http://wiki.developerforce.com/page/How_to_Write_Good_Unit_Tests
Filed under: Coding | 34 Comments
Ryan O’Neill
Software // Data // Stuff
The Geek Index 
They teach design patterns and unit testing in school now? What, in one last class in Software Engineering? I actually did an undergrad class in S.E in 2004 or ’05, and neither of those was taught, but rightly so imo. Big O is a definite loss to the self-taught though. That and /practice/ coding, and with databases, graphics, and parsing are the other things that school provides.
I enjoyed the article. Thank you.
I am a non CS guy started coding at an earlier stage, and it was a real nice article. Thanks a lot 🙂
I agree with “Name”. This is indeed stupid. You should call the list “3 things I missed while self teaching…”.
I’d rather label this list “top things your CS degree missed”. I don’t think you learn neither design patterns nor unit testing methodology in any CS degree. CS is maths, pure and simple.
You may be right. I don’t have a CS degree so I wouldn’t know 😉
I’m a self-taught programmer too, having entered the workforce in 1988 by taking a job that looked interesting because it let me get close to NASA…I learned to program on the job, and quick, as “programming” was not originally on the job description. Anyway…I digress.
I could not DISAGREE with you more. Those three insights – patterns, O(), and unit testing – were some of my earliest “aha!” moments. In fact, when I interview new programmers, I use those (and a few others) as markers of whether the candidate has paid their dues yet, is still learning, or has missed the point.
I don’t care if they teach these concepts in school or not…if you don’t have these insights well-mastered yet, then you are still an apprentice developer.
Absolutely agree, that was sort of the premise of the post.
Don’t be mean people, I used to make technical interviews, and you would be surprised to see how many people totally miss those points.
So even if the title of the article could have been worded better (surprisingly, self-taught developers I’ve seen are often more comfortable with that than the ones coming from software engineering schools), those are things worth remembering. So thanks to the article’s author.
Thanks for the comment. The title was just meant to be an attention grabber…worked pretty well but I suppose some people just glazed over the article itself. I’m often guilty of that so I can’t blame them!
I started writing code around age *14* and, for reasons only hindsight can explain, chose *EE* instead of CS when college came around.
Great article… I’m going to read up your links right away!
I have a CS degree and didn’t learn (or get em) these things either in school. But if I would list 3 things self-learned programmers don’t know and should learn would be:
– Computer architecure – processor, RAM, cache, clock speed and how these things inter relate.
– Play with 8086 may be. Write some mnemonic code/assembly to understand what it is compiled to.
– Learn C. Build some data structures in it. Deal with the stupid pointers and memory leaks.
Basically understand few layers deep within. Like TCP/IP stack or OS internals etc. What it gives you is a matrix/neo vision to the code and application.
You were able to get a CS degree without coming across Big O? Are you kidding? Of all the things that get taught in CS that aren’t really CS, Big O (and little O, theta, etc…) is one of them. Next you are going to tell me you never heard of a Turing machine!
Andrew. Please re-read the first two sentences of this article.
The problem with teaching yourself is that you need to know how to learn. Which specifics you missed along the way aren’t so much as important as the fact that you recognize them as something that you needed to know, then went out and learned them. There will ALWAYS be things that you don’t know – that’s just the way the world works.
As to those who say “X is so important, why didn’t they teach it,” though … there’s always something important which wasn’t taught. Take databases, for instance. I’ve had to teach database programming to so many CS graduates that it’s not even funny: they get hired because they’re good at something, and CAN learn, but database just isn’t taught to everyone, even at some of the best CS departments.
So, meh.
As to self-taught developers missing these three things, I’d disagree entirely: some of us are better at teaching and learning than others. Whether these three things are of any real import? That’s another question entirely
Things you missed out on by doing a degree.
1. Research.
Just that one. There are plenty of people with these three bits of knowledge but no degree.
OK, one more.
2. Common sense.
“There are plenty of people with these three bits of knowledge but no degree.”
I didn’t mean to imply otherwise. As I stated…these are things I, personally, felt I was missing when I started my career.
if you mean a “real” cs degreee, than you should add formal languages and petri nets.
nice article.
Hi Ryan,
I don’t know whether you have a degree in Computer Science or not (haven’t checked your profile). But all these 3 things that you mentioned are never taught at school.
In fact, at school you are taught the history and the basics of programming in Pascal, C, C++ and LISP (the latter is for artificial intelligence).
School gives you the background that you need to learn any programming language. It teaches you that the programming language is the simplest thing – the algorithms to develop your code are the most important.
Thanks for sharing.
Ugh… NO! I agree that design patterns and unit testing aren’t (or shouldn’t if they are) taught, but Big O absolutely is a fundamental part of CS.
Ryan, Thanks for putting yourself out there and providing good content and relevant links for diving deeper. I reinforced a few concepts and learned a bit too.
I appreciate your helpful words. good work. I hope you release others. I will carry on subscribing
Look, Computer Science has almost nothing to do with programming. There is a famous saying that computer science has as much to do with computers as astronomy has to do with telescopes. Computer Science is all about data and algorithms.
You need to learn about Turing machines, Incompleteness, Logic, Calculus (so you can learn Numerical Methods), Data structures, Database theory, Big O (and other algorithmic ideas), basic Algorithms for searching, sorting, shortest path, computer architecture, assembly language, etc..
Is programming required to make use of that list? Yes; is it the focus of Computer Science? Not by a long shot. Some people in the field study languages and work on new ones. After all, we need them to communicate with the computer, which makes it incidental, not essential.
Did you know that the gaps between floating point numbers gets larger, in chunks, the further away you get from zero? If you’re self-taught, probably not. Do you understand the effects of truncation and rounding? Do you even know what the computer is doing when you write high level code? I hope you aren’t writing a program where precise calculations are required with big numbers, because you’ll have no idea why the answers aren’t very good, or any clue how to fix it.
Using API’s written by people with an education because you have no idea how to actually make a computer do something useful, slapping a UI on top and calling yourself a “code ninja” or other such nonsense is all too common among self-taught programmers. Some of them pick up the essentials along the way or get grandfathered in because they understand some cryptic system the company can’t do without, but the rest just fizzle and burn, doing grunt work like web development that doesn’t require you to solve any hard problems.
I know I’m being harsh, but that’s because I used to be (only) a self-taught programmer. I’ve been to school and now I realize that I didn’t really know crap before. Don’t get me wrong, school doesn’t really teach you anything, but it does guide you in the right direction and tells you the things that are important to learn and holds you accountable for actually learning them.
I don’t know why you think you’re being harsh. This article was about some things I missed because I *don’t* have a CS degree. I’m still not sure that you’ve gathered that fully. It also never states that this list is exhaustive, nor was it ever implied to be.
It was just some things that I picked up my first 6-12 months in the industry(which was a long time ago) that would have been nice to know coming out of school. You’re really digging something out of this post that was never meant to be there.
I even suggested an alternate title in the very first paragraph of “3 Things That I Wish I Knew When I First Become a Programmer”.
Hey just wanted to give you a quick heads up.
The text in your article seem to be running off the screen in Firefox.
I’m not sure if this is a formatting issue or something to do with browser compatibility but I figured I’d post to let you
know. The design look great though! Hope you get the problem solved soon.
Thanks
Hi everyone, it’s my first go to see at this site, and post is in fact fruitful designed for me, keep up posting these types of articles.
Amazing! Its in fact awesome paragraph, I have got much clear idea concerning from
this piece of writing.
I do trust all of the concepts you’ve presented to your post. They’re really convincing and will definitely work.
Nonetheless, the posts are too short for beginners. Could you
please lengthen them a bit from subsequent time? Thank you for the post.
G’day, that was a fantastic written piece! Lots of good material,
I am grateful that I come across it.
I am going to bookmark your blog site! 🙂