There is an interesting misconception about programmers' tooling. One of the best programmers in the world for some reason use very simple tools. And a lot of people assume that it's because they are old and simply have not learnt the modern tools. This is not true. As you get better as a programmer you realize the importance of simplicity in engineering. You start cutting out the "fat" in everything including your own development setup. A lot of programmers start with very featureful heavy development environments and slowly refine them to a notepad over many decades as they realize what's actually important in Software Engineering.

@tsoding with content creation i feel this more and more. i have people telling me when i stream to use AI autocomplete or LSP plugins - they almost have a heart attack when i tell them i find even basic auto-complete distracting. im one step away from syntax highlighting being too much.

@tsoding curious to hear your thoughts on why simplicity is preferred.

@tsoding I am old and I simply have not learn modern tools.

@tsoding what is your rubric for who are the best programmers?

@tsoding Good engineers strip down setups because they've learned what actually matters, like fast feedback, minimal context switching, tools that don't break.

@tsoding I used to be a heavy Linux ricer, with the all arch + hyprland + waybar thingy (previously KDE etc) Now just a full screened terminal, and that's it... My tmux status bar just shows my battery % Other than that, I use a browser... Simplicity ftw x.com/i/status/20048…

@tsoding the best programmers I know aren't avoiding complexity, they just ran out of patience for tools that solve problems they don't have

@tsoding So maybe Linux having no good debuggers is acceptable if one is experienced enough...

@tsoding If you aren't using latest AI model to generate some slop you are falling behind by 6 months every day

I think a lot of it depends on the context. The type of software I wrote decades ago where 95% of what was running in my app was my own code , versus today , where the context of most software jobs is calling other libraries and 95% of CPU is running in library/framework/os code and IDEs are about finding the “magic words” on library functions and params, which is so large nobody would remember it all , IDEs with code completion are truly a major time saver. This is quite a different context than fun hobby projects

@tsoding I have this theory that the reason there are "no good debuggers for linux" is because, apart from the usual "printf is all you need", gdb actually has everything anyone could need from a debugger, and it's just a matter of "programming" it, which is what linux devs do

@tsoding You need proper tooling when working on large legacy codebases if you want to make meaningful impact. Editing files one by one will not cut it, and sed is too limited.

I went the other way, but I still have what is generally considered a minimal setup. I started with the basics, and only added if there was a REALLY compelling reason to do so. I do: (1) Version control with git - this is a tool that we can't and shouldn't live without, but is so good we don't deserve it (2) Minimal CI/CD pipeline for making production builds. This forces you to be explicit about all dependencies involved. I can't tell you how many projects get delayed by weeks or months because no one can replicate the original tooling. (3) Context-aware editor. The editor should make it easy to take or ignore suggestions. It should only do operations that it knows it can do flawlessly. I prefer VS Code unless I'm doing Java, in which case IntelliJ or Android Studio rocks. vi is fine, though. (4) Any code generation should either be (A) one-time only generation (i.e., template for starting something new that the programmer is to maintain), or (B) ongoing code generation but INVISIBLE to the programmer. If the programmer might have a reason to modify it, they SHOULD NOT have a reason to re-generate it.

@tsoding As a multi decade developer, I think most "tools" end up just getting in the way of doing the work.

@tsoding Life is too short to fix your project repeatedly when those tools or libraries break yet again.

@tsoding Hi from Cowtown; that's why I use: MinGW64/gcc cheesy easy light, fast, and portable.

@tsoding that's what I like about vscode, it's relatively bloated out of the box, but its modularity allows you to make the interface look very lightweight

@tsoding Debbugers aren't simple tools but are imo essential for software development

@tsoding I stopped feeling bad about choosing the GUI version of an CLI tool years ago. Too many commands, flags, and variables to learn when I already have too many of those even if I just take the smallest number.

@tsoding In university I used notepad Then I had CLion License ended, and I realized I couldn't type code without an IDE doing everything for me. Eventually I recovered, but now I am very careful not to become a slave to a corporation again. AI does the same thing - makes you a slave.

@tsoding I use a basic editor(sublime text), cmd(usually with tmux), and some custom in-house project management tools that have a simple web interface. For actual coding I don't have really any fancy features at all. I tried VSCodium(vs code with telemetry stripped) and its just "busy"

Nah, as I got older and better as a programmer, I realized tooling IS, in fact, extremely important, and having a nice developer environment (although it does not means "bloated environment") is a very nice thing to have. This is also true because, as I got older, my memory got worse and I started having a bunch of very specific pains in my hands, which means: I simply don't want to deal with this shit when technology can help me. This sounds a whole lot more like a romanticization of what you consider "simple", than what's actually helpful.

The progression you're describing is less about abandoning modern tools and more about developing clarity on what actually moves the needle in software development. Heavy IDEs solve legitimate problems, but they also create distance between the programmer and the code. As you internalize patterns and build intuition, that abstraction layer starts to feel like interference rather than assistance. The insight is recognizing that complexity in tooling often mirrors complexity in thinking. Simplifying your environment forces you to simplify your approach, which tends to produce better software.

@tsoding Started with Nopepad++ then jumped on the VSCode hype train, it slowed me down then went back to my old faithful friend Notepad++

@tsoding Fucking true. That's why javascript and typescript are trash.

@tsoding When you start building products that run in real world industries, and as projects grow in features over years of development, no, notepad is not enough. I get your point, but we cannot compare compiler optimization with building Netflix.

@tsoding "bruteforce then refactor" over years.

@tsoding tbh that's why I have dropped debuggers. And from months ago, I started thinking that even Neovim and LSP are bloated and I can remember all the things in my mind. But I haven't abandoned those things yet for convenience 😅

@tsoding Hence everyone using SEU with Christmas Tree mode on modern syntax.

@tsoding very true. but sometimes an IDE is the only way to have an acceptable debugging experience. and debuggers are one of the greatest tools ever. using since Amiga500 times, would never want to miss

@tsoding I think this is slightly uncharitable -- it's not that they learn what's important, it's that they *become more capable* The junior doesn't use the bloated tools because they're oblivious, they genuinely do need the training wheels

On the other hand, the same tooling cultists scorn Visual Studio, which, as a geezling, I have grown to love (coming from vim + custom Makefile infras). It’s a different kind of simplicity, on the far side of complexity. It allows me to focus on the design, rarely the tooling. And there is no better debugger. Native gdb is still awkward after decades.