The Requisite Mindset For Becoming a Great Programmer

Over the last ten years, I have had the fortune of working with some great programmers. I have also had the privilege of helping some people learn programming or get better at it. I have come to understand that the most difficult thing to grasp when learning to code isn’t programming languages or tools. It’s understanding and embracing the programming mindset. What’s that mindset? Well, it’s a few things -

Programming is mostly about using other people’s code or services

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, don’t expect anyone else to fix the problem. You’ll have to jump in and fix it yourself. Once you fix it, you can contribute back the code (and tests!) and earn some karma.

You have to accept this dynamic and make it a part of your workflow. New programmers often find themselves spending a lot of time trying to understand other people’s code and getting frustrated. Save yourself some frustration by telling yourself upfront that almost half of your time you will just be looking at other people’s code.

You’ll get stuck a lot — Learn from it

Let’s talk again about feeling stuck! Every programmer has streaks of pure productivity 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 a lot of learning. All programmers improve by making mistakes, often times silly.

It’s important to pay attention to your approach during these slow phases. If you learn to enjoy these phases and get better at debugging, you’ll have a lot of good days as a programmer. Again, it helps to have the right expectations when you start — getting stuck is inevitable so don’t let it get to you. Taking breaks and stepping away from the problem are often much more useful than banging your fist on the desk :)

Learn to slow down and read patiently

Most of us have learnt to skim through long text, skipping unimportant details. We have to — there is just too much to read out there! Unfortunately, programming is all about reading the details. Programmers don’t like writing documentation so most READMEs and docs are already to the point. I have rarely come across fluffy docs for open source projects. Reading them thoroughly is the fastest way of getting to know enough about their code.

I have experienced countless programming sessions 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 has a term for it — RTFM (Read the friggin manual)!

Resisting the temptation to Google too soon

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? When programming you need a lot less Google searches than you think and you need a lot more reading than you think.

You can’t even Google most errors

A lot of errors 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.

Another problem with searching for solutions is that most of the libraries are being constantly updated and a lot of answers are already out-dated. Unless you have read the reference material, you have no way of knowing if the solution even applies to you!

Getting comfortable with the terminal

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. A knowledge of the file system, exit codes and unix tools like grep go a long way in becoming a good programmer. Spend time exploring and customizing your tools.

Love Devops

If you have some free time, instead of whipping out a new web app, you are better off taking an existing code base and deploying it to a virtual machine on Amazon/Digital Ocean. Heroku is nice but setting up a server can teach you a lot. It helps you understand the big picture — DNS, proxies, security etc.

Embrace that programming is not just about banging out code

The most important thing to keep in mind is that programming is a wrong term for what you are 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 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.

Finally, have fun. Don’t take it (or anything else really) too seriously!

Originally published at blog.prateekdayal.net and edited for clarity. I also added a couple of new sections. If you liked this, checkout SupportBee