For whom should you vote?

No, I won’t tell you who is the better candidate in the upcoming Quebec elections. I just want to give you some perspective.

Are you able to reduce your expenses while at the same time buying a new car and a perfect house? If you had the choice to do that by putting everything on a credit card and then leave the bill for your kids, would you do it? Running a household is not so easy. You make compromises.

Running a whole province is even harder. The government cannot give you more of everything and have a perfectly healthy budget. When a candidate makes promises, don’t think “why is this other thing not on the list?” Think rather “will these things help us improve in the long run?” Here are a few things that I consider:

  • Do promises sound ridiculously and unjustifiably expensive?
  • Do they align with my priorities in the next 4 years?
  • How many people will they help? How many people will they hurt?
  • Are they actually useful or just fun to debate?

I mentioned priorities. Here are mine:

  • More doctors.
  • Fix crumbling roads and bridges.
  • Promote productivity and competency.
  • Reduce bureaucracy.
  • Start paying the 265 Billion dollar debt. more on the debt

When you vote tomorrow, remember what is most important to you. Pick a few items and see which candidate aligns best with these priorities.

Inappropriate April’s Fools pranks

If you think that someone who is offended at a joke has no sense of humor, I invite you to watch this scene from the movie The Lives of Others. The setting is East Germany, Stasi headquarters. Please watch before you read further.

You probably all agree that this prank was cruel. Why? Because the perpetrator is of a higher rank and the joke involves a threat to the person’s career. Notice how the lower-rank member cannot shake off the anxiety even after he discovers that this was a mere joke.

Now let’s see how this translates into an April’s Fools prank. Suppose you are in a position of authority over someone: teacher, landlord, employer, military officer, etc. You decide to make a prank on your subject(s). Add to that a threat to the person’s career or livelihood, and you become a sadist, not a comedian. My son’s teacher threatened his education through an April’s Fools prank. Although I learned within minutes that it was a joke, my heart rate climbed and stayed there for over 30 minutes. I had a pain in my chest for even longer.

Be mindful of how your jokes could affect people. If you are in a position of authority, be extra careful. If in doubt, don’t make a prank. Causing people distress is not funny.

As a side note, you might want to watch the whole movie to gain interesting insight into phone surveillance and other subjects that still plague our modern world.

How to kill creativity, part 1

Edit: I recommend reading this article first and then watching the video afterwards. It will make more sense in this order.

I first viewed this enlightening lecture on creativity by John Cleese (Monty Python) a few years ago. Since then, I saw an incredible progress in my problem-solving skills and generated countless creative ideas.

John Cleese explains that creativity is not a talent. It is a way of operating. It is a facility of getting yourself into a particular mood. It is an ability to play with ideas, for no immediate practical applications. And it worked miracles for me.

So now imagine a meeting in a company which aims to solve a problem. It typically has a fixed agenda, includes as many people as could be gathered and the solution has to be taken by the end of the meeting. These mistakes hinder creativity.


The agenda forces you into accomplishing a list of tasks, which is associated with the closed mode, the one in which creativity cannot be achieved. It’s alright if you need an update or get everyone on the same page, but not when you want a creative solution. I recommend splitting the meeting into a few of them, preferably 60-90 minutes each. State the problem at hand and start exploring solutions (not seeking them).

The wrong attitude

When solving problems, you need to bounce ideas back and forth. Having too many people or people who dismiss each other’s ideas is not helpful. When you’re exploring possibilities and someone tells you that it’s ridiculous, you’re no longer in a mood to play. I recommend only inviting a handful of people to the meeting (no more than 5). Tell them not to be afraid to throw ideas, because no idea is wrong at this point. Tell them not to mock other ideas, since bad ideas can lead to good ones in the creative process.

Pressure for immediate solutions

Some problems are hard to solve and require additional pondering time. Pressuring for a decision leads to poor decisions. In the best case, you’ll be missing out on creative solutions because pressure always put people in a focused, closed mode. If the decision can be postponed without consequences, then give people some time to digest the ideas heard and reconvene another time. The meeting should remain an exploration until the time comes to actually making the decision.


Achieving creativity takes practice. Listen to the video and try to remember to switch into open mode when devising any sort of strategy. I will post another article in the coming days to explain how I apply his 5-step guideline in the context of an IT project.

Unit Testing by Example @ ConFoo

I gave a talk last week at ConFoo. It was very well received and I had some amazing feedback.

One person told me that he has been trying to write tests for two years but never had any success. With the advice gathered in my talk, he was able to write a few tests and now has the confidence to write a lot more. Another person told me that he liked my step-by-step approach that allowed less experienced developers to learn and advance, rather than being thrown straight into Test-Driven Development (TDD) and then fail.

This was exactly my intention. Most  testing talks and blogs that I saw until now are not beginner-friendly. They are inflexible, preaching only 100% coverage, “TDD or go home” and being perfect from day one. They completely ignore the human factor. Beginners are turned off by that, which means that instead of having some tests, certain projects have absolutely none. Also, too many talks focus on the testing API rather than on how to approach testing in a project.

I taught people to start writing tests where they are easy to write. Once people wrap their heads around the basics, I show the next steps until I eventually get them to TDD. I want people to feel that it’s ok to practice, that they can’t be perfect from the beginning. I want them to have the confidence to start, or to try once again if they were previously unsuccessful. I want more people to write tests. I definitely convinced the 100 or so people who came to my talk.

I will definitely be giving this talk again at other events.

Raise the red flag

All project failures can be prevented.

There are countless reasons. Some technical and some non-technical.  Some internal and some external. Some we can control and some we cannot.

But there is one thing that they all have in common: we can raise the red flag. With enough experience, we can see things coming before it’s too late. Is the deadline too ambitious? Are specifications still not ready after a month? Did someone expect you to do something but didn’t explicitly ask you? Was someone supposed to have validated your work weeks ago? Is your source control workflow causing conflicts on each merge? Do bugs reappear after being fixed? Did you spend much more time than expected on a feature? Does a coworker promise things yet doesn’t deliver? The list goes on.

You can feel when trouble is coming. You know you can. If you wait until trouble happens to confirm your suspicions, it’s already too late. As soon as you know something, tell the people in charge. Raise that flag. Nobody knows the terrain as well as you do. Yes, many times people ignore these flags because of overconfidence or just lack of interest in the project. It’s not your fault. But at least you raised that flag. It can make all the difference between project success and project failure. If anything, you’ll sleep better at night knowing that you have done your duty and tried to help.

Project rescue expert