DevOps friends told me about their concept called "Pets vs. Cattle." Let me share it with you. Here's the short version.

A pet is your dog or cat. They're basically a family member. They have a name, they're unique, everyone loves them, and when they get sick - the whole family takes them to the vet and nurses them back to health however possible. You miss your pets and worry about them when they're alone for too long. Love your pets!

Cattle are your cows and sheep. I understand that cowboys probably aren't reading this, but tech folks often dream about having their own farm too, so just imagine yourself thirty years from now.

Cows give you milk, meat, and generally, if you have them - you probably live in a village and they're critically important for your food and survival.

However, if one of the cows gets seriously sick - you send it to slaughter to save the rest of the herd from infection. And immediately replace it with a new one.

You don't give names to cows and sheep, except maybe as a joke, but the overall health of the farm is still important to you - you take care of them and spend lots of time making sure the cows are happy, gaining weight and producing milk, so you don't starve next winter.

So both pets and cattle are important, but in different ways.

Back to DevOps. Before clouds, when "DevOps" were still called "admins" and people made jokes about them on Bash.org, every server was unique. You knew exactly that your website was running on a specific machine with 1GB RAM and 2GHz CPU in some datacenter.

When the site went down - you went to that machine and fixed it. The machine even had its own dedicated IP address and name for this purpose. This was your pet.

With the arrival of clouds, Docker, and Kubernetes, the situation changed.

Everyone realized that managing even a dozen servers is much easier when they're all identical and move together as a herd on your command.

If a server breaks or needs updating, you just kill it and create an exact copy right next to it, but new. With one command. Modern orchestration systems already do this automatically. When a server fails several times - then yes, that's a reason to think and check the logs. But it won't break the whole system.

Because modern servers are cattle.

I think it's obvious why Google, and then all other companies, started promoting this as the recommended approach to managing infrastructure. If it's still not clear, read the pros and cons here or here.

Now, finally, to the point of this post.

Developers ALSO need to finally change this paradigm

Right now, the vast majority of developers treat their code and project like a beloved cute pet.

They give it endless refactoring to make its fur softer, furiously argue about which version of food to buy this month, and always know where to scratch behind the ears when it starts acting up and crashes with OutOfMemory.

And then they face reality.

Where code is just a tool for solving a specific task for a specific business that hired them. And this task will change in a month. Which means 99% of the code written by developers will simply be thrown in the trash.

And from a business perspective, there's no problem with this: they hired you at a monthly rate, paid it regularly (hopefully), you wrote your code (also hopefully), and then that old stuff is no longer relevant and we urgently need to do this new stuff. How great that we already have developers and they'll write it! Right?

But from the developer's side, everything looks different: they tried hard, groomed, nurtured their pet, and then those mean boss-uncles took it and threw it away. The programmer obviously starts experiencing 👇

BURN-OUT.

Yes, one of the main causes of burnout is the lack of meaning in life, or translated to engineer-speak "they tell me something, I do something, but I don't understand why the hell any of this matters".

So, if you accept the fact that 99% of the code you write will be thrown away, why not start treating this as normal, rather than something extraordinary.

Personally, the "Pets vs Cattle" analogy helps me with this.

Cattle aren't "worse" than pets. Cattle are needed so you and the whole village have something to eat.

Not because you're a "slave to the system" and "the boss tells you what to do". But because you chose the path of a farmer, even if you haven't realized it yet.

You make sure your cows are happy, they eat well, their bedding is soft and their water is clean. You constantly monitor epidemic and virus reports to be ready for the new season. But you understand their purpose - to feed you and your village next winter.

You can give names to the prettiest cows, but you're absolutely clear that when the time comes - "Bessie" will turn into a juicy steak.

But you won't bury her and grieve like you would for a pet. Your cats and dogs still live warmly with you and are well-fed with meat. But whose meat?

So every module in your system is a cow, every microservice is a sheep, and every unit test is your chicken.

And your professional goal as a programmer is exactly the same as a professional farmer's - to learn how to most effectively manage your farm, not to cherish and nurture every duckling and hoard them for the future, more and more.

Nobody cares what your cows are called if your village is starving

When you start treating programming exactly like farming, many things become simpler.

From now on, every line of code written and successfully launched is your personal victory. A newborn cow. Both as a farmer and as a professional. And if next cold winter you have to turn it into meat - well, great, we'll breed a dozen more like it later. Life is long, and there will be many winters.

Even if it was the harshest winter in your history and all the cows had to be eaten, it doesn't mean you failed as a farmer and it's time to fall into depression. Quite the opposite. Your village survived, you ate well, this is your success. Everyone loves you for this.

You can look at everything else through this lens too:

There are basic things - knowing how to build a barn, knowing the difference between hay and straw, or, say, tractor driving skills. They haven't changed for decades and that's the foundation. Like algorithms and data structures.

There are, conversely, overly hyped things. All sorts of super-duper additives that make cows grow 10 times faster, but a couple of years later it turns out the meat from them causes cancer, and everyone starts hating them. That's like new JavaScript frameworks :)

Although sometimes there are quite fun inventions, like automatic back scratchers for cows. So becoming a Luddite and denying progress isn't worth it either.

And then there's that "balance." Time-tested tools that you use more and more confidently with each season, which become the foundation of your style and professionalism. Later you'll go to a farmers' conference with them, teaching juniors how to use a cultivator instead of hoes.

The more universal your approach - the better farmer you are. If something happens to you tomorrow, another farmer will simply take your cows and continue raising them. They won't need six months to memorize their names and learn your UnIqUe barn layout.

Even when getting hired for a new job, they'll ask you about that "experience," not about the number of cows you managed to preserve before leaving your previous farm.

So just accept as fact that 99% of your code (cows) will be destroyed and eaten, but you, as a programmer (farmer), will only get better from this.

Want to not only raise cattle but also have pets - start pet projects. That's why they're called that. When your life is going well and you can afford to have a pet - get one! It's happiness! Take care of it, groom it, buy it the trendiest toys to play with.

And if you don't need this - develop your skill as the best farmer in the region and forget about everything else.

But never. Never again confuse pets and cattle.

You're either a farmer or a loving owner. These are two different roles, though one person can be quite successful in both. When they separate them.

Otherwise, you're fucked and burned out.

Hang in there.