61–70 of 652 posts
Yes, I try to learn the language well enough that I know the parameters of common functions. If I don't, I consult the docs. If I need to find the definition of a function in another file, I use grep.
You should try turning off those features yourself for at least a month and see what happens ;) You’ll learn the answers yourself, much better than us trying to explain them. 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. You’ll learn the value of good project organization and file naming, and explicit impo…
This is the fundamental truth that those pushing AI as a replacement for programmers miss (intentionally or not).
I learned and worked for decades before these tools were available. If they still weren’t available today, you would find that you too could program without them.
I turn off autocomplete everywhere I can. Whether web searches, composing code, or anything else, I do not want the computer anticipating what I am about to type. I find it is often wrong, and always distracting. Yes, I try to learn the language well enough that I know the parameters of common functions. If I don't, I consult the docs. If I need to find the definition of a function in another file, I use grep.
>So to the devs who don't use these tools, how do you do it? Do you just remember every type and field in a codebase? What does your flow look like?
You don't have to remember every field and type, because you don't work with all the types at the same time. Ones that you work with more often, you remember.
Workflow is something like this: open the file, split to left and right to see two stack frames of the same code path, open another terminal tab, start test watcher. Make changes and see tests fail. If tests don't fail -- write more tests. Then write more code. The usual TDD struggle. In case of CSS, just change it in the browser, then copy back to editor and refactor a but, then check again.
When in doubt about spelling, press shift 8.
>What do you do if you need to look up the definition/implementation of some function which is in some other file?
:open another file and search through it, quote simple. How do I know which file to open? I know and when I don't git grep goes brrr. In theory you can jump to definition even in vim, use fzf to open files faster, in practice, none of that is not the limiting factor.
The limiting factor is iteration cost and the size of your context window.
That all being said, I use vs code now (at work) and use jump to definition all the time, because typescript support is just better in vs code. I think I started using it the moment I had to open more than one repo and switching between them on a regular basis.
Then I get back to my own fun stuff and there I use vim.
Give it a few weeks (or even a few months, I don't know). You quickly learn the "rhythm" of codebases -- and then eventually you've seen it all to the finest details.
Then it's "ezmode." And it's not just for one codebase, you become better and better at realizing the way a code base is architected (code base being anything from an actual application, to an SDK, etc).
There are still a lot of developers out there that basically are at the hammer and nails level of programming. They use a basic editor with basic syntax colouring and when they write broken grammar, the editor just misbehaves telling them they've typoed something. Many still use rg and fd or fzf outside or within their editor and are anti IDE. I think ultimately they do waste time, particularly they see refactoring a…
There is a trick -- never renaming anything. If the name is minted, that's it. It's canon.
Earlier quoted context omitted.
I think the point they are making is that you only read what is shown you instead of seeing the full docs and being encouraged to follow rabbit holes and browse nearby info. Speaking for myself, this has been one of the largest boosters in my own career: visits to a docs page that led to me basically reading the whole docs.
I am not sure if we are speaking about the same thing. LSP can give you type hints. What I am doing is that I am opening a "window" in my editor that has the full docs. You can browse through it freely. The issue with "non-Rust" languages is that the docs will be on a website. On most Rust projects (90%+), the libraries will use the Docs system which makes the docs fully available on LSP.
Whereas if your editor takes you directly to the method in question, you miss that opportunity.
You should try turning off those features yourself for at least a month and see what happens ;) You’ll learn the answers yourself, much better than us trying to explain them. 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. You’ll learn the value of good project organization and file naming, and explicit impo…