How to bring your team back to the office (3)


I think of my job often as being a translator between executives, managers, architects, developers, testers, customers, writers, etc. My favorite work projects have been those we conducted war-room style or in an open landscape, yet now it is almost two years since I’ve been in the office. We’ve filled in the gap a little bit with some team outings. Today I went in to the office to collect my belongings, before my vaxx-leper status kicks in and my physical access is deactivated. This is such a stark contrast with my experience at church where we worked hard to find some way to meet, at times even with our fussy government’s disapproval. What a joy and encouragement that fellowship was, and what a missed opportunity these two years have been for camaraderie at so many anxious companies and churches!

See also: How to bring your team back to the office (2)

Complex (2)

I have generally found NoSQL to be a disaster. Like agile processes, it allows you to dispense with certain disciplines, but for use at scale and over time it requires you to engage in substitute disciplines. Too often these are not practiced. From a recent work chat with minor adaptation:

Data hygiene is crucial. I wouldn’t be opposed to broader NoSQL/JSON use if we used JSON schemas wherever appropriate, but at that point it is probably simpler to flatten the data into tables.

A good schema is a species of defensive code; e.g., you can have higher confidence that the value you are reaching for is actually there no matter how old the document.

See also: Complex


I’ve joked for awhile that EDR and similar systems like CrowdStrike or Carbon Black would become Skynet. Or, more likely, a tool of international espionage and cyber–warfare. It doesn’t feel good to be vindicated. (Now imagine someone accomplishing this with a major browser or password manager application.) Complex and highly interconnected systems are difficult to make stable, resilient, or secure; and cannot possibly be made anti-fragile. (This is a lesser reason why I miss my old pickup truck.) I’m not very excited about Kubernetes for the same reason. It’s also partly why I’m not very excited about artificial intelligence; but additionally because analysis of data, whether by machine or by human, does not automatically involve either wisdom or decisiveness (see also Edwin Friedman and Nassim Taleb).

Crossposted on I gotta have my orange juice.

How to bring your team back to the office

A lot of people are offering advice on how to return to the office safely. Here is my evidence-based approach:

Bring your team back to the office.

You should, of course, continue to give people the freedom to work at home if you are able.

I’ve written much more on my other blog stressing that churches must be open for worship, and should do so as normally as possible. But there is also a tremendous benefit to other spheres of life—business, family, education, politics—for people to be face to face with one another. Beyond that, there is actual harm in exercising authority to constrain any of these spheres of life beyond natural limits.

Here is my evidence: Alex Berenson’s Unreported Truths. In addition to that, Edwin Friedman’s A Failure of Nerve offers the appropriate framework for leadership in difficult times: non–anxiety.


For some time now I’ve been a bit skeptical about the promises of blockchain in the business world. I’m a computer scientist and mathematician by training and by instinct, so I have gotten caught up in questions such as the suitability of different forms of blockchain proof, the difficulty of seeking Byzantine fault tolerance, and transaction database [in]efficiency.

However, I have come to realize that the value of blockchain technology does not lie so much in its solving multi-party transaction problems in some provably ideal way, but rather in its solving them in a suitable way—with well-defined interfaces, strong security, and backed by open software and algorithms. This in turn allows it to become a standardized platform. And that standardization is the real value of blockchain: it will both create efficiency and allow for easier innovation on top of it. Of all the solutions we could standardize on, blockchain has the most going for it.

Viva blockchain!

Slow down to speed up

The next maneuver that Mott proposed for his pupils was most complicated: ‘Randy, you’re in Gemini down here and you must intercept Agena-B up here. Don’t go for the target. Burn straight ahead. Go faster to go slower.’

‘Doc, I understand that part. But what in hell do I do next?’

‘As you move to a higher orbit, your speed will begin to drop off, and believe it or not, if you obey the figures your computer will be feeding you, you’ll bring your Gemini right in behind the target. The computer will time it so that when you’re about a hundred feet apart, your speeds will be identical, and so will your orbit. Then your twelve-year-old son could dock the two vehicles, because you can make the Gemini move a quarter of a mile an hour faster than the Agena, ease it into a docking.’

Claggett and Pope looked at each other, and the former said, with his bright Texan grin, ‘Like the pretty girl said in My Fair Lady, “I think I got it.”’

‘I believe the professor said that,’ Mott said. ‘And to protect you,’ he added, ‘we always time the docking so it occurs in the daylight part of the orbit.’

‘Real thoughtful,’ Claggett said.

‘So think about the orbits tonight. Memorize the diagram. And keep telling yourself, “To go faster, I must go slower.”’ (James Michener, Space, 502)

You can envision this somewhat counter-intuitive aspect of orbital mechanics in a couple of different ways. First, you can think of the higher orbit as stealing your kinetic energy (slowing you down) and converting it into potential energy (increasing your altitude). You can also picture it in terms of Kepler’s second law, which states that an orbit sweeps out equal areas in equal time. The higher your orbit, the more area your radius is sweeping across, and so your momentum becomes slower in order to compensate.

orbit2This notion of speeding up to slow down (and conversely slowing down to speed up) is useful for considering how organizations and projects scale. When your project (program, product, etc.) is small and your customer base is small, you can and do move very quickly. If you are a programmer, it is possible to rewrite your entire codebase in a few weeks. At this stage, organizational disciplines can feel like unnecessary drag on this perceived speed. But if you have fallen into the trap of thinking that way, as your project and customer base grow, the lack of discipline actually becomes a drag on your ability to make further change. Over time, with a continued lack of discipline, both the chance of error and the so-called blast radius of that error become larger. You are slowed down both by your fear of error, and by the cost of having to correct such errors. Being thus slowed down, how can you speed back up?

Certainly this sort of breakneck early speed may be a legitimate tradeoff. The term technical debt was coined to help articulate the fact that such a tradeoff is being made for the sake of present benefit against future cost. But as an organization or project grows, the need to pay down this technical debt becomes more and more critical. And this is where notions such as “paying off debt” and “slowing down to speed up” can help us to feel perfectly at ease with the time and effort we are spending on organizational disciplines that do not obviously contribute to more features and more customers.

For example: if I have “slowed down” by taking the time to create a large battery of automated tests for my codebase, then I am actually able to “speed up” in making further changes to that codebase, because I have a higher degree of confidence not only that my changes will not break existing behaviors, but thereby that my changes will not result in added support costs by exposing my customers to bugs.

To paraphrase the wise man: better is he who has self-governance than he who, without it, governs a city.

And keep telling yourself, “To go faster, I must go slower.”

See also: The Start-Up Trap

Resume keywords

I’ve had my resume posted online and from time to time I receive a solicitation for job openings. Over time I’ve paid attention to my referral logs to see how folks find my resume. Almost every search includes the following keywords, and almost always they are required keywords:

+objective +education +experience

A large majority of searches also exclude the following keywords, which was a little surprising to me. I imagine that these keywords are meant to exclude job listings. If you post your resume online you should take care not to use these words!

-job -career

I have also seen the following keywords and exclusions. They are less common than the above, but it is worth considering them:

  • +senior +programmer
  • +engineer developer
  • engineer developer
  • intitle:Resume OR inurl:Resume
  • “application programmer” OR “application engineer”
  • -sample -example
  • -your -we
  • -opportunities
  • -apply -submit
  • -tips -guidelines
  • -interview
  • -service

It’s possible that I’m missing other common searches because my own resume doesn’t meet the search criteria! If you are aware of other common search terms please let me know.