What Makes a Great Programmer?

Added these on your blog, but I will add them here as well:

I would not want to argue with any of these points, but I think that quite a few can be encapsulated in a specific philosophy:

Write code with the future reader in mind. At some point your code will need maintenance, so someone [which might be your future self] will need to understand what it does. Code should always be written with this requirement in mind.

Added these on your blog, but I will add them here as well:

I would not want to argue with any of these points, but I think that quite a few can be encapsulated in a specific philosophy:

Write code with the future reader in mind. At some point your code will need maintenance, so someone [which might be your future self] will need to understand what it does. Code should always be written with this requirement in mind.

• Has no comments.
• Uses (1 << 17) instead of a readable #define such as 'UART_INT_MASK'
• Is formatted terrible
• And of course like cbeckmann says, has no documentation

Often the bugs/problems with the code is rooted in that the programmer did not read the documentation on how to use the API (or microcontroller) properly.

It might be the most boring thing for anyone that uses a computer, to read documentation/manuals, but taking the easy path usually result in code not being stable.

All these issues are related to documentation (I consider readable code to be an important part of documentation).

Personally, I place a comment on the right hand side of each line, whether it's C, C++, ObjC or assembly code. The comment says what I expect the code to do.

Thus, if the comment does not match the code, the bug is in the code.

These days, most people know about Doxygen; a free Open-Source tool, which is widely used. If you write your comments correctly in the code, you've already got most of the documentation for free.

Other very useful tools are git and gerrit code-review. If you do not know what version control is, you gotta get git and use git from now on.

If you already know what version control is, but you don't have git, I recommend to switch to git from the current system you're using; simply put, because it's stable, secure and rapid - really, really quick. It's well written, it's portable and it's free (and to get back to the wheels I'm so fond of) it's a re-invented wheel by Linus Torvalds (ever heard that name before?).

The OpenOCD team is using git + gerrit code review, and this causes bugs to die before they even enter the code. Jacob, this might be two good tools for you to have a look at (3 including Doxygen, but you probably know Doxygen already).

A good programmer is important, yes, but providing a 'plain' programmer with excellent tools and teaching this programmer to use the tools right, may bring that programmer ahead of the earlier mentioned programmer.

Here we're speaking about staying up-to-date (as both Jacob Beningo and cbeckmann wrote earlier). Sometimes it's a good idea not to stick with the 'good old ways, which have worked for 30 years'...

...If you are a programmer, dare you type this command in your terminal window... ?

$ cd; egrep -Ri '(fixme|hack|unsafe|workaround|guesswork|unsure)' *

jacobbeningo.  Unfortunately, some companies don't understand the difference and outsource to places where wages are very low to the "code monkeys".  For my own company, we found that though wages might seem lower, the overhead to recheck their work is very high.  The code is often non-structured compared to the better trained engineers.