I've hired and worked with hundreds of programmers, most good. The observations in the post are all true, but another correlate I've seen is patience: willingness to slog through difficult, boring work to achieve a great outcome.
All of the very best programmers I know work incredibly hard and never allow a massive boring task to derail them. It's an interesting combination of confidence ("I can solve this insanely hard problem") and humility ("I am not above doing this crappy work").
Sometimes the solution is to automate the boring stuff; other times it's literally just getting through days of grunt work. The very best programmers I know are willing to do both, and know when to do which.
Am I the only one who feels like commentary that categorizes "good" and "bad" programmers is unhelpful? One can make a good case for somebody having more appreciable traits than another, but I would be loathe to call either "good" or "bad", even in comparison to each other. This kind of labeling is just namecalling, more harmful than helpful, a stroking of egos.
The reality is that different people have varying strengths and weaknesses for specific tasks; people have different rates of personal development in different areas. It is not a matter of "good programmer" vs "bad programmer"; it is a matter of "That person can do that task in a better way than I can" or "That person can do that task more efficiently than I can" by some perceived measure of "better" and "efficient". The comparisons between people are relative, not absolute, and divided across many kinds of traits.
However, this article does bring up a number of traits that many of us can probably agree with as "goals to achieve in personal development". For that, it has great conversation value. Personally, I like the notion that memory might be correlated to some quality of design and output.
If I were to pick a trait of importance for a programmer, it would be "Consistently improves bottom line growth." Things that factor into that might be "Writes maintainable code" and "Knows his tools well", but it is debatable that these subtraits have a clear correlation with "bottom line growth". Has anyone actually measured these things?
I know one programmer who I would call great.
Here's what I've observed from him so far:
1-A serious amount of fucks are given both via attention to detail, polish, and no corners are cut. I have been lazy comparatively and often accepted "good enough." I'm working on changing this so that my priority is what is awesome for the user, not easiest for me to implement.
2-At the micro level, before setting out with any new technology, he tests its properties thoroughly. For example, benchmarking each part of the setup on its most intensive tasks before building with it. No "assuming it will work" based on breathless blog posts. Using his intuitive sense of what is expensive, he also optimizes expensive operations in loops by hand (like mysql complex queries).
3-A well thought out, and well practiced tool-chain for development. Ex: Using vim and knows it well, pays for tools to make life easier, has easy backups with time machine to easily go back, etc.
4-Diverse range of skill, and eagerness to dive into something new at any point.
5-An ability to rapidly debug problems. I haven't pieced together how this skill is built, except it involves the usual logic combined with a better memory than mine (so remembering what to rule out) and a pattern recognition that comes from remembering similar problems.
Point 2 is something I've heard Jeff Dean strongly suggest. Write microbenchmarks for all the basic operations of the "black boxes" you'll be using to build the system. That way, you can do quick back-of-the-envelope calculations to estimate the performance of the system before actually building it. You can explore the problem space much more quickly when you can simulate the important characteristics in your head instead of having to actually type them out into an editor.
Point 5 is something my former manager once told me. He'd done RoboGames or something like that as a grad student, and he found that invariably, the teams that won were the ones who had built the best debugging infrastructure into their robot, so that when it didn't behave as expected, they knew exactly what was wrong.
This is as much a property of the program as of the programmer. The best programs usually have debug information built into the structure of the program itself, along with an easy UI for viewing that debug info so you don't have to stare at log lines all day. Once a couple programmers start doing this and everyone else realizes how much time it saves, it becomes part of the culture of the organization, and everybody starts designing programs with an eye toward "Will I be able to figure out what's wrong if this doesn't work?"
The closest open-source example I can think of is --verbose mode on many UNIX utilities, though that wasn't really what I had in mind. Developer Tools in Chrome is another example of the principle - think of how much easier it is to debug Chrome than IE6 - but again, not quite all the way. Imagine using Developer Tools to debug all of Chrome, eg. Webkit rendering (overlaid on the rendered page itself), resource parsing & scheduling, JS JIT compilation, etc, and not just the pages that execute within it. (Maybe this is possible, I'm not familiar enough with the Chrome project to know all the debug flags available.)
I certainly don't claim I'm a great programmer, but I can attribute a lot of my career success to focus on and learn to improve #5. I got the itch to improve it because the greatest programmer I know is a true master of rapidly debugging problems, and great at un-sticking projects when no one else can/will.
On point 5, thing is as a programmer (any career actually) with years of code experience, you just know the possible cause for any bug, and what function/class is at fault.
To elaborate, debugging is basically "applied memory recall". When you see a symptom, what happens is that you start guessing how it could have manifested. Sheer experience basically gives you better guesses.
I've been able to debug more effectively than my coding skill level would imply by dint of my better recall ability.
True but you can't just apply 1 and 2 to every problem and expect to meet deadlines. Part of the skill is to know instinctively how much polishing is enough.
I've found that just about everybody, myself included, thinks they're at least a good, if not great programmer. Obviously a lot of us are wrong!
I tend to think that being great can be a relative term as well. There's different needs. A great programmer who is a genius at coming up with innovations can't always focus to actually get any real work done. A programmer who isn't very creative may plow through tasks like a steamroller. One may be great at intuitive designs, another is great at hard-core algorithms. Which one is the greatest? Depends on what job they're supposed to be doing. Of course a terrible programmer can wreck any of these scenarios.
You're spot on about different needs. I used to work for a guy who was a genius at managing programmers and providing an environment for them to thrive (at least he did that for me). He once told me that for an innovative multi-year software project, he needed a small team of really good programmers to spend several years building and refining the core system (on R&D dollars). Then, several years down the road when the contract dollars started coming in, he'd need a much bigger group of average programmers to handle all the humdrum tasks of moving the right bits to the right places, supporting the right formats and protocols, etc. He understood that the average programmers wouldn't be capable of the former, and the great programmers wouldn't enjoy the latter. It was a significant realization for me.
The only way you can be a great programmer in a meaningful sense is by putting in your best effort every single time you do some programming work, always looking out for ways to improve your work and always looking for feedback from other people, basically cultivating a "beginners mind". Once you start thinking of yourself as a great programmer, you start paying less attention to what you are actually doing and start being over-confident in your decisions on the ground of your "greatness" and it is very easy to delude yourself - I know from my own experience. Being great is not a permanent trait you have to gain and will from that moment keep on having forever.
In other words, there really are no great programmers, there is only great programming.
I actually agree to some degree. Though it could definitely said that it's easier(less time & struggle) for some to create great programs than it is for others.
My entire life as a programmer has been about consistent and constant improvement. A little bit of improvement every day, every project. Committing to the craft(reading, exploring new langs/tools) will definitely allow you to create better and better code as the years go by.
"being capable of quickly shifting registers from the large picture to small details and back again — relies on the strong memory"
Something like that, yes. Just huge memory and fast processor. And unfortunatelly it is just talent, after 10-15 years in the profession you will see your limits: your programing skills can be developed further and further to be very good, but it cannot be developed to be really great. I am a good programmer, but not a great one. When I was young, I thought I am great (winning some small math competitions when I was a child helped to develop this false belief), but now I know I am just good: I don't have that incredible brain power (memory + speed).
But I am not depressed: being good is also fun, and anyway programming is not my identity: my identity is more a combination of software product design + programming.
I would agree that greatness in part depends on a certain innate talent, and most of us, no matter how hard we may try, will never get there.
I think the difference between his categorization of "Good programmers" and its subcategory of "Really good programmers" is the more interesting one though. Too many programmers seem to lack (or have lost) that drive to continually improve themselves, having become content with treating programming as nothing more than a 9-to-5 job during which they do little more than apply past knowledge. Like the article states, doing this puts them "at risk of slipping into the lower grouping by letting their skills atrophy".
The "Really good programmers" on the other hand are the ones with drive, with motivation; the ones that at least aspire for greatness even if they might stall out at merely being "very good". Every great programmer was once just a "Really good programmer", but you can't go from good to great without that passion.
I'm on board with this statement. I've realized for quite awhile that there are some guys who are just on another level in terms of sheer ability. Sadly I am not one of them.
I've run across a fair number of the 9-5 guys who used to be really good/good & use that as motivation to never allow it to happen to me. Always gotta push forward.
Because you have more control over your hobbies. At the end of the day, the success of your career is (at least in part) dependant on luck and the decisions of others.
I think most people are more likely to work at a job they dislike and spend their weekends on their own endeavors than the other way around, that's all.
I would phrase it slightly differently. I would phrase it as "able to consider multiple levels of abstraction simultaneously".
When I see code execute I almost unconsciously understand what the code is doing at a procedural and sometimes assembly level, as well as what it is doing at an architectural level. It's the skill you need if you are going to work on intentionally undocumented code. It means when I encounter a bug, I know what construct I'm looking for: "ah, yes, there it is." When I architect something it is as simple as it needs to be to do the right thing and I don't have to put any extra effort in to have it communicate meaning through structure.
My challenge is to provide guide posts to other programmers coming later to help them swap between those levels, because I don't need them myself, or do what I do now and work with other people who's minds also work this way.
If I come back to code I wrote five years ago I still grasp exactly what is going on, and the chances are pretty good I remember the exact code.
I'm still not one of the greatest programmers I know, though. Those can both simultaneously consider multiple levels of abstraction and leave that aside to consider tiny pieces. I can sit down and carve away marble to leave a program; they can sit down and merge tiny chips of marble into something that looks exactly like I would have created out of whole cloth.
For them, unit testing is easy. For me it is challenging and a necessary chore.
On the other hand, at least 40% of my job doesn't benefit from this, mostly because of missing tools. Moving into CMake was fantastic, because finally I could apply the same approach to release engineering I applied to writing code. There are definitely roles for which this is massive overkill, and lots of people who work this way spend all their time building tools to support it rather than producing software used by consumers.
> The other group, the reckless, consists of those who have the skills but don't have the discipline. They are the cowboy programmers of yore. They code according to their own desires, do nothing to integrate their work with that of others, scrimp on basic discipline, and cause work for other team members.
It is worthwhile to note that Steve, Linus, Feynmann (last one in physics, not coding) all belong to this category. These are the people who do programming (or whatever else they like) for their own pleasure - to derive fun out of. They are unafraid to challenge the status quo - and they are exactly the ones who cause disruptive changes in the world.
If at all, the slowness with which their reputation is dying makes me happy - because though they are capable of having highest success rate in creating start ups, unfortunately not all of them will succeed in building their own company. And it will be a sad world if these people are not allowed in established companies to make the changes that can swing the world in the organization's favor.
I've never understood the hate for cowboy coders. A great cowboy coder can do the work of an entire team. It's so typical for people to cry that the cowboy causes work for others, but I've never seen it myself, and I expect the great many who claim it are just following the group-think they've had drilled into their heads.
If you inherit a program from some other maintainer, there is a learning curve no matter what. A good programmer quickly learns how it's put together and plays the field they're on.
The problem is when your cowboy coder leaves your company, you are fucked. The code is undocumented, and incomprehensible. It works but you have no idea how it works and neither does anybody else.
You are using "cowboy coder" dramatically different than thr Dr. Dobbs article. He's talking about the kind of person who leaves bits of their shopping list in a comment in the source code.
I think a good memory is important as is a broad knowledge of their tool-set, but how did they get that way? I think curiousity is probably a programmer's biggest asset ... the desire "to know".
It's important, but I don't think it's crucial. I've seen a couple programmers that are really good that do not have good memories. They always have apis and cheat sheets open in their browsers they are constantly referencing, along with frequent searches on google.
Yeah, memory is important. It's easy to hack, though. The techniques are called mnemonics. Learn and practice a bunch of these, pick a few that work well for you. Eventually they will be very natural to you.
True. To clarify, I was just simplifying by calling my memory poor. I just have an attention deficit. So technically, I'm never committing to memory in the first place!
I think what's really interesting here is not what makes a good or great programmer but rather how everybody has different criteria for "greatness". I found this thread more enlightening about the commenters than about greatness.
This isn't that surprising: different people do different things, and their ideal programmer is relative to what they do. Somebody more business oriented would value more maintainable software and good team-working; a hacker type would value "getting things done" and "worse is better"; a more academic type would value novel and nontrivial work. Of course, in reality, what different people value is more nuanced, but the core point remains: there is no single definition of greatness.
Interestingly, there is some research to support the idea that ability to learn programming is a bimodal distribution. One interpretation of this was that people fall into three basic categories: those who cannot do the reasoning, those who can, but find it very unpleasant, and those who do it with some ease. Presumably most professional programmers would fall into the third category, but if there were some in the second category, that could perturb the distribution.
Bad programmers I've dealt with tend to share certain traits:
- Their code is large, messy and bug-laden
- They have very superficial knowledge of their problem domain and their tools
- Their code has a lot of copy and paste, and they have very little interest in techniques that reduce it
- They fail to account for edge cases while inefficiently dealing with the general case
- They're always rushing around putting out fires, trying to look like heroes battling vast problems against impossible odds
- They never have time to comment their code or break it into smaller pieces
- Empirical evidence plays no role in their decisions
It would be hard to self-test, but some clues would be: do you think you're the best programmer in the world? Do you find code with a lot of functions messier and harder to understand than code with only a few large functions? Do you routinely copy code from one place to another and make a few small changes to it? Do your programs tend to be a few huge files or lots of small files? When you're asked to make a change, do you usually have to touch most of the code or just a small chunk of it? If you say 'yes' to most of these, you're probably bad. If not, you're probably alright. :)
Another clue is to go read the CodeSOD articles at The Daily WTF[1]. If you find them funny or horrifying, you're probably alright. If you don't understand what makes them terrible, you're probably bad.
It's really hard to know how competent you are in any field, if you are incompetent.
There are known knowns, known unknowns, and unknown unknowns. The problem with really bad programmers, is that the unknown unknowns for them are really large... so they have no ability to gauge just how incompetent they are.
On the contrary,when you get better at coding, just like mathematics,whe you compare your codes with others programmers and are comfortable with the similar code patterns and habits, thats one of the indications that you're becoming a great programmer, just like mathematics.
Ayn Rand's opinion on genius was similar. She said that what was unique to genius was the ability to very easily shift between different levels of abstraction.
I would not refer to this as "memory", but as understanding. Memory is of course involved in understanding, but it is not sufficient for it, and does not by itself enable the ability to shift.
One of the great things about working in software is that if you want to work at the frontier and push the limits of what has been done before, you still can. Your peers may deride you as a "cowboy programmer", but they can't stop you.
Many other fields have been so heavily regulated by government that truly pushing the boundaries is either far more painful or impossible, therefore the pace of improvement in them is far slower than it is in the world of software.
All of the very best programmers I know work incredibly hard and never allow a massive boring task to derail them. It's an interesting combination of confidence ("I can solve this insanely hard problem") and humility ("I am not above doing this crappy work").
Sometimes the solution is to automate the boring stuff; other times it's literally just getting through days of grunt work. The very best programmers I know are willing to do both, and know when to do which.