Will Larson's Blog, page 34

Founding Monocle Studios.

Waiting to hear if I would be hired by Yahoo! in 2008, Luke Hatcher and I founded Monocle Studios. Between June 14th and November 7th, we designed and released our iOS game touchDefense. Unlike the story of Digg V4, this story has no industry relevance.

However, it's a period I personally look back on rather fondly.

The opening menu included animated towers and creeps that would periodically spawn and be vanquished. This was my favorite feature.

In 2008, I had just completed my year-long contract teaching English in the Japan Exchange and Teaching Program. W...

Nobody cares about quality.

You’re grabbing coffee with a coworker, and they’re caught deep in a rant loop, “Nobody cares about quality. They say they care, but they don’t care.” You helpfully decide to snap them out of the rant by providing some counter-examples, measuring your memories of the last few months and recounting some examples of slowing down for quality. Moments later, your contribution to the conversation is an easily traversed speed bump as the rant metastasizes, “They just don’t care.”

This is a quintess...

A forty year career.

The Silicon Valley narrative centers on entrepreneurial protagonists who are poised one predestined step away from changing the world. A decade ago they were heroes, and more recently they’ve become villains, but either way they are absolutely the protagonists. (Although, perhaps the role of protagonist is expanding a bit.) Working within the industry, I’ve worked with quite a few non-protagonists who experience their time in technology differently: a period of obligatory toil required to pry...

Notes on data modeling from Handbook of Relational Database Design.

I’ve been working through Handbook of Relational Database Design by Candace Fleming and Barbara von Halle, first released in 1989, which ambitiously attempts to define best practice for both modeling data in a database agnostic way and also address implementation concerns for implementing and tuning databases. I’ll write up note for both eventually, and these are my notes on the first half of the book on defining data models.

Quick summary: I haven’t taken a college-level databases course, an...

Organizing team offsites.

Last week, the team I support had our quarterly offsite. I’ve been running team offsites more and more frequently over the past few years, and have finally been able to nail down an approach that consistently feels like an essential, effective use of time.

My rules for effective offsites are:

Start with trust and safety. A good offsite starts with a group of folks who trust each other and feel safe bringing literal and intellectual honesty into the room. If you’re not bringing that team into...

Rewriting the Yahoo! BOSS Datahub.

In 2008, my approach to blogging was concocting an explosion of content on breaking technologies and hoping that would translate into notoriety, page views, or at least a job beyond teaching English. I attempted this approach to various degrees with PyObjC, Processing.js, Why the Lucky Stiff’s Shoes, and a few others.

This worked fairly well–density, novelty and recency are the necter that tempt the search relevancy gods–and eventually nudged open the door to my first job in techn...

Describing fault domains.

Fault domains are one of the most useful concepts I've found in architecting reliable systems, and don't get enough attention. If you want to make your software predictably reliable, including measuring your reliability risk, then it's an extremely useful concept to spend some time with.

A fault domain is a collection of functionality, services or components with a shared single point of failure. A fault level is a set of one or more fault domains serving the same purpose, for example if you...

Distributed systems vocabulary.

I've spent a fair amount of time recently discussing how distributed systems fail and strategies for preventing those failures, and the lack of a shared vocabulary poses a significant barrier to high-bandwidth communication.

Given some murky personal plans to write more in this area for the next bit, I've written up the vocabulary I've found most effective. Hopefully this will be useful in its own right, but at worst I'll use it to avoid repeating boilerplate definitions going forward!

Want...

Reclaim unreasonable software.

Big Ball of Mud was published twenty years ago and rings just as true today: the most prominent architecture in successful, growth-stage companies is non-architecture. Crisp patterns are slowly overgrown by the chaotic tendrils of quick fixes, and productivity creeps towards zero.

After a couple years wallowing at zero, many companies turn towards The Grand Migration pattern and rewrite their software. These rewrites are quite challenging and often fall.

An alternative path, which I wrote abo...

What's the inverse of literate programming.

One of my favorite ideas in programming that hasn't ever quite worked is literate programing. Literate programming explores how the act of writing and reading software might work if we blended code and documentation–the how and the why–much more closely, usually in the same file.

As I reflect back on writing my book, I wish I had tools to do the opposite: powerful, easily extensible tools to write books. I guess we could call it "programmable literacy", if we had to manufacture a...