When I was a solo founder, I found I needed a way to structure those vast stretches of unstructured time to ensure I balanced getting done everything I needed to with switching between various tasks, and avoiding burning myself out. I found it worked best to manage my work hours during the day using a variation of the Pomodoro Technique.
For those unfamiliar with it, this technique has you break down your working time into 25 minute sprints where you focus exclusively on work (i.e., no bathroom breaks, no getting coffee, no checking Facebook, etc.) with 5 minute breaks in between. During the breaks, you can do whatever you like, and every fourth break (i.e., every two hours), you take a 20 minute break.
I find this immensely useful, but I’ve needed to make some changes for it to work best for me. First, I use 30 minute work periods and 7 minute breaks. I like the 30 minute time because it makes it easy to figure out how much time I’ve worked in a given day. I find a good pace for me is between 4-6 hours (or 8 to 12 pomodori) each day. Second, I use 7 minute breaks because that’s how long it takes me to brew a pot of coffee.
However, there are plenty of times where my day just doesn’t break down this way. It could be that I have meetings to attend, or I’m working on something very intense and I feel I need a longer break, or whatever. In that case, I still hold myself to the discipline of being focused during each pomodoro, but I allow myself longer breaks in between. I also keep track of how many pomodori I’ve completed during the day, and hold myself to getting to at least my minimum number, but no more than my maximum (to avoid pushing myself too hard).
I’ve found this pattern works extremely well for me. 30 minutes on, 7 minutes off. Take longer breaks as needed. Set a minimum and maximum number of work periods for a day, and stick to it.
As a solo founder, there were a lot of times when I felt very conflicted about an important decision I needed to make. As an engineer, I often find myself vacillating on some tradeoff between various approaches to a problem. As a programmer, I (all too) frequently find myself stuck trying to figure out some weird bug.
In each of these cases, my natural inclination is to stick with it, and struggle through the problem until I’ve got it all worked out. Sometimes, this can even go on for hours late into the night. However, I’ve become convinced that’s really the wrong approach.
After much painful experience, I’ve taught myself to step away from my desk and go for a 20 minute walk when I find myself in that situation. While walking, I don’t particularly try to solve the problem (though I don’t deliberately avoid it either). Whenever possible, I ask my wife to go along with me.
That 20 minutes away, and especially the mild exercise and change of scenery, resets my brain. When I come back to the problem, I’ve forgotten all of the little details of exactly where I was with it, and I have to start over again. While this seems extremely counter-productive, it’s actually extremely helpful. The process of having to pick up the pieces again resets any erroneous assumptions I’d made about what I thought I understood about the problem, and it forces me to check my premisses about exactly what I think I know. Nine times out of ten, this is exactly what I need to get back on track.
I’ve recently started using JSDOM for testing my client-side code. While I’ve been very impressed with how simple it is to set up, and how fast it is, there has been one major obstacle which I didn’t see documented anywhere else: it doesn’t actually lay out the HTML elements.
width, or other such attributes to the elements. They are perpetually all zero.
Despite this, you can do a lot of rigorous testing, and in a way which is completely identical to how your might set up server-side tests. In fact, I use exactly the same project & test set-up for testing both my regular Node.js modules as I do for the client-side ones. All you need is a little bit of pre-test set-up code to construct the JSDOM window and load a test page, and you’re ready to go.
However, if you want to write tests which verify the layout of things, you’ll need to use another solution.
You’re likely here because you know me, and I shared this site with you. Chances are, if you’re not one of my friends or family, we work together, and I mentioned that I occasionally like to write about things which occupy my mind. Mostly, that’s to do with my work, but occasionally will stray to my hobbies as well.
One of the main things which fascinates me is the relationship between epistemology (how the mind works), and how to write better code. I firmly believe that poor coding style, consistently applied, is better than a free-for-all. However, I also—even more firmly—think we can do a lot better than that. Deliberately matching up how the human mind works with how we write code can yield objective answers to what are generally thought of as subjective preferences in coding style. You can expect many posts exploring that subject here.
I’m also fascinated by trying to improve the processes in our daily lives. This can be anything from brushing your teeth to managing a team. Of course, just the word “process” has a stigma against it as guaranteed to make simple things complicated. I couldn’t disagree more. Process is merely the way something gets done, and a good process is one which minimizes the effort required. This has lead to a strong passion for Getting Things Done (GTD), and I’m sure that will come up often as well.
Finally, there are a bunch of other things which occupy my time and my thoughts: being a good husband & father, listening to and playing jazz & classical music, woodworking, and playing Minecraft. You may well see posts on all of those subjects as well.
So, if any of that appeals to you, bookmark, subscribe, follow, or otherwise just keep an eye on this space.