Take any decision, question, concept, idea, team, project or plan and sprinkle the concept of time on it.

It might seem obvious or silly but I’ll explain with some concrete tech/project examples in a bit. Almost everything exists within the concept of time. Only a few things don’t. Constants sometimes don’t. PI is a constant. It’s not obvious how time relates to PI. Except when you consider that no one has yet found its end. The final value of PI (if there is one) is constrained by time. The answer of what PI actually is (if it can have a complete identity) is constrained by time. The speed of light is another constant. It might seem like it is unrelated to time. But speed is a function of time. Speed is meaningless without time. You can sprinkle time on the speed of light but this isn’t really what I mean.

What I mean is, you should consider time if you are building something, asking questions, trying to figure out what is best or doing what I’d consider everyday engineering things. Sprinkle time on the thing. It’s always there. So add it back.

Let’s look at some common questions:

Someone: What programming language should I learn?

The question is too open-ended in many ways. Let’s put time related things back into the original question. We’ll ask the person for more detail.

Sprinkle Time on it:

• How experienced are you?
• What year is it right now?
• What has happened recently that is influencing the possible future
• When do you need a job if that’s what you mean?

All those time details should always be packaged with that question. Without it, we are missing a dimension of the question and it barely makes sense. You can see this context/setup in well-phrased and experienced question-askers on stackoverflow. They setup the situation (present time) and maybe frame their constructed reality (their past).

Someone: What’s the point of a CI/CD pipeline? Doesn’t that slow down everything?

Maybe the person asking doesn’t even understand what CI is about. Add time to what they are doing now.

Sprinkle Time on it:

• What’s your employee turnover rate?
• How long does it take to onboard someone and have them deploy to prod?
• How many deploys do you do per day?
• How would you guarantee and feel drift of tests to code over time?

We could do the same thing with discussions about waterfall, big design up front, feedback loops, bit rot and just change in general. Change is time. Time is change. Nothing exists outside of time. It’s a dimension in our very universe. And sometimes/somehow it is excluded or forgetten about in decisions, thinking and conversations. It’s easy to add back in. You just sprinkle it like a salt shaker. It’s like a seasoning. Sprinkle time on that thing!

Someone: I hate javascript.

I know what they mean to say but … what if it changes? Software can change. Software will change. Culture is forever but software usually changes.

Sprinkle Time on it:

• When’s the last time you used javascript?
• How long did you work at it. We tend to like things we understand (experience/time).
• What version are you talking about, software can change.

So should you hate javascript forever? Should I bake my criticisms of any language into my brain forever? I understand chunking. But you need to tag these chunks as possibly out of date or have an expiration date. That memory chunk or bias you have is probably going to expire. Especially in software. Software’s whole advantage is that it can change. And that’s going to be change over time. I have a few niggles with Go 1.x (right now) but I know it could change (in the future).

Even this blog post needs time sprinkled on it. This very post will go out of date and bit rot. I have a blog post titled “Why Aren’t You Running Gentoo?”. A very low empathy start of a post from 2004. It’s not a relevant question to me anymore (time) and the tech landscape has changed (time). I have blog posts with the date of the post and no other information for this reason.

But to me, the biggest problem mistake I see is not considering time and ignoring that things can change. Take git history. You have 15 years of git commits on a web app going back to 2004. You have archived releases saved just in case you need to rollback. But why? Sprinkle time on that idea. Heartbleed came out in 2014. All your commits are useless beyond 2014. What are you going to do? Boot an unpatched system, compile against vulnerable openssl and deploy it? The world has changed. You can’t go back. This is true of most security patches. It’s not that security flaws are being found. It’s that the world is changing. The state of the world does not stand still even for your core technologies. It’s not standing still for your business or features either. You can’t rollback your database that far. Feature flags, sure. But deleting whole columns or tables? Breaking the user experience? It’s forward-only. And that’s how time works.

Ok, that’s enough about that (time). I think you get the point (time).