In my recent blog posting "The Secrets to Becoming a Great Programmer" I discuss a couple of characteristics of great programmers. You can read about those characteristics at
The Secrets to Becoming a Great Programmer
What other characteristics make a programmer great? Do you agree with my assessment?
Often, when someone needs help, the code I have to find the problem in...
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.
That is a problem that I have seen in the past. I think that sometimes I prefer to generalize or abstract certain concepts. This has been an interesting conversation.
> Personally, I place a comment on the right hand side of each line, whether it's C, C++, ObjC or assembly code.
I practice this in my early days of programming especially when I was starting in assembly language. Soon I encountered authors and programmers (or engineers whichever is preferable) who treat this as a poor or ugly programming practice. They assert that while comments can make a program self-documenting, prudence must be exercised in using them. Excessive or nonessential comments create clutter contradicting their intended purpose of helping a programmer write a more readily comprehensible source code. What they advocate is to place comments on small sections or blocks of code only, with the comment describing the purpose of the whole section. Comment on every line is highly discouraged.
Perhaps , I've already adopted this proposition. Now, I would place inline comments sporadically in an assembly language portion of a program and sparingly in higher-level language.