Comment by pocketarc | Hacker News Reader

Comment by pocketarc | Hacker News Reader

Parent Full thread

> without any apparent loss in productivity

I think there might be a few things to consider here:

1. Is it without any loss in productivity? Or are they so productive/skilled that they can still outpace most other devs even without the IDE's additional functionality?

2. Is there a loss in productivity, and they just don't realize it? Just because they can still do a good enough job without an IDE doesn't necessarily mean that they couldn't do a better job as experienced IDE users.

This is similar to the arguments people make against using Rust. "I can code C just fine and never have any issues, I don't need Rust"

It's also similar to this Copilot discussion. The people who say "I don't see any benefit from LLMs when coding", could it be that they just... don't have enough experience using LLMs? We've -just- had that come up in HN[0], where everybody in the comments was showing how they got the answer just fine out of their LLM of choice, while the OP was all about how AI couldn't possibly understand that bit of code.

[0]: https://news.ycombinator.com/item?id=41712564

My intuitive understanding is that a lot of an IDE's functionality - e.g. running builds, common refactorings, or searching for instances of a class - can be performed at a similar speed by someone who has a toolset of commands and shortkeys at the tips of their fingers. And if you do grok those commands, you can probably do even more flexible things than your IDE will easily allow. I also find that using an IDE means you can easily forget about how e.g. config files factor into the build process, which can make it harder to on the fly diagnose certain kinds of issues that depend on configuration.

But I guess you're right that we can't trust word of mouth and don't know for sure until/unless we have an agreed measure of productivity and can run with/without or before/after type experiments.

What's productivity?

Give competent developers - i.e. people trained to solve optimization problems in their sleep - a metric to optimize for. Call it "productivity". See what happens.

For sure, productivity is easy to define loosely but extremely difficult to measure exactly. Thinking for two weeks and then making a one-line change might be more profitable than churning out any amount of high quality code.

Yes, Vim and Emacs have been "IDEs" in all but name for decades. They just do things in a slightly different way which is arguably less "integrated" and more "modular", but feature-wise it's pretty much identical, and has been for a long time.

> I also find that using an IDE means you can easily forget about how e.g. config files factor into the build process, which can make it harder to on the fly diagnose certain kinds of issues that depend on configuration.

This is a fact that needs more attention, and it's why I prefer to onboard people with setup documents they work through rather than a canned working development setup, even though the former takes "longer" to get people up and running. The long term benefits in forcing people to touch and familiarize themselves with as much as possible far outweigh any short-term time gain.

Reply on news.ycombinator.com