On Wordle and Productivity
Well, here’s another example of something I started to write over two years ago only to leave it languishing in my drafts folder…
The Black Art of Software Estimation
I’ve been thinking about how hard it is to estimate effort when scheduling software projects. Consider the following tale:
I discovered Wordle around Christmas 2021, and played it every day, sharing my solutions with friends on WhatsApp. This continued for about three weeks.
Next I started thinking about how to program a computer to play the game well, and this consumed my thoughts for about three days.
Finally I built the program, tracking my time with the excellent Watson, which reports that I spent about three hours writing code before I was done.
When do you think I was most “productive” during the project described above? And what would have been a reasonable estimate of “effort” if it was your job to schedule time for this work?
By the way, the Code is on Github, and the program posts to Twitter as @lewordbot each day if you’re curious. (ed: not any more)
Play-Think-Build
My Wordle-solving project took place in three distinct stages:
- I learned about the problem domain by playing Wordle regularly.
- I designed a solution by thinking hard about the problem.
- I created the program by building my design.
That nice play-think-build pattern is something I have experienced many times on projects that have a heavy problem-solving element. And they’re the most fun and rewarding projects too!
Peak Productivity
My claim is that I was most productive during the “thinking” stage of the project, which I did mostly while walking the dog, doing the gardening, hanging out washing, cooking dinner and so on, constantly noodling on the problem and how to solve it as I went about those menial tasks.
My perceived productivity was highest as I sat at my desk during the “building” stage, typing furiously into a computer. But I wasn’t doing anything difficult; merely birthing the design in my head.
All three stages consumed around ten hours of effort altogether, from ten minutes per day during the “play” stage through to a couple of intense coding sessions towards the end. But those ten hours were distributed across three-and-a-half weeks of “calendar time”.
How would a manager have reacted if I’d said that the project would take ten hours altogether, with a deadline a month away, only for me to “waste time” by playing and thinking without making any obvious progress before rushing something out as the deadline approached? It’d look like I was procrastinating and avoiding work, only to pull out a miracle as the deadline approached.
Know anyone who works like that? It’s creativity in a nutshell.
Creativity at Work
The most fun I’ve had at work is during creative endeavours such as these, where tasks aren’t handed down to a programmer for implementation, but where new work emerges from the aether.
At one former workplace a colleague and I would walk to get lunch every day. It was a pleasant walk, about fifteen minutes there and another fifteen back, carrying our sandwiches. Enough time for a deep conversation about something interesting, and a welcome respite from sitting in front of computers “building” software.
Recently we had encountered a problem with the product we were working on. The details don’t matter, suffice it to say that it was a hairy ball of complexity and that we knew that it was something that needed to be solved in the next six months. It just wasn’t on anybody else’s radar yet.
Each day, for perhaps six weeks, we would chat about the problem during our lunchtime strolls. Sometimes poking around the edges, sometimes diving into the middle of it. Slowly refining our assumptions and trying to reach a consensus about how to think about the problem, then proposing different solutions to it. Playing devil’s advocate to unearth flaws and weaknesses in each other’s solutions. I remember it being a really fun and creative period at work, although no project had been planned or scheduled and we were doing all of this during our break time.
One lunchtime, during the walk back, we realised that we had run out of things to talk about. We had come up with a solution that would work, and which was impervious to any of the criticisms that we could think of. And so we walked straight into a meeting room with our sandwiches, quickly sketching up a design on a whiteboard. After eating lunch we returned to our desks and coded up a proof-of-concept that we had working in just a few hours. And that became the backbone of the product we were working on and endured, with tweaks and fixes, for over a decade.
Skunkworks
We were lucky that we had the freedom to work on something before it became a scheduled project. This afforded us the luxury of thinking about the problem until we decided we were done, instead of compromising that thinking time under a tight schedule.
In my experience, skunkworks projects like this are very rare. I think that’s because the first two “playing” and “thinking” stages are seen as a waste of time. If the engineers aren’t “building” then something has gone wrong. At best, a half-hearted version of the first two stages happen at other layers of the organisation, with work being scheduled before the engineering team learns of it. At worst, the “playing” and “thinking” stages don’t happen at all, and need to be shoehorned in while “building”.
I’m not sure how to solve any of this. By the time projects have been scheduled there is usually a tight deadline which means that jumping into the “building” stage as quickly as possible is in everyone’s best interest. But I think all organisations should give their engineering teams enough breathing space to allow them to embark on unsupervised “skunkworks” projects (along with routine maintenance and refactoring technical debt; two other important aspects of our work that are oft maligned and done only with the reluctant agreement of management).
More Dreaming, Less Typing
Your development team is a problem-solving machine, and engineers don’t solve problems by sitting at a computer and typing. They only do that at the end, after the actual work is over. If you want to innovate, give them the freedom to get creative!
