Learn fundamentals, not tools

Don’t spend your time learning tools. Most of them go stale faster than you can learn them.

I have been doing this for nearly twenty years. In that time, the only thing that has not changed is, probably, TCP/IP. Take infrastructure tooling: Chef, Puppet, Salt, Ansible. Docker Swarm. Mesos and Marathon (which I actually liked — their approach was interesting) — and which are simply gone. Only Kubernetes is left, and it won partly because it is Google. Ten years ago everything was Java and everyone carried Java around; now it’s the exception when you land on a project that has it. MySQL: nobody starts a new project on it, because there are more targeted things now. I’m not even talking about frontend frameworks.

All my knowledge of all those things came to nothing (well, almost). In five years someone will point at a diagram and say there used to be a database called MySQL, I see the icon.

Most tools are just wrappers over same underlying blocks. If you know blocks 100 tools over it became trivial to work with. Docker (and other containerization tools) is wrapper over linux namespaces and cgroups. Most databases build on top of B-trees. Most linux cloud network tools just configure routes and iptable. If you know that, it is easy to understand what tool actually do and what to expect from it, and differences similar tools has.

How the cycle actually runs

When people work on something they accumulate knowledge, and at some point that knowledge lets them see a better way to do the thing they’re doing. That has always been true of everything.

In my own field it was very visible. First we ran bash scripts to deploy. Then we wrote tools that deployed. Then we realised pull was not universal and things should push in many cases, which is far more reliable. Then we realised that was also not quite right and we should bake everything into VM images, faster and more controllable. Then someone noticed Linux had these container primitives sitting there, wrapped them, called it Docker, and you could bring up a whole OS with minimal overhead.

The tell that a technology is about to die

Any technology, once it becomes convenient enough and no longer has that many problems, is the best sign it is about to start dying. Because as soon as something works well and stops hurting, people start looking at what else could be done.

With Kubernetes I feel we are getting to exactly that point. It is overloaded. Too much of everything, too many knobs. And building the replacement is no longer a fifty-million-dollar project, which means it will definitely happen. Somebody will do it. Kubernetes becomes what TCP/IP became: the transferable layer underneath, increasingly turning into something else on top.

So learn what stays

Not the specific dialect of a database. SQL, and how SQL is used across different systems. Not the orchestrator’s YAML, but what orchestration is, what it is built on, what primitives it stands on. Learn those and orchestration becomes obvious.

You cannot avoid working with a tool, and you will learn it. The problem is people who focus only on that part, and find out five years later that almost everything on their CV has no link to reality any more, or it’s trivial. Who is posting Git or SVN into their CV these days?

So focus on fundamentals. Understand why things are how they are, this part will not change, not in your lifetime anyways. First-principles thinking is your friend. He is not easy to deal with, but he is who will keep you out of sinking in ocean of software.

And there is a paradox in it

The more fundamentals you know, the better you use the tools. And the more you work with the tools, the better you understand the fundamentals. AI takes away exactly that hands-on layer, so you may end up never fully understanding the fundamentals either, because you never had the practical experience they get built from. I don’t know how that resolves. We’ll see.