DevOps - How to become a -10x engineer
There is this myth of the 10x engineer/worker. It's somebody who can deliver as much as 10 others. This engineer gathered knowledge and developed skills to outperform everybody. Well, the 10x engineer might be a myth, but there are -10x engineers for sure!
There is this myth of the 10x engineer/worker. It's somebody who can deliver as much as 10 others. This engineer gathered knowledge and developed skills to outperform everybody.
Well, the 10x engineer might be a myth, but there are -10x engineers for sure!
What does this have to do with DevOps?
As we discussed in the "DevOps - 5 Ideals" and "DevOps - 5 Principles", but also the other DevOps oriented articles, we want to make the development and operation of software more fun and less cumbersome.
But, this also means that we need to learn how to improve, get better or collaborate well. This article will showcase some behavior that you should have a look-out for, if you want to establish a DevOps culture in your company or project.
What is the -10x engineer?
Before going into the "How to", let's have a look what a -10x engineer must be capable of.
A 10x engineer can accelerate the development by the factor 10. So, the team will be 10 times more productive, 10 time more effective, etc.
And the -10x engineer? Well, he needs to create more work. If you have a team of 7 developers, which normally takes 40 hours to get something done, this engineer must be capable of pushing this to 400 hours.
Easy enough? Let's dig deeper.
And … how to become one?
For a -10x engineer, it is key to apply all the below pattern. Only this will lead to -10x engineering. If you only apply a couple of them, you might become a -2x engineer or -3x engineer. So, let's aim for the best!
⚒️ More tools -> More fun
Don't hesitate. There are so many promising tools, you should seek for the best. In a small DevOps/Developer team, you can easily add Terraform, Ansible, Puppet, Java, Golang, Grafana, Prometheus, Kubernetes, Helm, Skaffold, GitLab, Karpenter, Crossplane and many more fancy tooling that keeps everybody busy.
The best? Nobody understands each of the tools to the fullest and is busy with searching for Stackoverflow answers, too.
📃 Documentation is boring
Don't waste your time with documentation. If somebody does not understand how to develop or use your code, he must be stupid. You can also take this opportunity to blame everybody how stupid they are and that they should "learn their stuff".
☢️ I have found this new language
Testing out new things is fancy! Every time a new programming language arises, you should use it in some way in your project. If your repository does not contain at least 5 different languages, you are just lazy.
Btw, you can do this with protocols, too. If GraphQL is the new thing, you should definitely make use of it in your project.
📝 Names are just names
Names are just names. Don't worry about giving proper names, nobody wants to read your code anyway. Functions, classes, or variables should help you with developing code and not with readability. And please choose super short names, something like "x" or "show" or "value". Nobody wants to type long function names or rely on auto-completion.
🤷♂️ I cannot decide this
You should never decide anything on your own. Even if you are the expert of something, you should involve more people. Budget must be approved from managers, edge cases must be found, explanation must be given.
Use this also to demonstrate how smart you are to people that don't understand your way of thinking.
❤️🩹 Can this be done better?
You have not even started with the implementation but found improvements already? A small change can be done better by writing 230 lines more code or refactoring a structural important class?
Now is the time. Make it better, drive it to excellence, and hide it in your super tiny task.
🔒️ Nobody-needs to know principles
Really, nobody should be involved in your thought process. Reviews are just a way to present your knowledge, and hiding things in plain sight can be a challenge, too. After all, "Security!!!"
If nobody understands your work, you cannot be fired, right? Furthermore, everybody needs to ask you about details after digging around for hours on their own. Stupid colleagues! Don't they understand that this is also about Security?
☕️ -10x Meeting culture
Just remember the following sentences and bring them up, whenever you like:
- I am late, since I was in another meeting!
- I need to skip our meeting in 5 minutes, something urgent came up.
- I haven't seen the invite.
- My microphone needs a replacement, but I don't have time to request one.
- Can we please re-schedule and invite x, y and z the next time?
- Can we decide this on our own?
I think, you can come up with even more on your own. After all, meetings are a waste of time, right?
🏛️ Architecture follows code
Many managers and stakeholders might request some kind of architecture from you. Well, nobody knows, right? How should you know what the perfect architecture looks like? Make them understand that you need to develop first and document the created architecture afterward (or not).
Architecture work just keeps you away from doing valuable work.
⭐️ Enforce your principles
During your carrier, you have gathered lots of experience, for sure. This may lead to principles like "test driven is slow" or "agile does not work". Enforce these on your team, your managers, and basically everybody.
After all, you gathered these experiences already, others need to understand that you are right about these.
🏗️ Refactor, Rework, Reinvent
If you find something that looks odd, most likely code from somebody else, don't hesitate to refactor it. Getting the last 1% performance improvements out of your code and enforcing design patterns should be at least 50% of your work. This will also lead to more knowledge in your responsibility.
If the team does not agree, hide the refactoring in other tasks and make them hard to cherry-pick.
🧐 Everybody else is stupid
You know, everybody else is stupid. We already stated this above. But you also need to ensure, that everybody knows this. Talking to another colleague about the stupidity of others ensures that this colleague knows about it. Facing the stupid colleague, shouting at him and blaming him in front of other colleagues will also help.
Also, ensure that you are involved everywhere, so these stupids don't break your valuable work!
💰️ Customers don't know either
Requests from customers are mostly vague, unclear, not precise and don't matter anyway. Who should know better than you? In the end, you are the expert, and you know what a software should provide, right?
They are meant to pay the bills, not to tell you how the product should look like.
Docs & Links
This 10x engineering topic can be found all over the web.
Eira May
Koosha Toofan
Team Codegiant
Conclusion
I really hope, everybody understood that this article is not super serious, but serious anyway. You can find a lot of the above behaviors in teams, companies, and projects alike.
If you really want to make your team 10 times slower, don't hesitate to apply the above. If you want to make them faster, look out for the above mindsets and try to fix them for your team.
After all, DevOps is about Collaboration, Simplicity, Customer focus and much more.
Have you seen any of the above? Do you want to add something? What is the most problematic behavior of team members that slows everybody down?
