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.
