The Stack Overflow Generation – A Guide for the Novice Programmer
August 28, 2015
Recently, I gave a talk at the Atlanta iOS developer meetup. The talk took up the first hour of the meetup, and the second hour was occupied by something called ‘Open Spaces.’
Open Spaces is a self-moderating panel – I won’t go into all the details – but it allowed a forum for everyone at the meetup to share their perspective. Many thanks to Joe DeCarlo at Turner for his tireless effort building the community through these meetings.
The entire Open Spaces session focused on one single topic – ‘How does a junior developer become a better programmer and get a better job?‘ The number of people asking that question was far greater than the people who had advice. This is a good thing; it means our industry is growing. But, as was evident from the discussion, there isn’t a clear path for someone to grow along.
It has been a long time since I’ve been a ‘junior developer’, so I have forgotten what the struggle was like. Not only that, the struggle was entirely different when I was learning to program – neither iOS or Stack Overflow even existed. There weren’t that many programmers in general, nor was there a reliable way of having a dialogue with them. But, the advice is still the same today as it was then.
I’ll talk about some of that advice in a moment, but first, I’ll take a crack at explaining what the developer world looks right now. This is just my perspective, so take it for what its worth. Feel free to skip ahead to the ‘What should I do?’ section, but those of you that read the next section will see the irony in that.
What it looks like now
The amount of information available on the internet is vast, the cost of obtaining the necessities for learning to program (like a computer) has shrunk, the higher level of abstraction in programming languages and platforms brings down the barrier of entry, and the high demand for programmers means more people are incentivized toward being a programmer (and the other support industries around programming).
These are all good things, but there is a flip side to them – not necessarily negative, just more to think about.
The high demand for programmers means that salaries are currently skewed higher than they likely should be. I know plenty of people currently making six figures that don’t truly understand what a pointer is. This will change. It won’t change because knowing what a pointer will become irrelevant (it won’t), but because the supply of developers will eventually meet or outpace the demand. Here are some graphs to more broadly illuminate the point that honestly I just wanted to draw and don’t really add that much to the conversation:
With regards to the lower barrier of entry, the other side of that coin is that it is possible to create and distribute a not-terrible application nowadays without knowing much about how it works. Early rewards can engage and inspire someone to continue on their journey, but, the barriers on the rest of that journey aren’t going to disappear. It’s a real possibility that without the right guidance or challenges, someone will go an entire career without ever being exposed the important barriers – ones they are capable of crossing, but never knew they existed. This was a common theme at the meetup – ‘I don’t even know what comes next.‘
The increased access to computers and the internet means the pool of possible developers is becoming larger, which means that a junior developer must compete just to get a foot in the door. A common question at the meetup was, ‘How do I stand out when applying for a job?‘
Then comes the first thing I mentioned, which is really the point I’m going to belabor momentarily: the endless flow of information on the internet.
The Perfect Storm
So let’s back up and look at the perfect storm that started everything: the iOS SDK comes out in July 2008, there was a low barrier to entry, the rewards were incredible, and marketing was a non-issue because the App Store was underpopulated.
One month later, Stack Overflow launches. During this time period, not only had the barrier to entry been lowered, there is also a place to go when stuck on a problem without necessarily learning how to solve the problem or why that solution worked. A lot of developers became developers without truly understanding what they were doing. It’s like being able to plug numbers into a physics equation to get a good grade on a test, but without understanding physics. Sure, you get an A, but when you’re tasked with knocking an asteroid out of a collision course with Earth, that A doesn’t really help.
Much of the information on the internet in general is misinformation. It is significantly easier to write misinformation than it is to create good information. Writing something with good information takes a long time, is exceedingly difficult to write, and rarely addresses a specific problem that someone might have. It often creates more questions than answers. Likewise, it is easier to read misinformation for these very same reasons.
Copying and pasting code from the internet may (seemingly) advance the specific application forward, but it doesn’t advance the programmer forward. (I say seemingly because good software isn’t just blocks of disparate code, it is a carefully orchestrated layering of components; bad code eventually implodes.) There will be many more applications built by people that are advancing themselves as programmers. At a certain point, someone who didn’t advance themselves will no longer be able to compete.
What can I do?
I bet you thought I would say to stop using Stack Overflow. But I won’t. I use Stack Overflow. After all, there are many talented developers who are members of that community. Here’s how I use it: if I’m trying to solve a specific problem on a specific platform, I check Stack Overflow to find the direction I need to head in – like a particular class or framework I should be looking at that I was unaware of previously.
Then I close my browser and open up the API reference documentation for that class. I read every method name on the class. Objective-C is nice because one can generally figure out what a method does by its name. Some methods sound interesting, so I read the full description of them. Sometimes I realize that class isn’t exactly what I’m looking for, but I go digging around in that framework for things like it.
There’s something subtle here that is often missed, and most assuredly is missed by those finding their answer on Stack Overflow: when you’re reading through the documentation to find what you’re looking for, you’ll eventually find it. But before you find it, you’ll read a lot of things you weren’t looking for on the way. You will remember these things even if you aren’t trying to remember them. Over time, you will have built up a huge database in your head of things the platform can do. This will not only help you find things in the future, but it will also create a map in your head of the way the platform works. It will teach you how to name and construct methods better, because you will be exposed to well-named methods often.
Usually, the API documentation is enough for me to start figuring out how I fit the code I want to write into the rest of my code. Sometimes, for really heavy subjects like the text system on Mac OS X, the API documentation isn’t enough to form an understanding of how all of the pieces fit together. When this is the case, I read one of Apple’s programming guides. These documents are conceptual explanations of how the system is intended to work and be used. Reading an entire programming guide for a topic can take a whole day.
The trick to reading programming guides is to resign yourself to the fact that you won’t solve your problem today. There won’t be a magical statement where you say, “Ah ha, now I will write this code!” You’ll learn something new and the code will take awhile to form. That’s okay; that one day will be worth months over the course of your career.
Don’t limit yourself to one platform or one language. Your second programming language will be the hardest programming language you ever learn, because you will rewire the way your brain thinks. Once you’ve seen two programming languages in depth, you realize they’re all just doing the same thing. Learning your third and fourth programming languages is easy – you’ll know what concept you wish to apply when solving a problem and figure out how that programming language implements the particular concept, or what alternatives it uses to solve a similar problem. Learn a functional programming language.
Don’t worry about finishing an application and putting it in the store. I hear that all the time, “Yeah, just put some apps in the store and you’ll get hired right away!” Anyone worth working for is going to care about how you built it, not about how many users it has or dollars it made, or whether the interface looks good or not. And we also all know that there is no such thing as ‘finished’, anyway. There’s something to be said about continuing to work on a project and improving it over time and that is important because it forces you to rethink how you wrote something initially based on what you want to add to it – but that doesn’t mean you need to build a shippable product and go through the deployment process.
Since we’re looking at your code anyway, we can run it ourselves to see what it does, as long as it compiles. (By the way, it’s really embarassing to send code that doesn’t compile.) Although, honestly, I never run the code. That’s not what I’m interested in. I certainly run the static analyzer on it, though.
Oh, and no one is going to steal your app. I mean, maybe they will, but if they have to steal a novice’s early project, are they really going to do anything with it? It then follows that you should host your project on Github publicly. That way, when you are asked for a code sample, you’ll have it ready AND you’ll demonstrate that you can already use version control.
Also, I can tell you what someone worth working for is going to look for. First is the basic command of the language – do you know how to use properties, write methods, implement callbacks, etc. Those are essentials. Next, someone is going to look for how you solved things that every app has to solve: Did you fetch something from a web service? How did you create interfaces? How did you store data? Did you define model objects? If there is some understanding of those things, that’s a good indication you will grab a junior developer spot.
Next up comes code style and design pattern usage: is there a consistent style for method naming, indentation, variable naming and so on? Does that style match the platform’s style? Is code kind of strung together haphazardly, or does it make use of concepts like delegation, model-view-controller and object composition? A mid-level developer is going to have a style and utilize design patterns with reasonable effectiveness.
After that, the architecture of the whole project will be looked at. This is usually accompanied by an explanation from the candidate explaining how the whole thing comes together: generally speaking, the shorter that explanation is, the more likely it is a well-architected system. This is where we start getting into seriously good candidates and I won’t get into that because you already know who you are and also I really wish you’d come work here.
Avoid recruiters at this stage in your career. Sorry to say, but the good recruiters don’t care about novice programmers. Nor should they. Additionally, once you get hooked up with a recruiter, in order for someone to hire you, they have stroke a check to the recruiter. A novice programmer is a long term investment for a company – you’ll get more out of them than they get out of you for quite some time. One junior developer looks a lot like every other junior developer in terms of potential – except the one with the recruiter costs more money that only the recruiter gets.
Spend the time googling Stack Overflow answers and apply it to googling for companies in your area that do development. If you’re like me and from Wisconsin, you may have to expand that search. Send them an e-mail. Tell them you want to learn and you’ll work hard. I don’t care if they have a job posting or not – one of our junior developers showed up at our door with a resume one day. I got my first programming job at Big Nerd Ranch by randomly filling out a Contact Us form. My first hire at stable/kernel did the same. You’re going to get some ‘No’s’ – companies have revenues and costs and when costs gets bigger than revenue, they don’t get to be companies anymore, so maybe paying you to learn doesn’t work right now. Or maybe right now is a perfect time. Won’t know until you ask.
Work for a company that wants you to be a better programmer and can also make you a better programmer. Ask the person doing the hiring how they plan to train you. There should be some kind of plan in place, and it should involve people that can code circles around you. Those people will be happy to give up some of their day – in which the code they are teaching you how to write would be boring and trivial for them to write – to work with you. There is simply no substitute for mentorship. Be the worst programmer at a company, because then you have that many more people to learn from.
Finally, understand that there are zero shortcuts and that this industry isn’t special. It’s definitely a weird industry right now, but at the end of the day, it’s the same as everything else in life: if you consistently work hard and listen, you will be successful.