Being my own boss has some definitely advantages, like being able to take a beach day on a whim or go to watch one of my daughter’s dance classes. The unfortunate side of that is that you still have to manage your time if you want to get shit done. Being a one man wrecking crew that runs a dozen social sites while attempting to build my brand as a blogger has it’s challenges. Fortunately, I’ve figured out how to schedule my weeks in such a way that I am not only constantly shipping, but even on a slower week I can feel accomplished by lunchtime on Monday.
Because it’s just me, I can survive without buzz words like “Scrum”, “Extreme Programming” or “Agile”, the only thing that matters to me is shipping. No meetings, no pairs, no “masters”, just me. But that doesn’t mean that I don’t employ some of those techniques, specifically sprints and backlogs. Before I get to that, let me give you a rundown of my typical week.
Monday
I like to refer to Monday as “Blog Day” as that’s what I end up doing first thing in the morning before lunch. By lunchtime I’ve posted something to my blog and can feel accomplished that something got done this week, even if the rest of the week goes sour. After lunch I start on whatever project I have planned out for the week.
Tuesday – Thursday
Tuesday through Thursday as usually about the same. Sometimes I bike up to my office (weather permitting) other times I work from home. The work is just a continuation of what I started on Monday. I try to be done with the week’s tasks by Thursday so that Friday is more in my favor.
Friday
Speaking of Friday, this is my “free time” where I generally just work on something that’s unrelated to whatever I was working on earlier in the week. This can include responding to emails, toying around with my blog or researching something. There are weeks where Friday is overtaken by working on whatever I had planned just because I was on a tear or because I was feeling behind and want to catch up.
Saturday & Sunday
I try not to work on the weekends, but that doesn’t always work out how I’d like. Sometimes I’m on a huge roll and just want to keep driving to completion so I try to catch a few hours to work on the weekend. Often times the weekends are just full of gaming and hanging out in the yard and stuff like that.
So that’s a vague overview of how my week works, but there’s more to discuss in regard to how I plan my workload for the week. Also, I’d like to point out that Monday through Thursday I do have a tendency to work in the evening a bit after our daughter is in bed. A “workday” for me can be anywhere from 4 to 10 hours depending on if there’s one of those spur of moment beach days in there 😉
Project Sprints
I like my projects to be broken out into sprints that last one to two weeks max. Each project is broken down into very small tasks that should take no more than a few hours. These tasks are loaded into a milestone in GitHub Issues so that I can keep track of my progress and because it’s a ton easier to close issues from my commit messages.
As mentioned, ideally I like to be done with a sprint by end of day on Thursday. Often times I will push off some tasks just to be able to close out the milestone if they aren’t necessarily mission critical (backlog if you will). Because I have a constant backlog of bug fixes and new features and ideas, there’s always something to be working on. Because it’s just me, there are no meetings, the exception being bouncing ideas off of people over instant messenger.
Bug Fix Sprint
One thing that I really hated about every place I’ve ever worked is that it was always a challenge to find time to go back to older code and refactor and/or rewrite it. I always say that time breaks all code, so I’ve made sure to give myself that time to rework older systems on my sites. I don’t necessarily plan for it, but every few cycles I do a bug fix sprint to handle the trivial bugs which often times leads to major rewrites and improvements to my codebases.
Having a cycle dedicated to bug fixes also allows me to stay focused on new development instead of being dragged down by trivial bugs. Often times my users are the ones that prioritize the bugs just based on how often it’s being reported. One or two people, no biggie, push it off. 20+ people? Yeah may want to fix that now.
Project Planning
Even without meetings a certain level of planning has to go into all of this. For my blog I like to keep a set of draft topics. For my other sites, I like to take some time a few times a week to organize all of my issues into milestones and start slapping dates on them. They do change around a lot so nothing is ever set in stone.
I’m sure at least a few folks are thinking “why not just work down the list, I mean all the work has to be done anyway, right?” That is actually a very true sentiment, but it doesn’t necessary lend itself to giving me a sense of accomplishment. Sure, every action item could be closed out, but seeing the meter filled and the milestone closed is a ton more satisfying for me.
Coping with Email
Like foosball, email is the devil. I keep an eye on my email at all times, but I don’t generally respond to anyone until I have at least a handful of emails to answer. Then at the end of the day I can sit down and knock out all of the emails in one shot and not have to worry about being side tracked while I’m attempting to get some work done during the day.
Ship or Die!
I know that my workflow isn’t for everyone, but I know that it’s been working for me for over 6 months now. I’ve been consistently shipping blog posts for 3 months straight now (quite possibly my longest stint ever) and I deploy code multiple times a day most days.
In the past I have tried things like the Pomodoro Technique and quite frankly, I don’t think it works well for programmers since it can disrupt you once you get into the zone. At this point, if I get into the zone, I run with it. If I’m having trouble concentrating or shit just isn’t working right, I take a break or switch gears to something else until I’m ready to get back to it. Since I only have to answer to me, it works!
