Bridging design and development with data

Programming and designing with Pure UI:

The process involved, among other things, creating a new UI, ditching the dependency on Flash in favor of HTML5 and introducing new functionality…The particular way in which I implemented it led me to some interest insights around the growing convergence of the designer and programmer roles…The fundamental idea I want to discuss is the definition of an application’s UI as a pure function of application state.

This pulls together three threads:

  • that design and development are duals in a deep way
  • thinking in data structures is useful even if you aren’t using gobs of parenthesis (i.e. Lisp)
  • removing resistance to experimenting with software behavior, in this case by describing behavior with data structures instead of conditionals in code, yields good things (see also Bret Victor)

Medium-term bet: Facebook, through tools like React(-Native), continues to push tasks that were previously outside of “text editors”, such as visual design and animations, into things-resembling-code via the function-of-state paradigm that React is sneaking into people’s brains.

(Also, the use of a fixed-width font in the page design there is 💯)

Microservices in context

An interview with John Allspaw, on Etsy infrastructure and operations:

For example, a good friend of mine runs and has run an electronic trading exchange. You could imagine his goals and constraints when designing an electronic trading exchange are very different than, say, Facebook. Facebook might be very different architecturally because they have different constraints than Amazon. And Amazon might be different than even Etsy.

When you have a conversation that unnecessarily paints the discussion as, “Are you micro-services or are you a monolith?” then it wipes away all of the context-specificity. Which you actually have no real way of talking inspecifics.

Compared to the previous buzzword, SOA, what does microservices mean? As far I can tell, its two things:

  • A Rorschach test. What do you see in this buzzword? What does it say to you?
  • A signaling mechanism. I’m most likely to hear about microservices from those trying to distinguish themselves from those other people who write code that doesn’t share their values.

Context-specificity is the important part. I’ve been reading David Byrne’s How Music Works and he spends the first chapter entirely on how the performance venue (a savannah, a noisy club, an austere concert hall) puts its mark on the music that is performed there (percussion oriented, loud and compressed, or quiet and precise).

In architecture, context is also king. Building and deploying services is different at Heroku, Netflix, Facebook, and the place where you work. You can build services of varying size and complexity anywhere on any stack. What the team, culture, and organization prefers is the real determinant.

I find it useful to read about other people’s service architectures to learn what works elsewhere. Even better if they describe the context they built that service architecture in. But it is always foolish cargo-culting to attempt to replicate another team’s architecture without the team and organizational context in which it was born.

When we model

I’ve observed a few levels of modeling (i.e. thinking about a problem and describing it in concepts plus data structures) that software developers do in the wild:

  • structural modeling, describe structure of the problem domain and represent that directly in code, probably using the concepts that your ORM or data layer provide
  • operational modeling, evolving a structural model to include models of the operations and workflows that interact with the structural models
  • deep modeling, evolving an operational model to include language that describes how the model, problem domain, and solution domain interact and describe each other

A structural model is what happens in a “just ship it” culture. If you’re lucky, you might start thinking about an operational model as you convert that just-ship-it app into an ecosystem of services connected by APIs and messaging.

Any of these models could poof into existence at a higher level. That is, a team could pop out an operational or deep model of a system on their first try. This is even more likely if it’s their second or third take on a problem domain.

Some ideas for kinds of even-higher level modeling that high-functioning teams perform: error-case modeling, coordinated system modeling, social modeling, migration modeling.

And, let’s not even speak of metamodeling :P

Word processors, still imitating typewriters

Right after we finish ridding the world of “floppy-disk-to-save” icons, I propose we remove this bit of obtuse skeumorphism from the default view in word processors like Google Docs:

the margin setting thingy on a typewriter
Who uses this anymore?

I vaguely remember using one of these to adjust margins and such on a real typewriter once. Its possible I used one to eek out an extra page in a school report during junior high. Since then? Wasted screen space!

Act like a modern device, word processors. Hide that stuff in a menu somewhere!

Ideas for Twittering better

When it comes to Twitter, things can get out of hand fast. Setting aside the hostile environment some people face when they participate in Twitter (which is setting aside a doozy!), it helps to have a few defense mechanism for what is appearing in your stream.

Most importantly, I evaluate each potential follow by the rule of “smart and happy”. Which doesn’t mean smart, angry people are automatically off the list. But, they have to show a really unique intelligence to get past my emotional filter. I made a graphic to boil down my “should follow?” decision:

How to decide to follow someone on Twitter.
How to decide to follow someone on Twitter.

Non-brilliant and happy? Probably in! Brilliant and happy? Probably in! Smart with a little bit of edge? Maybe. Just angry? No thanks.

Information overload, confirmation bias, and overwhelming negativity are also handy things to manage. I do a few things to keep my head above water and a not-too-dismal outlook on life:

  • Don’t worry about keeping up. It’s impossible. That’s OK!
  • When I have stuff that needs doing, shut it down. The tweets will go on without me.
  • Follow people with a perspective different from your own.
  • Keep a private list for high signal-to-noise follows. Good friends and people whose ideas I don’t want to miss end up here.
  • But follow a lot more people as a firehose of interesting and diverse voices.
  • When on vacation: don’t even care about Twitter. Disconnect as much as possible.

I hope one of these ideas can help you Twitter better!

“Everybody Wants to Rule the World”, too much of its time

I really dislike “Everybody Wants to Rule the World” by Tears for Fears because it’s a perfectly written song that sounds exactly like the year it was recorded, 1985. Five years earlier, it would have sounded mildly seventies-ish and been great. Five years later and it would have had a little more grit and sound very late eighties.

What I’m saying is, if I could un-invent certain musical sounds, the bass on that track would appear on the list.

Hype curve superpositions

It seems, these days, that technologies can exist in multiple phases of the hype curve, simultaneously. Two data points I read this weekend:

  • Node, which I personally place somewhere between “trough of disallusionment” and “plateau of productivity”, is in the “exceptional exuberance” phase for the author of Monolithic Node.js
  • Ruby, which I personally place in the “plateau of productivity” phase is in the “trough of disallusionment” for the author of The Ruby Community: The Next Version

In short, I strongly disagree with both of these opinions. But I think that’s not the useful datapoint here. The takeaway is that both viewpoints can exist simultaneously, in their own context, and not be entirely wrong.

Raising all boats

It’s easy to complain about PHP. For instance, why didn’t they choose ☃ as their namespace resolution operator?! As a developer with lofty opinions, I’m not a big fan of PHP. To me, it’s an argument against allowing accretion to determine the design of a system. I don’t think it’s controversial to call the PHP language, core library, and ecosystem “inconsistent” and “a matter of curious histories”. A language feature here, a library function there, year over year, and you’ve got a “quaint” design. Yes, those are scare-quotes.

Whenever I feel a big rant about PHP shortcomings approaching, I try remember a few important facets of its success:

  • PHP made programming web applications accessible to lot of people for whom writing CGIs with Perl, Python or Java servlets was overwhelming. Myself included!
  • You still can’t beat the simplicity of PHP’s deployment model: acquire commodity web hosting, upload source files, and done.
  • Due to its accessibility and ease of deployment, a whole new kind of person started building stuff with code. Jason Kottke called part of this Liberal Arts 2.0. Less mathy programming, more craftsy.

Fast forward to today. PHP is still doing fine, though lots of people switched to Ruby or Python many moons ago, depending on personality type. And lots of those have since moved on to other things. The technology hype curve is an overlapping, ongoing thing.

Of those that switched, many ended up with JavaScript, in the guise of browser-side frameworks or server-side Node (and its ilk). I think there’s a huge opportunity here. JS is not without flaws, like PHP. But its sort of backed into really broad reach. Embedded, games, applications, mobile, probably more that I don’t even know about. That could make it compelling for an even less math-y demographic of people building stuff with computers.

And yet, there is no single JS community. There’s browser people, there’s server people. The future may hold mobile, gaming, and device people. That creates dissonance and some uphill battles.

But maybe that’s the really cool part. The JavaScript communities will have to slog uphill a bit to make accessible the previously intimidating domains of mobile apps, games, and embedded software. And that could raise the boat for people who aren’t building web apps but could be building software.

Functions about nothing

The tricky thing about decomposing code into abstractions is you end up with “functions about nothing”. You’ve probably seen on of these: a method or function with really vague names glommed into a utility or enumerations junk drawer. It’s probably innocuous, but as you’re reading code, it takes you out of your flow and forces you to think in the abstract instead of the concrete.

It’s easy to guess how these things happen. Successive refactoring iterations end up pulling business logic into a pile of predicates and side-effects and separate pile of abstractions. We feel pretty good ourselves at the end of the refactoring and write a fancy blog post about it!

The rub is when we come back to read the code later. Its easy to find the abstraction first and get side-tracked by figuring out why it exists, the context in which it was created, and when we might use it again. This is better than predicates and side-effects interwoven. But it’s still a problem.

I don’t have a salve for this. I just wanted to put the phrase “functions about nothing” on the internet. [SLAP BASS OUTRO RIFF PLAYS HERE]

Missing the big picture for the iterations


Driving in Italy is totally unlike driving in America. For one thing, there are very often no lane markers. Occasionally a 1.5 lane road is shared by two cars moving in opposite directions. Even if there were lane markers, it’s doubtful Italian drivers would heed them. Italian traffic flows like water, always looking for shortcuts, ways to squeeze through, and running around temporary obstacles. For an American, driving in a big Italian city is a white-knuckle affair.

My conjecture is that the unspoken rule of Italian drivers is “never break stride”. Ease in and out of lanes, blend in at traffic circles. There’s almost a body language to Italian driving by which you can tell when someone is going to merge into your lane, when a motorbike may swerve in front of you, or when a tiny delivery van is going to blow past you on a two-lane road.


Start with the result. I find myself mired in optimizing for short-term results that I can incrementally build upon. This is a fine tactic, especially when getting started. It’s a nice way to show progress quickly and keep making progress when rhythm matters.

But, it’s a tactic. To make a musical analogy, it’s how you write a song, not how you write a whole album. At some point I need a strategy, a bigger idea. I need a result in mind.


I love to tinker with new technology. The grass is always greener with new langauges, libraries, tools, etc. I’ve learned a lot this way, and kept up with the times. I’ve got lots of surface-level experience with lots of things. But increasingly I want more experience with deeply accomplishing or understanding something.


Driving in Italy was extremely jarring for me at first. It closely resembled chaos. Eventually, I got used to it, at small and medium scales. (But never drive in Rome/Milan). Now, I sort of miss driving in Italy, at least the good parts. I miss the freedom to overtake other drivers without having to swerve through lanes, and I miss not stopping at traffic signals any time there’s an intersection.

Maybe this is a reminder, for me, that getting out of my routine (American driving) isn’t so bad. Worth the initial shock. Maybe my routines, my tactics, my tool/library/langauge novelty seeking, were helping me along as much as constraining me.

Maybe the big picture result, not the iteration, is the thing and how you get there (highly ordered American driving or seemingly unordered Italian driving) is of less consequence.