One of my favourite reads is Kottke.org, a blog by Jason Kottke. Calling it a blog is a bit of a slight: it’s more of a magazine, like a proto-New Yorker. It’s thoughtful and relevant, weaving current events, artsy things, various interesting edges of tech, and topics about general humanity. Kottke has been killing it […]

2017 was a good year for JavaScript. The newer language features are now part of our daily routine. Tightly integrated CI and packaging scripts are the norm, and we have a huge sea of libraries and tools available to us. The core JavaScript frameworks have settled down and mature to the point that we can be confident in JS as the base for large-scale commercial projects.

Some of my most productive business tools are the simplest. Take the *triage board*. It’s a whiteboard that hangs over my desk that has a list of my current projects, with magnets marking what I’m working on next. Weekly I erase the board and re-prioritize my projects, and daily I scribble notes and move the magnets as I work. 

I’m an idea guy. It’s why I love designing software, both in terms of system design and user experience. I love designing and developing products too. It’s something that can get me fired up, keep me from sleeping, and keep me motivated through even the darkest, rainiest days.

In PM land we use tools and techniques like burn down charts, sprints, and spikes. You can get obsessed over getting these things right, and fail to ship effective, quality software. The special language used in and around these processes adds to the problem too, as the language ends up feeling like an accomplishment in itself. Too much focus on the pomp and circumstance of a process takes away from actually building great software.

I made a quick print this weekend based on a few drawings I was working on last week. The idea was to make a block print look like a sketch, and to use background lines as a textural element.

Sometime over the last year I stopped paying attention to Twitter. Between the political cacophony of 2016 and a growing list of people I was following, the noise ratio was just too poor to hold my interest. Twitter had become like LinkedIn to me, a service I used to have a professional presence, but not one that inspired or taught me anything. I had given up.

Now this is where it gets interesting. I’ve been interviewing and hiring for almost 20 years. I have accumulated a bunch of questions I ask people. And while the technologies I talk about have changed, I have always expected certain skills and behaviours from specific levels of software developers. In terms of soft skills this has been very successful, but recently I’ve noticed that the hard skills have dissipated.

The New Year came and went without much of a fuss. I read about the [2016 Maker Challenge][1] shortly after the holiday, in the flood of annual self-help and 2016 resolution articles. The challenge was something I was keenly interested in, then promptly forgot about in the chaos of startup and family life.

We tried something new on art day recently: printing with Lego. It has potential, even if it’s a bit of a pain to clean up.

As designers, software developers, and business geeks we thrive on a few things. We seek inspiration. We obsess over details. We work long hours. And we need *focus*.

As a software designer, I love to design software. As software developer, I love building software. When I dream of better things, I funnel my ideas into new projects. When I don’t have time for all of my side projects, the projects pile up in a corner and gather dust. And when a side project is an unfinished publishing platform it gets in the way of writing.

I learned almost nothing about writing production code in my early years. And while discovered that I loved to imagine and build things in code, I barely brushed against the principles that would later be required to make real learning possible. My skills didn’t improve much either as my time was largely unfocused.

A developer asked me a seemingly obvious question today: I have an API GET request that requires a JSON body. Is that okay? It’s a good question too. It turns out the answer isn’t as simple as it should be. On principle the answer is, “No, it’s not cool”. A GET is an idempotent request […]

Friction works against you. It exceeds your ability to progress. It deflates you, stripping your motivation. It’s the hill you see before starting a difficult project. It’s the gravity that pulls you away when interest wanes. I’m starting a small project for a client today. It’s a simple set of improvements to something I built […]

One of my favourite JavaScript features is its literal object notation. It allows you to declare data structures in JSON, which is a very succinct, C-like syntax. You can use this notation to declare SETs, and the a in b syntax to verify a variable is in a set: /* Declare your set as a […]

Somehow I missed the recent larger EC2 unit sizes: When I saw this, I immediately thought: these numbers will have K, M, and G suffixes within the next 5 years. Compute units will be sold as 88 mega-ECUs. Imagine 88 giga-ECUs? The ECU is similar to our old measure of computing: boxen (except more virtual). […]

While writing a spec earlier today the last few years of progress in server land hit me: uptime is a facade. In the early days, server resources were expensive and scarce. Uptime was sacred. Long running hardware was celebrated, UNIX tools were born, beer was consumed. The problem of focusing on the hardware is that […]

I had an epiphany early this year: getting good at something isn’t about finding a groove or being especially clever, it’s about honing a method of doing something. Or lots of methods, meticulously crafted, carefully practiced, and well executed over and over again. That’s it. The problem is in discovering the method. It’s harder than […]

It’s not that these tools and techniques are bad in themselves, but our use of each should be fit into a well tuned approach to building software. An entire project delivery should be tidy, professional, and complete. There are a few causes to the problem of organizational buildup. Our software is limited, our methods need […]

So you can’t write. You’re empty, tired, and unfocused. You’ve tried exercise, meditation, caffeine, binge sleeping, and a dozen other cures–but nothing comes out. And when you do happen to squeeze out a few paragraphs, you stall, spiralling further into your uninspired daze. You are burnt out. Writer’s block and burnout are the same problem: […]

I know a few generations of developers. I find they tend toward different ways of thinking about software design, based on the languages and decomposition tools that were available at the time they formed their thinking. Their tendencies shift over time too, but often their imaginations are limited by whichever mode of thought they’re working […]

If you want to get better at something, do a lot of it. Throw yourself at practice and real chances to do it. When you want to become great at something, stick with it, obsess over it, and suck up all of the knowledge that surrounds it. And when you want to become truly incredible […]

Merlin Mann asks us why we’re waiting to be awesome, as he remembers Steve Job’s 2005 Stanford address. It’s a good question: why do we wait? There are all sorts of reasons, of course, but in the end my simple philosophy is: just fucking do it. Sometimes I have to say it to myself out […]

I’m a bit surprised that the argument over tables versus semantic layout is still floating around. It ignores the obvious: Any set of nodes can be rendered like a table Any table node can be rendered like a non-table node There is really no difference between a <div> and a <td>, except for the default […]

2010 has come and gone. I’ve shipped a few projects, each a number of times. I’ve registered dozens of domain names and dropped a few of the older ones. I’ve started (but not finished) a dozen spare time projects. I’ve had hundreds of new ideas, and a few of them were even interesting. I’ve learned […]

When you describe a design to a group of people, each person imagines something different. Depending on your story and the individuals, understanding may vary wildly. And if it differs enough, the result is chaotic–unpredictable and often negative. You need to fit how you show your ideas to different groups of people carefully, and notice […]

Boost’s Filesystem library is an incredible resource: it abstracts paths, directories, and stat results. It simplifies coding shell problems in C++, it’s portable, and is maintained by a large community of contributors. The one downside of Boost is that some of its newer libraries are poorly documented. ((Something I want to contribute to.)) Until I […]