Hello all,

So, I've been thinking about it for a while now and I've finally decided to redesign this blog.  I think it's well overdue, and I'm sure many of you would agree.

Right now I'm strongly considering going with a design as below and I would greatly appreciate any and all feedback that you may have:

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.

There is a legend surrounding the profession of architects that tells of an architect who designed a marvelous library in which he forgot to take into consideration the weight of the books.  This over sight on his part later caused the library to be condemned as the library gradually sank over time.  Although no more than a legend, it brings to light an interesting topic… When we make a decision and influence all of those around me, what if we miss something?

Well, our profession actually has certain check points that have been instituted to prevent such disasters from happening.

1.       Code Reviews:  This one is the most obvious, but code reviews are highly beneficial for both this check, and many others provided they should serve as more than a Hey, you spelled that name wrong purpose.  Code reviews can act as a final check to ensure that the developers are in fact sane in their design, and not off in la la land.

2.       Unit Tests:  This serves more to prevent someone from going in and changing something, and introducing these types of insights.  With a good set of unit tests covering 100% of the testable code, it is very easy to catch these modifications over sights provided the initial design was sound, and tested accordingly.

3.       Test Driven Development:  Simply put, starting with what the users (internal or external to IT) want, and moving backwards to provide the code can help to eliminate this issue as well.  When we code off in our own little worlds, we tend to add tons of edge cases and this could happen scenarios that no users would ever consider.  This is a mixed blessing because as developers we tend to be very detail oriented, and can often conceive of situations that could never happen in real life.

4.       Peer Programming:  Well, two sets of eyes are, and always will be better at catching bugs than one set… it’s that simple.

At the end of the day, this list is just a small portion of the hundreds of ways we’ve attempted to perfect our profession.  Realistically though, there are by far more failed attempts than successful ones at bullet proofing the art of software creation and it always comes down to one thing, the people developing the code.

Let us consider for a few seconds the scenario about the weight of the books again; lets apply this to software development and analyze just what could have been done differently in this situation.

1.       Code Reviews:  Well, sure if the design was reviewed it may have stopped this, but a good architect can sell any design even to other architects no matter how wrong it may or may not be.

2.       Unit tests:  Well simply put the initial design was flawed.  A good set of tests would have actually tested to ensure that the library would sink with the weight of the books, possibly exposing the issue.  Realistically it was never something which was taken out of the design, so no one would have thought to test it either.

3.       Test Driven Development:  I highly doubt the users would have ever thought to question the architect and ask if he had accommodated for the extra weight.  In fact, most architects would be offended if a user had questioned something like that because it is after all, their purpose to find those issues no one else thinks of.

4.       Peer Programming/Design:  Yes, this would have at least doubled the chance of finding this issue in the initial plans, but it could have slipped through to the end still.  Even peer teams are by no means perfect.

So I guess this kind of exposes a bit of an issue… maybe we aren’t as bullet proof as we think we are?  The only real suggestion I can think of is that we need to take that step back and look at the big picture some times, get our heads out of the code and look at the larger impact of the lines we write.  Maybe one line of code at a time, module by module is not really going to solve our problems?  I guess what I’m saying is when you look at the big picture, sometimes the code really is just a small piece of the puzzle…

Most of us are familiar with the title the ghosts in the machine from the 2004 movie IRobot, in which the phrase is used to describe the little things that happen within computer programs which we will never fully understand.  As a software developer this is something that is slightly confusing as I like to pretend that I know everything that my code does, after all it is the ultimate description of logic.  It does what it does; really there is no other more accurate way to describe code…

Now, this has always intrigued me however because it really is not as simple as I make it seem… I mean, when I wrote the code I knew what it did but when I’m staring at it years later after countless standards have evolved, my coding style has completely changed, and countless other people have been in and changed things it always takes a refresher course to figure it out.  Assuming that I wrote reusable code in the first place, and that the code was reused by several other pieces of code that where again reused by several more pieces of code what I am left with is assumedly a very common application.  This is a good thing; don’t get me wrong… but what happens when the initial code that I wrote decides to step on the toes of the code down the line?

Well it turns out after a simple Googling and a visit to Wikipedia that the same problem has existed for many, many years.  In fact, this issue was brought up by a philosophers hundreds of years ago, and is described in Arthur Koestlers discussion of his 1967 book The Ghosts in the Machine:

One of the book's central concepts is that as the human brain has grown, it has built upon earlier, more primitive brain structures, and that these are the "ghost in the machine" of the title. Koestler's theory is that at times these structures can overpower higher logical functions, and are responsible for hate, anger and other such destructive impulses.

So, turns out the human mind has the same problem as the code that I write.  I’m not sure whether to be honored or scared, but it immediately makes me wonder how far away are we from a time when our software starts to think the same way we do?  I guess it’s easy enough to dismiss that as another one of those Matrix questions, but let me ask you this… how do I know that it doesn’t think the same way I do, and if it does think the same way, how long before it realizes its own consciences. 

I mean, really, how do I know that the guy beside me can think like I can anyway…