3 ms·
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 mo
by maccard 2y 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.
- jessekv 2y agoI 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!
- maccard 2y agoAn 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)
- zahlman 2y ago>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....
- d3nj4l 2y agoOkay, now stick with it for a month.
- bitmasher9 2y agoI’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.
- troupo 2y ago> 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
- zahlman 2y agoI 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.
- throwaway346434 2y agoArguably, they did turn it off: the whole IDE, at once.
- pavon 2y agoExactly 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!