How to survive your first year as a programmer

The first year as a programmer is one of the most frustrating things a homo sapien can experience. You’re thrust from the world of ambiguous human communication into the icy waters of cold, hard correctness. There is no compromise with the machine. It does exactly what you tell it to, no more, no less.

You’ll spend hours on end fixing silly mistakes

You will spend hours checking the code you wrote, matching it up to tutorial content and staring at it wondering why you can’t get it to work the way it’s supposed to. And not only once. This will happen over and over again, at least a couple of times for each new language you learn (which if you’re a web developer is probably a lot of languages).

All experienced developers have been through this. Sometimes you’ll spend hours on a problem, sleep on it and then solve it within minutes of opening the code again. Other times it will feel as though no matter what you do you can’t find a solution to the problem.

In a few years time, after you’ve seen enough bugs like this, you’ll be able to spot them in a coworker’s editor from across the room within a split second of it entering your periphery. It will eventually become second nature. These frustrations are the fires your technical skills are forged in.

You’ll have to juggle lot’s of diametrically opposed advice

You’ll get tons of advice from people with different opinions, most of it conflicting. One senior developer will say that real developers do everything from the command line while another will tell you that developers who use the command line are stuck in the past. You’ll read blog posts about how test-driven object oriented programming is the product of divine revelation but other developers will espounge the benefits of immutability and functional programming.

You’ll be drawn in all sorts of directions by people with more experience than you. Who’s opinion should you take on board? Who’s right and who’s wrong?

The truth is that there are very few absolutes when it comes to practical programming. A lot of technical opinions of developers are based on their own experiences, the books they’ve read and the technologies they’ve happened to work with. They definitely do not do a full and thorough survey of the technology landscape before declaring their support for a given tool, application or methodology.

The trick to dealing with this is to reserve judgement. When a developer tells you that she thinks Postgres is a better database than MySQL, ask them why they think that. If you’re lucky, they’ll be able to enumerate concrete reasons for their opinion and you will have learned something.

You won’t be sure what to learn next

Should you learn more about visual design? Do you need a good knowledge of all CSS attributes to be effective? How good do your skills with SQL need to be? What’s this “Object Oriented” programming thing that everyone keeps going on about? Should you learn Ruby, Python or PHP? Do you need to learn all the new tags in HTML5? What about Javascript? Jquery? The DOM? AJAX? How good do your skills need to be at the command line? And if you have to learn all this stuff, what order should you learn it in?

The truth is that to be a functioning web developer you need a good mix of all of the above from day one. That’s just impractical, so you’re going to have to learn on the job and work around serious blind spots in your skillset. The best you can hope for is cataloguing your known unknowns and put learning them on a todo list for future study.

If I had to start from scratch, here’s what I’d do to ramp up my skills:

1. Maintain a list of technologies that you think you should learn or you know for a fact would make you more useful to your employer.
2. Rank them by how bad you are at them and how important you think they are to your skillset as a programmer.
3. Pick the skill that ranks highest for both and work through two or three technical books on the topic. You can normally find the best books on a topic by googling for “best books for learning X”. If you’re tight on cash, Zed Shaw maintains a list of free books on most technical topics you could possibly want to learn.
4. Repeat steps 1–3 for the next highest item on your list until you’re happy with your skillset.

Your ego is tied up with your code

You’ll feel that a failing in your code is a failing in you as a developer. If someone finds a bug in your code or points out it’s deficiencies, you’ll feel it’s an attack on you.

Learning to code well is like learning to write well: you need to get a few tens of thousands of lines of bad code out of your system before you start writing good code. There’s not much you can do to escape this. You might as well accept that you’re going to be writing a lot of bad code.

Developers with more experience and a healthy outlook on life stay a little more detatched from their code because they’ve already written tons of code that they themselves consider terrible. They welcome criticism because it’s an opportunity to learn and improve. You rob yourself of this opportunity when you get defensive about code just because you happened to be the one that wrote it.

You’ll feel like you have to know everything

Everyone around you gets into technical discussions using words and phrases that don’t make much sense to you. They throw around concepts with deep implications without explaining them, and in order to contribute it feels like you have this overwhelming barrage of topics to study up on.

The bad news is that you’re right, there’s a lot to study up on. No one sat down and decided that the total amount of knowledge a developer needs to build good software is roughly equivalent to how much an average person can handle. It’s hard, and the only real solution is to go word by word and try to understand new ideas as you come across them. In time this will get easier as everything is connected, but it’s a hard slog when starting out.

The good news is that the vast majority of people don’t fully understand all the concepts they throw around so easily. It pays to maintain a healthy amount of humility on any topics you’re not so sure on, both for your own personal development and the people who depend on you to write good software.

If you act confidently about topics where your knowledge is shaky, your software will be the worse for it. People who do know what they’re taking about will (rightly) think you’re an idiot. If you’re working on a team with me and you say the words “I don’t know” when you run up against the edge of your knowledge , my trust for you increases twenty-fold.

Wrap up

There’s a lot of hype reaching the mainstream media now about how great learning to code is. In all that bluster, they fail to mention that the first year of programming is a frustrating, humbling and mentally exhausting experience.

More than passion, you need a grim determination and belief that if you persevere, you will get good at it eventually. Learning to program doesn’t require above average intelligence. But like anything worth learning, it’s going to take a while before you feel like you have any sort of competence at it.