What makes a good programmer?

In order to actually succeed as a programmer, you actually need 3 traits:

  • Patience
  • Eye for detail
  • Being communicable


In reality, you will get stuck a lot, especially in the beginning. I will give tips on how to get stuck less frequently and when you do, how to get back on track faster. It is inevitable, that you will have situations where everything "should work", but doesn't. You might be stuck on problems for days or even weeks. That is the reality of being a programmer. It is not because you're bad, it is because there are a lot of moving parts to take care of and mainly - you are going to work with code others have written.

Eye for detail

You think a misplaced comma is a programmer joke? It isn't. One small mistake hidden somewhere can, in fact, crash a system. There are tools and techniques that help you with finding problems like this, but it is also inevitable. In programming "myProgram" and "MyProgram" may have two entirely different meanings. Everything has to be precise for the program to run smoothly.

Being communicable

"What? But I thought i'm going to give instructions to the computer, not humans!?"

Of course, but you will work alongside other humans, you will be taught by other humans and you will participate in code reviews with other humans, where other humans will look at your code, then at you, then at your code again. Then they will ask questions as to why do you think your code is the way it is. It is very important to be able to speak your thoughts clearly, to explain why you think your code will work the way you intend it to. It is also very important to ask questions when you are stuck. Do not even imagine that sitting and staring at your screen will magically solve the problem. You are a problem solver, so solve it. If you can't, you can ask for input from your colleagues or the internet.

One fun exercise is to have a toy on your desk and you ask it the questions you have. You might come up with an answer while vocalizing your problem. It is called "Rubber duck debugging", because the origin of this is when someone explained the problem to a rubber duck and came up with an answer to their problem.

As Wikipedia states: "Many programmers have had the experience of explaining a problem to someone else, possibly even to someone who knows nothing about programming, and then hitting upon the solution in the process of explaining the problem."

I myself have written questions to colleagues, only before hitting "Enter" I realize, that the answer is hidden in the question itself.