Fred Flywheel and Christmas Bugs

Nikolay Vasiliev
6 min readMar 22, 2019

--

Hello dear fellow readers, this time I would like to tell you a story about Fred Flywheel, Christmas bugs and what did they have to do together, eventually reflect on my own relationship with bugs in programs, and will recommend you a book that illuminates how I think the supernatural powers of Fred’s work.

(Copy-pasted disclaimer: Some names and identifying details have been changed to protect the privacy of individuals.)

Off we go!

Photo by Anton Darius | @theSollers on Unsplash

Please welcome: Fred Flywheel

Fred Flywheel is a guy I met few years ago, he used to work with my colleagues, and they kept a warm rapport ever since. Every now and then they would meet for a dinner or a board games night. Since then Fred moved to a different country to work for a big software company, where he is responsible for the reliability of intensively used software.

Among his friends he is a legendary person, a kind of computer wizard who spawns SQL injections to find vulnerabilities in the computer services of the university, programs his Arduino to flush the toilet and automate the opening of the window blinds at morning alarm time. What makes him stand out from the crowd of us bearded sweater-wearing specky bear programmers is that he is a naturally open and cheerful person. He’s got this magnetic type of smile that makes you want to smile in exchange. Fred is a kind of guy that uses vim and knows what iptables are for.

But these skills are much less powerful, in my opinion, than that one skill I believe he possesses.

Why a wizard would take the worst shift in the year

As part of his job Fred has to take shifts during which he is “on call”, which means, responsible for the reliability and overall functioning of a computer service. It means that for 24 hours they can literally call him and tell that certain thing went down, and, for example, users cannot login, or upload images, or something more detailed.

His job during this shift is to be available, receive the call and go and fix the problem. Since modern computer systems are a complex orchestra of hardware, software and network systems, there are many things that can break: like hard disks suddenly breaking, network cables get detached and part of the servers become temporarily unavailable. These situations cannot be automated, and that’s why modern computer systems still need a bulk of human intervention, even in the most developed software companies, where automation is the King. To mitigate the lack of automation they develop an outage cookbook full of recipes of how to act in which situation.

Now, you would imagine that these shifts are 24/7, all year round, and eventually somebody needs to be on call during holidays like Christmas. And they do.

Once when we were having a dinner with Fred and friends he told us that this Christmas he will not come because he is taking the Christmas shift.

“This must be terrible! “, I said.

“No, actually I quite like it! I volunteered!”, Fred said and smiled. After a pause that indicated my puzzled state he added: “Usually it is a quiet period, but if something goes on fire, it gets pretty bad!”

Then he explained that most common outages during normal days of operation are those related to developers deploying new versions of software, or maintenance of the hardware, which does not happen during “deploy freeze” and “feature freeze” plan which is in action during Christmas holidays. That’s why it is a quiet period; pragmatically speaking, it is like taking a shift that is easier to carry than others.

But since there are no “typical” outages it means that if something goes down, it is atypical, it is something weird, it is something for which there is no recipe in the outage cookbook. A person like me would get very anxious just to think about this, the unexpected nature of the bug and responsibility to fix it timely. But Fred seems to really enjoy this part.

How come?

Unexpected is not bad

What use can an unexpected information have? Dan and Chip Heath in their book “Made to Stick” say that it is an essential component of delivering ideas in a way they “stick”, in a way they remain in the heads of listeners like footprints remain in concrete after it dries up. (Sorry for the link to Amazon, I do not receive any cash for this, I just find it the most appropriate way to refer to the book.) They claim that unexpected is one of the key aids in facilitating learning and keeping the attention of the listener.

According to the authors, it is essential to make the listener wonder: Why is it so? Why does Saturn has its rings? What they are made of? Who killed Ratchett in the Murder on the Orient Express? It seems that wondering listener is much more likely to listen carefully and to understand and remember what was to be said.

The unexpected can have a broader use. To be honest, not many of us need to produce “sticky” ideas in our daily lives. A more generic use of unexpected the Heath brothers attribute to teaching. Unexpected information flags a gap in our knowledge, and our mind craves to fill it in, producing curiosity. And curiosity is what makes the learning so much easier and fun!

It looks like that for Fred these atypical, out-of-the-cookbook situations are a gap in his knowledge, they induce curiosity and he is actually having fun resolving them. When I first arrived to this conclusion, I felt enlightened. I think I even had a hindsight-like feeling of “it is so simple, how could I not have understood this earlier!”

Getting personal with bugs

In my own experience bugs that occured on my way would produce any emotion but curiosity. It would be anger and resentment if the bug was not mine, or feeling of being a lesser self when the bug was mine, indeed.

I remember, I stumbled over and over again upon that situation when your python script does not produce any output for long amount of time, though it should have produced some. After some quick googling I found out that I need to tell python not to buffer the output via a special flag. I would say to myself: “Hey, yet another time stupid language developers invented something counterintuitive that I can’t remember, but there’s nothing we can do about it, so let’s just try to remember this.” I would not wonder why did they decide to make it so, and of course I would forget this flag and get upset again.

This effect was especially unpleasant during University years when a certain project should have been delivered in short time but at the last minute a bug would show up, ruining the presentation of a program. It was later in my professional career when I noticed that I actually started having fun finding the root cause of a nasty bug. That made me feel like a tiny little superhero!

Having met Fred, and then reading “Made to Stick” made me confident that this is the right way to deal with the bugs. It’s a challenge! It’s an opportunity to learn something new! It’s an opportunity for an improvement in the software system!

Fred’s Superpower of Curiosity

I believe that the best, most outstanding skill of Fred’s is his curiosity, the way he harnesses it and drives towards the unknown — and wonderful. One would say, “But curiosity is not a superpower!” And he would be partially right. He would be right because curiosity, like joy, like anger, like love, like rage — it is one of the basic feelings that humans possess. But nevertheless it is not common to be a master of your own curiosity, and the benefits of gaining this skill are invaluable.

I hope you enjoyed this little story, and learned something new. As a little thank you here is a self portrait of the little Curiosity rover that is still exploring Mars, as I am writing this in 2019:

Curiosity rover (public domain image from relevant Wikipedia page)

Let there be enough of curiosity for all of us!

--

--

Nikolay Vasiliev

Which one do you choose: easy and fun, or complex and boring? Nikolay selects the second one — by making it easy and fun!