Experimenting with waking up early to work on side projects

In the past when I’ve worked on side projects it’s been primarily on nights and weekends. Between school and work, I never had time for them during the day and because I’m not much of a morning person, nights and weekends always worked better.

When my son was born about three years ago, a lot of the time that I would have put into side projects went towards trying to be a good dad to him and now also to my daughter. This led to less time during the week because after I would get done with work, I would spend time with them and after they would go to sleep, I wanted to spend time with my wife and relax. I also can’t stay up too late because I needed to get up with the kids in the morning. Similar story on weekends.

This has led to my side projects time dropping from maybe 10-15 hours/week to only 3-4 hours/week for the last several years.

Inspired by my friend and coworker Dave Martin, I’ve started experimenting with waking up early to work on side projects. Not 4am-5am like him (!), but just at 6am. That gives me 1 to 1.5 hours to focus on side projects most days. I take Saturday off and also wind up skipping some other days, but it’s probably doubled the amount of time I put into side projects to around 7-8 hours per week.

To make this work, I’ve also had to adjust my evening routine. Instead of going to bed around 10:30pm, I try to be in bed by around 9:30pm to make sure I get in 8-9 hours. I wind up watching less Netflix, but don’t feel like I’m missing anything important.

And as a side effect, I’ve found that I’m sleeping a lot better now that I’m no longer jumping straight from coding into bed a lot of nights. All too often I’d just lie there for hours waiting for problem solving mode to turn off. Now I read and it makes it much easier to fall asleep.

If you typically work on side projects at night like I did in the past, I encourage you to experiment with waking up and going to bed early for a few weeks to see how it works for you.

Building vs Buying Software

At Automattic and now at Help Scout I’ve been involved in several discussions about the merits of building something internally vs paying for a third party SaaS tool or plugin. Examples include the internal analytics platform Automattic (which we wound up building ourselves) and a business intelligence tool at Help Scout (which we wound up buying).

If you’re lucky it will be an easy decision, but more often than not there will be pros and cons to both approaches that you’ll have to weigh. Some of the factors include:

Do you have the engineering resources and know-how to build it? If not, you’ll obviously have to buy.

How much time will it take to build? As anyone who has built software knows, estimating how much time it will take to “complete” is often incredibly difficult. A one month project could easily turn into four after all is said and done. The more complex the project and the longer it will take to build, the more you should lean towards buying.

How much does it cost to buy? The cheaper it is the more it makes sense to buy.

How much will it cost to build? At first this might seem like $0, but engineers are expensive. A developer making $120K/year might be $180K/year fully loaded (with benefits, taxes, etc) or $15K/month. Several developers spending a month on a project can easily cost tens of thousands of dollars. And that’s not even counting PMs, designers, and anyone else involved in the project. It’s tempting to think “we have to pay them anyway so it doesn’t really cost us that”, but it’s not so simple once you consider what other revenue-generating projects they could be working on instead (and you don’t have to employ them anyway). There’s a real opportunity cost to building something internally.

Does the thing you’ll buy meet all of your requirements? If it’s critical that the software do something and the SaaS you’re considering doesn’t do it, you’ll probably need to build. However, you might be better off paying for a tool that is 90% of what you think you need vs spending weeks or months building something that might be 100%.

What other capabilities does the tool you’ll buy provide? While you might be able to build something that meets your minumum requirements, a tool you buy is likely going to do a lot more than the minimum. You may not think you need those extra features now, but there’s a good chance that you will later. At that point you might have little choice but to keep iterating on what you’ve built which can easily extend the duration of a project.

Is it important to own the data? Third party tools will likely collect user data which may be a concern both from privacy and analysis perspectives.

How likely is it that the third party solution will exist in 5 years? And are there alternatives you could switch to if that hot-new-startup you pay for shuts their doors in six months?

Are you building this as a long term investment? When we were considering whether to buy or build Automattic’s internal analytics platform one of the factors was that we planned on Automattic existing in 10, 20+ years so it made sense to invest time building something that we could use for the long haul. Be skeptical with this one though: while we might hope that whatever we’re working on now will exist in 20 years, the reality is that it probably won’t.

I usually default to buy unless there is a compelling reason to build. In my experience software usually takes much longer to build than initially expected so it winds up making more sense to pay for a 90% solution that you can have immediately and devote those engineering resources to the core business. But again, it’s often not so simple in practice and there can be reasons to build instead (full control over the features and design, ownership of the data, cost, etc).

I’d love to hear about your experience buying vs building. Was there ever a time you built something that you later regretted or vice versa?

More hours != more results

I used to play a lot of online poker and thanks to a combination of third party analytics tools like PokerTracker and ones I built myself, I was able to gain a lot of insights into my own play.

For example, the generally accepted best time of day to play online is usually late at night because that’s when people are the most tired and therefore make poor decisions. I once looked at how much money I made per hour broken down by hour of the day. Because I played a lot at night to take advantage of the poor play by others, I expected my highest hourly rate to be in the evenings and early morning. But the numbers told a different story: my hourly rate after 11pm was about break even. After countless hours of late night play, my overall profit would have been the same had I not played at all after 11pm.

Turns out that even though others were playing poorly during those hours, I was too, which negatated any advantage that I had.

The late night play also took its toll on my wellbeing during the day because I’d inevitably be tired from staying up late to play.

I bring this up because the experience taught me that working harder often isn’t the solution to a problem. It’s tempting to think that you can just put in more hours and you’ll achieve more results, but if the quality of your work suffers you might not make any meaningful progress or worse, you could undo the previous progress you made.

Next time you catch yourself trying to push through on a task even though you’re not feeling 100%, consider taking a break until you are.

A 70/20/10 approach to time management

If you have a lot autonomy in your job to choose what to work on, it’s worth spending some time thinking about how to effectively choose tasks and distribute your time among everything you have to do.

Lets say you have three tasks:

  1. Task A (High Priority)
  2. Task B (Medium Priority)
  3. Task C (Low Priority)

In this example, it’s clear that you should work on A, then B, then C.

But in the real world, each task takes a certain amount of time and that can complicate things. If you’re lucky, it looks like this:

  1. Task A (High Priority, 1 Day)
  2. Task B (Medium Priority, 1 Day)
  3. Task C (Low Priority, 1 Day)

In which case you should still do A, then B, then C.

This also works when the shortest tasks are also the highest priority tasks:

  1. Task A (High Priority, 1 Day)
  2. Task B (Medium Priority, 3 Days)
  3. Task C (Low Priority, 1 Week)

But what happens when the highest priority tasks also take the most time?

  1. Task A (High Priority, 1 Week)
  2. Task B (Medium Priority, 3 Days)
  3. Task C (Low Priority, 1 Day)

Is it still true that you should work on A, then B, then C?

We can test our principles by looking at how well they hold up under extreme circumstances:

  1. Task A (High Priority, 1 Month)
  2. Task B (Medium Priority, 1 Week)
  3. Task C (Low Priority, 1 Hour)

Should you still work on A then B then C when A will take a month and C will take an hour?

Probably not… but you also shouldn’t just work on your shortest tasks first either. You could wind up spending a lot of time working on low priority tasks without spending time on things that matter.

I’ve found that a 70/20/10 approach works pretty well:

Spend 70% of your time on your high priority tasks, 20% of your time on medium priority tasks, and 10% of your time on low priority tasks. In a standard 5-day work week, that works out to be 3½ days on high priority tasks, 1 day on medium priority tasks, and ½ a day on low priority tasks. And if you have multiple tasks with the same priority, work on the shortest ones first.

That will ensure that you’re spending most of your time on the things that matter, but still are making progress on the medium and low priority tasks that need to get done as well.

 

 

 

 

 

Effectiveness

If you followed me back in the day while I was working on my failed Lean Designs startup, it probably would have been hard to tell that things were headed in the wrong direction. Even for me, it took a long time to realize how many problems there were with the idea and execution.

I’ve thought about that a lot since then. It’s really hard to observe something and evaluate how things are going based on activity alone. Activity is necessary and important, but only if it’s applied effectively.

How can you tell whether activity is effective? Looking ahead, it’s difficult unless you have a deep understanding of the problem and the possible solutions. For example, it might have seemed like setting up an LLC and having a logo designed for Lean Designs were important tasks, but really they weren’t. If you’ve built an online business before you might realize that, but if not it would be tempting to look at the completion of those tasks and think I was making meaningful progress.

Looking backwards is a bit easier. Compare your current results for some goal with where you were a month ago, six months ago, a year ago. Have you made progress in whatever metric that matters? If your goal is to build and grow a SaaS startup, have you launched? What do your growth and retention rates look like? If you’re trying to lose weight, are you? If you’re trying to write more often, have you been?

It’s tempting to want to explain why when the results aren’t there. In the short run, there can be a lot of valid reasons why things aren’t going well. Bad luck, illness, etc etc. But the further back in time you go, the harder it becomes to attribute the lack of results to these types of factors.

If you look at where you are today with a goal and your results haven’t changed from six months ago despite lots of activity, it’s worth taking a step back and trying to identify the root cause. Ask why a bunch of times. Maybe there is a valid reason, but in my experience it’s often something more fundamental. Maybe I’m not as motivated by the goal as I thought which is causing me not to put the effort into it that is really required. Like with Lean Designs, maybe my entire approach is wrong. Maybe I shouldn’t have been working on Lean Designs in the first place.

And to be clear I’m not saying the ends justify the means. Just that results are important when goal-setting and the longer you go without meaningful results, the greater the odds are that something is fundamentally wrong with the goals or the execution.

Put another way, if I’ve been working on something for a while and the results aren’t there, I’m probably doing something wrong and need to re-evaluate my approach.

This might be obvious, but it took me a long time to really internalize it so I wanted to share in case it helps anyone.

Would love to hear your thoughts.

JavaScript Dates with Moment.js

One of the biggest frustrations developers deal with is working with dates. For an excellent overview of why dates are so complicated, check out JavaScript dates, trains, Passover, and Henry VIII by Curtis Autery.

When it comes to working with dates, JavaScript will make you want to hit your head against your desk. Even for simple tasks, working with JavaScript’s Date object can be a major hassle. It lacks a lot of basic functionality that you’d expect like being able to format a date/time a certain way, adding or subtracting from dates, working with locales, and a lot more.

There are hacky ways to accomplish these things as the thousands of StackOverflow posts about JavaScript dates can attest, but save yourself the trouble and check out moment.js.

Moment.js is an awesome library that makes working with dates in JavaScript a lot less painful. Dare I say it, maybe even enjoyable. Rather than give an incomplete introduction to its features here, scroll through the Moment.js docs page to see everything that you can do with it.

And next time you find yourself writing new Date in your code, take 30 seconds to download moment.js and save yourself hours of frustration.

Busyness implies unclear priorities

In Tim Ferriss’s recent interview with Derek Sivers (transcript here) there’s a really interesting discussion on the idea that being busy implies a lack of control and unclear priorities:

Derek:

Every time people contact you, every time people contact me they say “I know you must be incredibly busy”, and I always think “No, I’m not.” Because I’m in control of my time. I’m on top of it. Busy, to me, seems to imply out of control, you know? Like “Oh my God, I’m so busy! I don’t have any time for this shit!” To me that sounds like a person who’s got no control of their life.

Tim:

No control and unclear priorities.

Derek:

Yes! Exactly. So you asked how it’s applying in my life: on the little tiny day-to-day level, even personal things, even people you meet, even as I’m dating, you have to do the hell yeah or no approach. People ask you to go to events or even people asking to do a phone call or anything. I think “Am I really excited about that?” Almost every time the answer is no. So I say no to almost everything.

As someone who feels busy a lot, this really resonated with me. I’ve accumulated too many things, too many projects, and too many time commitments because I don’t say “no” often enough.

Here are a few work related changes I’m making to try to help:

  • This morning, I left about 25 Slack channels at work. I normally have two groups, one of favorited channels whose disucssions I try to read completely and another larger group of channels that I’m in but don’t try to read completely. I left almost all of the channels in the second group and several from the first. While this won’t free up a ton of time because I wasn’t reading the channels in the un-favorited group anyway, it did declutter Slack a lot which will help me focus more on the discussions that are important to me.
  • I attend several regular virtual hangouts at work that aren’t directly related to what I do on a day to day basis but I usually attend anyway just for awareness of what’s going on at other areas of the company. Some of these aren’t “hell yeah” meetings for me (to use Derek’s terminology) so I probably won’t attend in the future I’m needed.
  • I was following 51 P2s (internal blogs) at Automattic, but many of those were left overs from when I was part of a different team (I was on the Store Team but am now on the Data Team). I unfollowed a bunch, bringing my total to 36 30. Automatticians: there’s an easy way to figure out how many P2s you follow – ping me for details.
  • I uncommitted myself from some projects to allow me to focus more on the projects that are really important to me and to the company. I was a bit uneasy going into the “I no longer want to work on this so that I can focus on these other things” conversations, but folks were understanding and I’m really glad now I did it.

I imagine this exodus will looked pretty suspicious to any coworkers that happen to notice, but rest assured I will be returning after Christmas vacation :).

To wrap up: if you find yourself overwhelmed or busy all the time, try cutting a few things. It might not be easy, but you’ll likely find yourself much more relaxed as you decrease the number of things your plate.