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 ;-)
Ryan Merl
· 1 year ago
Brilliant article. :)
Jerome Gravel-Niquet
· 1 year ago
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.
Isaac Schlueter
· 1 year ago
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 :)
eric
· 1 year ago
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?
Marcus Cavanaugh
· 1 year ago
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.
James Golick
· 1 year ago
> ...*in my experience*, the very best programmers...
@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.
lapsed.cannibal
· 1 year ago
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."
@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.
Alex
· 1 year ago
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 ;)
robby
· 1 year ago
I think this guy just lacks proper planning, you should never have to write code twice or rewrite anything IF YOU PLAN IT PROPERLY!
Jeff
· 1 year ago
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.
Jeff
· 1 year ago
that's been my mantra for quite some time now... get it working now, make it pretty later.
pauric
· 1 year ago
To 'design' is the craft of deleting the non-essential.
Iterate early, often and simplify towards the optimum solution within the given constraints.
/pauric
Mathieu Martin
· 1 year ago
@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.
Tristan
· 1 year ago
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.
PK
· 1 year ago
"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.
Some scenarios that would benefit from the code-and-see process are :
- learning a new framework, experiment to see how things work - very complex database query, unless your relational math is up to par - using the Windows API, but that's a whole different story
P.K.
Dr Saxe
· 1 year ago
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
BluePig
· 1 year ago
| 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...
Julie
· 1 year ago
The delete key is easily the key I use the most too!
All Comments
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 ;-)
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.
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 :)
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.
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/00116...
Iterate early, often and simplify towards the optimum solution within the given constraints.
/pauric
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 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.
See: http://www.pkshiu.com/writing/programmers.html
Some scenarios that would benefit from the code-and-see process are :
- learning a new framework, experiment to see how things work
- very complex database query, unless your relational math is up to par
- using the Windows API, but that's a whole different story
P.K.
Respectfully,
Dr Saxe