From Linked Lists to the Myth of the 10x Engineer

I'm not sure when it started, but "10x engineer" has quietly become the litmus test for measuring a programmer's worth. Today let's talk about 10x engineers, and what the concept really means to me.

As a hardcore technical channel, we'll start with a basic operation — the singly linked list — as a springboard to discuss what makes a programmer with "good taste." Then we'll dive into the myth of the "10x engineer," and why this concept has been co-opted by certain bosses and managers with ulterior motives as an excuse to squeeze more out of programmers.

Let's begin with Computer Science 101 — linked list operations!

Deleting from a Singly Linked List

Requirement: Given a singly linked list L and a target node D, delete node D from list L. As shown below:

Linked list node structure —

// 节点结构
struct Node {
    int value;
    struct Node* next;
};
typedef struct Node Node;

// 链表结构
struct List {
    Node* head;
};
typedef struct List List;

We'll omit the linked list metadata here, since this article focuses on node operations.

The requirement is simple, widely applicable, a classic CS101 data structure that looks straightforward. Let's implement it!

The CS101 Version

Let's look at the implementation from "The C Programming Language" textbook (accidentally revealing my age here).

void remove(List *l, Node *node)
{
  Node *cur = l->head, *previous = NULL;
  while (cur != node) {
    previous = cur;
    cur = cur->next;
  }
  if (previous) {
    previous->next = cur->next;
  } else {
    l->head = cur->next;
  }
}

We use cur to store the current node and previous to store the predecessor of the current node. First, we traverse the list until we find the target node. Then we need to check the position of the target node —

Case 1: The current node has both a predecessor and a successor — link the predecessor to the successor;

Case 2: If the current node has no predecessor, it means we're deleting the first node, so we need to point the list's head to the next node;

Case 3: If the current node has no successor — same as Case 1.

Thorough consideration, case closed — you can call it a day. However, in Linus's eyes, this code is "not in good taste." Now let's look at code with good taste —

A Tasteful Singly Linked List Deletion

When the algorithm is nicely arranged, that special case can be handled with the same code than all other cases. After that, the check for that special case can be removed. - Linus Torvalds

A well-designed algorithm can handle all cases uniformly — in other words, you can eliminate the code for handling "special cases." - Linus Torvalds

No time to explain — let's jump straight to the code —

void remove(List *l, Node *node)
{
  Node **cur = &l->head;
  while ((*cur) != node) {
    cur = &(*cur)->next;
  }
  *cur = node->next;
}

At first glance, the code is half as long. Let's break down what it does.

First, cur is a pointer to a pointer, whose address is the address of the l->head pointer. Think of cur as an extra layer of boxing on top of the head node — this box's value is the address of the head pointer, which is the same as the location of the first node that list l points to.

Inside the loop, we similarly traverse the list. The only difference is that here we need to dereference cur through two levels.

The last line is where the magic happens! Here we set the value of cur (which is still a pointer) to the pointer of the target node's next node. cur represents the current positional pointer — note that this "position" doesn't refer to the position within the original list, but rather a higher-dimensional pointer assigned to each node. No matter how the list changes, the order of these higher-dimensional pointers remains the same. So assigning to cur simply replaces the value at the current higher-dimensional box position, regardless of what was in that box before.

In short, this is like launching a dimensional attack on the linked list — viewing the list from a higher dimension without being concerned with the list structure itself.

The Market-Driven 10x Engineer

After seeing the "tasteful" code above, does it change your understanding of the 10x engineer? Would you consider Linus a 10x engineer?

Before we discuss 10x engineers, let's look at the definition —

In programming lore, a 10x engineer can accomplish ten times the work of an ordinary programmer. An ordinary programmer can be imagined as someone who is good at their job but lacks the magical abilities of a 10x engineer. The more "goal-oriented" a task is, the more room a potential 10x engineer has to leverage their abilities to achieve the goal with far less effort than others.

A 10x engineer can accomplish ten times — even a hundred times — the work of an ordinary programmer. This definition is incredibly appealing — one person doing the work of ten — so much so that bosses eagerly try to find and cultivate 10x engineers. But the reason bosses are bosses is their bias toward action and results. Under this methodology, we see more and more "results-oriented" 10x engineers — 10x workload, 10x lines of code, 10x output, 10x hours — ultimately producing 10x overworked employees, while the salary... let's not go there. There are even training institutions offering courses like "The 10x Engineer Methodology," which mix in some basic software engineering concepts and motivational platitudes. The market has been wrecked by these so-called "10x engineers," and programmers can only swallow their frustration in silence.

So does the 10x engineer actually exist? I believe they do. Let me share my perspective on what a real 10x engineer looks like.

A note: here we're only discussing "programmers" and industry-related aspects, excluding things unrelated to software and coding, such as software engineering processes or motivational advice (though those are important too).

The Real 10x Engineer

Bad programmers worry about the code. Good programmers worry about data structures and their relationships - Linus Torvalds

Average programmers are consumed by code; good programmers are consumed by data structures and their relationships. - Linus Torvalds

Returning to the question at the beginning: Is Linus a 10x engineer? I believe he is — I'd even call him a 100x engineer. Yet look at his obsession with the linked list operation at the start of this article. He doesn't produce 10x output; from a lines-of-code perspective, his code contributions sometimes have a negative value (reducing 10 lines to 5). Especially in the later stages of maintaining the Linux community, he rarely contributed code directly, instead spending his time "critiquing" others' code in the community. So why do I consider him a 10x engineer? What's the standard for a 10x engineer? Elegant architecture? Clean code structure? Efficient coding frameworks? Or code that's easy to maintain and extend?

If you've seriously considered these questions and tried to define your own standard for a 10x engineer, congratulations — you've fallen into my trap! I believe that a "10x engineer" without context is meaningless. Moreover, 10x isn't a fixed multiplier — it should be read as "10 times x"!

Why do I say this? Let's use Linus as an example again. His preference for code "taste" and zero tolerance for poor quality established his position in the Linux community (the ranting aside, lol). However, if we remove the community context, all his qualities might not shine as brightly. In some market-driven companies, they might even be counterproductive. Consider the following scenario — imagine applying the Linux maintenance philosophy to enterprise software development:

Boss: "I heard the flash-sale feature is done? No issues shipping it in the next sprint, right?" Ls: "The code is terrible. Supporting 300 million QPS requires 2,000 nodes. I'm still doing code review and refactoring." Boss: "If we cut some features, can we ship on time?" Ls: "No matter how much scope you cut, the bad code still needs to be fixed!" Boss: "This feature MUST go live by end of month! The client has already paid!" Ls: "We'll see..." Boss (thinking): "What a stubborn programmer..." Ls (thinking): "What a tasteless capitalist..."

So, a 10x engineer without context is meaningless. Next time a boss invokes the efficient 10x engineer as a thinly veiled excuse to make you work overtime, I hope your immediate reaction is — this is a trap — and you gracefully direct them to read this article.

Especially after recently reading "No Rules Rules: Netflix and the Culture of Reinvention," I've become even more aware of how important context and environment are for a programmer (I'll write a dedicated review of this book later). At Netflix, all information about the company is shared between employees and management — subscriber numbers, financial reports (even before Wall Street knows), and so on. Only when employees have access to all contextual information can they possibly make the right decisions. If employees receive less information than their managers, how can you expect them to make correct decisions and bear the corresponding responsibility?

With complete context, you have the foundation for producing 10x engineers. On top of that, there needs to be sufficient freedom for programmers to exercise their creativity. At Netflix, everything from team dinners to multi-million-dollar projects requires no layers of approval. As long as the person in charge feels it's right, they can skip the approval process and just do it! That's right — if you think it's the right thing to do, go ahead and do it! For the programming profession, innovation is the primary productive force. And only sufficient freedom can incubate innovation! Only through innovation can true 10x engineers emerge and truly create 10x+ value.

In summary, 10x engineers do exist. But while the market blindly chases 10x engineers, we need to pause and ask whether we're providing the right environment — transparent information and freedom — to make "x" greater than one and produce 10x+ engineers! Conversely, in an opaque, closed environment, x will only shrink, and the final result may be less than one.

Conclusion

This article started with a singly linked list deletion operation, discussed "tasteful" code and programmers, then explored the current market's so-called "10x engineers" versus what I believe a real "10x engineer" is. Finally, drawing from Netflix's culture, I proposed that the "x" in "10x engineer" isn't a multiplier but a variable — only an environment of transparent information and freedom can forge true 10x engineers.

One last thing — a teaser for an upcoming book review:

Top-of-market compensation + Transparent information + Maximum freedom -> Self-organizing knowledge-intensive organizations -> Unlimited growth and value