Linux is Affected by the Curse of Engineers
Brilliant engineers can become bottlenecks when their innovations conflict with enterprise needs for stability and profitability, like…
Brilliant engineers can become bottlenecks when their innovations conflict with enterprise needs for stability and profitability, like challenges seen in the Linux desktop ecosystem
Disclaimer 1: 2025 marks my 21st year in my career. I had started my career as a software engineer, focusing on embedded systems, then distributed systems. The last 10 years, my primary focus has been on data. The following examples are coming from my experience and memories, but I changed the names and environments to respect individuals.
Disclaimer 2: What I am talking about in this article is the desktop environments of Linux.
Nearly 10 years ago, I was a principal engineer in one of the World’s most popular companies in their field. They are Fortune 500 as their customers are. One of my responsibilities was traveling around the world to address projects that had been significantly delayed or were impacted by major incidents, resulting in millions of dollars in losses per day. Generally, I created a war room for 3 days to identify the problems, solve them, and then leave.
I just returned from a customer visit, which was very tiring, and I was delighted to sleep at home. In the middle of the night, my phone rang. It was normal because no one knew which time zone I was in. I picked up. One of the program managers for Customer X was calling, and she was screaming about someone named Armand. I said, hold on, hold on, I just woke up, please take it easy. She was furious; projects were delayed by around 3 months, and she finger-pointed at someone called Armand, a senior engineer.
In such cases, I ask the default first question: “I understand your concern, but where were you and why didn’t you notice until 3 months?” This is an important question because there are different scenarios: If the engineer is not just doing their job, or because of individual performance issues, it is not my business. She said, “Can, please, don’t talk like you don’t know anything. We are stretched thin, and I am managing three different programs around the world simultaneously. You know, engineers are taking responsibility for planning.” Yes, I know, but I had never understood the situation because whenever I asked for more engineering resources, I was always getting project managers or program managers. For me, their PxManager resources were unlimited.
I asked several more questions because of the process, and she passed the checklist that I needed to involve. “OK, I am coming…”
I flew to one of the sites of Customer X. She was waiting for me at the entrance to help me get in and clear security. We went to a meeting room where the lead engineers were sitting. I have never met them before, and I introduced myself. They got relief because if something doesn’t go well, someone from human resources can also enter the room for them.
While we were talking, someone came in late and said, “Sorry, I was trying to save the system.” He just sat, opened his laptop, and started typing. I turned to the program manager and said, “He should be Armand.” He looked at me like I knew him, and I got his attention.
The problem was clear. Armand was constantly reinventing the wheel. The program was already in danger, and no one wanted to take responsibility. As a result, other engineers pretended to be quiet and shy, but it was not true. They were just being allies to blame one individual: Armand.
I formed the war room. It is a tough dedication because no one can leave the room without a solution. You eat, work, and sh*t together. Once I brought portable toilets because they were a bit far away from where we work.
The first day, it was very clear: Armand is a brilliant software engineer. Truly brilliant. The kind of person who can debug binary in his head, quote Knuth in casual conversation, and tell you exactly why your use of forEach is “philosophically wrong.” Unfortunately, he’s also allergic to using anything that already exists. The problem was not only that he was re-inventing the wheel, but also that his actions were in direct violation of existing commercial contracts.
Over the next two days, we sat down and drew the solution architecture, integration points, and trade-offs. Program manager and engineers were pleased, except Armand. I got another call and planned to fly tomorrow.
Today, I don’t remember how many days have passed, but it wasn’t too long ago. I got a call from the same program manager: “Can, you come here again.” This was not good because if there is another call after your visit, it may be understood that I didn’t do my job correctly. There was another process for such cases, and I asked her to complete it. HQ then needed to call me.
I flew around a month after she called me for the second time. It was worse than before. Armand dumped our work in the war room and built his authentication system, video decoding mechanism, and ArmandDB, which stored key-value pairs. They encountered scope creep, which prevented them from deploying Armand’s development because it could only run on his laptop. I don’t even need to discuss the commercial impact of his actions, as we were supposed to maintain the delivered system for 2 years. We found his line manager and told the story. He was shocked and said, “He is one of our best engineers.” I said, “I have no doubt about it, so place him in backend operations, not customer-facing projects or programs.” After completing some processes, nobody had seen Armand again. Maybe he was just relocated to somewhere else or was fired completely.
It is the curse of the engineers
I have worked with many brilliant engineers; some of them could fit in an enterprise setup, while others couldn’t. Those who couldn’t fit the enterprise setup either founded their own companies or changed their profession eventually. Those who could fit the enterprise setup either have become very successful or burnt out. So, sometimes, there is no happy ending.
When I talk to the successful ones, there is one single ingredient in common: “I have never lost my curiosity, but I kept them in my private life rather than applying it in an enterprise setup, because in an enterprise, the most important thing is profitability, not your maniacal engineering skills. Yes, you can develop a database from scratch and be skilled, but in reality, no one is interested in it. It is not because they are evil, it is because of how the world works and contracts.”
I cannot agree more.
Unfortunately, such a worldview, or what I would call experience or maturity, comes when you are getting older and stepping up in your career.
In Linux, we need this maturity
The main challenge in the Linux environment is that everybody is nearly free, depending on the project or source code you are working on. For Kernel, everything is still very strict, for example. But if you are building a distro or a package management system, there are no restrictions, which is great; I really enjoy it. But not everybody is like me, and the majority of technology users value stability, reliability, and a “just works” mentality. Here, we need to separate the freedom. I am not saying that Linux World should not be like this. What I am trying to say is that we also need other streams, as things are not changing dramatically, and values “just work”. Most likely, you’ll throw out some Linux distro names quickly, and most people will probably call Debian by default. Yes, the latest version (as of today, version 13) is better than ever, but it doesn’t “just work” because there is still not a stable desktop environment. Even the biggest names, such as GNOME and KDE. You still need to do many customizations.
While true gems like Armand are a competitive advantage of Linux, they are also becoming a bottleneck on business concepts.
We can discuss whether Linux should be included in the business concept. Then I will ask a very simple question: Why not? Is there any place in the world where you can live without money in tech?
We don’t need 5000 package managers, 2000 packing steps for every format; electron apps, because it is so fcking hard to publish native code for different Linux distributions. When you are doing this, there is no significant income, so most projects can’t transition out of their hobby state, or we try to use them in production.
I am not sure about you, but I see Linux as a very clever student, but unfortunately, wasting its potential because of the wrong friends.
Let me know about your thoughts in the comments…