Chapter 2: On Bit Depths and Fine Wines

April 3, 2021

NOTE: This post is part of my extended series on the “Experience of Development”. If you’ve not read the two-part introduction yet, it’s perhaps a good idea to hop over and check out part 1 and part 2 before continuing.

There were some great sessions at JavaOne 2008. Among the stand-outs for me were Josh Bloch and Neal Gafter’s Java Puzzlers (returning for the umpteenth time) and Kathy Sierra’s talk about reverse engineering passionate usersYou’ll need to rely on my memory for the contents of Kathy’s amazing talk because some people are horriffic jerks and that means the rest of us can’t hear from people like Kathy any more, despite the fact they’re awesome. .

What struck me at the time about Kathy’s session was how she had no words on her slides. None. At. All.

What’s stuck with me far longer was her use of the concept of “bit depth”, which wasn’t the traditional technical one you’re probably thinking about. Kathy used it to differentiate the kinds of users of a given service or piece of software. The argument of her talk was to zone-in on one particular kind of user; the power users, and reverse engineer your system from what they would think were excellent features backed by a solid and coherent system model.I believe this was perhaps an early version of her Badass Users book because reading her site now, a bunch of things definitely resonate.

She described these peeps as “high bit-depth users”. To explain this she explained how she understood wine. She had a low bit depth appreciation she saidApologies Kathy if I’ve got this the wrong way round . That is to say, she could tell red wine apart from white wine, but that was it. Others had a higher bit depth, and the higher their bit depth, the deeper and richer their concepts of wine were. The greater their awareness of things like grape varieties, the wine-making process, the regions wine came from and the influence of ‘terrior’, as well as their knowledge and their sensitivities to subtle cues and differences. Consequently, their enjoyment was more subtle and nuanced too. Whereas for a low bit-depth drinker wine might be “good” or “bad”, for a higher it depth aficionado might be “forward on the nose” with “good legs” but still “not quite as good as the previous vintage”Can you guess which end of the field I’m placed at yet? A little Google is a wonderful thing. .

So what about Josh and Neal? Well, if you’ve not familiar with their regular sessions (and accompanying book) let me fill you in. Both Josh and Neal had worked on key core aspects of Java. On top of this, Josh had also written (and frequently updated) the classic “Effective Java” while Neal worked on Google Calendar and led the Java lambda specification team. This meant both of them were ideally placed to host an annual session where they posed a series of questions to the assembled audience which largely ran along the lines of “given this code, what would you expect the output to be?”

The reason they did this was to illuminate some of the darker, more subtle, and (some would argue) less obvious areas of the Java language and core libraries. It was intended to educate, but it was also terribly good fun.

And, just like Kathy’s talk, years later it’s come to strike a new resonance in me.

Now, in light of my theory of what makes up “the experience of development” I think they were actively working to improve the bit depth of those attending their session. They weren’t just presenting facts. They’d explain why, draw out differences between Java versions, give a bit of history, and explain idioms which had come and gone, frequently as a result of things which were hard (or easy) in the Java development world at the time.

In expanding the Java dev bit-depth of those present, they were expanding the substrate mental models of those in the audience. Sometimes it was as low-level as how fundamentals such as primitives worked. Other times we moved up a little to syntactic sugar behind various bits of syntax. Other times still it was about the internals of various collections libraries, and other still attempted to help people grokk that great darkness which is co/contra-variance.

With this all in mind, let’s loop back to Kathy. As bit-depths increase, mastery does too. That in itself must surely bring additional elements to the experience of development. To have more detailed and nuanced substrate mental models must surely make them easier to work with, purely due to the ability it gives us to pick elements which do what we need more quickly, and consequently have fewer instances of surprise (especially puzzler-level surprises which in the many-sharp-edged world of Java can be real head-scratchers)I’ve even seen the pass-by-reference vs pass-by-value issue confound really solid devs for example. .

But there’s something else which arises from greater bit-depth and it’s something which has a direct impact on enjoyment. I’ve seen this with wine, with golf, and with programming. The more expert a person becomes, the less they can like certain things unless absolutely everything is perfect. Wine experts are far less able to just enjoy a glass of “really nice plonk” as some call pretty good wine, because a few subtle elements - which those with a lower bit-depth experience don’t even register - to connoisseurs are glaring issues. Terrible golfers (me) are happy to have hit a few decent shots in a round of eighteen disastrous holes, while I’ve seen a friend who played off a single-figure handicap have a bad week after they shot a double-bogey on a single holeThey still won. That didn’t seem to matter. .

The same goes for many high-bit-depth aficionados of programming languages. I’ve frequently seen them pick languages which are more “pure” and balk at having to sacrifice this purity in the name of getting things done, which generally means using a library or framework which does what they need, but which also forces them to do things in a style they feel is not their favourite.

I’m not saying this is bad. (I’d love to be that great at any language.) What I’m saying is, low bit-depth understandings of languages is almost always something which we will be motivated to improve on, for all but the languages (and frameworks / libraries) which we almost never touch. The higher levels of bit depth however, while they almost inevitably bring far greater knowledge and mastery of a language, can also frequently bring a reduced enjoyment of use, and perhaps even reduced effectiveness, when purity is not sacrificed sufficiently on the altar of pragmatism. (It can also lead in some cases to code which is nebulous and impenetrable to the average dev who isn’t at the same level of mastery. But that’s straying into the realms of the experience of developing with others which is a who other set of posts.)

That’s it for this post. I’m going to keep sharing these musings, and hopefully also begin to bring in some specific case-studies of how development is experienced by specific individuals. My next post begins this journey by attempting to do this from a personal perspective (and perhaps even finds a supporter). In the meantime I’d love to know what you think. If you have any thoughts or any other kind of feedback please leave a comment below, or reach out to me on Twitter. Thanks!