# It’s a trap; say no

It happened that I switched jobs at the end of August. Upon hearing that this was about to happen, a friend pinged me and asked whether he could hire my services for "one to two hours per week". I rejected the offer. I specifically told my friend that "one hour per week is a trap":

A week is 168 hours. You sleep 56 of them, so let’s say that you have to give 1 hour out of 112. To be more precise, 1 hour out of 72 you can spare. Surely you can allow yourself 1 hour of a side-gig, right? But then it is Monday. And you start your working day, and "oh, I’ll deal with this tomorrow" and this goes on until Friday and you say, "I’ll do it Saturday morning before the other chores". And you squeeze that hour somewhat grudgingly, between Saturday and Sunday night.

If I’m wrong, why are then all those Udemy / whatever vocational courses you’ve purchased unfinished? Did interest wane down on all of them right after the first couple of hours?

So say no to "one hour per week engagements". You’re setting up yourself for frustration and failure.

As for me, I’ve arranged for virtual coffee with my friend once per month to discuss his vision and progress. Because everyone needs someone to talk to.

# 1% better than yesterday

I am a >Code supporter. In the latest episode, guest Jerome Hardaway said something along the lines of:

Each day I want to be 1% better than the last

I don’t think that even he understands the power of the message. Let’s make a simple graph out of it, where on day 1 we have a value of 1 for a certain skill:

What this means is that in less than a year you aim to be x7 better than when you started. Granted this is only a rough estimate and depending the subject, the difficulty, other issues and any other kind of ceiling a x7 result won’t come, but still, the result won’t be linear.

As the days go by, you’re becoming extremely more competent than you thought, even if today you did not make it to be 1% better than yesterday, but only 0.1% better.

The point is that you do not stop.

# The 22 minute meeting rule

This is a nice trick for running your 30 minute meetings. I found it during listening to the latest episode of The Engineering Commons. 30 minutes are the standard slot for a meeting it seems. So plan for a 30 minute slot, but plan to run the meeting in 22 minutes. Why? Because if you are in a series of meetings, chances are that you’re going to be on time only in the first one (and even that is debatable). So delays accumulate and you can forget ever making it to the last meeting.

So why 22 minutes? My guess is that if you have planned for 5 meetings in a row, this 22 minute window slides enough within each 30 minute slot so that you can make it in all of them.

For longer meetings you can always multiply appropriately.

# The Last Lecture

Randy, it’s such a shame that people perceive you as being so arrogant, because it’s going to limit what you’re going to be able to accomplish in life.

I will admit to never having seen The Last Lecture. Over the years I’ve started watching it, only abandoning it after the first couple of minutes. The only thing that I’ve seen, and this only by chance, is the part where Randy Pauch describes how his parents let him paint his room. Somehow this stuck with me and in our house the kids are allowed to draw on the walls of their room, only in contrast to his parents, the room gets painted from time to time and the drawings are thus erased.

Somehow I decided to read the book. Mostly because it contains one of the most annoying phrases I’ve ever heard offered as consolation: “We cannot change the cards we are dealt, just how we play the hand”. Well, you cannot argue with a dead guy, and Pauch, if alive, would not let you win the argument.

It takes tremendous self discipline to write a book like that (even though technically he did not write it, he dictated it on tape and a writer undertook the polishing). I was told though by a good friend that similar efforts (like keeping a journal) help coping with the situation. And this is visible in the writing. As is visible that we are not the main audience of the book, his three kids are (lately I pick authors with three kids). He even admits that at the end of the book. The man has little time left and a lot of guidance to give. So what is this book? A self-help book? A career-advice book? A parenting one, drawing mostly from the example his parents set for him? All of that?

Time is all you have. And you may find one day that you have less than you think

It is a time-management book. Because here is a guy that was on the path to success, that had a lot to give to his field and his family, who is suddenly told that long-term plans do not matter any more. This is what you’ve got at best, squeeze whatever you can inside. So through his book (and the lecture I suppose) he basically delivers a lesson in time management (which explains how he managed to do so many things until he was diagnosed terminally ill), planning, team building, mentoring and correcting one’s behaviour.

This is not a book that made me feel relaxed or even good about myself after reading it. Nor is a book that I agree 100% with what is written. More likely close to 60% of the advice. But am I happy I read it? Yes. Should you read it? Only if you can handle enumerating all your mistakes so far.

# meetings and sabotage

It’s been a while since I’ve written any blog post and even more since I’ve written ten lines or more, so today I will copy something from this pdf that popped in my twitter stream (unfortunately, I didn’t keep a note of the tweet):

• Insist on doing everything through “channels.” Never permit short-cuts to be taken in order to expedite decisions.
• Make “speeches,” Talk as frequently as possible and at great length., Illustrate your. “points.. by long anecdotes and accounts of personal experiences. Never hesitate to make a few appropriate “patriotic”-comments.
• When possible, refer all matters to committees, for “further study and consideration.” Attempt to make the committees as large as possible – never less than five.
• Bring up irrelevant issues as frequently as possible.
• Haggle over precise wordings of communications, minutes, resolutions.
• Refer back to matters decided upon at the last meeting and attempt to re-open the question of the advisability of that decision.
• Advocate “caution.” Be unreasonable and urge your fellow-conferees to be “reasonable” and avoid haste which might result in embarrassments or difficulties later on.
• Be worried about the propriety of any decision – raise the question of whether such action as is contemplated Hes within the jurisdiction of the group 01’whether it might conflict with the policy of some higher echelon.

# “She’s a dancer”

This is one of my favorite productivity stories, although most people use it when confronted with educational or ADD/ADHD diagnoses:

Telling us a story about a famous ballerina, Robinson tells us that the young woman, these days, would likely be diagnosed as having ADHD, as she didn’t concentrate in her classes. Taken to see an educational specialist, the psychologist was smart enough to leave the room, turn on the radio, and let the young girl dance. He told her parents, “Jilien isn’t sick – she’s a dancer”. She went on to a dance school, joined the Royal Ballet and has choreographed most of Andrew Lloyd Weber’s musicals. Nowadays, we would give her medication and tell her to calm down.

So sometimes, when you see someone being unproductive, maybe he’s just not a dancer for the tasks at hand. If you’re a manager you may need to figure out how that person dances.

# Conway’s recipe for DevOps (well, sort of)

This is basically an effort to rehash Conway’s Recipe for Success for DevOps:

Work on several problems at a time

Conway was working with six problems at a time as a means to battle depression by failing to conquer a specific problem. Six problems are enough to fit your daily mood. It is more than one per day anyway. In DevOps the software stack you need to coordinate just to make your app go live is so versatile that there is always something you can work on daily even if your primary focus seems stalled. Beware though since this is also a way to not make any work at all. You can eat an elephant but somehow we seem to attract hordes of them. And then you can just stare at the monitor Hopeless.

A good strategy to combat this is what I once heardtype A people procrastinate by doing other things”. Your stack has more than six components, you can easily have more than six fallbacks should you get stuck.

If anything, please try and don’t ever break your rhythm. Interrupts cost. Context switching too.

Pick your problems with specific goals in mind

This is one thing that I suffer a lot. Everything is cool. And I want / need to know everything. In acceptable depth. Today. But this is not feasible even if we have 25h per day and no sleep. So, IMHO (and I try hard to do so) the plan is to pick problems with two goals in mind: Your current job and “the dream job” you want to land on.

Big problem

The difficult and important problem for Conway. The Architecture problem in the DevOps case. Is your running Architecture OK? Does it need improvements? Do you need something completely new? Are you to invent the next lambda architecture? How are you going to make your dent in the circle?

(Yes, you have to try to make a dent in the circle even if you’re not pursuing a PhD.)

Workable problem

Big problems mean big delays most of the time. And in trying to solve big problems you need practice. So you need to have an arsenal of problems you can work on that you can solve. They may be boring or even need repeated tedious tasks performed by you. Automate yourself out of them if you can. Flex your brain muscle so that you can work on the big stuff properly warmed up. Your current setup always has clear steps that you can walk forward. Nothing fancy that you could give a speech about, but something that you can complete during the day and feel good about it.

Book problem

I do not have a book project on my own. But over the last 20 years there have been two books that I wish I could find time to revise. I have a friend though that just finished writing a book and he seems pretty happy with the result.

If you’re writing a book, consider this as yet another problem you’re working on. If you’re not writing a book, well write something. There is always less documentation than needed.

Fun problem

You should always have at least one problem that you do for fun said Conway. Well I guess we have Github for that, don’t we? I think my current fun project will be cryptopals. Let’s see for how long.

“The trick in life is to find out what you think is play that the fools think is work so that they will pay you to do it.”

Happiness is the single productivity booster that one can think of. Grief and depression the best demoralisers. This post about Karojisatsu really shook me. And it came during a time that I was seriously thinking about DevOps inflicted depression.

I still have no generally applicable tricks about that.

# No slides?

This reached me through infowarrior (author of The PowerPoint Manifesto):

In a sign of how Carter intends to challenge his commanders’ thinking, he has banned them from making any PowerPoint presentations — a backbone feature of most U.S. military briefings.

Could it be that such presentations have become an integral part in briefings because of Patterns of Conflict? I cannot tell, but it sure is the most known military presentation outside the military world.

But where had I seen banning presentations before? Ah, Louis Gerstner at the decks:

At that time, the standard format of any important IBM meeting was a presentation using overhead projectors and graphics that IBMers called “foils” [projected transparencies]. Nick [a division head] was on his second foil when I stepped to the table and, as politely as I could in front of his team, switched off the projector. After a long moment of awkward silence, I simply said, “Let’s just talk about your business.”

# The Elements of Computing Style

I bought The Elements of Computing Style on an impulse, mainly because it is written by dds and I do not own any of his other books. So I did not even pay attention to the subtitle:

190+ Tips for Busy Knowledge Workers

So what I expected was a book with advise on writing code, or on choosing certain algorithms for solutions of certain (small compared to Big Data) sizes. But this is a productivity book of another kind. It offers advise from when to read email in order to make the most of your available worktime to whether your chair should have arms or not and why. It is written in a clear flowing style and if you’ve ever heard dds speak, you almost listen his voice while reading it. It is not heavy stuff and this makes it an excellent companion for the bus.

Given my aversion to certain word processors I particularly enjoyed advise on how to handle documents with them and picked up a few helpful tips along the way. Travelling advise was fun even though it does not affect me and I find chapter 2 (Work Habits) the most important one since it offers ways to deal with interruptions of the flow:

It can take us more than 15 minutes to enter into such a state of focused attention, and only a trivial interruption to exit from it.

The book is available from Lean Publications which makes it an interesting experiment as it has both a minimum and a suggested price and as you decide how much you’re going to pay for it, you are immediately informed how much of your money goes directly to the author.

# My browser’s “home” page

I try not to keep fifty tabs open and stress test my browser. But nowadays, opening my browser stress tests me. Whenever I fire it up, it opens:

• Gmail