TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

The Software Developer's Sketchbook

157 pointsby gongadorover 10 years ago

7 comments

michael_nielsenover 10 years ago
Chaim Gingold has a great essay that expands on related ideas, at <a href="http://www.levitylab.com/blog/2011/01/catastrophic-prototyping-and-other-stories/" rel="nofollow">http:&#x2F;&#x2F;www.levitylab.com&#x2F;blog&#x2F;2011&#x2F;01&#x2F;catastrophic-prototypi...</a><p>In particular, the following remarks from Gingold&#x27;s essay complement the OP well: &quot;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.<p>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.<p>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.&quot;<p>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.
评论 #8825596 未加载
评论 #8826040 未加载
chubotover 10 years ago
For me, that is my ~&#x2F;git&#x2F;scratch repo (formerly ~&#x2F;hg&#x2F;scratch).<p>I have a lot of experiments in there: different approaches to parsing; R&#x2F;OCaml&#x2F;Lua experiments; tests for interactions between Unix signals, processes, and threads; etc.<p>One thing I&#x27;ve also found useful is: whenever you see a neat code snippet on Hacker News or a blog, download the code, and write a shell script to build and demo it. You don&#x27;t even have to understand it thoroughly the first time around. But when you come across something related in the future, your brain will remind you of it, and you will have a little shell script you forgot about to puzzle through :) It takes like 10 minutes each time.<p>I have 141 different subdirs; probably half are my own and half are demos I learned something from (or hopefully will in the future).
评论 #8826190 未加载
checker659over 10 years ago
Can anyone recommend books to read on topics along the lines of this article. Basically, tips for programmers trying to bite off more than they can chew (but sort of have to, given the problem at hand)?
jherikoover 10 years ago
&quot;To become the expert, you need more projects. They can be smaller, experimental, and even be isolated parts of a non-existent larger app.&quot;<p>This is so true. A lot of the &#x27;experienced&#x27; people I&#x27;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 &#x27;experience&#x27; 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.
评论 #8826605 未加载
CookWithMeover 10 years ago
Although I agree with the conclusion (have several small projects in addition to a &quot;big&quot; one), I think the intro is off.<p>&gt; It takes ten-thousand hours to master your field, so the story goes, except that programming is too broad of a field.<p>If you&#x27;ve put in ten-thousand hours into the field of programming, you&#x27;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 &quot;I&#x27;m learning to program&quot;.<p>Learning new concepts and APIs is meta-skill, and one will become better at it the more different concepts and APIs one has used.<p>You&#x27;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).<p>So, if someone has &quot;mastered programming&quot;, 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 &quot;master programming&quot;. 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.<p>Most fields are too broad to know &quot;everything&quot; about, that is not specific about programming.
ameliusover 10 years ago
&quot;Ideas are more important than code&quot; -- Unknown<p>Therefore, I&#x27;d rather have a sketchbook for ideas :)
评论 #8828997 未加载
dandrewsover 10 years ago
His &quot;sketchbook&quot; sounds an awful lot like a REPL to me.
评论 #8825384 未加载
评论 #8826953 未加载