One of my coworkers, Luca Sartoni, is trying an experiment this month: every day his goal is to publish a post on his blog but spend no more than 10 minutes writing it. He sets a timer when he begins and at the 10 minute mark he puts a quick final polish on it and hits publish.
I really like that approach because it forces you not to overthink things. The majority of recent posts on this blog took a long time to prepare (I’m looking at you, backpropagation tutorial) and while I enjoy writing longform technical posts like that, if I limit myself to those then it’s unlikely that I’ll post very often. This year, for example, I’ve only published 8 posts which is less than ideal considering I work for a blogging service :).
I’ve tried this before, but always wind up falling back into the trap of spending too much time on the posts which leads me to not write very often. So lets try this: Joel, Ryan, and Adam, oh great coworking buddies, if I go more than a week between posts or if I start only publishing long posts, I’ll buy you all coffee next time we meet up. Hold me to it!
I make a mistake fairly frequently where I attempt to solve problems without fully understanding them first. The process almost always goes something like this:
- There is a problem that needs to be solved.
- I mistakenly assume that I know enough to solve it.
- I spend a lot of time trying to solve it.
- I eventually realize that I do not understand the problem well and that my solution does not actually solve it.
- I start over and make sure I understand the problem before trying to come up with a solution.
- With a better understanding of the problem, I’m either able to come up with a good solution or realize that I’m not able to.
I can think of many, many examples where I’ve fallen into this trap.
Lean Designs, a web design tool that I spent more than a year building, fit this perfectly. I thought I understood what features designers wanted in a web design tool and then confidently proceeded to build it without talking to any actual designers first (doh!). Only after a lot of time and money did I realize that I had made a lot of faulty assumptions and that the tool I had built did not solve any problems that designers actually had.
I’ve found that while managing people it’s easy to make this mistake too. For example, I once supervised two Airmen who fought constantly. I had heard from a co-worker that one of the Airmen, a young woman, thought her co-worker, a guy, lacked the technical skill to be in the position he was in. Without talking to either about the underlying issue, I assumed that this story was true and tried pairing them together so that they could learn from one another. When that didn’t work, I sat down with each person individually and learned from the woman that at some point in the past the guy had said something that made her think he was a racist (she was black and he was white) and that had caused her to be hostile towards him, which in turn caused him to be hostile towards her. When I asked the guy about this, he assured me he wasn’t (and I believed him) and he later apologized to her and from that moment on they got along much better. My first solution, pairing them together did not solve anything because it was attempting to solve the wrong problem.
For another example, just yesterday a coworker asked me for some help with a library that I had worked heavily on in the past. I quickly glanced at his code and confidently offered a few suggestions on how to improve it. He made the changes and was ready to deploy them when something caught my eye and I realized that the library might not be necessary in the first place. We wound up coming up with a much simpler solution that didn’t use the library at all.
If you find yourself making the same mistake, I try to remind myself that there’s no rush and that I’ll usually save time by making sure that I thoroughly understand the problem well before trying to come up with a solution. If you’re helping someone else, they’ll likely appreciate it too :)
A few weeks ago I decided that I wanted to write here more often, but I found it extremely difficult to come up with anything to write about. It’s not that I don’t have anything to say or share, but that none of it seemed worth saying or worth sharing.
After thinking about it for a while I realized that most of the writing I’ve done over the last few years has been focused on marketing the products I was working on. When I wrote something it was with the goal of making it to the front page of a site like HackerNews. The title had to be optimized for maximum SEO impact, the content had to have charts and numbers and insights that people would find valuable and worth sharing. As a result of this must-make-it-to-the-front-page mentality, the bar for what should be a blog post became set very high. If it wasn’t likely to get several thousand new visitors, it just wasn’t worth writing.
I’m going to try something new. Instead of a few big posts here and there I’m going to try to write shorter posts more frequently. At least in the beginning, nothing should take more than 15 or 20 minutes max to write. One word titles are fine, quotes are fine, pictures are fine. Anything goes. By writing more often I hope to become a better writer, share a bit of what I’m learning, connect with new and old friends, and perhaps benefit from some of your perspectives on whatever I’m writing about.
I’ll finish up by quoting a short story that I first saw in a post on Derek Sivers’s blog called Does quantity + learning = quality? which neatly summarizes why I think shorter posts more frequently is a good approach:
The ceramics teacher announced he was dividing his class into two groups. All those on the left side of the studio would be graded solely on the quantity of work they produced, all those on the right graded solely on its quality.
His procedure was simple: on the final day of class he would weigh the work of the “quantity” group: 50 pounds of pots rated an A, 40 pounds a B, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an A.
Well, come grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity!
It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.