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?
Hi Jacob,
I was thinking about attention to details, but it kind of overlaps with thorough testing.
When something undesired occurs once, it is quite easy to just re-run and discard the error.
I believe that even if the error was only seen once, it is important to find the root cause as it may hide something bigger...
One of the secrets is how programmers are managed. There is a very funny story by Orson Scott Card (I know, but this was good) on netjeff.com:
"Here's the secret that every successful software company is based on: 'You can domesticate programmers the way beekeepers tame bees. You can't exactly communicate with them, but you can get them to swarm in one place and when they're not looking, you can carry off the honey.'"
The article continues with how businesses fail because of inappropriate changes to team management. Personally I think that one of the strengths at ARM and some other high-tech companies is that almost all the managers are, or were once, very technical and understand how to balance creativity, knowledge, and discipline.
A great programmer wants to be inspired by an even greater programmer, and be admired by other programmers.
A great programmer needs something great to do and the freedom to do it.
I agree with you all the way, except from one thing:
"Do not reinvent the wheel".
If noone reinvented the wheel, Richard Stallman would not be able to get to his office at Microsoft in time.
-Besides, Michelin would also disagree.
I often reinvent the wheel, because the existing wheels are usually shaped like octagons or worse.
Things that are possible with new wheels would not be possible with the old ones.
However... I'd like to also state that you might be able to improve on those wheels that are already invented, so they'll become usable; if that's possible, go for it!
And one more thing for great programmers: Do not continously work on something 24/7, because there is a risk that you will "burn out".
If that happens, it may take up to 3 or 4 years before you can do just a single line of code again - you do not want that to happen.
Each time it happens, it'll take less time for you to get in that state where you can't get out, so please take good care of yourself!
(And frequently visit places that do not even have a computer close by!)
One of the good trade-marks of good programmers from an efficiency point of view is knowing when not to re-invent the wheel. Check out my blog “Buy” versus “Make”: It’s about risk management!. Often times, engineers at the technical level are wanting to create everything when pieces are already available. Sometimes, technical folks can also get in a rut and even if there is ultimately a better way of doing things that would improve their efficiency by 5x, they still hesitate to change their work flow.
That's true too. No need to create a new text-editor; there are plenty available.
But recently, someone wanted to make a piece of software, that could flash-program via JTAG.
Someone told this person to not re-invent the wheel, but instead use OpenOCD.
While OpenOCD is really, really good (especially after the recent big-endian fixes, so now even I can use it), it uses around 2.7MB space.
A new lightweight application would perhaps be able to fit inside an ARM microcontroller, thus making the entire JTAG-programming experience new. You would no longer have to compile sources for two hours in order to get a working version for your own platform.
OpenOCD *could* do that, but only if the microcontroller it should run on has a huge amount of memory.
In my opinion, re-inventing the wheel has to do with bringing people more options, plus making things possible that are not yet possible with any existing 'wheels'.
Still, as you say, if an existing tool can be used, it would (probably) be waste of time and energy building a new tool with the same capabilities.
Thanks for the comments! My reference to "not reinventing the wheel" was meant as mentioned that a programmer needs to be aware of what is going on in the industry and if they can leverage someone else's work such as a 3rd party component, etc to get the job done then they do. I've seen many times when programmers rewrite a common from scratch themselves, fight with it, introduce horrible bugs into their system when they could have simply bought an inexpensive piece of software that did the same thing but had already been tested and validated. It goes in line with the "Not Invented Here Syndrome" that some programmers have where if they didn't write it then the code is unacceptable.
Thanks for the additional insights and the comments greatly benefit the community!
I hope that the ARM CC will serve as a place for brainshare for programming ARM, so that engineers can build on each other rather than re-discovery everything from scratch.
I'm slightly disappointed in that again there is an implied relationship between programming and software engineering. What makes a Great Software Engineer is quite a different proposition to what makes a good programmer.
Niall, I love your point and would like to hear more what you think the difference is. This brings out small nuances that has implications to how a project is done.
Hi Peter,
Thanks you beat me to it (and much more eloquently than I'd put it!)
In my mind programming is just a tool - an important one, but only part of the whole story. An engineer being a "good programmer" is like a carpenter saying he is "good with hammers" - it's an incomplete skill set by itself. Being a good engineer is about much more than just grinding out lines of code, and generally needs a skill set which is well versed in the whole code carpentry workshop. This may range from the technical - writing specs, knowing how to design and test system - to the more soft-skills - communication, ability to review, project planning, task estimation, and balancing the technical and business needs. All are vital to the successful delivery of any project with more than a handful of engineers ...
Indeed - guilty of over simplification for the sake of making a point .
> you cannot be a programmer without being an engineer
Yes that was really the point I was trying to get across. There is a lot more to "being a programmer" than "programming" so I dislike the name. Personally I find writing code - the act most traditionally called programming by many - a little tedious. By that time I've done the fun part - the design, understanding the system, etc. You do find some people who only want to write code, and who actively avoid most of the other parts, but they are few and far between - most people are multi-disciplinary.
At the other end of the spectrum I work with very good software engineers who no longer write much code at all; they have other expertise be that designing and writing specs, running QA teams, etc. Understanding software code is key to the job, but writing it isn't.
In that case, I would say before one can become a great software engineer, they need to go through the drudgery of programming. Just because someone can code does not make a good system in the end. It still needs a good system architect to make good manageable, efficient, and maintainable codes.
Indeed, and a lot of discipline!
Becoming a good programmer or software engineer isn't done overnight. Often this takes years and in some cases (like mine) decades...
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 ?