Comment by maccard

1 year ago

I agree on turning it off to find out. I disagree with almost all of your takes though. If you work without it, I would similarly suggest turning it in for a month.

> You’ll learn where all the reference docs live for your language, libraries, and frameworks, and along the way you’ll learn more by actually reading the docs.

I know where they are. I use them every day. But reaching for them to check every argument if every function I use is a waste of time. It als only works for stuff that has a full suite of documentation. If you’re using an internal library you’re very likely searching the code anyway.

> good project organisation, file naming and explicit import statements.

Good file naming is a crutch for a lack of tooling to explore and modify at a project level. Good project organisation doesn’t require you to disable tooling with semantic knowledge of your project. And explicit imports are a (necessary) distraction m.

> And you’ll learn that the speed of typing, even long method names, is not the limiting factor of your productivity.

It has nothing to do with the speed of typing and it never has. It has everything to do with working at the abstraction level I want to work at - my codebase. It’s using the tooling that means I think about “I have an X and I need it to do Y. “ rather than “let’s go context switch to the browser to figure out if it’s len, count, size, chars”

A good corollary is a linter - it’s incredibly important to the project, knowing and understanding the rules and why they exist is very helpful and would benefit everyone on the team. But a computer can do it for us, and let us focus on writing the code rather than ensuring we have tabs instead of spaces.

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

  • This is also exactly my take. I've been coding over 40 years, long before autocomplete was really a thing, and that's probably the main reason I find autocomplete and all the stuff that pops up in modern IDEs to be annoying for all the reasons you described.

    Autocomplete and all the other bells-and-whistles just get in my way, most of the time. It's literally the first thing I disable for myself when I install a new developer machine. The few times I set up a new machine and don't disable it, I am reminded why I want to disable it very quickly.

  • Autoclosing parens, brackets, braces -- one of the most annoying things to me, for example in tools like JupyterLab, but also in IDEs.

    • My editor inserts them and “smartly” overwrites them. If you type it yourself it will ignore it and move the cursor. You can hit delete and it will remove the added parenthesis, or you can keep typing and it will leave it there for you.

      It’s been configurable as an option to have those in every editor I’ve used for about 15 years

    • Yeah that's something I disable in every tool I touch. Especially when I'm typing something like foo(), by the time any autocomplete inserts that closing parenthesis, I will have already typed it, and now I'm distracted.

      I don't mind suggestions if they are unobtrusive, but anything that interrupts my typing is an immediate no-no.

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

    All the things that can be turned off/tuned. Strange that you don't spend the time learning the tool you admonish others for using

    • I don't in any way "admonish others for using" IDEs and I have no idea where that accusation came from.

      And no, of course I'm not going to spend time learning an IDE that someone else recommended to me. I spend my tool-learning time on tools that I selected because I expected them a priori to be useful for me.

  • Okay, now stick with it for a month.

    • I’ve been coding for 2 decades. Autotyping anything is something I always find incredibly disruptive, regardless of how long I spend with tools that do this.

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!

  • An LLM is like having an over eager junior dev with an eidetic memory who hasn’t slept in a week. It’s a superpower (minus the human rights issue) most of the time unless you’re not keeping an eye on it.

    I’ve replaced so many tiny manual processes with python and batch scripts, and rewritten them in go when speed became an issue because of Claude and ChatGPT. I know enough to spot the glaring issue. I’m never going to sit down and write a batch file that installs my toolchain as it’s not done enough to warrant my time. But Claude will, and now our build machines use the same scripts and it means everyone is in the same environment (c++ on windows so our options are limited here)