#08: Your tools do not need to be the future

Every few months, programming announces that everything you know is obsolete.

A new language, editor or framework appears. Its website has a dark background, one suspiciously perfect benchmark and a code sample compressing twelve deliberately ugly lines into three that nobody has deployed. Within a week, people happy on Tuesday are writing migration plans on Friday.

Then comes the testimony.

I used to love that language, but it sucks. This one is so much better. I am more productive than ever. It is the future of programming.

The future of programming arrives remarkably often for an industry that still cannot reliably centre a rectangle.

I have struggled with this anxiety too. I like my tools. I can solve the kinds of problems I care about with them. Then the internet explains that liking them is evidence of professional decline and that a genuinely serious engineer would have replaced the entire stack before lunch.

After programming since roughly 1994, I have now survived enough futures to notice that most of them become ordinary tools, obscure trivia or abandoned GitHub organisations. The useful question was never whether a tool belonged to the future.

It was whether the tool belonged in my hands.

I do not use the best programming language#

I write a lot of Go. Not because Go is the best language ever written. It is not. Please put the pitchfork back in the monorepo.

I use it because Go maps reasonably well onto how I tend to think about services and systems. Data moves explicitly. Control flow is visible. Deployment often ends with one binary rather than a travelling circus of runtime dependencies. Errors remain in the room instead of teleporting into a distant exception handler wearing a fake moustache.

Go has its little acts of hostility. Error handling can become a geological layer of if err != nil, and the type system spent years responding to requests for generics with the emotional availability of a concrete bollard. Still, I can usually hold the program in my head, find the part that is lying and ship it. That balance works for me.

Sometimes I am an ANSI C enjoyer. C maps better to keyboard firmware, where a tiny metal leg of an STM32 can become both UART and somebody’s punctuation key. C does not protect me from C. That is practically its brand. But when a peripheral register contains the wrong bits, being close to the hardware helps.

At work I use a lot of C# because that is what our integration platform speaks. I also enjoy parts of it. Its mature runtime and tooling let me model dreary business systems without pretending an invoice is a revolutionary distributed-computing primitive.

These languages are not competing to become my personality. They have different costs, failure modes and relationships with my brain.

The closest thing I have to a selection algorithm is this:

1value(tool) = problems_solved
2            - cognitive_friction
3            - operational_cost
4            - migration_tax
5            - amount_of_weekend_lost_to_build_system

There is no term for social-media excitement because social-media excitement has never paged me at 03:00 and repaired a production integration.

None of those choices were made because somebody promised me they were the future.

I have already seen the future#

When I started doing web development, people told me Lasso was the future of the web.

Now, do not be shy. Put up one hand if you have heard of Lasso. Put up both hands if you have actually used it. Keep them up if you are a web developer.

So, zero.

Yeah. Thought so.

Lasso was not uniquely foolish, and the people using it were not idiots. It solved real problems. That is precisely the point. A tool can be useful without becoming the permanent future of its field. It can dominate conference talks and still become something future engineers meet only while excavating an old system.

I have watched this happen to languages, databases, compilers, application servers, package managers, operating systems and enough JavaScript frameworks to make carbon dating a frontend skill.

Some disappeared. Some survived in a niche. Some ideas returned twenty years later with a new logo and a launch post explaining that nobody had ever thought of them before. Meanwhile COBOL continues processing money, C continues operating everything with a memory address, and JavaScript continues escaping every containment strategy devised by computer science.

Predictions about programming are usually predictions about communities, economics and organisational inertia disguised as opinions about syntax. An elegant language can lose because it lacks libraries, documentation or employers willing to bet payroll on it. An irritating platform can survive because replacing it requires three years, forty integrations and the cooperation of a vendor whose support portal only works in Internet Explorer.

Code is never selected in a laboratory. It lives inside teams, budgets, existing systems and the cruel passage of time.

Switching tools is real work#

The standard argument assumes tools are interchangeable skins over the same abstract activity. If editor A has more features than editor B, switch and receive productivity. Product comparison pages do not include the model already living in your nervous system.

I have used some form of Vim for as long as I can remember. These days it is Neovim with a small TUI setup I understand. Its motions are motor memory. Text objects, registers, macros and quickfix lists compose into an editing language that fits how I move through code.

Replacing that is not brew install other-editor. It is replacing thousands of tiny, practised decisions.

People have told me for years that I would be more productive in Emacs, VS Code or whichever JetBrains product currently has enough RAM to develop self-awareness. They recite features without asking which problems my setup solves. I do use VS Code with Lean 4, usually while crying. That may be more about Lean than VS Code. Another editor can be the sensible choice; I just do not owe it a permanent migration.

My terminal preference did not begin as vintage computing cosplay. I spent roughly eight years using laptops without Xorg because terminal workflows made better use of the hardware, let me run more terminals, and the web was still usable through ELinks. Then websites decided documents required GPU acceleration, six megabytes of JavaScript and consent from seventeen tracking vendors. The terminal remained where I could see the system clearly.

Familiarity reduces the distance between intention and result. It can create blind spots, but accumulated fluency has value even if the new tool has rounded tabs and launches 11 percent faster on the founder’s laptop. A migration should solve a problem large enough to pay for what it discards.

The productivity cargo cult#

The cargo cult begins when we copy the equipment of productive people and expect productivity to arrive with it. Someone builds remarkable systems using a modal editor, split keyboard and language released last Thursday. The internet extracts the easy lesson: acquire all three. Nobody can install the judgement, failed projects and quiet practice which did the work, so we buy the props and hope competence appears during the firmware update.

Tools are fun. Configuring an editor can be a satisfying hobby, and a new language can teach you another way to model state or ownership. I built a Kubernetes platform for a static website; I am in no position to arrest anyone for excessive tooling.

The problem is confusing tool activity with problem progress.

You can spend a week moving a working project to the fashionable framework and end with the same product plus newer build errors. You can rebuild an editor into an air-traffic-control dashboard while never writing the thing you opened it to write.

You can have the shiniest tools available and still do nothing all day.

The industry encourages this for one simple reason.

Tools are much easier to market than judgement.

Nobody can sell you ten years of experience in a launch-week discount. They can sell you an AI-powered terminal which summarises the error message immediately above it.

So every tool becomes a lifestyle and every preference becomes a faction. People stop saying this works well for my constraints and start saying anyone still using that is unserious. A local choice turns into a universal law because Twitter has once again slapped its e-penis on the table and mistaken noise for engineering evidence.

That is not technical discussion. It is status theatre with a package manager.

Curiosity without conscription#

None of this means staying inside the same toolchain until the heat death of the universe.

New tools matter. Rust forces useful conversations about ownership and memory safety. Functional languages change how you think about data and effects. A different editor may reveal friction you had stopped noticing. Better debuggers and static analysis can remove entire categories of wasted time.

Curiosity is good. Conscription is not.

Personal fit stops being the only criterion when other people inherit the result. In municipal systems and integration platforms, the best technology for an organisation is often the one twenty engineers can understand, not the one two engineers adore.

The launch enthusiast eventually changes jobs. The payroll integration stays. A boring language with known failure modes, usable documentation and a credible upgrade path can be the more ambitious engineering choice because the organisation can still operate it five years later.

Collective fluency is a system property.

When something shiny appears, I try to ask what specific pain it removes:

• Does it make a problem I actually have easier to express or debug?
• What operational machinery arrives with it?
• Can the team maintain it after the enthusiast leaves?
• Is the ecosystem alive, or merely loud?
• What working knowledge and tooling would the migration discard?
• After the novelty wears off, do I still want to use it?

Sometimes the answer justifies a switch. Sometimes the experiment itself is valuable. Sometimes the new thing is genuinely better and the old tool has become an expensive collection of workarounds held together by institutional memory and one build server nobody is allowed to reboot.

Then move.

But move because you found a better relationship between the tool and the problem, not because a stranger posted a bar chart where the bars began at 97 percent.

Does this bring me joy?#

“Does this bring me joy?” sounds unserious as an engineering criterion. It is still more informative than “is this the future?”

Joy does not mean frolicking through a meadow while the tests applaud. Sometimes the right tool is boring, a team standard outranks personal taste, security support ends or the only maintainer retires to raise goats. Responsible engineering contains many things which do not spark joy.

But enjoyment often points toward cognitive fit: fast feedback, understandable failures, useful constraints and a willingness to return. A tool you enjoy invites practice. Practice builds fluency. Fluency makes difficult work feel possible.

Misery has a cost too, despite the industry’s long experiment with treating it as proof of professionalism.

So have an honest look at whatever you are using. Does it bring you joy? Does it let you do the work in front of you? Do you understand how it fails and can you operate what it produces?

If so, keep using it.

Try new tools because curiosity is one of the pleasures of programming. Learn new languages because each one gives you another angle from which to attack a problem. Replace your setup when the new thing earns its migration cost.

Just stop comparing your toolbox to somebody else’s career performance on social media. There is no magical editor, language or framework that will turn you into a 100x engineer. There is only knowledge, practice, judgement and a long sequence of tools which either help those things reach the machine or get in their way.

The future will arrive whether or not your editor has a minimap.

You still have to write the code.