×

What Could You Still Achieve If From Tomorrow Only a Simple Text Editor Was Available?

Many younger software developers began their careers in an environment overflowing with tools: a mature IDE with dozens of plugins, AI assistants like Copilot that suggest, correct, or even write entire code directly in the editor. Add to that frameworks that bootstrap everything, and extravagant runtime environments that seem to take every effort off your hands.

Of course, I enjoy these possibilities today too – they make us faster and more productive. But I wouldn’t want to miss my experiences from the time without all of that. Back then: only a pure text editor, maybe with syntax highlighting, but without IntelliSense, without automatic dependency resolution. No framework, just pure code. No containers or Kubernetes, but directly on bare metal or plain Linux.

Today’s tools are there to be used. But you should consciously forego almost all of them at least once. Especially in languages with strong standard libraries like Go or Python, this is feasible and instructive.

My Concrete Suggestion for You

Take a weekend and build a small but complete project – for example, a simple HTTP server, a CLI tool, or a file processing utility. Rules:

• Only a simple editor (vim, nano, or even Notepad – without plugins).
• Only the language’s standard library, no external packages.
• No build tool like Maven or npm, no Docker, no AI assistant.
• Compile/run directly via the command line.

It will feel strange. It will be laborious. But that is precisely the pure essence: without unnecessary dependencies, without external constraints – just the fundamentals and your ingenuity. I am convinced: once you experience how simple and elegant something can run, you won’t immediately reach for the next library or tool for every problem in the future.

The Value of Scarcity and Deep Understanding

When I started programming in the early 90s, there were hardly any sources: books, reading other people’s source code, and exchanging ideas with like-minded people. Information was scarce and valued. This forced us to truly understand things, not just copy them. It’s not about rote memorization, but intuitive understanding – a muscle memory for the brain. That stays with you, even if you need to look up the exact name later.

Today, with AI assistants, it’s easy to think: “I don’t need to know that myself anymore.” But what if you’re offline tomorrow? If AI becomes more expensive and only available in a limited way? Or in a whiteboard interview without an IDE? What can you still accomplish on your own then? Was it ultimately just the tool doing your work?

Anticipating Objections

Some will object: “In reality, everything has to be fast – we have deadlines!” Sure, in day-to-day work, tools count. But this experiment only costs a few hours or a weekend – and makes you faster, more confident, and more independent in the long run.

Another objection: “Modern projects are far more complex than they used to be.” That’s exactly why it’s important to know what’s happening under the hood. The more layers you put in between, the greater the risk of losing control.

Lessons from Other Crafts

In other professions, this is a given. A carpenter first learns with hand tools – planes, saws, chisels – before reaching for the CNC machine. It is the manual skill that creates the foundation for using the machine meaningfully.

Why do we believe in software development that more and more tools are the solution? This can’t end well – we lose control. Frameworks become a black box for the code, tools a black box for the process.

The Path Forward: Conscious, Minimal Use

Complete abstinence would be wrong. But conscious, minimal use is the way. Knowing what you really need – and what you don’t – grants you freedom.

Frameworks and tools promise higher throughput, more profit. But the more you only work with tools, the more replaceable you become. The fallacy that “AI replaces developers” is increasingly being debunked – because real problem-solving goes deeper.

Use tools so they support your work. Don’t become the operator of the tools – because we can (still) do it much better!

Take on the challenge. You’ll be surprised by how much you can really do – and how liberating that is.

Further Explorations

• Project Euler – Sharpen your algorithmic and mathematical thinking with problems designed to be solved with minimal code.
• Build Your Own X – A curated list of step-by-step tutorials for recreating technologies from scratch.
• Coding Challenges – A collection of challenges that encourage you to implement tools like curl or wc yourself.
• Crafting Interpreters – A book that guides you through building a programming language from the ground up.

Have thoughts on this article? Join the discussion on —I’d love to hear your perspective!