When in doubt — “Bonjour-hi”

Apparently there is language drama in Montreal:

The unofficial greeting in the bilingual Canadian city of Montreal has long been a friendly “Bonjour, Hi!”

But that standard is no more since a motion mandating store clerks to greet customers only in French was passed in Quebec’s provincial legislature.

The problem is that Montreal is officially French-speaking. But English is extremely popular, and the main language of tourism. So ingenious citizens came up with “Bonjour-hi” as a way to be inclusive, and signal that they are capable of speaking english and french.

We have something to learn here. When in doubt: offer options.

  • When giving a suggestion, offer two if you don’t know for sure
  • When asking boss for advice, offer two possible solutions
  • When trying to make a decision, consider at least two options
  • When somebody is [un]comfortable, offer them option to stay or leave

Picking one out of two is hard, so let’s recall what Agile Software Development teaches us:

When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.

Dave Thomas

By following “Bonjour-hi” approach, we are not diluting power or wasting time, we are showing that we are empathetic and thoughtful. Offering option doesn’t need to be artificial, stick to your guns when you are sure. But otherwise — consider two options.

Setting up artificial limitations will teach you new tricks

In creating art, there is one technique that always attracts attention. That is setting up artificial limitations or restriction to the process.

In writing, there is whole zoo of techniques or challenges (see wiki and TV Tropes articles) that aspiring artist can borrow from. In movies, one can try to make a film using a single continuous shot (Russian Ark) or only using natural light (even indoors, see Barry Lyndon).

Constrained writing Wikipedia article

In software development one successful artificial constrained that comes to mind is 10+ Deploys per Day at Flickr that contributed to the launch of DevOps culture.

In cooking we have Plating Carrot in One Minute or dinner under $10. We have challenges of finishing game in least amount of time or beating games blindfolded. In programming we can try to implement algorithm with the least amount of bytes or program while drunk.

All these attempts at meeting strict restrictions (apart from being artistic goal) lead to generation of very creative solutions. When used as an exercise, this approach attempts to artificially limit most crucial resources, or resources we are bad at managing. You can’t finish project in a month? Try one day! Always over monthly budget? Here is $50 / $100 / $150 for a week of groceries.

In science we’ve seen several examples of setting up artificial constraints. Comes to mind: 3 Minute Thesis, 72 hour science, and 3 year PhD thesis (don’t take that one too seriously).

All these examples teach us valuable skills of time and resource management, allow us to get better at scope definition, and help understand what is slowing us down.

To work through the problem, force your process to be starved for key resource. The approach is to pick something that feels the most painful, and try to aim for it. You can only pick things you control (no “10 Science papers a year” but “10 co-authorships a year” is doable). In academics it is most likely going to be time.

Image result for cost time scope
Triangle of doom. When restraining quality, we have to balance time, cost, and scope to achieve result. When one resource is limited, others need to be sacrificed

You will have to sacrifice some things: either pay more, or aim for lesser scientific achievement. But amount of information and training you’ll gain might be well worth it.