Book Review: Work Clean

Down into some net rabbit hole, I stumbled upon a review of Work Clean. I chuckled: a productivity book, philosophizing about how cook’s approach to preparation (mise en place) would fix all our problems? Bring it on, I have a long commute.

Actually, I found the book surprisingly good if you stick to the practical side and discard the hyperbole. As an occasional home cook with a big dose of planning and OCD built into me, I got the point.

Here I’ll share some of the key takeaways I got. I recommend you get the book, by the way.

Commit to being honest with time. Plan daily.

If you are anything into GTD (David Allen’s Getting Things Done), daily planning, weekly reviews and in general a big amount of overhead in your system is probably already a given. But this is probably #1 in my book. If you plan your day (preferably the evening before or at least, before really starting it) you’ll have a better sense of where you stand and how you are doing with your day. Proactive, not reactive.

Immersive focus vs process time

Remember, anything that needs your input or feedback on a project to keep it moving forward is process work.
This is a distinction I had never paid attention to. Process time is work you can “pay in advance”. In a kitchen, this would be starting the oven so it’s hot when you need it, while you chop veggies. Roasting bell peppers: they’ll roast while you prepare something else. Process work was just scrubbing and placing into the oven.

In more mundane, office style work, this would be part of delegating, communicating and unblocking your peers. Start the day unlocking and unblocking the work of others. Communicating, requesting what you need lets you keep the day going.

Always be unblocking

Try to unlock all your projects, goals, missions. The question to ask is what is keeping me from pushing forward? What is the show stopper?

Likewise, try to unblock (specially if you are the blocker) your colleagues. If you work in an Agile environment you’ll be familiar with the standup process, where a daily status meeting is quickly held by members of the team, and is when any blockers (operational, logistic, personal) are raised.

(or you can also take the Always be knolling approach)

Counting mistakes: keeping a mistake log

Kaizen is a fabled Japanese term in the manufacturing/productivity world. It is translated usually as constant improvement. But there is nothing to improve if you don’t know where you are failing.

Keeping a mistake log is the way to continually improve. Find where you failed (no need to be anything life threatening: if you misplace your keys, it’s a failure), log it and strive for improvement. We do this constantly at work: any failure generates a postmortem, and from it we plan to prevent the same mistake from happening again.

Distraction routines

Another interesting approach. What to do when you can’t concentrate or need a break from your current project? In other words, have tasks, projects or goals for when you don’t feel like working more on what you are doing now. Who has not sorted their closet to avoid other work? This is the same, but without avoiding the important work. It’s only a break.


Try to finish everything you start. The more projects you have lying around unfinished, the larger burden you’ll feel. If you can’t finish something, prepare the task for picking it up. Write down the next steps, prepare any tools needed. Schedule a follow up session.

The approach to routines

Routines, for the author are not actions (nor habits) but placeholders for actions. You can have a commute routine: you are sitting, bring so and so devices, can do so and so. You can fill this routine with several different actions.

Having a clear idea of which kind of actions can be fillers for each of your routines is key to optimizing your time (if you want to).


It may not have been a groundbreaking read, but I was surprised by the interesting ideas and the exposition. Focusing on cooks was kind of a fun take for a productivity book, and what made me pick what I would have otherwise skipped. Pick it up, you may get some interesting idea.
Written by Ruben Berenguel


Using Processing from Scala

Processing is a flexible software sketchbook and a language for learning how to code within the context of the visual arts.

I had always wanted to play with Processing (after leafing through The Processing Handbook and Visualizing Data some years ago). My general dislike for Java or the JVM made me just play a very short amount of time with processing.js something around 2011 (there was a native processing.js application for iOS, I used it for a while on my iPad and iPod Touch).

But, times have change and I’ve been working with Scala for 2 years already. Since Processing is built on top of Java, using it from Scala should be easy (or doable), but finding details (specially not involving using IntelliJ or other IDEs) is tricky. I could not find anything useful so I had to patch it up from several sources.

These are the steps I had to follow to get it running on Mac OS, with Java 8 and Scala 2.12 (the version of Scala is not that important though, and after all is set in the SBT build).

Clone my sample project

You can find a minimal sample project here. I’m using Spire for its implementation of complex operations (also, I have wanted to try this library for a while), so this comes as an extra dependency in addition to the OpenGL bindings for Java.

You can run sbt update while you do all other steps, since fetching the dependencies can always take a while.

This will draw the Mandelbrot set using the Distance Estimation Method. I first found this algorithm in The Beauty of Fractals and have liked ever since. It is the algorithm used for the header on this blog and on my LinkedIn profile. A pity it’s not as easy (or even possible) to derive for entire transcendental functions, otherwise I would have used it for my paper.

It's a straight implementation to show a bit of Processing and have a nice image, but it has no antialiasing, no controls for iterations or parameter tweaking. Zoom and adjustments are automatically picked by a really dumb scaling (it shows as you start zooming) and there is no colour palette (nothing prevents adding it except that it would add complications).

It's not the nicest Scala ever. Processing is based on Java, and to get some things working mutability seems to be the best approach. For now.

Install the native libraries for jogamp

Jogamp is the set of multimedia API bindings for Java (binds to OpenGL, for instance, with the jogl sub-package). For Processing we need to install the native libraries (jnilibs in the case of Mac OS, dlls for Windows, so for other Linux systems) into our Java classpath.

To do so, first download the full jogamp 7zipped package from here. On uncompress, move all jnilibs in the lib/macosx-universal folder to somewhere in your Java library path so Java can find them (or, alternatively, change your path). You can easily look which paths form it by firing a Scala REPL and running

In my system this points to ~/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java and I put them in the first (since it seems user specific)

Download Processing

You need the core library from Processing in jar format to use in your builds. Just download the processing app, and get core.jar from the Contents/Java folder in the application bundle. Place it into your lib folder.

Although I could add it to the Github project (this core is LGPL), I prefer leaving this as a manual step to make sure anyone trying always has the latest version of Processing.

Ready to go

sbt run

If everything went fine you should now see the following (after some time computing):

And, if you click randomly a few times

You can also try to find the magical command that gets you a coloured gradient

Written by Ruben Berenguel


ClassNotFoundException for Akka logging

A few months ago I stumbled into the problem of Akka logging, specifically ClassNotFoundException when using akka.event.slf4j.Slf4jLoggingFilter, just by following the details of the Logging - SL4J section of Akka documentation. Of course, the error source is obvious in hindsight, but in the moment the fact that this was a multiproject build with several dependency paths made me miss a crucial reason for longer than I want to admit:
Add this to your dependencies (I'm assuming you have a val for akkaVersion to DRY):
"com.typesafe.akka" %% "akka-slf4j"  % akkaVersion

FACEPALM (Picard styled, but more hair)
Written by Ruben Berenguel