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?
> 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.
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.
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.
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.
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.
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! ;-)
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.
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.
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)' *
Needless to say, documentation is important.
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.
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.
"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)
(It is not. You had forgotten the leading 'w' and the profanity filter bleeped you. I edited your post to add the w)
Shh, Peter - if you call a programmer a 'hammer', then he/she would probably feel offended.
The World is a strange place.
In Denmark,you cannot be a programmer without being an engineer. It's more or less impossible.
Reason: An engineer is someone who built or made something. Whether he built a gadget that blinks a LED or he just drew the entire thing on paper, he would be an engineer.
I do not know how it is in the rest of the World; it may differ.
But as soon as you've made your first "Hello World!" program, you're no longer only a programmer, but you're suddenly a hybrid programmer+engineer.
So I would say an engineer may not be able to do a single line of code; he could draw the program flow on a piece of paper and let others build the actual program.
Same about bridge-engineers; they usually do not do the hard work; they're just architects.
But there are engineers (in the engine-rooms), who became engineers because they worked with programming, designing circuits or physically built a bridge...
And there are engineers, who are educated to be engineers, who would maybe never even build or design anything; they just have the education and that entitles them to call themselves engineers.
Confused yet ?
View all questions in Embedded forum