Markus Werle

When you […] Think of Things, you find sometimes that a Thing which seemed very Thingish inside you is quite different when it gets out into the open and has other people looking at it. - A.A.Milne

The early bird catches the worm but how about the dragons we slay at night?

A Direct Message at Night

It’s Saturday night 3:00 am. I am awake at my desk digging through stuff from my ever growing TODO list and trying not to panic. I am good at that. I mean: not to panic. It’s the only thing you can do as CTO of a startup. The Signal Messenger notifies me about a new message received. It’s from one of my employees, let’s call him Gregor, as a cross reference to the dragons in the title.

Gregor proudly informs me about a programming task he finished and the problems he solved.

It was quite tricky. That week we had a vivid discussion about the appropriate design, data ownership, delegation and code organization criteria for reusable components, scalability and ease of use. You probably know this kind of discussions. A philosophical contest is nothing compared to that.

I immediately check the pull request and take a glance at the result of this night shift and I feel an urge to immediately give some positive feedback. The problem is not only solved, but all my hard requirements, my extra wishes (I always have those) and my criticism of the former design was taken into account. 100% solved. Extraordinary solution, elegant by design, easy to grok on the library user’s side, catching usage errors at compile time.

This guy is amazing. Outstanding code quality. A solution right on the spot. Not the overcandid and overengineered stuff that sometimes stems from long discussions.

Early in the Morning

You want to know who Gregor is? Gregor is the employee who overslept two meetings the very same week, one at 10:00 am, the other at 11:00 am. Gregor also is the one who forgot we had high visit during the week and appeared in a track suit.

Can’t be so hard, Gregor? Look, we really need some communication in this interdisciplinary team and E/E was in need of clarification. It’s not helpful you don’t care! It’s not helpful you shrug your shoulders and mumble around in rudeness and disrepect for your team mates - and your boss.

Sleeping it Over

I made a decision. I did not put my energy into changing other people. I changed myself: All meetings which Gregor had to attend, especially the recurring ones, I moved into the early afternoon1.

If we had to schedule before noon due to lack of alternatives, I provided Gregor with a verbal warning notice the day before.

Conflict settled.

Dissecting a Message

If I understand correctly, the sentence

The early bird catches the worm.

is the postulate that if you start working early in the morning, then your productivity will rise and the quality of your work outcome will be leveraged. It is stated in such a form that it sounds like a general truth or a law of nature.

The problem with statements like these is that they get traded by managers around the world without thinking it over. Nobody takes the time to question the amount of truth in this. Nobody cares if this is backed by science2. Some people even believe that Daylight Saving Time is a thing3.

In my opinion a non-violent communication is inappropriate here. Let’s talk plain: This idea is total and utter bullshit.

Neither reliability, maintainability, testability, portability, nor reusability of the code depend on the day of time it is created.

If you really want to know what contributes to code quality, probably ask Joel Spolsky4. If you want to make a statement about the correlation between sleeping times and quality of work outcome, probably consider Albert Einstein5.

Nothing Else Matters

I also would like to share my own personal view, totally not backed by science, totally anecdotal, after more than 25 years of software engineering:

The quality of work outcome depends on two things6:

  1. education
  2. the intrinsic motivation of your developers

Homework

  • Is the working environment you are creating inclusive?
  • Does your way to organize work reflect the fact that people are different? Does it take into account that some people would like to start very early in the morning while others start to be productive at 8:00 pm?
  • Does your company provide an environment where asynchronuous communication is possible?
  • Do you embrace and use KPIs? If yes:
    • How do you measure work quality?
    • How do you measure code quality?
    • And how do you measure intrinsic motivation?

  1. This decision may be backed by science - and experience from decades at work, of course. ↩

  2. I searched for scientific research correlating code quality to daytime and couldn’t find something. Maybe you give it a try yourself. ↩

  3. Daylight Saving Time is a thing? Spoiler alert: it’s not. ↩

  4. Recommended reading: The Joel Test: 12 Steps to Better Code ↩

  5. Albert Einstein reportedly slept for at least 10 hours per day ↩

  6. I am keeping the list short, such that it is easy to grok and easy to remember. ↩

You May Also Enjoy