I've used IDEs and just plain ol vim. And I tells you, having an ide allowed me to debug problems my team thought undebuggable.
The reality is that rubymine costs 100/year for personal use, and I pay them with a smile because to me it is worth 10x that price. The reality is that ides can help you hide from bad package management. But package management is but such a tiny portion of code organization. And all editors let you find files by name or jump to definition. Some do it far better than others.
Watch someone use the latest jetbrains platform to see type annotation injection into typescript code. I've seen developers abandon vscode and others once they saw how smooth ides can be out of the box with the coolest features.
This blog post isn't insightful and doesn't even manage to present a consistent case against IDEs, and boils down to a sequence of weak strawmen. Describing a IDE's job as making it easier to type is pure nonsense and fails to even acknowledge what a IDE is and what it adds beyond text editors. In the very least, IDEs make it easy to navigate projects and run searches for things like source files or symbols, with the latter supporting types of searches not available in pure text searches such as finding where a function of a particular subclass is called.
This sort of article fall into a fallacy trap which is failing to understand what "integrated" in "IDE" means, and proceeds to fail to address what exactly is integrated.
You can extrapolate the whole "IDEs are a crutch" idea to pretty much any tool that saves time by automating something you would have had to do manually.
High level languages hide the underlying machine code being generated, so developers become less familiar with what the CPU is really doing. But in a way that's the whole point.
In the end, newbies will rely on the crutch to develop faster at the expense of not immediately understanding all that is happening behind the scenes, while more experienced developers will leverage the IDE to automate those things which they are tired of doing themselves. Eventually newbies learn what's happening under the hood.
> You can extrapolate the whole "IDEs are a crutch" idea to pretty much any tool that saves time by automating something you would have had to do manually.
You're not a real developer if you don't write in binary /s
back in its day, eclipse was actually ahead of its time. A usable refactoring tools, incremental compilation, edit/replace method while the program is running, run program with syntax error (as long as you don't hit that line), etc...
To support all these feature, they have written their own java compiler.
Overtime, it get bloated and collapse over its weight.
The point was something with spellcheck, much like an IDE would have with code mistakes, would have caught that error easily. Which takes away from his argument that you don't need IDEs.
Kind of like if someone was selling you a super reliable lawn mower, but it took 4 or 5 extra rip cord pulls to start, would have me less inclined to believe his pitch.
vim doesn't; it has an strong, active plugin infrastructure but the vast majority of people using vim don't use plugins at all
Reminder the topic here was we don't need IDEs because people should be smart enough to do it in an editor. I think that with spellcheck it's reasonable to say that if people make mistakes that could be solved with spellcheck, they could also make mistakes that could be solved with an IDE
What is an IDE? As someone who worked on IDEs approx between 2003 and 2014 (I did not like the market afterwards, commercial IDEs I basically impossible now unless you are legacy, like JetBrains).
What is an IDE? Personally, I consider IDE an integrated suite of source editor, visual debugger, build system. E.g. I put a breakpoint, push a button, it builds, runs and hits a breakpoint. Other tools (SCM integration, profiler integration, design tools) are an add-on.
So, is Bash an IDE? I think pretty much every modern editor allows setting up macros so it is possible to trigger build/run GDB from within the editor. Does author have an issue with Vim, Emacs and Sublime? What is the difference between Sublime and VSCode?
I started working after the collapse of RAD (rapid application development, think Delphi/VB) and model-driven tools (where you do UML and generate code from model). I am very strongly against those tools, don't think they can be done well. But those are category separate from IDE :) E.g. Rational Rose - could generate code from UML and parse the code to UML, but no code writing inside.
Another thing I take huge offence is people dumping on Eclipse. It was a revolutionary product that disrupted the space. It was blazingly fast compared to Java IDEs of the time (JBuilder, Visual Cafe and such) and had refactoring support comparable to IntelliJ (that was a paid product). It got destuffed at a critical junction (complete rearchitecture from Eclipse3 to E4) and saw crappy plugins (and Java really lost popularity since). But it was an amazing product 24 years ago.
I think this is an important distinction. I've seen many coworkers who laugh at my JetBrains IDE while claiming that their 'text editor' is better as they load it up full of plugins thus turning it into an IDE.
My general takeaway about the dev community is this- stop giving a crap about what other people are doing. If you find a tool that fits your needs and that you like then I'm delighted for you. Ask others if you want to learn but stop telling others they're wrong for having their own preferences.
I love this comment and love to see IDE features returning to editors via language servers and better build tools.
Eclipse RCP was a pretty cool toolkit for building enterprise desktop apps that could be deployed to both Windows and Linux desktops. You could build complex stuff without much effort. And by 2000s standards it looked pretty slick and sophisticated.
An IDE is integrated: it comes with the tools (debugger, build system, language support, etc) built in. If they're not integrated, it's not an Integrated Development Environment. I'd say things like VS Code, Sublime Text, Vim, and other plugin-based editors are "Plugin-based development environments", or PDEs (my term). Most IDEs these days are hybrids; they come with an integrated environment and support plugins as well.
Things like Eclipse IDE, IntelliJ and such are packages and not the products. Think distinction between Linux distro and Linux kernel.
E.g. my former team used to ship "IDE" - that is, use new project wizard to setup your folder, use editor to write the code, press a button to build, debug and profile. We also shipped standalone "visual profiler" - that had custom configuration for window layout/toolbars and stripped down list of included plugins. You open an executable, profile it, see per-line metrics in the read-only editor (that was a complete editor from the IDE, just in read-only mode).
So, does dropping a bunch of plugins (that noremally should not activate unless used) suddenly convert sluggish IDE into fast editor.
I feel like the negative perception of IDEs usually comes from busy UI. Devteam needs to balance discoverability (e.g. adding UI for configuring build and debug) and perceptions of the lightweightness.
No offense to the article author, but this is written like someone who has either never used a good IDE, or never learned how to really effectively leverage a good IDE (mastering all features, memorizing keyboard shortcuts, adjusting configuration to match your style, etc).
Yes, obviously the most time consuming part of developing software is thinking. But with an IDE, I can sometimes do some of that thinking out loud in code and rapidly prototype as I go with refactoring helpers, etc. This is not always the best approach, but it's a technique that has its place and is simply impractical without an IDE.
A strong senior engineer in a text editor can likely beat a junior engineer with the best IDE. But a strong senior engineer with the best IDE (and experience with that IDE, this is important!) will absolutely run circles around an equally strong senior engineer with a text editor.
I don’t think this is true largely because an experienced text editor user will generally have access to most of the same capabilities in a different form. Where there are differences, the win sometimes goes to the ide, and sometimes to the text editor, but generally people adapt their tools to themselves, and themselves to the tools, and in the end it shakes out to be about the same level of productivity.
I’m not convinced that people can easily switch though. I’ve met people who never really get the hang of working efficiently in the “Unix is the IDE” style of using text editors, and I can say from personal experience that I’m just never going to be particularly good at IDEs. I suspect that each tool simply appeals to a different personality type- and that’s okay as long as our projects don’t lock us in to something and we let people have the flexibility to use the tool that works for them.
I'm glad you have a toolset that works for you. To each their own!
But I swear as an IDE user, when non-IDE users try to describe to me how their toolset is just as good as an IDE ("most of the same capabilities in a different form"), it is like I'm a modern human coming into contact with member of a tribe that has been isolated from civilization, and they're trying to convince me how it's just fine to live in a mud hut without AC or running water, and that they've got all the basic stuff they need. Instead of going to a grocery store or farmer's market, they forage and hunt for food (and they're very proficient at it!). Instead of using bikes/cars/trains/planes to travel, they walk everywhere (but it's great exercise!).
And of course there is nothing inherently wrong with living any way you choose. In fact there are many merits to living more "primitively". But it'll be over 100 degrees today in Texas and I'm really glad I've got AC.
I'm genuinely not trying to be condescending here, so I apologize if that is how this came across. My main point is: I really think you should give IDEs a shot. The good ones are very good!
It did come across as quite condescending. The fact is that I’ve tried IDEs, many times. They aren’t a good fit for me.
If we’re doing unkind takes though, I’d say a better analogy isn’t that the non-ide users are ignorant so much as it is that the ide users are, through a lack of ability or motivation, unable to create their own tools to improve their craft, and so take whatever bland uninspiring monument to mediocrity that someone tries to sell them. Like a person who condescendingly eats ramen dry from the package and informs the person cooking a good meal that surely they must be ignorant to not realize you can buy perfectly edible food at the gas station on the corner.
Now, personally, I prefer to think better of people than that- and I assume that people are just choosing to use what works for them, and to not be a jerk about it.
Ha, I actually love that analogy! I will neither confirm nor deny whether I've eaten ramen dry from the package before...
I really didn't mean any offense, so I apologize. I was just trying to find an analogy for a feeling that I've otherwise found difficult to articulate, but I probably did not adequately convey the lighthearted sarcastic tone I intended. My bad.
As I said at the top of my last post, I would never intentionally begrudge or shame anyone for using tools they feel are a better fit for them -- to each their own.
No worries, sorry if my reply was a bit short too. Sounds like we're both happy for what we use, and willing to do a bit of lighthearted teasing of people on the other side with no real ill-will. I think that's a pretty good state for the world to be in.
Or perhaps you're the person standing there explaining to me why I should give up my set of chef knives for the single all-in-one convince of a Swiss army pocket knife :)
Personally, I've tried IDEs occasionally for decades and they've never stuck. I find that a lot of their integrations are ideal for narrow problem spaces, however, I don't often find myself fitting well into the designed problem space.
What do you mean by "beat" and "run circles around"? Is this some sort of speed test? Fewest bugs? Most efficient code? Something else?
One problem with CS being so male-dominated is the endless focus on turning everything into some sort of d*ck-measuring contest at each turn.
I write code for a large part of my living because I'm good at it and I enjoy it. I personally enjoy plain old Sublime over an IDE. I'm here to maximize my contribution to society and enjoy my time on earth. I'm not here to "beat" somebody in some nonsensical code battle.
My experience is that is it obvious from code that who did't used Pycharm. My colleagues use JupyterLab as best, mostly vim, and their code quality is underwhelming. Open their code in Pycharm, immediately see red highlights everywhere: They can't see any of those syntax and type errors in vim.
Full search or replacement has never been easiler after I shifted my workflow to Pycharm. Of course same thing can be done in the terminal, by typing 800 time `cd A/somewhere; vi something`. Why make life harder when tools are accessible?
This seems to me like an argument against power screw drivers, just because someone has one doesn't make them a carpenter or make carpentry easy for them. But would a skilled carpenter be better of saving their cognitive resources by offloading things to automation or tools, yes a hundred times.
While reading this article, I could not understand what the alternative was. Did he mean it's better to use Notepad++? Vim? Both of those have extensions that turns them into decent Integrated Development Environments. So just plain text files, no extensions? That just sounds annoying.
Finally understood what he was talking about in the last few paragraphs, when he mentioned only knowing how to run tests and pipelines through an IDE. He was talking about a GUI! I agree, clicking a button on a GUI that's magically hooked up to GitHub and runs whatever it needs to for testing is "complexity that pretends it's invisible", which was a great phrase. It's always a good idea to learn how to run everything from the terminal, because it's hard to hide complexity behind terminal commands. Not that it's impossible, but it's more of a philosophy from Unix for every command to only do one "action". So to build a project in Go, one runs `go build .`. And to run it, `go run .`. To test it, `go test ./...`. To debug, a set of flags must be passed to build. To build for a different target, a different tag. It's very explicit. In an IDE, relying on whatever buttons are made available means that these commands may be combined, or simply made unavailable
The author seems like they have never used Visual Studio or Rider to its greatest extent.
The Unix equivalent of a single Visual Studio install and all its functionality is
- clang
- CMake
- gdb (which is pretty lousy compared to VS' debugger)
- valgrind
- perf
- some record-replay tool (maybe perf?)
- system package manager
- language server protocol tool
- clang-format
- clang-tidy
And a whole other host of refactoring tools that just aren't present or possible in the author's tool of choice, Vim.
Sure, one could do complicated editing with indecipherable incantations in Vim, but I spend most of my time thinking, not typing—ironically the same argument that the author uses. I don't need a faster, more to-the-metal tool. I like the abstractions an IDE provides. Working with Git is immensely simpler in an IDE than it is in the command-line. Autocomplete, refactoring, and go-to-definition functionality is superb. All these help me think and write better code.
One problem I recently ran into with rider is the inability to run two commands at once in a launch config without them blocking each other. (Basically, it seems like launch configs are ALWAYS running serially)
You cannot claim 3rd party tools that aren't a part of the IDE as a victory for the IDE. That's absurd. If you find editing code with Vim to be indecipherable, that suggests you don't understand it, and that your opinion is likely not well informed.
I don't blame you or anyone else for not understanding vim because it's an obtuse dinosaur of a program that fails to meet the preconceived notions of modern users. Just understand that you don't know what you're talking about. If you get vim, you'd understand that IDEs are nothing but a bundle of cheap gimmicks.
I spent over a decade customizing and tweaking my vim installation, but for the past 5+ years I've been team IDE (JetBrains in particular). It's really incomparable if you have a good IDE for your language of choice.
"You'd understand that IDEs are nothing but a bundle of cheap gimmicks."
Honestly, I didn't think that these tabs versus spaces equivalence for IDEs versus text editors still existed today, but apparently people tie their personal identities to their tools more often than I would've expected.
Meanwhile, the third camp of people just use the applications that they're comfortable with, preferring to focus on getting the actual work done rather than making sweeping generalizations.
> You cannot claim 3rd party tools that aren't a part of the IDE as a victory for the IDE
They're not 'third-party tools'. That's what the 'integrated' in 'IDE' stands for, you don't need to maintain and pull a disparate collection of tools; there is one install and everything including the linter, compiler, linker, debugger, runner, profiler, benchmark, package manager, and version control system is part of it.
Let's also not use linters because... why exactly? Or let's go back to writing ASM because programmers no longer know how the CPU works. The whole point of abstraction is that we can do more, better, more efficiently.
The only thing an IDE brings to the table is a different user experience. A better user experience can be beneficial, but is not akin to giving up tooling. There is no reason (purposeful attempts at vendor lock-in aside) for the same tools to not be available outside of the IDE.
It's more like GUI vs the command line. Both can ultimately get the same job done, but the experience is different. And, frankly, I'm not sure there is one winner takes all. Sometimes GUIs allow you to do more, better, and be more efficient, but other times it is the command line excels at those things. There is situational dependence.
Not quite so. You need to explicitly run a linter, then look up the code lines that it's complaining about. In an IDE, you will have the lines marked while you are writing the code. Plus you get code completion and so on.
Working in a pure text editor works if you have a relatively small piece of code you can focus on while working, but I've seen very experienced engineers become extremely slow or completely fail with their vim setup when they suddenly work on something that's beyond the 20k line mark.
I use vim instead of an IDE and I've tried lots of IDEs (Visual Studio/C++, Code::Blocks, JetBrains stuff, Eclipse, VS Code). For more table setting, I also use a lot of linters and formatters (via ale), but I don't use any autocomplete.
I don't have any problems getting by with shell, sed, grep, and whatever debugger. I've debugged bonkers issues (gdb is super powerful), I've changed the names of things across huge codebases using sed, I've found all instances of things using grep, etc. I've written scripts to do these things and some of them I've reused (ex: I have a script that grep's the output of git status to see what I need to add to a commit to continue a rebase and then runs that git command).
It did take time to learn, but I would argue it didn't take longer than really getting to know an IDE. And now, I have pretty good knowledge of standard tools that's broadly applicable to lots of other problem domains. This has been useful as I've had to dip in and out of data engineering in the last few years, but it's also nice to just be able to whip up utilities to solve random problems that always crop up (does Funko sell some kind of Doug McIlroy talisman?).
As a result, I've always felt that IDEs were vaguely disempowering. I'm good at using *NIX on a variety of problems, and deploying these skills over the years I've gained a pretty deep understanding of how lots of things work (what makes grep fast, forking overhead, file descriptors, buffering on pipes and I/O in general, etc). I can't overstate the degree to which this has made me a better SWE. I'm not a PyCharm user or CLion user, I'm a computer user.
I don't want to veer too far into "IDE users are sheep" or whatever; I definitely don't think that. But for me, digging into *NIX tools essentially taught me about computers and software engineering, and gave me a broadly-applicable skillset that I use to solve bonkers problems all the time, but where I wouldn't even know where to start in something like VS Code. A good example here is I was just rereading tptacek's post on hiring (from also rereading the "Misidentifying Talent" post by luu) [0] [1], and he talks about one of the interview work sample prompts involves reverse-engineering a custom binary protocol. I don't really know how I would do that in PyCharm (or whatever the Ruby equivalent is), but I would make pretty quick work out of it in Wireshark.
I think these arguments just come down to aesthetics. Some people think that IDEs are fun to work with in their GUI magnificence and find a vim/emacs/etc. system extremely opaque and tedious. Others think that it's fun to wire your own system together to suit your own way of thinking and working, and feel suffocated and disempowered by an IDE. Use what you like, have fun, don't yuck my yum.
I found a compromise for IDE's (or in my case a heavily extended Emacs). I always really disliked IDE like functionality. It just pops up so many distracting information. Things you type will be marked in red as an error because I haven't finished typing it. 'Yes, I know there in no semicolon, I haven't typed it yet!'. It disturbs my train of thought when autocomplete suggestions pop up, and they might not be what I meant. Some IDE's do it fully automatically or break the flow of your typing in some way so you constantly have to watch your screen to see what it is doing.
But, it can also be very handy. Sometimes I have to search for the name of a function only where autocomplete could have helped me, or I get a PR comment for some minor error that my IDE would easily have spotted. So what I do know is that I only manually invoke syntax checking and completion functions. That way I can use it when I need it and not get constantly distracted by it.
I still turn off all the 'lens' like features, I don't like all kinds of verbose information intermixed with my code.
huh? I don't see these as mutually exclusive. And I say this as somebody who is equally adept using the Jetbrains suite of tools, and then dropping to a terminal to string together a bunch of GNU utilities in a giant piped bash statement.
And I really don't understand your comparison of using a jet brains IDE... to monitor network traffic. It's fairly self evident that if you want to do packet sniffing at a low level that wire shark is your best bet. Maybe you meant comparing fiddler to wire shark? (High level vs low level)
Yeah that's fair; I'm responding to the sentiment that without an IDE you're left to the tender mercies of stitching together lots of other tools yourself. I think the reality is we're all using lots of different tools, and tools that try to "be everything" are almost never good, so I think it's more nuanced than "I only use one tightly integrated tool and it's better than using a dozen tools I have to integrate myself".
I also think those other disparate tools are actually really good, and reading about and researching why they're good has given me a deeper understanding of software engineering that I can now apply in my own work. I think this is probably also possible with IDEs, but I think they're a little less approachable (and often closed source/proprietary) so it happens a lot less.
> I've changed the names of things across huge codebases using sed, I've found all instances of things using grep, etc.
You're able to change the name of a variable named 'user' without affecting comments or descriptive text about 'the user'? Props to you if you can do all that with grep/sed across, say, a combined PHP/JS project; I wasn't able to do that as easily as I can in IDE-land.
It's generally a combination of sed, grep, and vim. I don't think I'd be changing 'user'; more like 'user.email' to 'user.email_address'. My steps there generally are:
- grep to see how bad the problem is
- sed what you can
- vim the rest
Oftentimes the compiler or tests will bail you out; like just change the field name and fix the errors clang finds. If I don't have that kind of thing I consider adding it.
Also while it might take a little longer (though I've used IDE refactoring wizards and it's close), I almost never do it. Could be the kind of thing where like, "changing this would take 10 minutes and be really irritating, so let's take 5 minutes here and nail the name, or establish a convention", which I think leads to better codebases and probably trains you better as an engineer.
This seems to ignore situations where you're coming in to any codebase you didn't write from scratch. Naming and conventions are already established - they're bad. Refactoring entails moving, renaming, consolidating, etc. Personally, I've found most of these activities are usually much simpler to run using tools crafted for that purpose vs crafting my own from a variety of tools.
I've had a few interactions with folks who were staunchly "anti IDE" (not saying you are), but was watching a 'director of engineering' give a walk through of their codebase via vim, and was bashing on IDEs. "If you need an IDE, you probably shouldn't work here. You should always be able to know everything about your code, where stuff is, etc. I wrote most of this and it's not that hard". When I brought up that he had a multi-year 'lead' on people new to the codebase, and that IDEs often make it pretty quick to explore and familiarize oneself with new-to-me code... he just 'pffft'-ed that away as 'sounds like more of a you problem' comment. They were also trying to hire, and having a hard time (this was... 10 years ago... so no idea how they're doing now on hiring front).
(Sorry, just now reading this because I'm bored haha)
I guess my first thought here is that Vim has stuff like "go to definition", and depending on your language has had it for quite some time. I do agree there's a kind of toxic "in my day we wrote programs directly on spinning hard disk platters by being very careful with a magnet and tweezers" attitude in places, but I'll bet that for every one of those there's an equal, "I use actual good IDEs and anyone who doesn't leverage them can't possibly be as productive as me", so I think it probably washes out.
I don't think you should know everything about your code, the opposite actually. I think you should be able to entirely forget everything about your code when the day ends. I think you should be able to walk onto any codebase and quickly understand how things work having no foreknowledge, as though you'd forgotten everything over night. I don't think this has anything to do with IDEs or editors, but has everything to do with coherent mental models and documentation. Without that stuff, you're just Ctrl-P'ing around, just like w/ IDEs. My manager uses VS Code and whizzes around pretty well. I use Vim and whizz around just as well (arguably better as I don't use go to definition so I'm grepping and guessing where stuff is with... idk very good accuracy). I don't really see a point in arguing about it.
> Refactoring entails moving, renaming, consolidating, etc. Personally, I've found most of these activities are usually much simpler to run using tools crafted for that purpose vs crafting my own from a variety of tools.
I hear so much about refactoring and this kind of thing, and it conjures up this image of some sorcerer extracting a pervasive, cancerous hydra from a code's corpus and transmogrifying it into a new, tamed organ. I think a few things about this, but mostly "I frequently have to rename and restructure countless structures/classes and functions/methods across a multi-million line codebase and I need a tool to facilitate that" sounds bonkers to me. It's also hard for me to square that with any kind of testing infrastructure, code review process, or design process. Having to do that kind of thing even once is pretty wild; I can't imagine having to do it so often that I require tooling for it. I can't imagine an engineer dropping a multi-thousand line PR on me with "I refactored billing, but I used IntelliJ so don't worry" in the description. I wouldn't even look at it, honestly.
Which is to say, I actually think it is rare and generally unsuccessful. I've used refactoring tools and wizards in IDEs. They'll rename fields, change types, update type signatures, generate new getters/setters, etc. That's cool (I don't need it though, because I have Vim and macros)! But that's not really refactoring, that's changing names and types. Refactoring is changing the fundamental representation of the problem space, which means you're changing what different classes/modules are responsible for and how they meet those responsibilities. IDEs won't help you with that, but testing can and it's independent of IDEs or editors. I can imagine an engineer dropping a multi-thousand line PR on me with "I refactored billing, took forever to get tests to pass, but now they do" in the description. Not only would I look at it, I would dig in and help refine the approach (or whatever).
So again, I think IDEs are fine. I'm sure there are benefits to either side and I'm not super interested in them. I think it's largely an issue of aesthetics. But, again I think you're right that smart people try to make their aesthetic choices "correct" as though they're above irrational personal preferences, but the best thing I can say about that is it's just no fun haha.
This is one of those opinion pieces that serves as a stronger argument for the opposite position. If this is the best the author can come with, it's a very weak position indeed.
I agree with the authors conclusion but the argument here is underwhelming.
IDEs are sloppy and slow and they make engineers do dumb things.
"Why did you change all the whitespace in this file?"
"I dunno my IDE did it."
And almost every time I've had to retrain someone on git, it's because they were using an IDE and never understood how git works. The same issue pops up with debugging in situations where you only have gdb or ptrace and not your ide.
The author makes some good points about project organization and general attention to detail. I've used IDEs for over 20 years. Even when I used emacs for C++ and scripting languages, back in the day there weren't worthwhile IDEs for them on the platform I used, I looked forward to the day when there would be. I'm an IDE believer. However, I'm a stickler for organization, naming consistency, and general tidiness in codebases, because I think it affects onboarding speed and mental overhead for programmers, and I often rub up against programmers who don't notice shortcomings in these areas, because they rely on their IDE features to avoid spending any thought on code organization.
They don't care if a method is badly named or misspelled because they barely read names before they ctrl-click them. They don't care that files are haphazardly organized because they navigate by searching. They pick up a ticket and slack somebody to ask where the fix should go. Once they're in the right place, it's click click click and they're on their way.
The best programmers read class names and method names. They look at the directory structure to get a sense for how the codebase is organized. They try to understand the logic behind code they inherit, they try to write code with an evident logic that the next person can follow, through good organization and meaningful, consistent naming.
I've had programmers tell me that they didn't know a word was misspelled because they figured it was a word they didn't know. I told them if they see a word in our codebase they don't know, they shouldn't gloss over it, they should look it up, because somebody thought about that word before they typed it. They roll their eyes. They think everyone is like them and craps out names without thinking about them. They don't realize this has anything to do with why they're still mid-level at their age and people don't trust them with anything important.
In the end, I don't think the author is correct. I don't think that using a poor tool makes a programmer better, even if it forces them to do important things they wouldn't otherwise, like notice how things are named and organized. And I think the best programmers are better and faster with an IDE. But I certainly understand where he is coming from.
The section on Lock In effects makes little sense to me - if you look at popular .NET IDEs for instance, they mostly produce .sln and .csproj files - which is the defacto .NET standard, and works with the standard command line tooling. They're portable between IDEs, and you still produce .cs files with raw source code that you can open in any text editor.
It's similar with PHP via something like PHPStorm, Python via something like PyCharm - there's no real lock-in beyond personal habits in IDEs I've used.
More generally, in this space... using a text editor (with or without plugins) and using an IDE are both valid approaches. I do not believe either are fundamentally better than the other. Try both approaches and choose for yourself - it's all about finding what suits you as an individual and makes you more productive. You may even find that your choice differs depending on what software stack or language you're working with - mine does.
"Hot takes" aiming to belittle or degrade people that choose the opposite to you are unhelpful at best and discourage people from trying both options for themselves. No one is a worse developer because they like working with a simple UI with minimal distractions and separate tools for separate tasks, and no one is a worse developer because they like more integrated tooling with code suggestions, refactoring tools, integrated debuggers, etc.
I don't want to defend the author's point, but I do believe he saw this happen, because I've seen it myself. People used their IDE for something like code generation, didn't know how to do it without the IDE (even positively said it couldn't be done outside their IDE) and then when a database column gets added and somebody with a different IDE tries to tackle the problem, they can't. "I can tell you how to do it with Eclipse." "I... haven't used Eclipse since 2007." "Well, after you install Eclipse, here are the directions for setting up the plugin and regenerating the database code."
To the author's statement that it affects adoption of CI/CD, I've seen that, too, where teams didn't know how to run their Junit unit tests outside of an IDE and nobody felt capable of figuring it out. They were wrong, it didn't take too long to figure out, but they honestly believed that running Junit tests was a feature of their IDE, and were not aware that it could be run separately.
These aren't persuasive arguments about using IDEs, because any sensible person can avoid them. I don't want to defend the author's point; I just want to say that I believe him when he says he's seen these things.
Ah, I was thinking more about lock in as more of a hard technical lock in (where he talks about setting up new build systems, CI, etc) rather than a soft lock in created via a lack of education & understanding, but I can see how that can happen if people just use tools without understanding what they do. That's a fair point!
There are incredibly flexible, concise, low-ceremony languages, with implicit types where placing an IDE between you and code kinda obfuscates them. These are the languages where I think the best representation of code is the code itself.
Then there are elaborate, verbose, high-ceremony languages with explicit types, where looking at code and keeping up with ceremony might be a bit overwhelming. For those languages you probably want a lot more automation and a variety of info representation that goes way beyond code.
I'd go out on a limb to say that everyone here who likes/dislikes IDEs will split almost perfectly among those two language categories.
You're the reason I wrote "split _almost_ perfectly".
That said, looks like your history involves .NET -> Python/.NET. I went .NET -> PHP -> Ruby/Elixir/Go. It took me some time to withdraw from .NET before I started preferring not to have an IDE. If you're still split half/half between two worlds, I can understand why you're still hooked.
I disabled all the UI elements in IntelliJ so it looks like Emacs, and I learned Vim motions. IdeaVim takes a .vimrc and I have almost everything I'd want from Emacs/Vim. Works great for me, I can pretend it's an old school editor until I need the IDE stuff which is rare. Plus it scrolls smoothly at 120 fps and I can tweak it, manage plugins, and install plugins without editing config files.
It's impossible to have large team at a company working without a small set of IDEs. Just the sheer amount of explanation/teaching one has to do to any new to the team is going to overwhelm them. We can't expect people to be fine with just the command-line and some minimal editor. It doesn't work that way.
Not only problems but understanding; as someone who once taught beginning programmers, and assisted someone else before that wherein the students were given step-by-step instructions with an IDE and as a result many had little idea what to do if something didn't work, I started with the "text editor and command line" approach and those little problems mostly disappeared. Another side-effect I noticed is students being more confident in their work, which is likely because they felt like they understood what was happening at a deeper level of detail.
As a power vim user I still use a solid step by step by debugger and auto complete in which ever tool that provides. It just so happens to be vimbindings inside a jetbrains/vscode window!
The author seems to have a particular IDE/text editor and programming environment in mind. But they don’t ever reveal what those are and makes an argument much more general than that.
Ie: This one IDE is worse than this one text editor for this one programming environment. So every IDE is worse than every text editor for everyone.
I am sorry, but there is zero truth in a sweeping generalization like that.
What is an IDE anyway these days? VSCode with plugins is more IDE than some IDEs. The lines are all blurry. Is syntax highlighting considered to be an IDE? Clearly it’s doing more than text editing. It’s understanding the language.
Believe it or not, those days of pure text editors are long gone. Almost every modern iteration of a text editor does a lot of what would have been squarely in the realm of IDEs some years ago.
These are all just tools. Some are better than others in specific situations. Without the specifics, this kind of argument is noise.
Working without an IDE, I have less confidence when making potentially impactful changes. Where else is 'foo' used? What are the code paths that lead to method 'x'? If I rename this, will my tests also reference the new name?
78 comments
[ 3.5 ms ] story [ 141 ms ] threadThe reality is that rubymine costs 100/year for personal use, and I pay them with a smile because to me it is worth 10x that price. The reality is that ides can help you hide from bad package management. But package management is but such a tiny portion of code organization. And all editors let you find files by name or jump to definition. Some do it far better than others.
Watch someone use the latest jetbrains platform to see type annotation injection into typescript code. I've seen developers abandon vscode and others once they saw how smooth ides can be out of the box with the coolest features.
In any case. Just my take.
This sort of article fall into a fallacy trap which is failing to understand what "integrated" in "IDE" means, and proceeds to fail to address what exactly is integrated.
High level languages hide the underlying machine code being generated, so developers become less familiar with what the CPU is really doing. But in a way that's the whole point.
In the end, newbies will rely on the crutch to develop faster at the expense of not immediately understanding all that is happening behind the scenes, while more experienced developers will leverage the IDE to automate those things which they are tired of doing themselves. Eventually newbies learn what's happening under the hood.
You're not a real developer if you don't write in binary /s
back in its day, eclipse was actually ahead of its time. A usable refactoring tools, incremental compilation, edit/replace method while the program is running, run program with syntax error (as long as you don't hit that line), etc...
To support all these feature, they have written their own java compiler.
Overtime, it get bloated and collapse over its weight.
Kind of like if someone was selling you a super reliable lawn mower, but it took 4 or 5 extra rip cord pulls to start, would have me less inclined to believe his pitch.
Reminder the topic here was we don't need IDEs because people should be smart enough to do it in an editor. I think that with spellcheck it's reasonable to say that if people make mistakes that could be solved with spellcheck, they could also make mistakes that could be solved with an IDE
We are all human, we all make mistakes
The spellchecker is enabled with
There are also countless features for linter integration. Quickfix, location list, line gutter, highlight groups, popup windows, and much more.What is an IDE? Personally, I consider IDE an integrated suite of source editor, visual debugger, build system. E.g. I put a breakpoint, push a button, it builds, runs and hits a breakpoint. Other tools (SCM integration, profiler integration, design tools) are an add-on.
So, is Bash an IDE? I think pretty much every modern editor allows setting up macros so it is possible to trigger build/run GDB from within the editor. Does author have an issue with Vim, Emacs and Sublime? What is the difference between Sublime and VSCode?
I started working after the collapse of RAD (rapid application development, think Delphi/VB) and model-driven tools (where you do UML and generate code from model). I am very strongly against those tools, don't think they can be done well. But those are category separate from IDE :) E.g. Rational Rose - could generate code from UML and parse the code to UML, but no code writing inside.
Another thing I take huge offence is people dumping on Eclipse. It was a revolutionary product that disrupted the space. It was blazingly fast compared to Java IDEs of the time (JBuilder, Visual Cafe and such) and had refactoring support comparable to IntelliJ (that was a paid product). It got destuffed at a critical junction (complete rearchitecture from Eclipse3 to E4) and saw crappy plugins (and Java really lost popularity since). But it was an amazing product 24 years ago.
My general takeaway about the dev community is this- stop giving a crap about what other people are doing. If you find a tool that fits your needs and that you like then I'm delighted for you. Ask others if you want to learn but stop telling others they're wrong for having their own preferences.
This is only acceptable for things that don't have a network effect. If svn is the universal standard, then that forces me to use svn.
Eclipse RCP was a pretty cool toolkit for building enterprise desktop apps that could be deployed to both Windows and Linux desktops. You could build complex stuff without much effort. And by 2000s standards it looked pretty slick and sophisticated.
E.g. my former team used to ship "IDE" - that is, use new project wizard to setup your folder, use editor to write the code, press a button to build, debug and profile. We also shipped standalone "visual profiler" - that had custom configuration for window layout/toolbars and stripped down list of included plugins. You open an executable, profile it, see per-line metrics in the read-only editor (that was a complete editor from the IDE, just in read-only mode).
So, does dropping a bunch of plugins (that noremally should not activate unless used) suddenly convert sluggish IDE into fast editor.
I feel like the negative perception of IDEs usually comes from busy UI. Devteam needs to balance discoverability (e.g. adding UI for configuring build and debug) and perceptions of the lightweightness.
Yes, obviously the most time consuming part of developing software is thinking. But with an IDE, I can sometimes do some of that thinking out loud in code and rapidly prototype as I go with refactoring helpers, etc. This is not always the best approach, but it's a technique that has its place and is simply impractical without an IDE.
A strong senior engineer in a text editor can likely beat a junior engineer with the best IDE. But a strong senior engineer with the best IDE (and experience with that IDE, this is important!) will absolutely run circles around an equally strong senior engineer with a text editor.
For reference, my daily driver IDE is Rider.
I’m not convinced that people can easily switch though. I’ve met people who never really get the hang of working efficiently in the “Unix is the IDE” style of using text editors, and I can say from personal experience that I’m just never going to be particularly good at IDEs. I suspect that each tool simply appeals to a different personality type- and that’s okay as long as our projects don’t lock us in to something and we let people have the flexibility to use the tool that works for them.
But I swear as an IDE user, when non-IDE users try to describe to me how their toolset is just as good as an IDE ("most of the same capabilities in a different form"), it is like I'm a modern human coming into contact with member of a tribe that has been isolated from civilization, and they're trying to convince me how it's just fine to live in a mud hut without AC or running water, and that they've got all the basic stuff they need. Instead of going to a grocery store or farmer's market, they forage and hunt for food (and they're very proficient at it!). Instead of using bikes/cars/trains/planes to travel, they walk everywhere (but it's great exercise!).
And of course there is nothing inherently wrong with living any way you choose. In fact there are many merits to living more "primitively". But it'll be over 100 degrees today in Texas and I'm really glad I've got AC.
I'm genuinely not trying to be condescending here, so I apologize if that is how this came across. My main point is: I really think you should give IDEs a shot. The good ones are very good!
If we’re doing unkind takes though, I’d say a better analogy isn’t that the non-ide users are ignorant so much as it is that the ide users are, through a lack of ability or motivation, unable to create their own tools to improve their craft, and so take whatever bland uninspiring monument to mediocrity that someone tries to sell them. Like a person who condescendingly eats ramen dry from the package and informs the person cooking a good meal that surely they must be ignorant to not realize you can buy perfectly edible food at the gas station on the corner.
Now, personally, I prefer to think better of people than that- and I assume that people are just choosing to use what works for them, and to not be a jerk about it.
I really didn't mean any offense, so I apologize. I was just trying to find an analogy for a feeling that I've otherwise found difficult to articulate, but I probably did not adequately convey the lighthearted sarcastic tone I intended. My bad.
As I said at the top of my last post, I would never intentionally begrudge or shame anyone for using tools they feel are a better fit for them -- to each their own.
Personally, I've tried IDEs occasionally for decades and they've never stuck. I find that a lot of their integrations are ideal for narrow problem spaces, however, I don't often find myself fitting well into the designed problem space.
> IDEs Can Create Lock-In Effects
Because all the things come before this point are so absurd.
One problem with CS being so male-dominated is the endless focus on turning everything into some sort of d*ck-measuring contest at each turn.
I write code for a large part of my living because I'm good at it and I enjoy it. I personally enjoy plain old Sublime over an IDE. I'm here to maximize my contribution to society and enjoy my time on earth. I'm not here to "beat" somebody in some nonsensical code battle.
> One problem with CS being so male-dominated is the endless focus on turning everything into some sort of d*ck-measuring contest at each turn.
I hope you read what you wrote. Trying to be more effecient at work is "dick-measuring contest"? And somehow it's a gender problem?
It almost sounds like you're assuming women can't be competitive and enjoy writing better code faster.
Full search or replacement has never been easiler after I shifted my workflow to Pycharm. Of course same thing can be done in the terminal, by typing 800 time `cd A/somewhere; vi something`. Why make life harder when tools are accessible?
They're fast but oh what hell they leave behind.
Finally understood what he was talking about in the last few paragraphs, when he mentioned only knowing how to run tests and pipelines through an IDE. He was talking about a GUI! I agree, clicking a button on a GUI that's magically hooked up to GitHub and runs whatever it needs to for testing is "complexity that pretends it's invisible", which was a great phrase. It's always a good idea to learn how to run everything from the terminal, because it's hard to hide complexity behind terminal commands. Not that it's impossible, but it's more of a philosophy from Unix for every command to only do one "action". So to build a project in Go, one runs `go build .`. And to run it, `go run .`. To test it, `go test ./...`. To debug, a set of flags must be passed to build. To build for a different target, a different tag. It's very explicit. In an IDE, relying on whatever buttons are made available means that these commands may be combined, or simply made unavailable
The Unix equivalent of a single Visual Studio install and all its functionality is
- clang
- CMake
- gdb (which is pretty lousy compared to VS' debugger)
- valgrind
- perf
- some record-replay tool (maybe perf?)
- system package manager
- language server protocol tool
- clang-format
- clang-tidy
And a whole other host of refactoring tools that just aren't present or possible in the author's tool of choice, Vim.
Sure, one could do complicated editing with indecipherable incantations in Vim, but I spend most of my time thinking, not typing—ironically the same argument that the author uses. I don't need a faster, more to-the-metal tool. I like the abstractions an IDE provides. Working with Git is immensely simpler in an IDE than it is in the command-line. Autocomplete, refactoring, and go-to-definition functionality is superb. All these help me think and write better code.
I don't blame you or anyone else for not understanding vim because it's an obtuse dinosaur of a program that fails to meet the preconceived notions of modern users. Just understand that you don't know what you're talking about. If you get vim, you'd understand that IDEs are nothing but a bundle of cheap gimmicks.
Honestly, I didn't think that these tabs versus spaces equivalence for IDEs versus text editors still existed today, but apparently people tie their personal identities to their tools more often than I would've expected.
Meanwhile, the third camp of people just use the applications that they're comfortable with, preferring to focus on getting the actual work done rather than making sweeping generalizations.
They're not 'third-party tools'. That's what the 'integrated' in 'IDE' stands for, you don't need to maintain and pull a disparate collection of tools; there is one install and everything including the linter, compiler, linker, debugger, runner, profiler, benchmark, package manager, and version control system is part of it.
It's more like GUI vs the command line. Both can ultimately get the same job done, but the experience is different. And, frankly, I'm not sure there is one winner takes all. Sometimes GUIs allow you to do more, better, and be more efficient, but other times it is the command line excels at those things. There is situational dependence.
Working in a pure text editor works if you have a relatively small piece of code you can focus on while working, but I've seen very experienced engineers become extremely slow or completely fail with their vim setup when they suddenly work on something that's beyond the 20k line mark.
I don't have any problems getting by with shell, sed, grep, and whatever debugger. I've debugged bonkers issues (gdb is super powerful), I've changed the names of things across huge codebases using sed, I've found all instances of things using grep, etc. I've written scripts to do these things and some of them I've reused (ex: I have a script that grep's the output of git status to see what I need to add to a commit to continue a rebase and then runs that git command).
It did take time to learn, but I would argue it didn't take longer than really getting to know an IDE. And now, I have pretty good knowledge of standard tools that's broadly applicable to lots of other problem domains. This has been useful as I've had to dip in and out of data engineering in the last few years, but it's also nice to just be able to whip up utilities to solve random problems that always crop up (does Funko sell some kind of Doug McIlroy talisman?).
As a result, I've always felt that IDEs were vaguely disempowering. I'm good at using *NIX on a variety of problems, and deploying these skills over the years I've gained a pretty deep understanding of how lots of things work (what makes grep fast, forking overhead, file descriptors, buffering on pipes and I/O in general, etc). I can't overstate the degree to which this has made me a better SWE. I'm not a PyCharm user or CLion user, I'm a computer user.
I don't want to veer too far into "IDE users are sheep" or whatever; I definitely don't think that. But for me, digging into *NIX tools essentially taught me about computers and software engineering, and gave me a broadly-applicable skillset that I use to solve bonkers problems all the time, but where I wouldn't even know where to start in something like VS Code. A good example here is I was just rereading tptacek's post on hiring (from also rereading the "Misidentifying Talent" post by luu) [0] [1], and he talks about one of the interview work sample prompts involves reverse-engineering a custom binary protocol. I don't really know how I would do that in PyCharm (or whatever the Ruby equivalent is), but I would make pretty quick work out of it in Wireshark.
I think these arguments just come down to aesthetics. Some people think that IDEs are fun to work with in their GUI magnificence and find a vim/emacs/etc. system extremely opaque and tedious. Others think that it's fun to wire your own system together to suit your own way of thinking and working, and feel suffocated and disempowered by an IDE. Use what you like, have fun, don't yuck my yum.
[0]: https://sockpuppet.org/blog/2015/03/06/the-hiring-post/#work...
[1]: https://danluu.com/talent/
But, it can also be very handy. Sometimes I have to search for the name of a function only where autocomplete could have helped me, or I get a PR comment for some minor error that my IDE would easily have spotted. So what I do know is that I only manually invoke syntax checking and completion functions. That way I can use it when I need it and not get constantly distracted by it.
I still turn off all the 'lens' like features, I don't like all kinds of verbose information intermixed with my code.
And I really don't understand your comparison of using a jet brains IDE... to monitor network traffic. It's fairly self evident that if you want to do packet sniffing at a low level that wire shark is your best bet. Maybe you meant comparing fiddler to wire shark? (High level vs low level)
I also think those other disparate tools are actually really good, and reading about and researching why they're good has given me a deeper understanding of software engineering that I can now apply in my own work. I think this is probably also possible with IDEs, but I think they're a little less approachable (and often closed source/proprietary) so it happens a lot less.
You're able to change the name of a variable named 'user' without affecting comments or descriptive text about 'the user'? Props to you if you can do all that with grep/sed across, say, a combined PHP/JS project; I wasn't able to do that as easily as I can in IDE-land.
- grep to see how bad the problem is
- sed what you can
- vim the rest
Oftentimes the compiler or tests will bail you out; like just change the field name and fix the errors clang finds. If I don't have that kind of thing I consider adding it.
Also while it might take a little longer (though I've used IDE refactoring wizards and it's close), I almost never do it. Could be the kind of thing where like, "changing this would take 10 minutes and be really irritating, so let's take 5 minutes here and nail the name, or establish a convention", which I think leads to better codebases and probably trains you better as an engineer.
I've had a few interactions with folks who were staunchly "anti IDE" (not saying you are), but was watching a 'director of engineering' give a walk through of their codebase via vim, and was bashing on IDEs. "If you need an IDE, you probably shouldn't work here. You should always be able to know everything about your code, where stuff is, etc. I wrote most of this and it's not that hard". When I brought up that he had a multi-year 'lead' on people new to the codebase, and that IDEs often make it pretty quick to explore and familiarize oneself with new-to-me code... he just 'pffft'-ed that away as 'sounds like more of a you problem' comment. They were also trying to hire, and having a hard time (this was... 10 years ago... so no idea how they're doing now on hiring front).
I guess my first thought here is that Vim has stuff like "go to definition", and depending on your language has had it for quite some time. I do agree there's a kind of toxic "in my day we wrote programs directly on spinning hard disk platters by being very careful with a magnet and tweezers" attitude in places, but I'll bet that for every one of those there's an equal, "I use actual good IDEs and anyone who doesn't leverage them can't possibly be as productive as me", so I think it probably washes out.
I don't think you should know everything about your code, the opposite actually. I think you should be able to entirely forget everything about your code when the day ends. I think you should be able to walk onto any codebase and quickly understand how things work having no foreknowledge, as though you'd forgotten everything over night. I don't think this has anything to do with IDEs or editors, but has everything to do with coherent mental models and documentation. Without that stuff, you're just Ctrl-P'ing around, just like w/ IDEs. My manager uses VS Code and whizzes around pretty well. I use Vim and whizz around just as well (arguably better as I don't use go to definition so I'm grepping and guessing where stuff is with... idk very good accuracy). I don't really see a point in arguing about it.
> Refactoring entails moving, renaming, consolidating, etc. Personally, I've found most of these activities are usually much simpler to run using tools crafted for that purpose vs crafting my own from a variety of tools.
I hear so much about refactoring and this kind of thing, and it conjures up this image of some sorcerer extracting a pervasive, cancerous hydra from a code's corpus and transmogrifying it into a new, tamed organ. I think a few things about this, but mostly "I frequently have to rename and restructure countless structures/classes and functions/methods across a multi-million line codebase and I need a tool to facilitate that" sounds bonkers to me. It's also hard for me to square that with any kind of testing infrastructure, code review process, or design process. Having to do that kind of thing even once is pretty wild; I can't imagine having to do it so often that I require tooling for it. I can't imagine an engineer dropping a multi-thousand line PR on me with "I refactored billing, but I used IntelliJ so don't worry" in the description. I wouldn't even look at it, honestly.
Which is to say, I actually think it is rare and generally unsuccessful. I've used refactoring tools and wizards in IDEs. They'll rename fields, change types, update type signatures, generate new getters/setters, etc. That's cool (I don't need it though, because I have Vim and macros)! But that's not really refactoring, that's changing names and types. Refactoring is changing the fundamental representation of the problem space, which means you're changing what different classes/modules are responsible for and how they meet those responsibilities. IDEs won't help you with that, but testing can and it's independent of IDEs or editors. I can imagine an engineer dropping a multi-thousand line PR on me with "I refactored billing, took forever to get tests to pass, but now they do" in the description. Not only would I look at it, I would dig in and help refine the approach (or whatever).
So again, I think IDEs are fine. I'm sure there are benefits to either side and I'm not super interested in them. I think it's largely an issue of aesthetics. But, again I think you're right that smart people try to make their aesthetic choices "correct" as though they're above irrational personal preferences, but the best thing I can say about that is it's just no fun haha.
IDEs are sloppy and slow and they make engineers do dumb things.
"Why did you change all the whitespace in this file?"
"I dunno my IDE did it."
And almost every time I've had to retrain someone on git, it's because they were using an IDE and never understood how git works. The same issue pops up with debugging in situations where you only have gdb or ptrace and not your ide.
They don't care if a method is badly named or misspelled because they barely read names before they ctrl-click them. They don't care that files are haphazardly organized because they navigate by searching. They pick up a ticket and slack somebody to ask where the fix should go. Once they're in the right place, it's click click click and they're on their way.
The best programmers read class names and method names. They look at the directory structure to get a sense for how the codebase is organized. They try to understand the logic behind code they inherit, they try to write code with an evident logic that the next person can follow, through good organization and meaningful, consistent naming.
I've had programmers tell me that they didn't know a word was misspelled because they figured it was a word they didn't know. I told them if they see a word in our codebase they don't know, they shouldn't gloss over it, they should look it up, because somebody thought about that word before they typed it. They roll their eyes. They think everyone is like them and craps out names without thinking about them. They don't realize this has anything to do with why they're still mid-level at their age and people don't trust them with anything important.
In the end, I don't think the author is correct. I don't think that using a poor tool makes a programmer better, even if it forces them to do important things they wouldn't otherwise, like notice how things are named and organized. And I think the best programmers are better and faster with an IDE. But I certainly understand where he is coming from.
It's similar with PHP via something like PHPStorm, Python via something like PyCharm - there's no real lock-in beyond personal habits in IDEs I've used.
More generally, in this space... using a text editor (with or without plugins) and using an IDE are both valid approaches. I do not believe either are fundamentally better than the other. Try both approaches and choose for yourself - it's all about finding what suits you as an individual and makes you more productive. You may even find that your choice differs depending on what software stack or language you're working with - mine does.
"Hot takes" aiming to belittle or degrade people that choose the opposite to you are unhelpful at best and discourage people from trying both options for themselves. No one is a worse developer because they like working with a simple UI with minimal distractions and separate tools for separate tasks, and no one is a worse developer because they like more integrated tooling with code suggestions, refactoring tools, integrated debuggers, etc.
To the author's statement that it affects adoption of CI/CD, I've seen that, too, where teams didn't know how to run their Junit unit tests outside of an IDE and nobody felt capable of figuring it out. They were wrong, it didn't take too long to figure out, but they honestly believed that running Junit tests was a feature of their IDE, and were not aware that it could be run separately.
These aren't persuasive arguments about using IDEs, because any sensible person can avoid them. I don't want to defend the author's point; I just want to say that I believe him when he says he's seen these things.
There are incredibly flexible, concise, low-ceremony languages, with implicit types where placing an IDE between you and code kinda obfuscates them. These are the languages where I think the best representation of code is the code itself.
Then there are elaborate, verbose, high-ceremony languages with explicit types, where looking at code and keeping up with ceremony might be a bit overwhelming. For those languages you probably want a lot more automation and a variety of info representation that goes way beyond code.
I'd go out on a limb to say that everyone here who likes/dislikes IDEs will split almost perfectly among those two language categories.
That said, looks like your history involves .NET -> Python/.NET. I went .NET -> PHP -> Ruby/Elixir/Go. It took me some time to withdraw from .NET before I started preferring not to have an IDE. If you're still split half/half between two worlds, I can understand why you're still hooked.
Not only problems but understanding; as someone who once taught beginning programmers, and assisted someone else before that wherein the students were given step-by-step instructions with an IDE and as a result many had little idea what to do if something didn't work, I started with the "text editor and command line" approach and those little problems mostly disappeared. Another side-effect I noticed is students being more confident in their work, which is likely because they felt like they understood what was happening at a deeper level of detail.
Ie: This one IDE is worse than this one text editor for this one programming environment. So every IDE is worse than every text editor for everyone.
I am sorry, but there is zero truth in a sweeping generalization like that.
What is an IDE anyway these days? VSCode with plugins is more IDE than some IDEs. The lines are all blurry. Is syntax highlighting considered to be an IDE? Clearly it’s doing more than text editing. It’s understanding the language.
Believe it or not, those days of pure text editors are long gone. Almost every modern iteration of a text editor does a lot of what would have been squarely in the realm of IDEs some years ago.
These are all just tools. Some are better than others in specific situations. Without the specifics, this kind of argument is noise.