I have had the fortune of working with some great programmers, not only from the web development world but also from embedded software. I have also had the privilege of teaching some people to code or help them get better. One of the hardest things about teaching people to code is to teach them the non-coding skills/mindset needed for a programming job. Based on my experience, here are some of the most important skills that you should learn/understand to be a better programmer
As much as programming is about writing code, it’s a lot more about using other people’s code. And most of the code that you’ll be using is going to be open source. Open source is a very ‘as-is’ and ‘fix-your-own-problems’ kinda community. If you download someone’s code and it doesn’t work, only you can help it (others might help you but please don’t expect them to). You can’t write to someone or have someone show you the way (or at least not as easily). You have to accept this and consider this as part of your workflow. That’s why new programmers can’t estimate how long it would take them to get to understand how to use other people’s code or not get stuck on a problem in trying to use it. So tell yourself that maybe half the time you will just be looking at other people’s code.
Every programmer has streaks of productive sessions but they also have a lot of slow frustrating phases where they can’t make much progress. It is often these phases that lead to very fast learning. All programmers improve by making mistakes (oftentimes silly) and learning from them. It’s very important to get stuck and find the solution but even more important to learn from the process so you can find the solution faster the next time. Programming is a very failure driven learning domain. Like building muscle strength, you have to fail before you build new skills. Failure in programming is thankfully cheap.
Reading is the most important skill in programming. Unlike other walks of life where sometimes the prose is too verbose and people learn to skim through a large text skipping most trivial details, programming is all about reading the details. Programmers usually don’t like writing documentation so there is a good chance that they have written as little as they could while still conveying everything important. Reading it is the fastest way of getting to know enough about their code to be able to do the most important things using it. I have seen (and been in) countless cases where one gets stuck for the longest time on something that was mentioned in the README. Or a simple example that you could have adapted to your use-case had you read the README! Open source also has a term for it – RTFM (Read the friggin manual).
Again unlike some other professions where your only source of information can be a google search, programming is a lot about using the information already presented to you. Errors are an excellent example of this. We are trained to close any dialog box without even looking at it. In programming, error traces often contain the most important information that you need to find your way through. Let’s say a nil error is thrown. Which line number triggered the exception? If there is an expression over there, is everything defined? Can you print the value of everything and verify it? When programming you need a lot less Google searches than you think. You need a lot more reading than you think.
A lot of error messages are specific to your environment or setup. For example a path to a file you are missing. Googling this will not lead to much and you will have to read the trace anyway to figure out the most important part and google it.
One of the most important tools of the trade is the command line. Sure there are integrated development environments but they only end up confusing people more by making more things look like magic. You are better off using a terminal and understanding how things work. Working knowledge of the file system, exit codes and UNIX tools like grep goes a long way in becoming a better programmer. If you have some free time, instead of whipping out a new web app, you might be better off taking an existing code base and deploying it to a virtual machine on Amazon. Setting up a server can teach you the most amazing things that years of writing code can’t.
The most important thing to keep in mind is that programming is the wrong term for what you are most likely going to do. You are in the business of writing software and that involves understanding customers, understanding the technology, understanding deployment, backups and a host of other things. If you only count time spent on the keyboard writing actual code as programming time, you will always end up feeling very unproductive and in the end, demotivated. Time spent reading, debugging, deploying or isolating a rare bug is an important part of programming. You can’t separate that from writing code.
Level up every day