The Software Developer's Sketchbook

I found the OP to be disquieting, and your link even more so. I haven't written that many distinct programs in my life, and I never did well in programming contests with tight time limits. I tend to agonize when I program, hitting a conceptual wall after every few hours that I'm unwilling to just hack my way through. Usually I go away for a day or month before coming back to continue for a few more hours, until I hit my next wall. I enjoy building a few familiar things over and over again -- the game of life, RSS readers, chessboard apps, more recently lisp interpreters -- but by and large I am bored by doing things that have been done before. I'm constantly trying to run before I can walk. Maybe this habit/cadence is fundamentally limiting my pace of improvement? After all, I started programming late in life, and I've only been programming 18 years or so (compared to the 12 at the start of the Gingold essay). Maybe I still have a lot to learn, and I should try to do more, faster? Focus less on truly hard problems and more on mastering skills?

But I think your link also helps me understand my strengths (and rationalize away my weaknesses :) All its examples are from games, which are by definition a short-lived genre of program with a constant churn of rewrite and reimplementation in a hit-driven business. I tend to obsess about system software, where code tends to accumulate slowly and huge swathes are never rewritten. In my domain it isn't being able to write software that's key, but being able to read other people's code. That's what I struggle with, and it's at least not obvious that these articles' approach helps with getting better at reading.

I return to the first paragraph of the OP: programming is too broad a field. I suspect we think of it as a field only because it's so incredibly young. It's quickly flowering into a foundational skill, on par with reading and writing (perhaps replacing 'rithmetic?) It's not a single domain, but all domains, each with its own subtly different emphasis on core skills, preferred paths of improvement, and likely failure modes. These articles aren't as comprehensive as I had first feared.

(I realize I'm not actually rebutting anything the articles said. Both are valuable and I'll continue to mull them. I'm just airing insecurity here.)

What do you mean by "write a shell script to build and demo it"? Pardon my ignorance.

"To become the expert, you need more projects. They can be smaller, experimental, and even be isolated parts of a non-existent larger app."

This is so true. A lot of the 'experienced' people I've met in the industry with 10 or 15 years behind them have done nothing but their jobs in that time to practice their art, and their 'experience' is therefore of such low quality that an exceptionally good junior with a few hobby projects behind them can outclass them even in their own specialist area.

This is so laughable and a little typical of HN.

I've worked with guys that have done nothing other than Spring and Hibernate for nearly a decade and they know those platforms inside and out. There's just no way someone junior with a few hobby projects are running rings around those guys in their areas.

However, if you take something new, or something these guys haven't used, then yea.... rings could be run. Other than that, I don't think so.

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

(self-promotion here) or perhaps a polyglot code notebook: http://beakernotebook.com/