Hiding behind the Busy Work

Your plate is full, there is a ton on it, so where do you start?

With the menial garbage?  Yeah, go work on that first, go work on the stuff that is cluttering your plate and keeping you away from the good stuff… it’s work that’s on the periphery that is taking up space in your head and slowing you down.

And it’s easy, it makes it look like you are working, but you are really not, you’re hiding – hiding from the work that matters, that will make an impact that will take you to the next stage.

But it’s easy and when you step back it looks like you did a lot, but really, you just worked away at the easy stuff, avoiding the hard stuff.

The thing about easy stuff is that it never goes away, it always finds a way to get back onto your plate, to start taking up space.  But the hard stuff, the stuff in the middle, what if doing that first had the bigger impact – it’s riskier, harder, you have to slow down and think – you just can’t do.

But you can plow through it.

Think of your plate as a meal when you were a kid – would you eat all the amazing food first – the steak and fries – only to agonize over the asparagus and broccoli, taking forever to eat it all and leaving the table with that taste in your mouth?  That taste of – “I left the hard stuff for the end and this would have been simpler if I did the easy stuff first” –  Or would you eat the broccoli first and finish off with the steak or perhaps eat both in tandem?

When I was a kid, I always left my broccoli for the end, but now I’m learning to eat my broccoli first.

Note: Substitute whatever foods you want, sorry I’m not a broccoli lover.

The Flattened Table Pattern

Years ago I attended my very first technical conference, SqlPass.  I was only a DBA for a few months at the time and it was a very last minute adventure.  I would spend the next 3 days at this conference becoming inundated with all things SQL Server surrounded by peers who had been doing this for much longer (I had only been a DBA for 3 months).

The only session I remember from that event was this guy (sorry don’t remember the name) who got up on stage and talked about this big project he did for this restaurant review site and how he had to process millions and millions of records in an OLTP (Online Transaction Processing – think Shopping Carts) fashion and make them available to the website in a very quick and efficient way without dropping performance.

He had to denormalize the tables and he did it.

I remember the scoffs from the crowd, “how could normalization be broken”, “how could you go against everything we hold dear”… I, as the newbie on the scene, watched the arguments go back and forth but this speaker’s answer to it all was perfect – “It just didn’t work”.


Years of experience, years of patterns and practices and “it just didn’t work” silenced everyone.  He walked through why he had to make the changes and where the benefits came from.  He didn’t advocate that this was how to solve everyone’s problems, but he did advocate that this how to solve his problem.

I think of this often when I hear people scoffing at someone’s design because it doesn’t follow the design pattern du jour.  Sure design patterns are great, they give you a path, they give you an idea, they give you a starting point but at the end of the day ask yourself what you would rather have – “A system built on a design pattern that is constantly requiring maintenance and changes to keep running” or “A system built without a pattern or practice, maybe the code looks a little dirty, but it runs like a machine, never stopping, never needing to catch it’s breath or have a bug logged against it, it just works”.  That’s how you should code – to make it work.

The Caring Call Centre?

I had to make a call about a month ago to an ISP when a site I was working on went down in the middle of the night with no warning.  My first fear was that all of our data had been deleted and I did not know anyone who had a backup.

I called up the ISP and miraculously got someone on the phone and spoke with them.  At this point in time, my heart was racing, my anxiety levels were through the roof and I felt a large hammer precariously positioned over my head.

Whilst on the phone, the agent said all the correct things to try and talk me down off the bridge… all the correct things… from a script.  Not too mention, I knew the call centre was not where I was and as I pleadingly talked with the agent about the importance and concern over the data, I knew my concerns did not fit into their script.  So left the call with my ticket #.

The next day, after almost 15 hours of downtime, our site was restored and all was up and running – the agent even reminded me that – “see we told you nothing would be lost and now it is back up”.  Even though all has been working fine since then, it is the script that still lingers in my mind, what if the problem went outside of the script, what if the site didn’t come backup, what if my data was accidentally deleted?

Even though the script “showed” and “proved” that they cared, it didn’t instil the confidence in me that they were really caring for me and problems and in the end that I really just got lucky this time.

It’s Always The Same People

It’s Always The Same PeopleGood.

I hear this phrase a lot – “It’s always the same people stepping up, someone else needs to step up”.  Sometimes I am that person, sometimes I hear it said of others, each time I say the same thing…


Whether it’s for the love of what you are doing or the need to make it happen for others.


At the end of it all, those people are going to the ones that leapfrog, surpass, struggle and push because they were willing to go the extra mile to make something extraordinary happen – whether its in family, career or somewhere else in life.

I don’t feel bad for those same people, I raise my glass to them.

Service Restarts Go Boom!

Want to throw a wrench into someone’s day?  Assign them a critical production bug.

Everything they had planned for that day just went out the window as they now to try to identify, isolate and solve the problem.  Sometimes it’s obvious, sometimes it’s not and the time it can take to resolve can go from an hour to the entire day.

Want to throw a grenade into someone’s day?  Tell them they have to restart a service or reboot the system for this production bug to be resolved AFTER a change to data has been made.

There is nothing that drives users or release managers over the edge more than having to restart your crummy service all because you had to change a configuration file and/or update a database table.  And yes, I am going to call it a crummy service because there are so many patterns and libraries out there that it is so easy to wire an event to a configuration, listen on the event and reload and/or set a time to refresh your cache.

IT guys love, love, love self-healing services that when they fall over restart, when something changes they reload.  In short – they just don’t do, they think.

Want to impress someone with your amazing coding skills?  Ask them (IT) to update the logging flag on your service so you can see the debug statements coming out and identify what is really going on in the service, all while not affecting a user’s ability to interact with and use the system while you are working on it.

It’s something small, it might take you an extra day of coding with some unit tests et al (configuration files), other changes maybe a bit longer, but in the end – the work will always, always be worth it.

Don’t believe me?  Just take a look at the guy’s face who needs to make the change on that critical server next time, their smile will say it a.