It wasn’t all that long ago that I discovered that I had no time to get anything done, but was always busy running this way or that to get everything accomplished.  It took a bit of Googling, but I eventually found this system that seemed to work for me:

1.       Prioritize – Take all of your tasks and put a prioritization next to them.  I labelled them from 1 to 5 with 1 being the highest priority and 5 being the lowest.  Although this seems conceptually simple it really wasn’t once you consider all of the politics that surrounds a developer’s day, all of the outside influences and those dreaded obligations which constantly pop up.  Once you get a good list, move on to the second item.

2.       Toleration – Give yourself permission to stop pretending to be superman and trying to solve all of the world’s problems.  Not to say that a single person cannot make a difference, but I realized that maybe I could not do everything I wanted in the timeline I wanted to.  Once I realized this and gave myself permission to move the lower priority items to a “wish list” life became simpler.  Personally I took everything that was a priority 4 or 5 and moved it to a wish list that I revisit on a weekly basis to check if priorities have changed.

3.       Think like Lego, in blocks of time – So, it’s not rocket science, but it’s often forgotten by most.  We are best when we focus on a single task at a time, for a period long enough for us to accomplish something.  So, with that said I took my task list from above and set aside a reasonable amount of time to accomplish everything, looking at what needed to happen when.  When you do this you have to keep in mind that you want to leave enough time for each task independently of everything else, and also consider when you are your best to do certain tasks.  For instance I’m at my best to read about new technologies early in the morning because no one else is in the office and the chances of me getting disrupted mid-sentence is kind of slim, so for the first hour and a half each morning it’s set aside for reading, followed by half an hour for a blog entry on one of my blogs, and the rest of the day goes from there...

4.       Systematize – At this stage you know when you’re going to do everything; you just have to look at how you’re going to keep your time goals.  Well, the best advice I could find on this said that you should organize the hell out of your life.  For instance make sure your desk is organized so that if you need a stapler you could reach for it without even looking where it is, because it’s always going to be in the same place.  There is no secret that a cluttered desk is the first indication of a cluttered life, so why can’t it work the other way?

5.       The Art of Doing Nothing – Ok, not quite but there is something about making sure you schedule your mental breaks that will greatly increase your productivity.  As a rule of thumb they suggest that you schedule a break every 90 minutes, but I find that being a developer this number is slightly flawed.  I typically schedule enough to have a break every hour, but I take them when I’m at a good resting place.  This works nicely if you consider that for every hour of work, 50 minutes of development gets done and a ten minute break is taken at some point.

And there you have it.  That’s how I went from working on tons of different things, to working on a few short things and actually accomplishing considerably more than before...

Let me start out by defining exactly what I mean by a Successful Developer.  The ideal Successful Developer is one who is loved by management, users, and fellow developers.  I know what you’re thinking, how hard can this really be?  Well, take a look at your own career and think back on how much you’re really liked in these three areas...

Managers typically look for someone who can make them look good.  This isn’t meant to knock anyone who I’ve ever worked for, but rather a simple fact of life.  A developer who makes a manager look good is someone who knows how to play the political game; someone who knows when to open their mouth and when to keep it shut; and finally someone who under promises and over delivers, on time, always.

Well, this is possible I guess, but typically a developer who makes their manager that happy isn’t really a developer but more a Manager in training.  Sure it’s easy to quadruple your estimated effort, promise nothing, and meet the insanely high timelines you’ve set out for yourself but let’s face it, a good developer is the ultimate logical individual.  If it is going to take a good developer one month to do something they will tell you it will take a month... we don’t make things up, life is what it is, nothing more nothing less.

Users are probably the easiest to please.  As long as you’re completely honest and deliver what you promise to them on time they’re typically happy.  Although this is no simple task in today’s political nightmare we consider Software Development, keeping our promises are usually fairly easy, but usually lead to CLM’s (Career Limiting Moves for those of you not familiar).  Again, Developers are very logical people so telling the truth usually comes naturally to us, but makes enemies with those who don’t want the truth.

Now, this is by favourite category because it is the most often forgotten.  I was once told by a lead that he was not here to make friends, that business is business and personal lives are personal lives.  Although this true we have this thing called the community who we have to report to as well.  If I constantly make promises that other developers cannot keep, I make enemies even though I may have believed the task possible. 

At the same time, I have to include myself in this category.  That is, I have to consider how many times I’ve sold myself out because I made a promise, and found myself working countless extra hours on my own time just to make that ridiculous deadline that was imposed on me.  The next time you find yourself on the tail end of a 12 hours shift staring at your keyboard wondering why the keys can’t type themselves take a second to ask yourself just how happy you are with yourself... I bet you’ll be pretty irked about it.

Then there is the maintenance factor.  That so often overlooked “extra” cost that I have yet to find a project team who actually cares about it.  The fact of the matter is simple a project team is there to developer a set of features, on time, and on budget... they don’t care if it takes someone two or three times longer than it should to make modifications after the fact, their success is based purely on their delivery date.  Well, I guarantee you that for every line of code you write someone at some point will have to maintain it.