This post by math/CS prof Peter Boothe caught my eye:
What I am claiming here is not just that if you code faster, you will get your solution written faster. I am claiming if you code faster, you will get your solution done MUCH faster. The speedup is greater than linear.
I agreed with the sentiment, but I wasn’t sure about his explanation. Then I read this comment from Matt Kangas:
IMO, the key point is: teach exploratory programming.
That’s the answer! Here’s my experience: I took exactly one CS class as an undergrad; it was so arduous, so time-consuming, that I vowed to myself: Never again. But I kept being drawn to various programming projects, so I learned to code competently on my own time. At some point last summer, I think I hit the 10,000 hours of practice that Malcolm Gladwell posits as a heuristic prerequisite for being really good at something. One thing I learned around hour #7,500 was the importance of testing pieces of code independently as much as possible when building a larger project. Beginners always work at the application level: Change something, re-run the application, see if it works. This is sometimes necessary (if, say, you’re changing the UI), but should be avoided whenever possible. Experts tend to write code in small, unit-testable pieces. Many are test-driven.
Not every test has to be a formal unit test. Just trying out a line or two of code on its own and watching what happens is often useful. This is yet another reason why Java is dead to me as a language. Java is so slanted toward BDUF that when it sprang forth Athena-like from the head of James Gosling, it was blessed (?) with a formal standard for documentation, but no command line interpreter—a feature offered by just about every other language, including Java’s spritely yet statically-typed spawn, Scala.
For those of you building anything big enough for Hofstadter’s Law to apply, my #1 piece of advice would be this: Get your code tested, today!
Tags: coding2 Comments
There is some truth here, also some truth in Pete’s post.
Coding fast is a good thing no doubt, but it’s hardly a be all end all.
I rank the following as far more important:
Thinking clearly about your problem and the abstractions you will use for solving it is the first and foremost task for a software engineer.
Decomposition, which is related to good abstractions, is the ability to find the relevant (independent) sub-problems and solve them (independently).
This ability then goes hand in hand with interface design, and here I do not mean UI design, but API design. Consistent, well-thought through interfaces that are easy to learn, easy to remember, anticipate a client’s needs, and are easily composable, are a key to good software.
Coding is the thing you do at the end when the problem is solved.
That said, you and Pete give a good description of how I prototype. This is almost always understood to be throw away code though, and is not always necessary.
The “fast coding” thing is nice when:
1) I don’t understand the technology I’m working with very well.
2) When there is a tricky algorithmic aspect to what I’m doing.
3) When I’m developing a new technique or idiom.
4) When I’m not exactly sure where I’m going or don’t feel like thinking through a problem. After all it is fun to hack sometimes.
Clearly #1-#3 imply smaller chunks of code, while #4 is basically cowboy coding and probably should be discouraged for “real” projects.
And yes, test-driven code is an asset. It should be obvious that good abstractions, good decomposition, and good interfaces aide the test-driven methodology.
I’m glad you liked it, and especially glad that it stirred up something in your brain!
I think I agree with you in broad strokes — testing and experimentation and exploratory programming are large reasons for increased speed. But it’s important to emphasize that it’s the underlying fluency and ability to make small changes quickly that makes those techniques useful. You can’t be agile if you aren’t small and quick. If that quickness weren’t there, then exploratory programming would have a *huge* time cost, and would not be nearly so useful. With larger time costs comes an increasing tendency to do a BDUF and that leads to decreased speeds, which leads to larger time costs, which leads to a greater tendency to do a BDUF, which leads to.…
Anyhow, it’s exactly the native fluency and willingness to experiment that I need to impart to my students, but I am unclear how to teach it. It seems like a “knack” more than a traditional body of knowledge or a skill, which means that the best I can currently do is repeatedly throw students at problems which benefit from that knack until they start to develop the knack. But that’s basically hazing, and surely there is some less cruel way to go about imparting an exploratory attitude and fluency…