Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Benefits of Not Using an IDE

alexander-hansen.dev

Post reply on HN
Print view View original

201–210 of 389 posts

Re: Benefits of Not Using an IDE

#201

Post by rzwitserloot »

bccdee wrote: post #165
drunkpotato wrote: post #136

Earlier quoted context omitted.

The best developers I've found are the ones who know how to work without an IDE, even if their preference is to use one. Contrastingly, the worst, slowest developers I've worked with rely on their IDE without understanding what it's doing for them, and are helpless in new/unsupported situations. They also, 100% of the time, screw up their git repositories on a regular basis, and need someone who knows what they're do…

The thing I hate most about IDEs is when they insinuate themselves into a project's development workflow so deeply that you can't make do without them. Do I have to spin up a whole session of the IDE just to run my test suite? Do I have to dig through eleven nested GUI settings dialogues to find out what the command to build the damn project is, just so I can tweak a build parameter? Is there so much boilerplate or X…

> Do I have to spin up a whole session of the IDE just to run my test suite?

In the java ecosystem at least, the answer is no. But in highly CI-based situations, the answer is still no, but you DO need the CI system to be up, and the only way to run a test at all is to just commit something and see the CI system run it, e.g. because the tests require a database engine that isn't installed on your development machine.

I'm not saying that's a good idea, just saying that I have seen that in real (as in, for pay and for real eyeballs) dev teams. I've never observed 'I only know how to run my tests inside the IDE'. IDEs (again, this is mostly speaking from the perspective of the java ecosystem) use build tools as project definitions, and those build tests all know how to run the test suite from the command line. `mvn test` is all you need to type.

> Do I have to dig through eleven nested GUI settings dialogues to find out what the command to build the damn project is, just so I can tweak a build parameter?

No, it's `mvn install` or `mvn build` or whatever take on 'build' you are looking for specifically.

If you ditch your IDE, __nothing__ whatsoever would change: Your build is _still_ based on a build tool. (it better be, in the sense that trying to run the build by hand or by patching a bunch of shell scripts together is almost 100% correlated with very low quality dev teams in my experience).

In other words...

what are you on about? IDEs don't abstract such details away to extreme degrees. In fact, insofar that they ever did (generally in GUI builders, which, what with the web and languages like java and Adobe Air and silverlight falling by the wayside in the past few years for front-end dev - are kinda dead), the new takes on such tools all very explicitly keep the whole 'actually this just edits a text file of some sort and this automated click-the-GUI-together tool is bending over backwards to ensure that the underlying file looks as close as possible to what you would write by hand.

Re: Benefits of Not Using an IDE

#202

Post by willjp »

the_third_wave wrote: post #56

I think the benefits of working with KISS tools - the opposite of 'everything but the kitchen sink' in Emacs parlance - is that it significantly lowers the cognitive load. This may sound odd when comparing a rather bare-bones vi + tools setup with a bells-and-whistles IDE like Visual/Android/whatever Studio but it just ends up working that way for me. I already need to keep enough state in my head for the project I'm…

Agreed, I like (trying) to understand as much as I can about how my environment works so if/when something breaks I only need to learn the last 30% in a crisis, and I'm already familiar with the core. It doesn't always work, sometimes there is just too much.

It's usually useful, at least in some abstract way to the team. It felt essential when I worked alone and was accountable for everything.

Re: Benefits of Not Using an IDE

#203

Post by oneplane »

Lio wrote: post #120
oneplane wrote: post #59

None of this matters in the slightest as soon as you have to work with other people on stuff. At that point common tooling is more important than specific personalised tooling. If everyone is using IntelliJ and you're using Atom, it's going to be problematic. Not because of either of those tools, but because you now have a discrepancy that is not relevant to the work you're doing yet it's creating problems for the wo…

I don’t quite get this as an argument for forcing a prescribed IDE on team members. You mention scaffolding tests, things like this can be left to external tools and then it works for all IDEs and all editors. Then you can let people use what they find most ergonomic.

I mentioned that because in 2005 that was a real PITA and the first example that came to me. It's not a 'real' problem in Greenfield problems today. It also isn't really the point, but just an example for people who don't get the point (and apparently not a good one at that).

The point was: if you make it difficult to work together because you have a high horse / hill to die on / unique incompatibility, it makes teamwork unreasonably hard and inefficient, which becomes a problem as soon as time and/or money is involved. The "haha I am so much better because I don't use an IDE" line of thought falls within that category. So does "I run TempleOS so that my code is blessed" and "I don't like git so I use TFS and you can all suck it".

Now, say you have something much easier to not care about tools; i.e. a gitops driven workflow for your terraform code. Then it doesn't really matter what you have locally because until your code is merged it is in no way/shape/form going to create a problem. On the other hand, if you refused to use efficient tooling your performance might be half of what other people might present and that means the people that pay you don't get a good value from your work. Efficient tooling might mean: something that understands the syntax or AST of what you write and points out errors so you don't find out after the fact.

Re: Benefits of Not Using an IDE

#204

Post by city41 »

falcolas wrote: post #103
city41 wrote: post #27

I consider not needing to remember library and api details a benefit. I'd rather dedicate my brain cycles to something else. As for syntax, I don't recall ever struggling to remember syntax of languages I frequently code in. Also the point about IDEs auto generating toHashCode, toString, etc. If your class needs these methods, whether they were auto generated or not seems besides the point. The point the IDE is "comp…

Why do doctors memorize medicines and their effects? Because it's faster to retrieve from memory than from documentation, even automatically presented documentation. It removes a context switch. The "brain cycles" are only run while doing the memorization, not while actually doing the work. > I don't recall ever struggling to remember syntax of languages I frequently code in. Because you've memorized it.

Do they have every single medicine memorized, or just the ones they most commonly use? Sure, I tend to remember the parts of libraries and apis I use often, but I'd still argue my editor having a reminder just a keystroke away is very beneficial.

Re: Benefits of Not Using an IDE

#205

Post by HelloNurse »

adrian_b wrote: post #182
wokwokwok wrote: post #34

Listen, long story short: just say no to nonsense like this. Given the choice of a) tooling, or b) no tooling, you’re not being smart, cool or clever by choosing b. Obviously, what tools you pick are important and heavy IDEs like IntelliJ are a trade off between speed and functionality, and yeah, more nimble tools do exist, and it’s definitely worth trying different development tools to see what makes you most produc…

There is a very large difference between a very smart source code editor (e.g. Visual Studio Code) and a complete IDE. I consider the first essential and the second completely useless. For editing or just navigating the source files, the smarter the editor is, the better. On the other hand I have never seen any IDE where the management of projects (e.g. adding/deleting/moving/renaming files and setting compilation/li…

Regarding especially Eclipse, project and build management in an IDE can be good. Typical Java projects that use Maven and are built "officially" with scripts and CI systems without an IDE can be worked on by Eclipse quite cleanly by

  - Checking sources out of version control
  - "Importing" them in the Eclipse workspace as projects from existing code in an arbitrary location
  - Configuring what Maven installation, and with what configuration files, is to be used to build your projects
  - Defining a grimoire of Maven command lines (build and test locally, build and deploy somewhere else, package for release, etc.) as run/debug configurations
The impact is limited to harmless project metadata files (containing nothing important that isn't mirrored from Maven POM files) and repeating in the closed world of Eclipse options configurations, paths etc. that are probably already in scripts, CI pipeline definitions and so on.

Re: Benefits of Not Using an IDE

#206

Post by Shorel »

Well, I get linters (errors are highlighted even before the file is saved), jump to function definition and a lot more in Sublime Text.

I mean, I don't use an IDE, but at the same time, reading the comments, I don't miss much of what it offers.

Re: Benefits of Not Using an IDE

#207

Post by 9front »

the_third_wave wrote: post #95
Waterluvian wrote: post #52

Earlier quoted context omitted.

“Power drills have batteries or cords and motors that wear down and they’re more expensive and complex and can break more easily and it’s just smarter to bring hand crank tools to the worksite.” - Nobody

Power drills are simple tools, they are the 'vi' equivalent of the 'ed' manual drill. The physical equivalent of an IDE would be a laser-guided auto-centering/levelling drill with automatic drill bit changer/sharpener, depth guide, dust evacuation and material sensor with automatic lookup for which hole size and depth to use for the given task. It would weigh 15 kg, need an external power pack and be unusable in tigh…

The Hole-Hawg drill is the IDE equivalent. Recently discussed on HN: https://news.ycombinator.com/item?id=28015229

Re: Benefits of Not Using an IDE

#208

Post by djhworld »

Ehhh, I dunno.

I've yo-yo'd between minimalist setups and full blown IDEs over the years.

Nowadays I'm happy with IntelliJ for Go development and a little bit of Rust. There's something quite freeing from not having to tinker much with configs and just get on with actual work!

Admittedly I do use the terminal feature in IntelliJ quite extensively so I'm not making full use of the features, but meh.

Re: Benefits of Not Using an IDE

#209

Post by Macha »

mattgreenrocks wrote: post #12

Maybe I’m weird, but at some point I stopped fixating on which tools to use and just settled on a personal workflow: * terminal open at root of project used for source control * one or more tabs for ssh/VMs etc * IDE/VSCode/vim for editing Any of those is fine. And sometimes I switch between them depending on my mood. If I’m out and about it can be nice to conserve battery and focus by going full terminal mode. If I…

> IDE/VSCode/vim for editing

To the point on this one, I sometimes find myself running neovim inside the IntelliJ or VSCode terminal, when I need to edit a config file quickly while running scripts in that terminal, or just to edit a file outside the project directory. Or like you, I primarily use the git CLI, because IDEs often use to me unintuitive mappings of GUI buttons to git actions ("what does Synchronize do for git?"), so then it pops open $EDITOR to write my commit message.

Re: Benefits of Not Using an IDE

#210

Post by Macha »

dntrkv wrote: post #85
nicoburns wrote: post #43

Earlier quoted context omitted.

Depending on which ecosystem you're working with you may be able to get those tools elsewhere. If you're working with client-side JavaScript for example, then you have multiple choices of browsers with excellent debuggers built in.

That’s still not the same as debugging within your IDE. Having to switch from the browser back to your IDE to find the files to make changes is just another context switch that slows you down. Plus, dealing with async loaded files can be a pain in the browser.

I've tried using VSCode's debugger for Javascript before. And it can be kind of nice, but ultimately on larger projects with their own build tools it can be hard to keep the sourcemaps working in such a way as to not screw up VSCode's debugger, and the gain over Firefox's built in debugger wasn't worth the effort for me to continue to maintain that config.
Post reply on HN