My first few forays into the world of programming were confusing, frustrating and some of the most daunting experiences I’ve had. It can seem like everyone around you has a vast fountain of knowledge and started writing code when they were 8 so you have no hope of ever being as good as them. The truth is that almost everyone experiences this and with enough time people will look at you in the same way.

The points outlined below are a list of concepts I wish I had grasped early on in my developing days. I would have saved countless hours of wasted time and I want to make sure you avoid these pitfalls in your endeavour to become a better developer.

#1 Perfection is the enemy of progress

Sure, everyone wishes their code could be perfect, but labouring over every line of code until it’s as efficient as possible and perfectly written is going to severely slow your progress. The concept of an MVP in programming is a Minimum Viable Product. Whatever it is you are making to teach yourself a new concept, get it working in the most basic capacity, learn what you wanted to from the exercise and then if required come back and refactor your code. If not, move on and start learning something else.

#2 Don’t let changes pile up

Two agile development tenants come to mind here. The first is to develop small, incremental releases and iterate, The second is to test early and often. One of the biggest mistakes I made when I started developing would be to start a new project, write 200 lines of code, and only then spin it up for the first time.

The result would be 4 or 5 different errors all compounding and obscuring each other, making it much harder to find the problems. If you test early and often while incrementally developing small pieces of functionality it will be noticeably easier to debug and test.

#3 ‘Cheating’ is not only normal but expected

I see this with a lot of the new starters at my current company. When they run across an issue, instead of googling the problem they want to get to the root of the issue themselves so that they can learn from the experience. While this can be a good approach to simple problems, and you shouldn’t just immediately turn to google every time an error pops up, more complex issues should be researched. I haven’t met a single developer who doesn’t use google frequently throughout their day, even at the upper end of the experience scale.

#4 A degree will get you in the door, knowledge will get you a job

I have been involved in the hiring process a few times when looking at new developers for my current company. and while a degree is an extra point against your name, it is by no means the be-all and end-all of the hiring process. A candidate with a strong portfolio or even just a basic level of knowledge and a willingness to learn is going to rank much higher than someone with a degree but the wrong attitude. That being said, if you are in the position to get a degree it is a fantastic way to gain the knowledge in a structured and guided environment.

#5 Knowledge of concepts is vastly more important than syntax memorisation

Too many new developers will spend forever trying to memorise how to construct certain elements and not enough time on the big picture. Knowing what to use and when to use it is 90% of development. Once you have that you can google the exact syntax, or even better use a snippet manager.

#6 Pair programming is like steroids for development learning

I understand that not everyone can physically sit down next to someone and collaborate but it is the most powerful tool I have found for new developers. When I started my first full-time developer position I was lucky enough to be doing so alongside a friend from university, and due to a combination of lack of organization and lack of company resources, for the first two months at the position, we only had one laptop between us.

This sounds like a terrible idea as it would immediately cut any productivity in half right? That wasn't my experience, those two months were probably some of the biggest periods of growth I ever experienced. It was often the case that one of us would get a concept better than the other and help the other figure out the missing pieces and everything just came together. So much so that I have suggested the concept be trialled again if we ever get two new starters at a similar time.

#7 Finish what you started

My early days were riddled with jumping from one idea to the next, trying out this new language, and then the next. If you start a project to create something instead of just as a learning exercise, put in the time to finish it. By starting a new project every few days I got good at starting projects and doing the same few tasks, but it took a long time before I learned how to polish a site, or how to release something to production and all the tasks that come with that. If you are always working on starting things, you’ll never learn to finish them.

#8 Be wary of cutting edge technologies

Being up to date and using new technologies is important, but once you make your way to the very bleeding edge it’s like the wild west for a new developer. There is often very little documentation on how to achieve things, and if you are working with release candidate builds there will often be bugs that just further complicate things. Working with bleeding edge technologies is a lot of fun and can be a great way to drive your learning, but as a new developer, it’s easier to walk where others have been before.

#9 Conventions are important, but you can’t always have your way

Naming conventions and best practices are important, and when you are working in your personal projects these can be whatever you want, but in a professional environment these will often already be determined and you will be at the mercy of the team. It’s important that no matter how much you disagree with the naming conventions, you follow the rules that have already been set out. If you do disagree with the standards, however, this shouldn’t stop you from making suggestions for future implementations and bring the standards up for discussion.

#10 You will hate code you wrote 6 months, or even 6 days ago

I have never met a developer who can consistently look back 6 months and be happy with their code output. As a developer, you should always be learning and improving. After a big revelation (like how you should be writing reusable code) and a new perspective, you will look back on your previous code and cringe at how you didn’t do this one thing quite right. This is normal and a sign that you are improving.

#11 Perhaps most importantly, just get stuck in

Too often new developers will get caught up in reading about a new technology or an interesting design pattern, but truth be told the best way to learn programming is to write something! So pick up a simple project or try and complete a coding challenge, and it will get easier and easier.