How To Become a Better Programmer by Not Programming

The best programmers are not normal… they are either obsessive compulsive, bipolar, paranoid, or neurotic.

Well, to give you an idea, I program perhaps once every few months. The few times I dive into code, I’m there for a reason. Nine times out of tend, I write the unoptimized version within the first 10% of the time I spend coding. The other 90% is a pretty even split between optimizing the code and tweaking its functionality. I think the reason I never became a hard-core programmer, even though I’ve been told time and time again that I have the chops, is that I simply don’t want to make the compiler and debugger my two best friends (and worst enemies). I’m not a social butterfly by any stretch of the imagination, but I need more social interaction than that…

You either have it or you don’t…

I think there’s a common arrogance among developers that “great programmer” == “thinks like me”.
In one instance I was arguing for a significant abstraction layer between some incoming data and an (informal) datamart we were building on top of it. The incoming data was from several sources and a) was very inconsistent, b) the developers kept making mistakes when trying to glue all the data together so they could use it, and c) I didn’t want to impact all of the downstream apps when the incoming files were modified.
My co-worker wanted very minimal abstraction, because a) more abstraction means more code to maintain and more opportunities for bugs and b) the incoming data only changed 2-3 times a year, and c) most of the people who used the data were familiar with the incoming feeds but wouldn’t have access to the code base, and therefore if we put too much code in between it would be hard for them to differentiate bad incoming data (very common) from bugs in our code (also very common).
For 2-3 days each of us was convinced that the other was at best naive, more likely stupid, and most certainly SUCKED as a developer. But ultimately we were both right – we were just optimizing different aspects of the problem based on our gut feel for where the pain would be in the future.
As a coda, I ended up winning the argument and (as I was debugging and modifying the abstraction layer over the next few years) developing what I call “The Law of Constant Pain”. There is no optimal spot where pain is minimized – all good solutions trade off pros and cons in equal measure, so all good solutions are equally bad and good. Making it better in one aspect makes it (at best) equally worse in another aspect. (And of course there are lots of solutions that are worse all around, but the people who come up with those are the real lousy developers.)

This may be tangential to the topic …

“The main idea of our column is that “talent” is overrated; that practice really does make perfect; and that it’s a good idea to do what you truly love in life, because if you don’t, you probably won’t work hard enough at it to get really good.”

http://www.freakonomics.com/blog/2007/01/08/practice-makes-perfect-revisited/

One more point. If I owned Microsoft I’d want cracker-jack programmers. But if I ran an IS department I’d rather have VB6 developers with business degrees than brilliant computer science grads. This is a bit bigoted, but real life is messy and inelegant. People with an CS background too often seem to get frustrated (or even angry) when their elegant solutions can’t handle the real world. Obviously the real world is at fault in these situations, and therefore it just has to change. People with an IS background seem more willing to tolerate messy solutions if it means the business problem gets solved quickly and correctly.

I know there’s a balance, but it should be tilted towards the activities that earn money for the company, not to some propeller-heads mathematically pure conceptual frameworky things.

Great post, Jeff.

The problem with more of the “people” aspects of software development, is that I believe these skills are very hard to learn or practice.

If it doesn’t come naturally to you, can you practice or learn enough about how to get people to like you and have decent human interactions with them?

With some things you can “fake it til you make it,” but the real issue you’re dealing with in personal dynamics is empathy. If you’re just naturally nihilistic and have no empathy for others, and use them as objects or ends to your means, then no matter how hard you fake it – that will still show through.

And it is a damn shame that more corporations don’t recognize the value of the 99%'s out there. It’s why anyone in that category should seriously consider starting up their own thing with a couple of buddies – it’s the only way you can extract that latent value.

Gates was only saying that programming experience won’t turn one into a good programmer. He never said that programming experience will not make one a better programmer.

i will say that it is not about coding but more about understanding the requirements. if you know the problem then you can solve it, but if you don’t, how can you solve it? think about it. a better programmer is one who understands the problem faster then others.

I used to spend every waking moment in front of the computer also. Then I got tendinitis so bad I almost had to change careers. Now I spend no more then 4 or 5 hours a day at the computer, but I’m still a damn good programmer.

Be careful people.

Interpretation: Compare “programmers” to singer-songwriters. A would-be songwriter can practice on an instrument all day and all night for years, but if they have nothing to say, then? “Passionate” people throw themselves into larger concerns, and out of their experience and personality will have plenty to say as a result. … As one side-effect, programmers will say it through code.

Gates was only saying that programming experience won’t turn one into a good programmer. He never said that programming experience will not make one a better programmer.

That’s right. And what I’m saying is that the skill differential between mediocre and great programmers is so wide and so vast, that the tiny differences between great programmers are barely significant.

Once you’re a great programmer, you’re worth 5, 10, 20 mediocre programmers. See the many data points cited here:

http://www.codinghorror.com/blog/archives/000072.html

Studies have proven time and time again that, statistically, there is NO correlation between years of experience and skill in software development. This isn’t conjecture, this isn’t my opinion, it’s a scientific result supported by experiments and hard data.

Therefore, if you are already a great programmer, and you want to distinguish yourself even further, you should learn complementary disciplines, rather than going for the 99.5th percentile skill level of greatness. Nobody can tell a 99.5th percentile coder from a 98th percentile coder. But they can sure as heck tell the difference between a great coder and a great coder who also understands usability, the business, the customer, etcetera.

In my opinion this is disheartening for beginners,
Someone who does not know anything about programming and wants to learn
you say something like this to them and there goes there desire to learn out the window~~!!!
My comment on this is Not everyone is a great programmer to start They worked diligently at it and if there not so great it’s because someone like you wrote a statement like this and discouraged there desire!

I am, as the original post describes, a “good” programmer, but not a great one.

My algorithms/modules/programs work. They do the job. But, they are neither elegant nor efficient. No matter how much I programmed, no matter how much I studied, my raw ability to problem-solve did not improve. My repertoire of languages improved. My documentation improved. Other things improved. But, not my ability to produce elegant code, nor efficient code.

I’ve recognized this, and thus, when required to produce code, explain to the requestor that the end result will work, but will likely be brute-force rather than elegant, and can always be edited for efficiency.

.

Bravo. Exactly what I’ve been telling fellow developers for years.

“…Competent software developers have already mastered the skill of programming”

Can some one define the programming skill? if there’s such a thing.

Programming is closer to art than any other engineering profession. The range in the solution field is so great that solutions to any problem are as varied as the colors of the rainbow. In fact I’m willing to assert that the reason why there are great programmers and not so great is the same reason why there has been and will only be one Monalisa and one DaVinci.

Well most programmers aren’t in the 90th percentile, so there’s still room for programming improvement. I’m not convinced by this “innate talent” argument. See my response: http://haacked.com/archive/2007/01/30/Better_Programming_By_Programming_Better.aspx

Although I do agree that the “tangential” skills are very important for all levels of developers and most likely will make a developer more valuable faster than improving programming skills.

i wonder why programming is related to art? I taught programming is all about the logic. Good programmer can solve a problem by producing a good logic. from my perspective, coding is more like giving instructions for computer to do this and that.correct me if i’m wrong…

While I think there are “problems” with programmers (http://www.edmblog.com/weblog/2006/11/the_problem_wit.html), I do think that most people don’t want to write code (http://www.edmblog.com/weblog/2007/01/does_everyone_e.html), and could not if they wanted to. The fundamental problem is that programmers and business users have a different perspective (http://www.edmblog.com/weblog/2005/08/different_persp.html)
JT
http://www.edmblog.com

ooops…grammar mistake…“taught” should be “thought”