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.