Already for a long time the sentiment and opinion on so called “rockstar engineers” or “10x engineers” is that they are mythological and don't exist. Even those self proclaiming ones are wrong. They are not who they say they are, they are just fronting. I think the reasoning that brings forth saying it is a myth is dangerous to our field and society in general.

You are a rockstar

If you are an engineer, any engineer, then you are a rockstar. Not only are you a rockstar, you are a surgeon, a caretaker and a craftsmen. I will speak from a software engineer perspective since that is the one I know, but I am certain this applies to any engineering domain.

Rockstar

We are a rockstar any time we fix a bug, any time we go into uncharted territory and come out conquering the area, any time we challenge ourselves with unfamiliar aspects and dominate them and make them our own. There is nothing like that dopamine and adrenaline hit after conquering something unknown and making it known. Adding that to your tool belt. Because other people are either unmotivated to solve these bugs that are not really bugs and have been there since the beginning of the codebase or are just incapable.

The next story I want to share, will come across as arrogant, egocentric and generally narcissistic. I will say it is told by someone who is confident in their ability and has no problem to rely on their particular skill. It has been honed and crafted over years of working and experience. It is a great skill to have. There is something very safe about having that knowledge that you are competent.

There was a codebase that was relatively old, like 5-10 years old. It was a Java codebase written with Spring framework. The old school Spring framework in the beginning and then to Spring Boot and so the task was to finally upgrade all the dependencies to latest versions due to security vulnerabilities and general technical debt. This meant also upgrading certain libraries we were using that got new APIs and therefore fixing the broken code that resulted from that. A software engineer was tasked with this aspect and got 90% done when he hit something that stumped him. Spent a good portion on this problem and just was stuck and could not figure it out. Another engineer was called to tackle it together and the other engineer also tackled it solo. They were getting stuck too. Then a third engineer was called and took a look and said he did not have any idea how to fix this problem. I said at this point, have one more person look at it and then I would like to take a look at it. The final person was a junior engineer and he also got stuck. Did not even have an idea where to start, how to evaluate what the problem could be.

The problem was that one of the dependencies to a specific version of Spring Boot just made it compile, but crash every time it booted. Some internal stack trace was thrown and it was not entirely clear why this particular error arose. I got the problem and I did not ask any of the previous engineers what they did, so I went in blind. Now at this point several people spent a considerable amount of time on this problem. I would say maybe a full work week between them. I got the codebase. Ran the maven build command, then run. It crashed like so many others. First thing is in the stack trace I looked for our class names. I saw one. In an old part of the codebase. I took a look at the specific code and I realised they were using Spring internals directly. Rather than configuring it through the auto configuring boot strap code way. So I changed those lines, that broke some other things but eventually it got fixed. It took me roughly 2 hours or so. From identifying the problem to solving it. These were senior engineers with each having roughly 10-15 years of experience. They could not solve this issue. It sounds simple when I reveal the problem. However it took some digging to find it. I looked in the wrong places too, however doing so much debugging into these exotic issues made me better experienced to deal with this then people who only create the things they know.

At the point I fixed it, I was smiling ear to ear. I was gleeful. I remember feeling confident when I began and thinking I will fix it, and I did fix it. I conquered the unknown yet again. This is exciting work. Legacy codebases are where it is at.

Point being, I was a rockstar at that point concerning my mood and vibe.

This experience was something I have had multiple times in multiple situations. I knew nothing of AWS, DevOps and Infrastructure as Code at all. I got hired to do a job and I had 6 months to fully migrate a well running live system of millions of users from in-house servers to the cloud. I did that. I did it with four other guys, but I was definitely a part of the team fulfilling a role. I knew nothing of blockchain, smart contracts, kubernetes and HyperLedger. I had one month to make a functional demo. I did that. I deployed a fully working production ready system and a quick showcase demo in that time span.

Surgeon

Which leads me to the following, we are also some what of a surgeon. Any software engineer here that had to fix something live on production, whether database or code, knows how precise you have to be. How skillful to not fuck anything up. How do you get there though? Partly by observing, but mostly, by doing. You do as much as you can of these operations in your local dev stack. Then you can fuck up as many times as you want and learn each time what not to do. When it comes to production stack you will immediately slow down, be careful, think about what you are doing and execute it to perfection.

Caretakers

Which leads me to being a caretaker when you are a software engineer. We care about the state of the codebase, we care about not messing up customer data, we care about the feature actually doing what the customer wanted, and we care about doing the right thing. The scene from “A Scent of a Woman” comes to mind. Where Al Pacino's character says, > “I have come to the crossroads in my life. I always knew what the right path was. Without exception, I knew, but I never took it. You know why? It was too damn hard.”. > “Now here’s Charlie. He’s come to the crossroads. He has chosen a path. It’s the right path. It’s a path made of principle that leads to character.”

We software engineers, we rockstars, are Charlie in this instance. If you identify more with Al Pacino's character, then you might be a solutions architect.

Craftsmen

Which leads me to say we are craftsmen. Like craftsmen in other fields, we need to hone our craft. We need to keep learning, experimenting, failing, and most of all keep practising. You do not become good by reading articles on HackerNews and think you can program. Any engineer knows what the worst thing is about our field, something none of us wants to be, or associated with being and that is being a code monkey.

There is nothing like the sight of an amputated spirit. There is no prosthetic for that.

Code monkeys are not even junior devs, they are just writing text on a screen in a particular order that happens to pass the automated PR tests. Most people need to understand that being a software engineer is not just writing text in a file on the computer and how hard can that be? The same way a content creator on YouTube is not just shooting a silly video and making millions, how hard can that be? I tried the YouTube route. I got about 2300 subscribers, took an ungodly amount of my free time to execute. It is relentless, it is constant, and it is so easy to lose focus and will to continue to create.

Try to be a junior software engineer, just see what it actually takes and you might think differently on these software engineers and their capabilities.

Just take to heart you coded something. You wrote some text in a file on a computer, and you created something. You made something that was not there before. You did that. Not anybody else did that. Take pride in your work, make sure you do it with thought and care. That will make you get as close to happiness as you can get.

Hip Hop artists

We are also hip hop artists/rap artists. We have beef like nobody. Whether it is Vim/Emacs, Python/Golang, or what have you for framework war. We firmly believe we are right and the other is wrong. There is nothing wrong with believing you are right. There is nothing wrong with saying it works for you and your case, but it does not for me and mine. There is nothing wrong with saying that you find another point interesting and you have not considered that perspective. Stay humble, yet confident in your knowledge and ability. Critical thinking should be at the forefront of all of this.

Problematic reasoning

The reasoning that we are not being all of the above, and why it is being perpetuated, is because this new age is having the digital assets and how to operate them become central to our civilisation. This means that if you are in power you have to rely on these operators, these craftsmen to keep your wealth and power. In turn that might mean that these craftsmen also hold a share of the power. That equilibrium must not be attained. Same reason why it was worked against that unionisation would become a thing. This would mean that the factory operators (engineers) would be in better position and therefore wield more power. The people in charge knew they would lose a portion of their hold over them. Well now the same will happen to us. We need to believe and trust in ourselves and not become divided. Not be pitted against one another.

In a larger picture it also feels this has to do with the trend that men are being amputated of their spirit. The thought of ambition, trying to be the best at something is not something that is being actively championed by parents and society in general for men. Also the fact you are able to take pride in your abilities is something I do not see is a normal thing to do these days. The reason why I say specifically men in this case is because most software engineers are men. That is what makes this a relevant point. The ratio seems to be roughly 70-30 men to women in software engineering fields, broadly speaking taking the whole field.

I remember I felt weird the moment I consciously thought I can do this because I know I can. I am really good at delving into unknown territory and fixing things in a fast and efficient way. I almost felt ashamed I thought that. I found that so weird. Now I am just confident in my abilities. I know I can rely on them.