11 paradoxes of engineering

The 11 Paradoxes of Management: LEGO leadership principles, written as pairs of seemingly opposed values or actions to be kept in careful balance. Examples: "To be tolerant - and to know how you want things done", "To be self-confident - and humble".

Near the LEGO headquarters in Billund, Denmark, there's an employee-access-only corporate history museum called LEGO Idea House. There's lots of fascinating tidbits: a whole section on the company's genesis as a wooden toy outfit, early test moulds to experiment with different ways of achieving clutch power between bricks, even this electronic train set from 1968 which would start and stop at the blow of a whistle.

(I doubt these whistles had the same devious properties as Cap'n Crunch whistles - but the general concept of audio input interfaces is the same. Makes me wonder if anyone tried to drive their electronic train with a pan flute, or maybe even an early Moog synthesizer.)

Compared to that, the above image of LEGO leadership principles from the 1980s might appear boring. (Did I mention there's also a lot of really cool LEGO sets on display at the museum?)

Still: for a set of non-dualistic principles to show up in the offices and boardrooms of a Danish company 40 years ago, sporting a massive yin-yang taijitu, seems strange. At the time, immigrants accounted for less than 3% of the Danish population (and damn does Statistik Danmark have some slick minimalist data visualisation).

It should be noted that Niels Bohr beat LEGO to this symbology by roughly another 40 years when he designed this amazing coat of arms in 1947...

Coat of arms of Niels Bohr. The motto reads "contraria sunt complementaria" (opposites are complementary).

...which expresses much the same thought as the 11 Paradoxes. Apparent opposites can, in fact, be necessary complements of each other.

Bohr was likely thinking here of wave-particle duality rather than management, but in some sense that's even more fascinating. The principle that things are not always black-and-white finds expression in such wildly different worlds as physics and corporate leadership.

I think that most complex human endeavours are like this. You learn concepts, concepts coalesce into general rules, rules turn out to have all kinds of exceptions. If you get really good at something, eventually you learn that some of the exceptions point to better rules, a new meta in the game, and you learn to balance those new better rules with the good old rules that haven't changed.

I now have just over 15 years of experience in the tech industry under my belt. I like to think that I've successfully avoided the 1 year of experience, 15 times trap, and that I have at least some hard-gained wisdom to share.

And certainly software engineering feels like a paradoxical field at times, an odd midpoint between craft and capital-E Engineering, an industry where it often seems we're making it up as we go along even as we utterly transform our world.

So, without further ado, I present my first draft of...

The 11 Paradoxes of (Software) Engineering

  1. To hold high standards - and to just ship it, early and often
  2. To build for our users and the business - and to build something we can maintain
  3. To experiment and innovate - and to choose boring technology
  4. To plan for the scale you want - and to implement for the scale you have
  5. To automate the boring stuff - and to do things that don't scale
  6. To sweat the details - and to see the system as a whole
  7. To keep testing coverage up - and to avoid meaningless tests
  8. To measure what matters - and to accept that not everything that counts can be counted
  9. To not repeat ourselves - and to repeat ourselves when needed
  10. To carve out space for deep work - and to communicate and collaborate
  11. To stay hungry, stay foolish - and to step away from the screen