Category: Programming

Here’s my personal challenge for this year: I will try to complete at least 20 small software projects in 2020 and document them here on Global Nerdy. The number of projects I’ve chosen to attempt this year comes straight from the way the year is commonly pronounced: twenty-twenty.

Why am I doing this? Because now that I’m back to writing code for a living — after a good long period of time as a product manager or owner, a developer evangelist, or a marketer — and I want to up my game. Yes, I’ll get lots of practice at work, but as those of you who code for a living know, the projects you do at work tend to focus on a narrow segment of what’s possible with code, and largely about solving a business problem instead of learning a new technology, language, or skill.

There’s also another reason: quantity leads to quality.

There’s a pretty good chance that you’ve heard the “ceramics class quantity vs. quality” story. It’s from the book Art & Fear: Oberservations on the Perils (and Rewards) of Artmaking, and it’s appeared many times over the past couple of decades on sites that techies are likely to read. In Cool Tools, Kevin Kelly included it in a list of excerpts from the book way back in 2003, Jeff Atwood wrote about it in Coding Horror in 2008, then Jason Kottke wrote about it in 2009, Ben Thompson cited it in Stratechery in 2015 when writing about Buzzfeed’s success, and in 2016, it’s referred to in a Hackernoon post.

Here’s the story, with emphasis added by me:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an “A”.

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.

Here’s Jeff “Coding Horror” Atwood’s take-away from this story:

Quantity always trumps quality. That’s why the one bit of advice I always give aspiring bloggers is to pick a schedule and stick with it. It’s the only advice that matters, because until you’ve mentally committed to doing it over and over, you will not improve. You can’t.

When it comes to software, the same rule applies. If you aren’t building, you aren’t learning. Rather than agonizing over whether you’re building the right thing, just build it. And if that one doesn’t work, keep building until you get one that does.

In short, it boils down to the old adage “Practice makes perfect,” or more accurately, “Practice makes progress.”

Most of these projects will be built for “toy” systems: mobile devices, wearables, the Raspberry Pi and set-top boxes. I’ve made this choice for a number of reasons:

1. I got an Apple Watch for Christmas! Sure, it does neat things like track my exercise and tell the time, but the real reason I got it was to write apps for it.
2. “Toy” projects allow me to constrain them so that they don’t take an excessive amount of time to build, which is key when you aim to put together 20 projects in a year.
3. My day-to-day work is mobile development. Anything that makes me better at it is a good thing.
4. I need topics for my meetup, Tampa iOS Meetup. Yup, that’s making a grand comeback shortly.
5. I’ve already got an interesting side project that involves the Apple Watch.
6. I also got a mini-screen for my Raspberry Pi, which has been neglected as of late.

6. Finally, and most importantly, I’m doubling down on the philosophy that I talked about on The 6-Figure Developer podcast: “Always bet on the toy.”

Creative Commons photo by Chris Cox. Tap to see the source.

Chris Dixon wrote about this ten years ago in an article titled The next big thing will start out looking like a toy. Here are the opening paragraphs:

One of the amazing things about the internet economy is how different the list of top internet properties today looks from the list ten years ago.  It wasn’t as if those former top companies were complacent – most of them acquired and built products like crazy to avoid being displaced.

The reason big new things sneak by incumbents is that the next big thing always starts out being dismissed as a “toy.”  This is one of the main insights of Clay Christensen’s “disruptive technology” theory. This theory starts with the observation that technologies tend to get better at a faster rate than users’ needs increase. From this simple insight follows all kinds of interesting conclusions about how markets and products change over time.

Disruptive technologies are dismissed as toys because when they are first launched they “undershoot” user needs. The first telephone could only carry voices a mile or two. The leading telco of the time, Western Union, passed on acquiring the phone because they didn’t see how it could possibly be useful to businesses and railroads – their primary customers. What they failed to anticipate was how rapidly telephone technology and infrastructure would improve (technology adoption is usually non-linear due to so-called complementary network effects). The same was true of how mainframe companies viewed the PC (microcomputer), and how modern telecom companies viewed Skype. (Christensen has many more examples in his books).

He also points out that something being toy-like doesn’t necessarily mean that it will become the next big thing. He’s saying that initially they seem like toys, but due to external forces, they become useful in ways that seem obvious in hindsight but invisible at the time. It’s yet another example of William Gibson’s cyberpunk maxim: “The street finds its own uses for things.”

Dixon closes his article about the next big thing being a toy with this paragraph, which mentions the new decade:

But startups with sustaining technologies are very unlikely to be the new ones we see on top lists in 2020. Those will be disruptive technologies – the ones that sneak by because people dismiss them as toys.

Watch this space as I post about these projects throughout 2020! The first — a simple Apple Watch app that’s also a “How to write an Apple Watch app” article in disguise — will be here on Global Nerdy soon.