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 hunting bugs
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. This will happen over and again, multiplied by the number of languages you decide to learn.
All developers go through this. Sometimes you'll spend hours on a problem, sleep on it and then solve it within moments of waking. Other times it will feel as though no matter what you do you can't find a solution to the problem.
After you've seen enough a few years of bugs like this, you'll be able to spot them in a coworker's editor from across the room. It will eventually become second nature. These frustrations are the fires your technical skills are forged in.
You'll receive conflicting advice
You'll get advice from other developers, most of it conflicting. One senior developer will say that real developers do everything from the command line. 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. Other developers will preach the benefits of immutability and functional programming.
You'll be drawn in different directions by people with more experience than you. Who's opinion should you take on board? Who's right and who's wrong?
There are very few absolutes when it comes to practical programming. A Technical opinions of developers are based on their experiences, the books they've read and the technologies they happened to work with. No one does a thorough survey of the technology landscape before declaring their support for a given tool, application or methodology.
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. Collect opinions from more than one developer. Find out if there's a consensus. Read original material and do your own research. Take no-one's opinion as gospel, but put effort into formulating your own.
You won't know what to learn
To be a functioning web developer you need a good mix of all of the above from day one. That's impractical, so you're going to have to learn on the job and work around 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:
- Maintain a list of technologies that you think you should learn or would make you more useful to your employer.
- Rank them by how bad you are at them and how important you think they are to your skill-set.
- Pick the skill that ranks highest for both and work through two or three technical books on the topic. If you're tight on cash, Zed Shaw maintains a list of free books on most technical topics you could want to learn.
- Repeat steps 1-3 for the next highest item on your list until you're happy with your skill-set.
Your ego is in 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, 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'll be writing a lot of bad code.
Developers with more experience stay a little more detatched from their code. 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 terminology that doesn'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 an overwhelming barrage of topics to study up on.
The bad news is that there's a lot to study up on. No one 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. The only real solution is to tackle new ideas word-by-word. In time this will get easier as patterns between topic emerge, but it's a hard slog when starting out.
Most people around you don't fully understand the concepts they throw around so easily. It pays to maintain humility on any new topics, both for your own personal development and the people who depend on you to write good software.
If you act with confidence about topics where your knowledge is wanting, your software will be the worse for it. People who do know what they're taking about will lose trust in you. If you want more senior developers to take your opinion seriously, be comfortable with saying "I don't know" when you find yourself at the edge of your knowledge.
There's a lot of hype in mainstream media now about learning to code. 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. A belief that if you persevere then, given enough time, you will improve. Learning to program doesn't require above-average intelligence. But like anything worth learning, it's going to take a while before you have any sort of competence at it. Embrace the process, keep pushing and it will get easier.
- Najaf Ali