Audience: total beginner software engineers
Reading time: not that long
This January Square hosted the 4th College Code Camp by welcoming women who are studying engineering in college to Square’s SF office for five days of nerdventure.
I’m always really impressed with these students and I tell them in complete honesty that I’m really glad they’re doing what they’re doing so that one day I can work for them.
I’ve said the same when speaking to folks from Hack Bright, Code Fellows, Ada Developers Academy, General Assembly, and Hack Reactor.
The response I get is just about always the same: The students laugh nervously, smile at me, and probably wonder why I think that joke is funny.
It’s not a joke though – they really are going to have bright careers.
Each one of the students currently struggling with the concept of recursion will, if they keep working at it, eventually get it and move on to reach some far further goal. Maybe they’ll build a service that attracts thousands of new users overnight or they’ll make the front page of Reddit or they’ll be condescended to on Hacker News. Then they’ll know they’ve made it in this ridiculous industry.
But at this point in their career where they’re talking to me those things are all a far-away dream. And it’s hard to see how to get from where they are to where they want to be.
Learn to code in three and a half days
When I was starting my career in the mid-2000s there were two ways to educate myself: Reading the source code or giving up. The latter offers terrible odds of success.
Now there’s Coursera, Treehouse, Khan Academy, any number of bootcamp-style programs (including the unbelievably good Ada Developers Academy), Stack Overflow, O’Reilly and basically the entire rest of the internet.
It’s now almost trivially easy to take your first steps as a software engineer.
In fact, thanks to Hour of Code there are tens of millions of people who’ve tried their hand at programming for the first time.
I’m a huge proponent of getting people into engineering and I disregard the critics who say we’re letting prospective students underestimate how difficult it is. Underestimating the difficulty of a task is one of the most consistent character failings of an engineer. So anybody who thinks they can build a distributed messaging graph after 9 weeks is gonna fit right in.
However.
The stuff you’re missing
The skills you have after a Coursera class or a multi-week code school are not enough to get a good job. Unless you’re either independently wealthy or happily poor you don’t really have time to futz around for a few months on hobby projects while making no money. Even more importantly, the skills you have aren’t enough to let you feel confident in your abilities. You can solve some simple problems but you’re going to spend all day faced with terms and concepts that are still far beyond you.
More aggravating is you don’t even know what skills you’re lacking. If you interview you may get feedback that they’re “only looking for very senior people right now” which is code for “we don’t know how to train you and we actually need to hire somebody who can train us.” So I’ll break it down for you: You’re missing two large, entirely separate categories of skills.
Category 1: A broad knowledge of libraries and development patterns
The first category is what employers say they’re looking for: Senior experience in software engineering. They want somebody who knows every data structure. They want somebody who knows why Nginx can process hundreds of megabytes per second with almost zero CPU usage and they want somebody who knows the difference between a linearizable and non-linearizable system. Somebody who can debug a Linux box where all application processes are ‘zombied’ and can explain why Rust is an appropriate language for embedding inside a Ruby gem. They want somebody who can do TDD and write a parser for ARVUN in a day.
Sound intimidating? Yeah, it’s totally intimidating. But you know what? Nobody knows all that stuff. I even made that last one up (ARVUN is just some random letters I typed). As a natural byproduct of your daily work you will absolutely collect these insights into how computers function. What you learn will be different than what your peers will learn. This means you’ll always think everybody around you is a genius for what they know and they’ll think the same thing of you. Software engineering is an infinite field[1] so when a prospective employer lists stuff you should know they’re basically selecting a random set of acronyms that they’ve heard some of their peers mention. You already know stuff that they don’t even know that they need you to know.
A fantastic example of the ridiculous breadth of knowledge required to build software is illustrated by this Code Fellows blog post. I happen to know all of those things (because I learned them one at a time over about 8 years) but I have absolutely no idea how to, say, design a network. Seriously. No idea at all. Network engineers seem like gods to me and I to them.
So you’re screwed – permanently – because you’ll never know most of engineering.
Category 2: Comfort with your language and fundamental concepts
Luckily, those aren’t the skills you need to get a good job. When I hire people at Square and when I’ve hired in the past I look for teachability and familiarity with the primitives of building software. No matter what your training or experience I can’t hire you if you’re unable to learn. No matter how junior you are if you know your tools and know how to build pieces of software with me guiding you through the hard parts I can hire you and I know you’ll keep learning and contributing for your whole tenure at my company.
The largest blocker to your employment is that the tools of your trade don’t yet feel comfortable in your hands. You haven’t mastered your editor, you can’t reflexively set up a new project and get boilerplate code running while your mind is distracted. You haven’t yet tried all the wrong ways to write a recursive function. This is the primary thing keeping you from passing a coding interview (at a good company that actually tests your skill and doesn’t just ask you trick questions). Luckily, it’s also a set of skills that’ll help you be successful on the job as an engineer. Training yourself this way for an interview isn’t cheating yourself or your employer – it’ll really make you more valuable on the job.
You’re going to have to ignore that whole first category of stuff. Learning how each piece of software works is a fun lifetime journey and you can always learn things right when you need to. But if you want to get your first programming job you’ll need to develop a real comfort with the primitive pieces of your craft.
An aside: How to actually learn to program
Let’s get one thing straight: You can’t just watch a video online and know how to do something. This isn’t just about code. You can’t learn to sail a boat that way, you can’t learn to juggle that way, and you can’t learn to type that way. Unless you actually have a project and work on it until it’s done-ish and you face all the hurdles that crop up on your way you can’t develop your skill. And if you want to truly understand what you’ve been learning there’s one ancient, highly-successful method for making the knowledge fixed in your brain: Teach it.
I learned Ruby on Rails at Rails Forum way back in 2006. And I did it not by asking questions but by answering them. Somebody would be stuck with “How do I make an ActiveRecord query that uses multiple tables” or a similarly impossible question and I’d dive into the Rails source code to find an answer - even though I knew nothing more than the person who asked it. This is still the best way make concepts clear in your head. Find a project you want to complete to pick up the basics and teach somebody else those basics in order to master them.
What to learn: Learn your editor
I can’t stress enough how much easier your whole career will go if you make it a habit of memorizing shortcut keys and learning the advanced features of your editor. Whether you’re using Vim and Emacs like some 1980’s proto-hipster or Sublime Text like a modern day one there are advanced features in each that you don’t even know about. In every good editor you can select rectangular blocks of text and manipulate them. You can find all instances of a term in a single file or multiple files and modify them all at once. You can jump automatically from where a method or function is called to where it’s defined. Seriously, every editor can do this.
What to learn: One language
Somebody you know is really excited about the hot new language. Ignore them like you would ignore your crazy uncle’s politics at Thanksgiving. Nod and smile and just keep working on whatever language you have started learning.
Every language is fine to learn because they’re all terrible. Just like human languages[2] – each programming language can do some stuff super well and falls down at others. Ruby is elegant but psychotically inconsistent. Python is straightforward but will literally murder you if you try to upgrade to version 3. Java is powerful but will make you type the word ‘logger’ 5 times if you want to create a new logger (Logger logger = Logger.loggerFactory.iHateMyself.CreateLogger()). Lisp and Haskell will allow you to represent human life in just a single, mathematically-provably perfect line but nobody will care. JavaScript is the blunted stump of what could have grown into a computer language.
So learn a language and figure out how to express yourself in it. Learn its quirks and learn to love it despite its ugly parts. If you like your primary language start reading more about why it’s broken and terrible. It should probably take you about a week to figure out the serious limitations of any language. And only once you hate it a little would I trust you to build something important with it.
What to learn: Building small things
The best developers I know aren’t the ones who’ve crafted some huge system (though many have). The best developers can start and finish a small project in a single day. Maybe it just mashes up Instagram data with their Google Calendar but it’ll be about fifty lines of code and it’ll do exactly one thing properly. The more of these you write the more confidence you will have when solving any kind of technical problem.
I even have some suggestions for stuff to build as practice. These little things will give you the reflexes you need to pass a technical interview and they’ll also make the act of programming move from an intellectual exercise to muscle memory.
Project #1: Building a hip-hop name generator.
This is an easy and a fun one. Pick a list of first words and a list of second words then randomly print bad rap names for people by combining one element from each. “Lil’ Dicey”, “Ebenezer Money”, “Shady Slurpdog”. Set aside an hour and you’ll be able to print randomly generated names to the screen. Skills you’ll learn: arrays, using randomness, concatenation, printing to the screen.
Project #2: Building a word search solver.
You know those boring airport time-waster puzzles where there’s a grid of letters and you have to find the words in it? Make a program that can find the words ‘jack’, ‘danger’, and ‘coding’ in this:
CRZJPHJ
OEEMAAS
DGUGCCJ
INSKNEK
NAKATAD
GDSHJED
This’ll take you a couple hours if you’re familiar with your tools or all day if this kind of problem is new to you. Skills you’ll learn: depth-first or breadth-first search, nested arrays.
Project #3: Generating a maze on a screen.
Give this one a full day. It requires solving two different problems: You need to figure out the logic of how to generate a maze and you need to decide on some way of drawing something on the screen. A primitive, perfectly acceptable way would be to print “|” and “_” characters on a screen to symbolize walls.
Here’s an example of a pretty sweet-looking one: mazegenerator.net
The way you should build this is by cheating as hard as you possibly can. Seriously, just Google “building a maze generator” and follow along with how other people have done it. Skills you’ll learn: recursion, depth-first search, managing multiple data structures at once.
Project #4: Building a sudoku solver.
SO. FUN. Okay, maybe not the funnest thing ever, but if you like Sudoku it’s a blast. Same instructions as above and I recommend cheating on this one as well. Peter Norvig has a lovely and complete example of doing this in Python.
Project #5: Project Euler
Project Euler is kind of the gold standard for programming puzzles. It asks you to use any programming language in any environment you want to solve simple number questions. The first few problems are very easy and if you sort the problems by the number of people who’ve finished them you can find all the most accessible ones. Don’t worry if one is too tough, there are questions there for kids learning to code and questions for math Ph.Ds. Hopefully you’ll even find yourself accidentally learning the fun parts of math as you go. Project Euler will definitely make you a better developer because you’ll need to set up simple functions over and over and over and the nuts and bolts of programming will start to become muscle memory while you let your brain work on higher-level stuff.
Project #6: My interview question
That link above is the question I would ask you if I were to interview you for a job. It will be harder to solve the problem on your own at home rather than alongside me because you don’t have me explaining the hard parts but you’re welcome to try it. Cheat as hard as you can. If you come in to interview at Square and I asked you that question and you say “I tried it at home until I was good at it - watch this!” and then you did it really well I’d just hire you on the spot. That kind of initiative is what makes people successful in this industry.
You’re going to be fine
With each of these (except the first) you’re sure to run into some walls where you feel stuck and when that happens I’d love if you reached out to me on Twitter and we’ll crowd-source some help.
Even after building several projects you may still be feeling like computers are magic and you’re a dummy and maybe you don’t have what it takes to do this work. You may feel like everybody else ‘gets it’ and you’re missing something but don’t know what it is. You may even feel like everybody else is the same as each other and you’re the odd person out. Regardless, you’re going to do really well in this industry. You can type, you can think, and you can make computers obey you. In a couple years it’ll be your turn to teach newcomers the basics and to help them calm down and trust that they can do this. Until then just practice with your editor, practice with your language, and above all remember that you do have what it takes and you’re going to be fine.
Special thanks to the engineers Liz Rush, Danielle Sublett, and Davida Marion who reviewed drafts of this post.