A recent pair of articles from Dr. Dobbs reminded me of a famous line from Anna Karenina:
All happy families are alike, but each unhappy family is unhappy in its own way.
Paul Johnson argues that Tolstoy had it backward, that there is more variety in happy families. He argues that there are “obvious, recurring patterns in unhappy families” such as drunkenness and adultery. In any case, back to programming.
Are unhappy programmers all alike? Or happy programmers?
Andrew Binstock wrote a pair of articles asking what makes great programmers different and what makes bad programmers different.
As for great programmers, Binstock says they have wide knowledge and good judgment of how to apply that knowledge. True, but not unique to programming.
But he also says great programmers have the ability to quickly switch between levels of abstraction. Such a skill could be useful in other professions, but it’s particularly useful in programming because software development requires knowledge of many different levels of abstraction. For example, data ranges from bits to terabytes, each with its own level of abstraction. Not many professions regularly have to think about phenomena at multiple resolutions ranging over 12 orders of magnitude.
As for bad programmers, Binstock lists a number of common traits but boils it down to this: “In my experience, at the core of bad programming is invariably a lack of curiosity.” I’d agree that a lack of curiosity explains a lot, but it leaves a great deal of unexplained diversity in bad programming.
Rightly so, we can deduce that there is no possibility for cat’s to be good programmers, for they will die.
Lack of curiosity is certainly a cause for bad programming or bad anything. Lack of curiosity about oneself, or the inability/unwillingness to introspect, probably has more to do with it than the lack of curiosity about programming. Then again, the incurious tend to be so about most things.
The tribalism of “I am a programmer” and “My language/platform rocks; yours sucks” also contributes. But isn’t that just lack of curiosity defended by intentional confirmation bias? “I don’t want to know that there are things that I don’t know”.
We live in a world that likes to play “sucks ‘n rocks”. Black and white. Winner loser. The curious revel in shades of grey. And they write better code.
so curiosity killed a great programmer… a cat XD.
DanS: Here’s a post I wrote about why programmers tend to get into these sucks/rocks arguments: Ford-Chevy arguments in tech.
This tribalism isn’t limited to programming either, though programmers aren’t very good at disguising it. Professional scientists, for example, get into the same sort of arguments, though they cover their childishness with more sophisticated language. But peel back the rhetoric, and they’re still saying my tribe rocks and your tribe sucks.
This. In my experience, the abstraction issue is harder to deal with.
Lack of curiosity will guarantee someone is a bad programmer, or at least not a good one for very long. A good programmer can adapt and learn new tools. Which is why the fact that so many computer scientists come out of school with zero knowledge of anything other than Java. If they had no hobby projects or things they tinker with outside of the classroom, I’m not interested in hiring them.
But honestly, a lot of bad programming comes from lack of basic algebra, and poor ability to deal with abstraction. And good programmers, at some level, need to be haughty and/or lazy — to look at a repetitive task and say “there’s got to be a better way! This work ought to be done by a machine. Let me write something up.” If they don’t have that attitude, they’re not going to be any good.
I don’t think the post was about bad programmers just unhappy ones.
Things that are guaranteed to make me unhappy (and possibly others/majority):
1) Highly unstable or no set goal for a program. I have had and currently have projects where the manager just shows up every couple of weeks and asks for new stuff. No real clear direction of where the product is going, what the goal of it is to accomplish just one off feature requests every couple of weeks.
2) Dictating languages for no other reason than that that is what the manager knows (even if they don’t code themselves anymore). Example building a completely independent little tool. Manager says “thou shalt write this in ruby”, even though I’m not a fan or good with ruby and could bang it out in a half hour in C rather than spend 2 days looking through ruby forums to figure things out for code only I will see.
3) Lack of appreciation for how hard our job/tasks are sometimes. They guys walking into your office with pie in the sky ideas of how you are going to get data from 5 different databases and flat files on 3 OSs, that is unstructured user entered data with perfect accurancy into a web based plotting tool in 30 minutes just in time for his meeting at 2pm.
4) Making you do 3) and then not using the software but instead asking you to run it everytime.
Ursula LeGuin has an excellent reply to Tolstoy’s statement as well in her “All Happy Families,” in the collection The Wave in the Mind:
“The falseness of Tolstoy’s famous sentence is nowhere shown more clearly than in Tolstoy’s novels, including the one it’s the first sentence of. Dolly’s family, which is the unhappy one we are promised, is in my opinion a moderately, that is to say a realistically happy one…In the greater novel, the Rostovs when we meet them might well be described as a happy family…But the Rostovs are not ‘like’ anybody; they are idiosyncratic, unpredictable, incomparable…
“Tolstoy knew what happiness is–how rare, how imperilled, how hard-won…Why he denied his knowledge in the famous sentence, I don’t know. He did a good deal of lying and denying, perhaps more than many lesser novelists do. He had more to lie about; and his cruel theoretical Christianity led him into all kinds of denials of what in his fiction he saw and showed to be true.” (36-7).
Where’s developers who are curious about everything and can not produce?
@Acaz
Yep run into those occasionally. Don’t have to work with them usually though. I’m usually the only, or at least the only production quality, dev at my work (academia healthcare setting). I really don’t care too much how incompetent Matlab goons are their tools already speak for themselves. They code for months and then go oh no the program is slow as hell, I have know idea how the algorithms work behind the function calls so can’t tell you if I’m doing something dumb, can’t figure out how to make it a standalone app, need to buy something to get it into a web accessible fashion etc.
There curiosity often extends only as far as the tools they already know they’ll read documentation to try to find the R/Matlab/whatever function call that will solve their current problem but learning how to code something deeper than “if (object = ball) plot(object) end” they aren’t interested in. How to render things better to the screen, how to write algorithms and understanding how to solve their problem themselves not spend 10X more time find the tool they need and writing the one line and if it looks right stop thinking before you actually have to understand what is going on etc.
The big pet peeve I have experienced with truly IT/dev technical people not domain workers that happen to code is the IT guy having no clue how to program or the programmer that has no idea how to set up a svn repository or diagnose a common computer problem (like wifi connection issues). Usually what happens there is the IT guy either:
a) lives with a problem for years not realizing 20 lines of a shell script will automate 30min of work a day.
b) Just accepting crappy software as the best that can be done. I’ve literally told vendors “It looks like you are using this vendors controls, why are you doing things this way it sucks. These other guys use the same controls and suck less.”
c) The flip side: assuming anything you can dream up to put on a screen is equally easy. Why doesn’t Win Server know when I’m installing it that “obviously” I want a SQL Server box so my swap should be x, these things installed etc. No concept of how giving a lot of options on one screen actually makes things hard to find, confusing/scary for new users etc. Essentially no sense of style or usability psychology.
For devs lacking curiousity with IT it usually means you get requests to build up things (can we get a cassandra cluster, and oh yeah I want all the config into a git repository with automatic pushes) but know interest in how it works. They just want to find an example somewhere on the web and add a line of code that says (cassandra-cluster get where tag = “ball”) (or whatever the syntax is) and have a magic cluster in the background that just happens to be perfect for their data use pattern etc without having to describe the problem to anyone (or even think it through themselves before making the request) and absolutely no clue how to tell if something is wrong unless it throws a compiler/runtime error.
Unhappy programmers are stuck on boring projects.
Happy programmers dig for the challenge in every project, and don’t stop until they find it. Or, as my boss would say, until they create it. I think that may apply to me.
Curiosity is part of that, but I think there’s something deeper, a need to be more than utilitarian, to seek to innovate, at least a little, in every project. Even if the project is yet another reinvention of the wheel. Perhaps it is a need to stretch and grow, more than mere curiosity. Or to find something to be curious about.
I’ve found myself volunteering to join hopelessly stuck, delayed and over-budget projects. Not as a savior (I’m an average programmer, and no kind of a leader or manager), and not as a masochist, but more as, well, a volunteer. I like to help.
More than that, I like to learn. If 30 years of programming has taught me anything, it is that I learn massively more from failure than I do from success. So, in a sense, joining a project full of unhappy programmers is often a learning opportunity!
What constitutes bad programming?
@human mathematics
I’d say anything that is not maintainable as a first approximation. Unless you are really really sure that it is a one off thing that will be used but never looked at again (say a shell script to move log files to a “backup” folder). Which implies bad programming would be anything like:
1) Poorly structured: one big function that does everything under the sun ie the typical “Go” button on a form followed by every single thing your program does in the event handler, er nicht gute.
2) Obscure for no reason. Sure maybe you can get the job done with a double linked list of pointers written in C that points to wrapper functions written in OCaml but what is the likelihood that the next person looking at it will know C well enough to get the double linked list and happen to know OCaml too?
3) Intent not obvious from the code or comments. One line functions named “GetEmployees” with a statement like: return Data.Employees; is fine anything more complicated needs its intent spelled out in the comments. That way if something odd happens 2 years later on a different version of the OS someone can say: hey yeah that isn’t working as intended and try to fix it.
I’m sure there are more but that is a start at least.
@Mike
I agree with your points, but I think you missed an important one:
0) Incorrect. The results of executing the program are not what it claims they are. Maybe this means that the backup misses some files, maybe it means that the computed matrix inverse has sign errors, etc.
This extends onto your #3 as well:
3.5) Correctness not obvious from the code or comments.
That’s the thing about people who think they hate computers. What they really hate is lousy programmers.