The Difference Between Engineers and Tool Operators

From my point of view, and from my own experience, there has always been a clear difference in software between two kinds of professionals: those who understand how computers work, and those who learned a framework as a trade and built a career around it. That distinction can make a company work, help it succeed, or send it into disaster very quickly. Having engineers on your team who can work across multiple areas, think through a solution from beginning to end, and understand how the pieces connect is an excellent sign.

Technology was never as static as other industries, and today it is even less so. Decades ago, an air conditioning installer could spend an entire career doing only that without needing to understand much about electricity, plumbing, architecture, or the broader system around the job. In some ways, that mentality moved almost naturally into software. For example, for almost a decade, many Flash developers lived inside a bubble. It looked like knowing Flash was enough to have a very well-paid job. But when the platform started collapsing after 2008, it became clear who understood systems and who had only learned a tool. Most developers from that era were simply bootstrappers. Very few were true craftsmen of the Flash trade, and those were engineers who understood systems very well, many systems, not just one, well enough to push ActionScript to its limits.

Another example: when I started this profession as an engineer, or hacker, more than 27 years ago (yes, I am old), there were specialists for everything, and I had become one of them. But I had no limits when it came to learning, and I always got involved in everything. I was lucky to be surrounded by hackers and to learn from them, to pay attention, to not be afraid of installing a new operating system, writing my first lines in a new programming language, or trying a new software architecture. That habit of trying new things and understanding how they worked opened doors in every part of my career.

But not everyone had that same spirit. Most people had only put in the effort required to learn the basics of a platform, and then they became the usual sedentary professionals. The developer who only worked on frontend only touched HTML and CSS, and that was it. They knew nothing else, and that was exactly how they were valued. Backend engineers wanted nothing to do with frontend, and vice versa. Many backend developers barely understood backend, because backend is not just building REST APIs. There is data modeling, and for that, there was also a specialist who wrote queries. There is infrastructure, security, deployment, observability, performance, and a long list of other concerns. Everything was so fragmented that companies could barely function unless they had an enormous team where every person existed to change one comma in one specific backend function. Even inside backend, there was always someone who had spent their entire life working on one module, and nobody else on the team had even inspected what that thing was. The fear of touching something and breaking it was always in the room.

On paper, that dynamic can look almost generous, because one might think all those people had jobs. In practice, it was far more harmful to them than people realize. Projects died very easily, and everyone ended up out of work because the company could not operate without that swarm of narrowly specialized workers. If Bob got sick, the whole team fell apart. John, who was also on the team, knew nothing about HTML or CSS beyond the basic concepts, because he only wrote PHP. But do not ask John to write HTML or CSS, because he only understands databases and SQL. As you can see, many of the people we called engineers were actually bootstrappers: specialists in one platform, helpless everywhere else.

That kind of professional is the least fungible. It made sense in the past, when everything was a mess and having someone who knew a lot about HTML and CSS made a real difference because of browser inconsistencies, rendering engine bugs, and all the strange problems of that era. But today, that problem and many others no longer exist in the same way.

Some people will remember the title “fullstack,” those renegades who were often disliked by their peers because they were reckless enough to touch every piece of the puzzle. I still remember the dismissive comments from former coworkers when they had to give an opinion about “the engineer who can touch everything.” The comments sounded like the usual American version of “jack of all trades, master of none.” I include myself here, because I repeated that line too, almost out of inertia. But the real reason was fear. I was afraid that all the effort I had put into learning and mastering one platform would suddenly lose value, because this new engineer who was interested in everything might eventually take the precious place I had earned through so much effort. That engineer, or any engineer, really.

Yes, that future “super-engineer” could not match my level on that specific platform yet, but he had no psychological barrier preventing him from getting there. That small detail made me see things differently. That was when I realized that if engineers are not fungible, we are in deep trouble. We are the frog sitting in water that is slowly heating up. At first, it feels warm and comfortable, but little by little the temperature rises, and by the time we notice, we cannot get out of the pot anymore.

There was also another word back then: “hacker.” Hackers were the fullstack engineers of their time, and everyone respected them. Hackers touched everything, went everywhere, and achieved wonderful things. They picked up a programming language and, somehow, those bastards knew how to squeeze every last drop of performance out of it, and they did it fast. Everyone wondered how they managed to do it. Hackers were not like wannabe fullstack developers. You could sit them in front of a new technology, and before long they would come out victorious.

Few of us paid attention to that, and today some of us are enjoying the rewards. But many people only watched the results hackers produced and kept doing their same narrow job. The key to that question was that hackers had two basic components of a good engineer: they cared about understanding the system, and they put real effort into understanding it. For a hacker, making a prompt and looking at the result is not enough. A hacker spends months pushing a system or platform to its limits. Eventually, he discovers details buried in forgotten documentation, or details hidden deep inside the source code. That gives him an obvious advantage over everyone else.

Every hacker I have known in my life has been excellent. They are the kind of people worth having nearby, both because they are a source of knowledge and because they are the engines that start running when something new needs to be built.

The reason is simple: in technology, an engineer or hacker cannot depend on a single platform or system. He must be able to change stacks, understand the system, and remain useful. If you want to succeed in this world, you must hire engineers or hackers, preferably those with plenty of scars, or young engineers who are truly passionate about building products and solutions. People who do not only know how to write a goroutine in Go, but who understand how things work, at a high level, at a low level, and sometimes at a very low level. People who invest time in experimenting and learning, not people who got an AWS certificate and immediately started acting like they were on vacation.

Today, with AI, the bootstrapper has become a more complete role. With enough willpower, he can build things from beginning to end. But he is still the same bootstrapper from before, the same person who knew one or two platforms, only now wearing different clothes. In essence, he is still the same character: no blood in his veins, unable to leave his comfort zone, frozen by a simple question because he no longer trains his brain to understand, only to execute.

Sometimes I think it is like building an eighth-generation fighter jet capable of doing a thousand things, and then putting an average person in the cockpit. He manages to take off and perform a few maneuvers, but he does not understand the two thousand controls and capabilities of the aircraft. He does not know what to do when something goes wrong. He would probably fire every weapon at the first scare in front of an enemy. Actually, he might not even realize the aircraft has a problem and would keep flying it anyway.

That is today’s bootstrapper with artificial intelligence. He can build, yes. Does he understand? Little to nothing.