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?
(It is not. You had forgotten the leading 'w' and the profanity filter bleeped you. I edited your post to add the w)
"is 'who' always replaced by '**' ?"
(This is now corrected, thanks Alban. I found out now that I get the ability to edit the posts, when going to the article page; those are not available from the overview in the streams)
Lovely discussion!
It's so important to recognise that what makes a good programmer and what makes a good software engineer are very different. I know individuals who are incredibly talented programmers but just don't get the "engineering" thing at all; conversely, I know excellent engineers who can't write code for toffee (hope that's not too UK-centric a phrase but I'm sure you can work out what it means!)
A really good "software engineer" combines both.
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.
Needless to say, documentation is important.
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.
I was looking at the cups being given out at ARM in China, and it occurred to me what I am missing, I had it years ago but it vanished mysteriously. What I really need to be a compleat ARM programmer is my
ARM POWERED TM
mug to drink my coffee from! ;-)
Agree. We should not just want to discard or quickly patch errors and don't exert effort to find the root cause of a problem, it's like replacing a blown fuse without investigating the cause of overload.
For: "Do not reinvent the wheel" and all replies.
My interest in RISC started in mid- to late 1990s. For me then, RISC is "reinventing the mill." Several implementations of the concept succumbed to technical, commercial, political, and other sorts of obstacles but the surviving architectures (with ARM not just surviving but highly successful) brought us new, previously inconceivable devices and a way of refining good old things. We should be grateful to all those who did not accept the status quo.
When I was a teenager and up in my 20s, I do electronics and programming like "I'll sleep when I'm dead." After reading books and articles in physiology and listening to medical practitioners, I adjusted. I agree with your last paragraph. Having adequate rest is not just good for our health it makes us more efficient and productive at work.
There may be places in the world where someone could be a de facto engineer. Attainment of the title or status could be based primarily on one's skill in "building or designing something." How technically meritorious "something" needs to be depends on the norms of that particular society.
In some parts of the world there are legal definitions of being an engineer. It will require a college diploma and depending on the jurisdiction, a licensure exam. In some cases the competence to build or design "anything" does not matter.
> 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.