Plankers: why midnight 00:00 is a dumb deadline

How many times have you heard people tell you that ‘deadline for submissions is midnight on Tuesday’ (or insert weekday of your choice)..?

Sysadmin guru and technology commentator extraordinaire Bob Plankers thinks it’s confusing, if not downright dumb.

Plankers is author of The Lone Sysadmin and in addition to his role as virtualization architect at The University of Wisconsin-Madison, USA.

Suggesting that midnight is a essentially a poor choice of timeslot for scheduling anything, Plankers says that midnight belongs to tomorrow —and that’s not how we how humans think, if we’re focused on the task in hand that is.

The focus of his argument centralises on the face that, in the world of the sysadmin, DBA and for many other operations professionals, midnight is a popular time to schedule automated processes.

“I get it, it’s easy. If you run something at midnight you don’t have to do much processing to separate yesterday from today. The problem is that there’s a ton of stuff already running on the hour, and you’re just piling on. Most people try to avoid shopping when it’s crazy busy, why would you want to run your jobs that way? If you ran your job a bit earlier or later chances are it’ll run faster because you’re not competing with everyone else,” wrote Plankers.

If not that, then what?

Plankers makes a great point, that is – in the contemporary world of always-on software application development we work in a cycle of Continuous Integration (CI) and Continuous Delivery (CD)… so slotting in nightly builds at ‘traditional midnight’ probably isn’t possible anyway and if we do push for that slot it could well cause a log jam.

As we now look to hit equally specific, but more widely dispersed deadlines, Plankers asks us to be strict about how you write your deadline times and use the time & date in the ISO 8601 format to help avoid global formatting issues (YYYY-MM-DDThh:mmTZD).

Thanks Bob, we’ll aim for diversity in every sense of the word.

Plankers: get savvy about your schedules.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

This is kinda like when they hire management that approaches hiring like this, or thinks DevOps is a keen idea - They say, "We don't need a leader with experience, we need a monkey in a suit!". And then we get this.

Here's the hard facts; Generalists aren't attractive because they are passable at many things, and not particularly great at anything. What kind of management says, "I know we have some important disciplines here, but I don't want anyone who is particularly great at any of them." It is because they are cheap. Business loves cheap labor.

A specialist is someone who has made conscious decisions to focus their career to become extremely knowledgeable and effective in their discipline. They are, of course, more expensive - but you also get outstanding value for your money. Most experts start as generalists, so many have a solid background. They just happened to find their calling/talent.

DevOps is the most lighthearted approach to running enterprise staffing that I can imagine. Development and Operations have very different goals. Each is its own unique discipline, and the experience of either is a regimen of conditioning geared toward achieving different goals.

Do I know of any good developers who are good ops? A few, and they are expensive. Any expert developers who are incredible operations folk? Not yet. However, I know plenty of hacks who may be good at one and fancy themselves to be great at the other. That is a problem....

Ever hear 'Knowing just enough to be dangerous?'

If your company is in it for the long term, just staff correctly. Get a few senior experts in the disciplines that are critical to you; You can save money by giving them an inexperienced team to mentor, as per the workload. I KNOW this may cost a little more up front, but you will end up with a staff that knows what they are doing. The value of competence cannot be overstated.

You get what you pay for.

Or have another banana and drive up to the IT day-labor shop. Don't be surprised when IT projects go badly.

Earlier this year I blogged a list of 5 questions to ask at interviews for DevOps-minded staff, which seemed useful to quite a few people:

1. How does HTTP work, and specifically how does a web page appear in my browser?
2. How would you prepare for a migration from one [CMS/CRM/database/hosting] platform to another?
3. What different types of testing need to be carried out on a software system, and what tools would you use to achieve this?
4. How would you make the key aspects of a software system traceable?
5. How would you assess how “deployable” a software system is?
This also is perfectly applied to testing generalists.

In addition to the ways suggested by the article, I'd recommend to pay attention to activities like participation in conferences (especially, presenting and leading), blogging, publishing articles, participation in meetups and research projects.

This is where you're more likely to find self-driven and passionate professionals.
Interesting article, but not much most of us did not already have knowledge of. A lot of good posts on suggestions to enhance the hiring of future prospects. I'd rather have a busy squirrel than a sloth as an employee.
To piggy back on agareev's comment, one of the best ways t help find quality people for any discipline is to see what they do outside of their work world. Granted, not everyone speaks at conferences, not everyone blogs, not everyone contributes to open source projects, but a lot of the best people in their industries do, and if they are not available, they can likely recommend several others who may well be. Start digging into some people's  work, and see what they do outside of the office. That may give some great hints as to who will actually cut it as your DevOps hire of choice (and can be used for programmer, business analyst, tester, etc.).
Thanks, Michael :)

I especially love your point that passionate people ignite folks around them.
"The Goat Farm" podcast and the videos from the DevOps Enterprise Summit do an excellent job of highlighting actual companies (not just unicorns) that have gone through the DevOps journey. 

We also had several at Red Hat Summit 2016 that detailed their journey:  

1. Airbus:

2. Produban (Bank Santander):

3. SSB (Swiss Rail):