Comment by jasonpeacock

>If you work without it, I would similarly suggest turning it in for a month.

In the past when I've tried to use IDEs, I've often given up within minutes because they would keep doing things that disrupt my flow - like popping up an entire menu of autocomplete suggestions in a way that obscures other code I'm trying to read, or autotyping a close bracket that I would have typed anyway by muscle memory, or not making it clear how to move the cursor past something it auto-typed, or interrupting me with warnings that something won't compile when I haven't finished typing it....

Exactly this. The last of my projects recently moved off of RHEL7, and I am ecstatic that I have a new enough version of vim to use LSP everywhere. I know how to navigate code and documentation manually. I know how to cobble together a poor man's version with ctags and scripts. And it is all a huge waste of time. I'm using an editor that is famed for letting you do everything with the keyboard more efficiently than you could with a mouse. That encourages you to navigate using hjkl for the slight speed improvement over moving your hand to the arrow keys. That has all sorts of ways to perform bulk editing actions faster than manually, and lets you write macros when that isn't fast enough. And yet having keyboard shortcuts that speed up code navigation that I am doing constantly is somehow a bad thing that I should eschew to build character? Forget that!

I upvoted both you and GP.

There are times when the "programming" job is best done with vim or even just a notebook in a quiet place.

Other times, an LLM or IDE can help get a new project going faster. Especially if you are unfamiliar with the language or framework. But in the latter case, do review the output until you understand it. So far even the best LLM will make subtle bugs, but unless its in a language you know well, you might have a hard time spotting them!

untyped languages (Python, Ruby)

Both of those languages are strongly typed.

It seems you're confusing the fact that the type checking happens at runtime (that is to say, that they are dynamically typed) to mean that they're "untyped", but that's just not the case.

If one is confused about the languages one is using at this level, then modern tooling features aren't likely to help much.

> I don't really understand the aversion to using these tools

No one is yucking your yum, it's not an aversion, it's that we don't need them, it never really occurs to us to use them, just like it never occurs to you to not use them. You make it sound like people who don't use them are fumbling and tripping over themselves and aren't actually writing any software.

If you browse through the doc, you will find yourself reading the doc.

If your code editor looks up the doc, you find yourself reading what the code editor shows you.

Wikipedia, (real) historians have some aversion to using it. No argument, it is convenient.

Do you have your neovim config public?

Or for switching between many languages without having to work on remembering if it's lowercase, lower, tolower, lcase, or to_lower this time.

Yeah I use LSPs in vim and this is where I've landed.

Really great for quickly showing you errors and providing passive feedback. I also autocorrect linter errors on save.

But everything else about how I do work is basically unchanged; I haven't found autocomplete to be worth it.

What does replacing programmers have to do with typing speed? You mean the stuff copilot does was never the limiting factor of productivity? I agree, but copilot is not replacing programmers; replacing programmers is more than typing and proponents know that. It might get there.

I still don't understand how it would hurt if you can focus on the parts that do influence your productivity and have the rest appear automatically. But that's just me.

> This is the fundamental truth that those pushing AI as a replacement for programmers miss (intentionally or not).

I think this blend of comment shows a good dose of ignorance discussing the role of AI as a replacement for programmers.

It's not like PMs are suddenly seeing engineers vanish from software projects. It's that AI makes developers so much more productive that you only need a subset of them to meet your work requirements.

To give you an example, AI tools can indeed help you write whole modules. Yes, code can be buggy. Yet, the "typing" part is not what developers benefit from AI. Developers can iterate way faster on designs and implementations by prompting LLMs to generate new components based on new rewuirements, which saves you the job of refactoring any code. LLMs can instantly review changes and suggest ways to improve it, which would require either reading up on the topic or asking a fellow engineer on payroll to spend their time doing the same job. LLMs can explain entire codebases to you without asking a single question to veteran engineers in the team. LLMs can even write all your unit tests and rewrite them again and again as you see fit. LLMs can even recommend best practices, explain tradeoffs of approaches, and suggest suitable names for methods/variables based on specific criterias.

This means AI can do a multitude of jobs that previously you needed a whole team to do, and for that you no longer need whole teams to do a job.

That's exactly the problem: You don't know the code. You're relying on autocomplete to tell you what the signature of the function you're looking for is.

I rely less on documentation because I've got it all memorized due to not relying on autocomplete.

I’m curious as how it lets you rely less on documentation. If you don’t know what you’re looking for then how will you know you chose the right thing?

The classic example of getting this wrong is probably C# developers using IEnumerable when they should’ve used IQueryable.

I have a theory that autocomplete actually increases the API surface area. One of the reasons Java has so many classes and such a huge sprawl is because Java got good tooling pretty early compared to other languages.

Also about less context switching. If autocomplete gives me a full method name that I kind of remember, it saves me a trip to the browser and coming back, which saves a lot of time and avoid a family of errors when they add up.

But imho it does a disservice to new developers because they rely more on the exploratory aspect. At least that's how I remember it from doing C# in Visual Studio many years ago. You have a general idea of what you want, you type object dot and scroll the auto-complete list to find the method you think you need. And even if you can make it work after fiddling with it for ten, fifteen minutes, you can't be sure that's the best way to do it. And then you never want to go read the docs and learn the mental model and the patterns behind the library or framework. I believe it will only get worse with AI-generated completions.

> Another failure with this approach is C/C++. For reasons that I kind of understand but don't approve, its standard library either hidden (so I can't just navigate to malloc implementation) or obfuscated with endless underscores (header template libraries), which makes it unreadable.

That's a complaint with C++, not with C.

You can very easily do development in C without much of what you rely on when using Java, C#, C++, etc.

The one thing, in C, that I do lean on a lot is compilation errors I get shown while developing: C is simple enough that a build of the current project's changed files takes 20ms or so. In practice, it builds faster than I can type.

We have so many levels of autocomplete now. When I was in school intellisense was just becoming a thing, and it made me so much more productive. Being able to quickly scroll through method names and then jump to the docs was a huge time saver. Another big time saver is when they added the ability to highlight a function and read the doc inline/popup. Now I never leave the code window which is great for keeping focus.

> To think that some people are still writing code like in the 70's.

I'm one of those, sort of. I did install vscode used autocomplete, find definition and on the fly compilation for a while. In the end I turned it all off bar the syntax checking.

Even my i7 32GB laptop it just got in the way, my typing lagging by many seconds while it recompiled and pondered autocomplete. I left syntax checking on only because while it still fell behind in revealing typos, sometimes by minutes, but at least it kept responding to my keystrokes.

I eventually gave up and went back to vim. It's a sad state of affairs when I can find a definition faster with 40 year old tools than a modern IDE can do it. I respect your decision to use modern tools of course, but I'm not sure I'm the luddite here. An Integrated Development Environment that runs slower than I can think is not an improvement in my books.

As for languages and online docs, one of my first steps in learning any new language is to memorise it's standard library. I don't use other libraries unless the bring something very substantial to the table, in such case I memorise them too. Not having to wait for a IDE to suggest autocompletes means the code flows off my fingers, but also means if the IDE starts lagging my typing I get really pissed off.

All that said, I recently tried using IDE + AI + integrated RAG, and was blown away. It's code suggestions are still so bad it's not worth taking the time to evaluate them, but omg as super grep it's amazing. Yes, it might take 15 to 30 seconds to evaluate my "can you find the code that does X" plain English request and provide links to the key functions, but it would take me hours to read through tens of thousands of lines code I haven't seen before to get the same result. Finally, after 40 years, we may have seen the first step change in programmer tooling since the move from line editors.

You seem to be being downvoted but you are correct. I find it hilarious how so many programmers hate using very useful and productive tools. It would be like a engineer refusing to use 3D CAD software.

To think that some people are still writing code like in the 70s.

This is a muddled hyperbolization. These features barely existed (in terms of widespread use) even 10 years ago, but everyone got along just fine, even founded FAANG-scale companies without them, and so on. Yet you're making it sound like if you aren't using them, then you're basically still writing COBOL.

Not using productivity tools is just hurting you.

The commenter very clearly isn't saying you shouldn't use them. And their point had nothing to do with any "sensation of superiority".

They simply meant that -- yes, it is possible to not only be productive, but highly productive without these tools -- and that if you just tried to get along with them for a while, you just might learn a thing or two. For example, if one is even the slightest bit hesitant as to how one would go about resolving one of the issues that the OP asked about, without the help of modern tooling features:

   What do you do if you need to look up the definition/implementation of some function which is in some other file?

Then one definitely has some important learning to do.