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:
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:
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”.
Filed under: Coding | 34 Comments