The Software Developer's Sketchbook

His "sketchbook" sounds an awful lot like a REPL to me.

Chaim Gingold has a great essay that expands on related ideas, at http://www.levitylab.com/blog/2011/01/catastrophic-prototypi...

In particular, the following remarks from Gingold's essay complement the OP well: "My hard drive was full of failures. Twelve years after learning to program, I looked back on all my software: none of it was finished, and what was, wasn’t ambitious enough. The projects that started out ambitiously always seemed to fall back to earth, like failed rockets lacking the power to propel their own weight into orbit. Sure, there were interesting ideas in there, lots of wacky toys, and I had even attempted a few large projects, but none of them ever came together like the cool games and software I had always admired.

Sure, I had become a pretty good programmer, and learned to make cool stuff, but clearly none of it would ever amount to anything. I just didn’t have what it took.

I went to graduate school at Georgia Tech, and read some Chris Crawford. I learned that he had the same problem. But he didn’t think of it as failure. For him, this was an organic part of the development process. The failures filling his hard drive were actually “prototypes” that helped him decide which ideas were worth pursuing. For each good idea, there were a large number of stupid ones that didn’t work out. Failing, for this successful designer, was a way to find the good ideas. The revelation hit me like a ton of bricks. Maybe I had a chance after all... Master artists like Escher or Van Gogh don’t just sit down and crank out a finished piece. Artists create numerous sketches and studies before they undertake finished paintings, let alone masterpieces... All of my software failures, which I was now thinking about as prototypes, sketches, and studies, had taught me a thing or two about design and programming. If you want to learn to draw, you have to make a ton of bad drawings first. The difference between practice and failure is simply a matter of attitude."

These ideas are, of course, not new, but Gingold has thought about them deeply and distilled them sharply. The essay as a whole goes much further than the above excerpt, and is well worth reading.

Although I agree with the conclusion (have several small projects in addition to a "big" one), I think the intro is off.

> It takes ten-thousand hours to master your field, so the story goes, except that programming is too broad of a field.

If you've put in ten-thousand hours into the field of programming, you'll not need to put in another ten-thousand if you switch from, say, a vector-drawing tool to a music composition software. Yeah, you might miss some stuff like everything related to audio - but picking up the concepts and one or two related APIs should be two or three orders of magnitude quicker than "I'm learning to program".

Learning new concepts and APIs is meta-skill, and one will become better at it the more different concepts and APIs one has used.

You'll also need domain knowledge, of course. Again, working with domain experts and users is a meta-skill that you may want to train (or you may depend on someone in your team to do most of that for you, e.g. a Product Owner).

So, if someone has "mastered programming", she should be able to be dropped into an unknown domain and have the skill to identify and pick up the parts she is missing in a fraction of the time it took to "master programming". Mastery of a skill means the switching costs between domains is significantly reduced, but not zero. Same is true for a carpenter: Building a ship is different from building a house or a bridge, yet a master of carpentry will be able to pick up the skill of building a ship more quickly than, say, a master of programming would.

Most fields are too broad to know "everything" about, that is not specific about programming.

One of my favorite quotes: "Success is the process of going from failure to failure without loss of enthusiasm." I like it because it highlights that failure is a point event, while success is a process, a trajectory. So comparing the two is fallacious. It is possible for both to coexist.

There's still a useful distinction to be made -- the "sketchbook" talked about is the collection of stuff you've done over some longer period of time that you can look through / look back on. It's not a description of a tool, although as you noted the language used in the last paragraph of the post is very similar to the language people use to describe the use of a REPL.

I'm a fellow emacs user, I use SLIME-like functionality practically every day. My "sketchbooks" are my ~/workspace folder and my github account. I have some older "sketchbooks" in the form of tarballs of my ~/workspace folders from old machines.

I thought that basically everyone who wrote software had similar collections of little projects, finished and un-finished, until about a year ago when it came up in discussion with a few other devs who didn't.