It's becoming increasingly obvious to me that the majority of people don't use the right tools in their professional lives.  I can understand that most people aren't as excited about trying out new technology as I am, and it seems reasonable for these people to stick to what they know in their personal lives.

There is no excuse for this when it comes to your job.  Even if you love what you do, it's still work and the main point is to either make as much money as you can or to make enough money while having little impact on the rest of your life.  In either case, what excuse do you have for not using everything at your disposal to increase your production?

I know a number of people who do nothing but sell things to consumers all day.  They work mostly independently and are responsible for their own processes and operations.  These people for the most part use some combination of excel, post-its and notebooks to store all their important information.

These people could without a doubt be much more effective sales people if they upgraded their tools.  Whatever the cost is of leaning a new system, it would easily be worth it given the opportunity cost of the current system.

Anyway, I just think we should all stop and think every once in a while.  Think about the ten most tedious, error prone, or inefficient aspects of your work life.  Chances are good there's a way to fix a couple of them by simply changing your tools.  

I'm not exempt either.  I need to figure out how I can get SVN version control and FTP deployment out of my life for good.

Hopefully this will be a big month for me.  We're starting some really cool projects at Zane Benefits and we're expecting to see increased returns from some of our old ones.  It's hard not to get excited about the momentum building both at Zane and the healthcare system as a whole.

I've also got two weeks left to finish the freelance project I started last month.  Then I need to start full time on cbBlitz, the fantasy football site I started with my brother last year.  There's a lot going on.

Ok, so to avoid getting too emo with this post, I just want to mention something interesting I've noticed as my work load has gone from reasonable to OMG HOW WILL I FINISH IT ALL!!!!

Every time I take on a side project I worry that it might hurt my production at Zane.  Oddly enough, I think I get more productive at Zane the more work I have waiting for me at home.  I think I've boiled this down to two things:

1. Fast Pace - It's kind of hard to go back and forth from leisure to discipline.  It's easier to wake up early every day rather than just one day a week and I think the same thing applies to the rest of your life.  The past couple of weeks I've been doing things non-stop (a trip to St. Louis, a trip to Zion, work, side-project, blogging, mountain biking...) and it's a piece of cake to keep it going once I have momentum.
2. Cross Training - In sports, athletes train outside of their discipline to help keep themselves balanced.  I'm finding similar results by working on dramatically different projects all at the same time.  When I finish programming, I'm refreshed and ready to blog.  Then I'm ready to design.  By taking on extra work, I'm making my day job less monotonous.  I've also learned some really great things from side-projects that I've started incorporating at Zane.

My point is, I'd be less productive if I only focused on my full-time job.  I work slightly fewer hours than I would without the other projects, but I get a lot more done with the hours that I do spend at Zane.  I hope to start a company one day.  If that ever happens, I'm going to encourage every employee to take on projects outside of work.

What do you think?  Have you had similar experiences?

I posted last week about how feature bloat can ruin software.  Adding lots of small features to a project doesn't just add harmful bloat, it slows down real improvements.

Several times per day something comes up where five minutes of coding could significantly improve our software.  When this happens, I add that idea to "the list".  Everyone at the company knows that when something goes on the list, there's no telling when (or if) it will ever be completed.

I'm going to use this post to defend that way of doing things.  It's really easy to say, "but it would only take five minutes.  Why don't you just do it now?"  The simple answer is that while one individual improvement only takes five minutes, I have about 200 small things on my list.  If a developer stops to make every little tweak imaginable, the software will suffer.

No amount of tweaks will ever add up to have the impact of a well planned and carefully implemented week-long project.  This is one of those situations where the whole is greater than the sum of its parts.  One block of five minutes is certainly better spent on a small fix than a week-long project, but a week of small fixes can't compare to a week focused on one important problem.

Additionally, it may only take five minutes to complete a small project, but it could take 30 minutes or more to get back in the flow of whatever you were working on before the interruption.  It's hard to say "no" to little things, even if only temporarily, but it's irresponsible to let yourself become distracted from the real work.

And that's what the title of this post is talking about.  Just because something only takes five minutes, you should still treat it like a project.  You should still put it on a list and prioritize it just like you would a month-long project.

Each day I get into work and decided what I should spend my time on.  This is based on which projects I think have the best chance of improving our customers' experiences and help our company grow as a result.  When that idea for a small tweak that would make everything better comes in, I have to remember that I'm working on my current project for a reason and that's because it's the most important thing right now.  The tweak can wait.

There's a pretty easy compromise for programmers.  We generally deploy new code every Friday evening.  I don't want to get into the details of our version control system, but deployment is a lot easier if I don't start any other major projects until the old ones have already been released.  That means that if I finish a couple hours early on Friday, I can spend that time checking items off "the list".  This is a great way to make sure that the little things get fixed but that they don't take over my week.