One of the great things about pair programming is getting to see how somebody else approaches a problem. One can learn a lot by observing another programmer's thought process. For example, the first day of working with Mat, I learned that some programmers use something called a 'debugger' to troubleshoot problems in their code.
Jokes aside, I think every programmer should take every pairing opportunity they get. This article is about a realization I had while pair programming with Daniel Haran on the way to RubyFringe.
Evidently, not everybody is quite as hard on their delete key as I am.
Always Delete
At one point during the train ride, Daniel looked at me, and said, "Wow — we're deleting more code than we're keeping!" To which I responded, "Yeah, of course we are. Don't you always?"
This illustrates one of my strategies for writing great code. Trying to get it right the first time is futile. So, I stopped trying.
I'd much rather get it out of my brain, and in to my editor, no matter how crude; see my tests go green, and refactor it immediately. Mostly, that means deleting the entire implementation, and starting from scratch. Let me tell you why.
Speculating Sucks
Trying to perfect an implementation in one's mind is a form of speculation. It is extremely difficult to judge the readability of something you cannot read, or the performance of something you cannot run. Such a judgement may be possible in some cases, but it will never be a replacement for actually seeing, reading, or running the code.
A good portion of the time, the solution that seems crude in my mind turns out to be perfectly adequate once I see it in my editor. Sometimes, it's even fairly elegant. When my first try sucks, refactoring leads me to the right solution far more quickly than speculating ever could. This is because identifying problems in my initial implementation is so much easier when I can actually see, and manipulate it.
A great programmer certainly has a better sense for which solutions are going to be more readable. That programmer will usually get closer on the first try. But, in my experience, the very best programmers are the fastest at trying out several different solutions and choosing between them, or quickly iterating on one, until it's perfect.
Exponential Productivity
The elegant implementation you see when you read a great programmer's code is often the third or fourth try. The great programmer is often more effective because they can implement several solutions in the same amount of time it takes the average programmer to implement one.
All the while, they are improving their base of experience by having real interactions with many real solutions to the same problem. That allows them to arrive at a better solution to the problem next time. That, I believe, is one of the reasons programmer productivity is exponential.
Conclusions
Since I started working with highly productive languages like Python and Ruby, I have come to believe that code should be disposable. The easier it is to refactor, or even rewrite (a form of refactoring), the better. That's one of the reasons I am a proponent of dense languages. Anything that can't be easily refactored due to its size is a major liability.
It seems pretty clear to me that programming is best learned through doing. That's why so many philosophy graduates, and jazz musicians are better programmers than unmotivated kids with software engineering degrees. Writing code is a lot more valuable than thinking about code.
The faster you can write, and evaluate code, the faster you can get better, which accelerates your ability to write and evaluate code. That's exponential growth.
Ok, I'm not gonna respond to the debugger diss, aside from this self-referential sentence :-)
Instead let me suggest an interview that would probably be of interest to you. It's one of the very few podcast episodes that I considered to be an instant classic as soon as I listened to it.
The interview is with Ward Cunningham, inventor of the Wiki and one of the inventors of extreme programming. In the interview they talk about concepts such as doing the simplest possible thing that can possibly work, and then improving on it by refactoring when necessary. I think this is an approach similar to what you're referring to here.
The interview is by Randall Schwartz and Leo Laporte, on FLOSS Weekly: http://twit.tv/floss27
Oh and if I recall correctly, I think he did a significant amount of Smalltalk and therefore refers to the expression of "debugging a program into existence". So I'm not alone ;-)
Brilliant article. :)
I had never considered this (not being a frequent coder, just a RoR fan), but it sounds like it could help me a lot when I get to coding.
I totally agree about the software engineers sometime doing lesser quality coding jobs than self-taught motivated individuals with no education related to software conception.
I couldn't agree more.
Nothing makes my day more than being able to delete a couple hundred lines of code.
Delete first, ask questions later. So many coders are afraid to make deep changes like deleting code. The rewrite is better almost 100% of the time. And if it isn't, well, that's what version control is for :)
James, you are saying that for a programmer to be great they must write software exactly as you do? Is this inclusive? Can a programmer be great and not program like you?
Absolutely brilliant advice. Revision and refactoring should be easy.
It‘s the difference between speaking and writing: If everyone had to convey their emotions through speech, without the ability to take back and revise our words, we‘d have big communication problems.
@eric: absolutely not. Nearly all of my software development experience can be categorized in to a couple of pretty specialized areas of the field. And, most of this advice very specifically applies to working with expressive, dynamic languages. In other areas, with other tools, I can't claim to have any idea. There are certainly other effective approaches.
What I will say, though, is that when expressive, dynamic languages are an appropriate solution for your problem domain, this strategy is _an_ effective one for producing great code.
This is spot-on perfect. I couldn't agree more. And, really, I think this applies to any creative endeavor.
Coding Horror recently had a post on this very subject:
"Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay."
http://www.codinghorror.com/blog/archives/001160.html
@Mathieu: The debugger in Smalltalk is not really a debugger; it's an object browser. Calling it a debugger is like calling Emacs an editor--it's technically true, but it totally misses the point. Ruby doesn't have this since it's not image-based, so it's really an apples-and-oranges kind of thing.
Great article. I agree 1000% that writing code is more important than thinking about code. But I majored in econ so maybe this is just hopeful thinking ;)
I think this guy just lacks proper planning, you should never have to write code twice or rewrite anything IF YOU PLAN IT PROPERLY!
Your outlook is valid up to a point I think. The first 5 years or so of coding it helps a lot. Then after time (I've been going at it for about 15 years now) the need to write all the code diminishes and instead I plan and think out how it will be, then usually end up writing it once and with very few if any major bugs.
that's been my mantra for quite some time now... get it working now, make it pretty later.
To 'design' is the craft of deleting the non-essential.
Iterate early, often and simplify towards the optimum solution within the given constraints.
/pauric
@Phil I certainly didn't want to diminish the Smalltalk object browser ;-) I'm perfectly aware that it's probably the most powerful environment for object oriented development to date.
I was just referring to an expression I heard a bunch of times from Smalltalk people. "Debugging a program into existence" refers to the fact that with Smalltalk you can literally code what comes after your breakpoint and then continue execution.
If it wasn't mentioned in the Cunningham interview, it was probably in the Dan Ingalls one, a few episodes later.
I dont think there is anything in particular about your approach that requires an "expressive, dynamic language". How can you optimize if you dont know how different implementations perform? if you havent tackled the problem 3 different ways, you dont truly know what your problem is, and you haven't spent enough time learning the border cases.
I liked ror before i started working on a stagnant ror project. documentation from the initial dev was minimal. and monkey patching was extensive. i ended up doing a rewrite(thats refactoring right?) with spring/swf on tomcat. finished it much sooner than it would have taken me to begin to figure out what was going on in the failed project.
"Trying to perfect an implementation in one's mind is a form of speculation" -- this is frightening. No need for perfection, but a good programming should have no problem thinking up a solution to a problem in her mind. Do not confuse coding with programming. Implementation/coding is a necessity until we get programming languages that offer higher level of abstraction. Ruby and Python are getting there. Trail-and-error "programmers" that have to write code and run them to see if their solutions are correct should not be programming.
See: http://www.pkshiu.com/writing/programmers.html
Some scenarios that would benefit from the code-and-see process are :
P.K.
The one key that you don't want to wear out is the Delete key, sounds like a good lesson learned my friend. Respectfully, Dr Saxe
| One of the great things about pair programming is getting to see how somebody else approaches a problem. ... and then he goes on about what people can learn from him...