Hacker News Reader

Comment by n4r9 | Hacker News Reader

That's an interesting comparison because it seems to me that there are still a significant fraction of experienced developers using text editors like vi and sublime, without any apparent loss in productivity. Also, I use VS almost all the time but have had to learn how to bypass it when there are errors that aren't flagged up by its particular build process. I wonder if the same will apply in the case of AI assistants - they'll be great for more junior developers who will never need to learn good practises for refactoring, debugging etc... until suddenly they do. Not saying it's a bad thing, just that you may not need to worry too much about "losing out" if you're not on the hype train.

View on HN

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

>I wonder if the same will apply in the case of AI assistants - they'll be great for more junior developers who will never need to learn good

I can't think of a worse idea than giving copilot to a junior dev... I use chatgpt a lot, but I've got lots of experience. One has to understand how the big picture works very well to not find yourself led down the wrong path.

It's worse than that.

Most non-technical business stakeholders don't really understand what we do. You don't see shows about awesome devs doing awesome shit, like you do for lawyers, doctors, business people, etc. All they know about us is that we're nerds who work like two hours a day and can't be bothered to go into the office.

They do, however, understand ChatGPT and how it can be used to create whatever you want (see also: Eric Schmidt's missive to Stanford business undergrads that made the front page here some time back).

Given this, they are EXTREMELY incentivized to give/force upon ChatGPT to juniors. If they can give this to juniors and maintain feature velocity with an acceptable amount of quality degradation, then they can eventually move software development to lower-cost countries with weaker worker protections wholesale (and use good old fashioned protectionism to make sure that those countries don't try to steal our slice of the pie).

Quality issues can be fixed by expert consultants who know their shit, but that market won't be big enough for all of us.

> Most non-technical business stakeholders don't really understand what we do. You don't see shows about awesome devs doing awesome shit, like you do for lawyers, doctors, business people, etc. All they know about us is that we're nerds who work like two hours a day and can't be bothered to go into the office.

You do, but it's even more ridiculous nonsense fantasy than a typical doctor or a lawyer show (e.g. all the hacker girl scenes like https://www.youtube.com/watch?v=hkDD03yeLnU, https://www.youtube.com/watch?v=u8qgehH3kEQ).

Reply on news.ycombinator.com