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?

Your contribution to the world.
Your contribution to the world.

(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.

Read a book by the way. Make reading books your book project. That’s mine too.

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.

Enjoy your life

“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.