3 ms·

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 pe

by n4r9 2y ago

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.

nottorp 2y ago
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.
- n4r9 2y ago
  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.
arp242 2y ago
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.
tivert 2y ago
> 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.

by n4r9 2y ago

nottorp 2y ago

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.

n4r9 2y ago
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.

arp242 2y ago

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.

tivert 2y ago

> 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.