7 ms·

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

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 import statements. And you’ll learn that the speed of typing, even long method names, is not the limiting factor of your productivity.

csomar 2y ago
I use Rust, so explicit imports are required. However, I fail to understand this point > 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. With neovim/LSP, I have a key binding (Kg) that opens a small window within the editor with the rustdocs. Not only this is faster than going to the browser, typing the type name, opening the docs, looking up the method but also it ensures that I am looking at the docs of the correct version that my code base is using. I don't really understand the aversion to using these tools. They are "auto-complete" and not generative complete. This means you need to know what you are going to type for them to help you.
- not-my-account 2y ago
  Do you have your neovim config public?
  - csomar 2y ago
    Not really, as I have API keys and other stuff in it unprotected. However, I used this as a base (https://github.com/ayamir/nvimdots https://github.com/ayamir/nvimdots) and heavily modified it. There is a user directory (lookup the user_template) where you can config everything out of the base.
- hirako2000 2y ago
  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.
  - csomar 2y ago
    Which is why I mentioned that I am coding in Rust. They are the same docs.
    - alpinisme 2y ago
      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.
      - csomar 2y ago
        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.
        hamandcheese 2y ago
        I believe the distinction is that if you have to manually browse the docs and navigate to the method of interest, you might see something else interesting along the way. Whereas if your editor takes you directly to the method in question, you miss that opportunity.
        powersnail 2y ago
- deleted 2y ago
  [deleted]
- thwarted 2y ago
  > 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.
  - PittleyDunkin 2y ago
    > it never really occurs to us to use them, just like it never occurs to you to not use them. This doesn't really make sense, either. How do you not consider the right tool for the job? Do you just use whatever you learned to code and never really bothered to consider that you might be more or less productive with different tools? LSPs don't always offer a productivity increase in all contexts—they seem to be mostly useless for dynamic languages like ruby and lisp and javascript—but I have a hard time imagining a programmer that couldn't benefit from them in the right context. And they're just a straight-up improvement from iterative compilation and ctags, the latter of which never really worked very well in the first place.
    - thwarted 2y ago
      My great-grandmother never used a mixer when making cakes or bread, long after mixers were available, and she was able to pump out treats and full meals without batting an eye, the best anyone ever had. I don't have a problem with my "productivity", whatever that means. I'm not trying to write code faster, my own experience is that writing code faster leads to shitter code. I'm not hindered by my tools, and most of my programming time is spent thinking and understanding, and none of these tools have afforded me better thinking or understanding, and often times they get in the way of my thinking.
      - PittleyDunkin 2y ago
        Yes, very zen. How does your pairing partner feel about this?
      - oneeyedpigeon 2y ago
PittleyDunkin 2y ago
Personally, the biggest benefit I get from LSPs is just proactively letting me know compiler errors before running the compiler (and I miss this working in extremely dynamic situations, like macro-heavy lisps). I definitely would side-eye someone who willingly eschewed that. But the rest of your points are well stated from my perspective
- JeremyNT 2y ago
  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.
seanmcdirmid 2y ago
And then you'll turn it back on and feel the lifting of a significant mental burden. Autocomplete has never been about the speed of typing things, and always about finding and recalling abstractions that you sort of know but haven't committed to strong memory yet.
- viraptor 2y ago
  Or for switching between many languages without having to work on remembering if it's lowercase, lower, tolower, lcase, or to_lower this time.
  - deleted 2y ago
    [deleted]
enjo 2y ago
>And you’ll learn that the speed of typing, even long method names, is not the limiting factor of your productivity. This is the fundamental truth that those pushing AI as a replacement for programmers miss (intentionally or not).
- anonzzzies 2y ago
  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.
- motorest 2y ago
  > 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.
  - 2y ago
LAC-Tech 2y ago
Counter argument - I did this for years with neovim in all my side projects, and now I have a fast minimal autocomplete set up I enjoy it a lot more. Turns out I never did memorise the entire API surface of rust, and enjoy the editor suggesting functions.
CrimsonRain 2y ago
None of these need the absence of those features. I do all of these, I also use auto complete, all LSP features and then some. And ofc copilot etc too.
1209412comb 2y ago
It is pretty bad because coworkers use LSP / fuzzysearch and they will not do naming in a way that's more easy for the brain.
zaran 2y ago
Autocomplete is more for discoverability than saving on typed characters, letting you rely less on documentation and more on the actual interface you're interacting with
- devjab 2y ago
  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.
  - MrLeap 2y ago
    Can you elaborate on this? I'm one of C# developers who operate predominately in the Unity3d slums. This isn't familiar to me. The closest thing coming to mind to me is mixing up IEnumerable and IEnumerator when trying to define a coroutine.
    - devjab 2y ago
      IQuerable Inherits IEnumerable and extends it with functionality to lessen the memory loaded when querying a collection (typically when reading from a database). Using IEnumerable can increase memory usage significantly compared to IQuerable. Not every C# developer knows the difference, in my region of the world it’s an infamous mistake and is often the first thing you look for when tasked with improving bottlenecks in C# backends. On the flip-side, using IQuerable isn’t very efficient if what you wanted was to work on in memory collections. There is an equally infamous somewhat related issue in Python with list vs generators. Especially common when non Python developers work with Python.
      - MrLeap 2y ago
        Ah this explains why I'm not familiar with misusing IQueryables. My domain is predominately in memory. Thank you for the explanation.
  - 2y ago
hardwaregeek 2y ago
No but speed of lookup is definitely a limiting factor. And with rust goto definition also goes to the doc comment so I can easily read the docs in my IDE
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 ago
  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!
  - maccard 2y ago
    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)
IshKebab 2y ago
I don't need to turn it off to find out - I've worked in enough untyped languages (Python, Ruby) or badly set up ones (C++) where code intelligence tools don't work to know what it's like, and none of your points are true. 1. I know where the reference docs live already. Auto-complete doesn't obviate that need. 2. Again auto-complete doesn't completely obviate the need to navigate by file name/path (though it does reduce it), so I already know that is valuable. 3. The speed of typing sometimes is a limitation. I'm not a slow typer but sometimes there are situations where you just have to type out something tedious, and you're not doing anything other than typing. Yes even with fancy Vim/multiple cursor editing. Auto-complete speeds that up a little, but Copilot sometimes speeds it up a lot. You should try it. For example for printf debugging, with copilot you can pretty much just type `dbg!` and hit tab. Much faster. You also missed some significant advantages: 1. go-to-definition makes navigation much faster 2. type inlays make understanding the code much faster 3. auto-complete makes looking up method names much faster (is it .starts_with or .has_prefix? .contains, .has, .any, or .some?) The only upside of not using LSP tooling is that sometimes it can bring your computer to it's knees, whereas plain text editing will always be fast. Easily worth it though.
- aguaviva 2y ago
  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.
  - IshKebab 2y ago
    I'm not confusing anything. It's relatively common to call the use of dynamically typed languages without static type hints "untyped". I'm pretty sure you knew what I meant and are just trying the classic "you used this word in a way I don't agree with therefore you're wrong".
    - 2y ago
brabel 2y ago
To think that some people are still writing code like in the 70's. Not using productivity tools is just hurting you. I don't know what sort of misplaced sensation of superiority doing things the hard way may bring to you, but please don't give bad advice like this to young people. If they want to experience writing code without the help of modern tools, they can just use one of the so many languages whose tooling sucks: Nim, D, Odin, Zig come to mind (not criticizing them, but they still have a lot of work to do, and I know that they're all investing on doing it because yeah, everyone wants it). Nearly every single developer who uses those tools complain about tooling if they have used better tooling before (e.g. Rust, Dart, Java, Kotlin, C#). When I have top-notch tools, I can write code that's a lot more advanced than when I don't (and I know that too well because I still insist on using those languages with bad tooling, unfortunately for me as it's a pain sometimes), because everything becomes much, much easier: docs, navigation, inline warnings, auto-suggestions (for languages that you're not too familiar with that's a godsend, love IntelliJ for Java, Clippy for Rust, for example). You actually learn from those things (as opposed to continue learning things that don't matter). Don't be a software ludite.
- aguaviva 2y ago
  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.
  - 2y ago
mrweasel 2y ago
Turning off especially the autocomplete would be a good exercise for many. I've worked with developers who relied on the autocomplete in Visual Studio to the point where they'd wear down the tab key. They'd rarely consult the documentation and do endless type conversions or attempt to construct the objects required for the API that sort of sounded like what they needed. I think meeting developers like this will make you dislike autocomplete. If you know what you're doing though, it is amazingly helpful and can save you many wasted hours on silly syntax errors.
- matwood 2y ago
  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.
jckahn 2y ago
This a fun idea, but honestly… who has the time for that? I’ve got features and bug fixes that need to be delivered quickly. Taking the slow road (especially if intentional) puts a target on my back for dismissal. If keeping my job requires relying on the latest tech and tooling, that that’s what I’m going to do.
vbezhenar 2y ago
Here's my take. One of my hidden superpower that I often see others are missing is navigating library code. Especially in new language. I don't like reading docs. Very rarely docs are good. Usually docs are incomplete or outright wrong. So I never read them unless absolutely required. I just navigate library, skimming through its source code. Whether it's standard library or third-party library. I failed this approach with Scala and it was main reason that I abandoned this language. Its collections were so absurdly overcomplicated, that I decided this language is doomed to collapse under its own weight. Apparently I wasn't very wrong. 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. So it's not absolutely universal approach, but generally it works. And of course it requires "jump to definition" editor feature.
- lelanthran 2y ago
  > 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.

csomar 2y ago

I use Rust, so explicit imports are required. However, I fail to understand this point > 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. With neovim/LSP, I have a key binding (Kg) that opens a small window within the editor with the rustdocs. Not only this is faster than going to the browser, typing the type name, opening the docs, looking up the method but also it ensures that I am looking at the docs of the correct version that my code base is using. I don't really understand the aversion to using these tools. They are "auto-complete" and not generative complete. This means you need to know what you are going to type for them to help you.

not-my-account 2y ago
Do you have your neovim config public?
- csomar 2y ago
  Not really, as I have API keys and other stuff in it unprotected. However, I used this as a base (https://github.com/ayamir/nvimdots https://github.com/ayamir/nvimdots) and heavily modified it. There is a user directory (lookup the user_template) where you can config everything out of the base.
hirako2000 2y ago
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.
- csomar 2y ago
  Which is why I mentioned that I am coding in Rust. They are the same docs.
  - alpinisme 2y ago
    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.
    - csomar 2y ago
      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.
      - hamandcheese 2y ago
        I believe the distinction is that if you have to manually browse the docs and navigate to the method of interest, you might see something else interesting along the way. Whereas if your editor takes you directly to the method in question, you miss that opportunity.
        powersnail 2y ago
deleted 2y ago
[deleted]
thwarted 2y ago
> 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.
- PittleyDunkin 2y ago
  > it never really occurs to us to use them, just like it never occurs to you to not use them. This doesn't really make sense, either. How do you not consider the right tool for the job? Do you just use whatever you learned to code and never really bothered to consider that you might be more or less productive with different tools? LSPs don't always offer a productivity increase in all contexts—they seem to be mostly useless for dynamic languages like ruby and lisp and javascript—but I have a hard time imagining a programmer that couldn't benefit from them in the right context. And they're just a straight-up improvement from iterative compilation and ctags, the latter of which never really worked very well in the first place.
  - thwarted 2y ago
    My great-grandmother never used a mixer when making cakes or bread, long after mixers were available, and she was able to pump out treats and full meals without batting an eye, the best anyone ever had. I don't have a problem with my "productivity", whatever that means. I'm not trying to write code faster, my own experience is that writing code faster leads to shitter code. I'm not hindered by my tools, and most of my programming time is spent thinking and understanding, and none of these tools have afforded me better thinking or understanding, and often times they get in the way of my thinking.
    - PittleyDunkin 2y ago
      Yes, very zen. How does your pairing partner feel about this?
    - oneeyedpigeon 2y ago

PittleyDunkin 2y ago

Personally, the biggest benefit I get from LSPs is just proactively letting me know compiler errors before running the compiler (and I miss this working in extremely dynamic situations, like macro-heavy lisps). I definitely would side-eye someone who willingly eschewed that. But the rest of your points are well stated from my perspective

JeremyNT 2y ago
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.

seanmcdirmid 2y ago

And then you'll turn it back on and feel the lifting of a significant mental burden. Autocomplete has never been about the speed of typing things, and always about finding and recalling abstractions that you sort of know but haven't committed to strong memory yet.

viraptor 2y ago
Or for switching between many languages without having to work on remembering if it's lowercase, lower, tolower, lcase, or to_lower this time.
- deleted 2y ago
  [deleted]

enjo 2y ago

>And you’ll learn that the speed of typing, even long method names, is not the limiting factor of your productivity. This is the fundamental truth that those pushing AI as a replacement for programmers miss (intentionally or not).

anonzzzies 2y ago
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.
motorest 2y ago
> 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.
- 2y ago

LAC-Tech 2y ago

Counter argument - I did this for years with neovim in all my side projects, and now I have a fast minimal autocomplete set up I enjoy it a lot more. Turns out I never did memorise the entire API surface of rust, and enjoy the editor suggesting functions.

CrimsonRain 2y ago

None of these need the absence of those features. I do all of these, I also use auto complete, all LSP features and then some. And ofc copilot etc too.

1209412comb 2y ago

It is pretty bad because coworkers use LSP / fuzzysearch and they will not do naming in a way that's more easy for the brain.

zaran 2y ago

Autocomplete is more for discoverability than saving on typed characters, letting you rely less on documentation and more on the actual interface you're interacting with

devjab 2y ago
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.
- MrLeap 2y ago
  Can you elaborate on this? I'm one of C# developers who operate predominately in the Unity3d slums. This isn't familiar to me. The closest thing coming to mind to me is mixing up IEnumerable and IEnumerator when trying to define a coroutine.
  - devjab 2y ago
    IQuerable Inherits IEnumerable and extends it with functionality to lessen the memory loaded when querying a collection (typically when reading from a database). Using IEnumerable can increase memory usage significantly compared to IQuerable. Not every C# developer knows the difference, in my region of the world it’s an infamous mistake and is often the first thing you look for when tasked with improving bottlenecks in C# backends. On the flip-side, using IQuerable isn’t very efficient if what you wanted was to work on in memory collections. There is an equally infamous somewhat related issue in Python with list vs generators. Especially common when non Python developers work with Python.
    - MrLeap 2y ago
      Ah this explains why I'm not familiar with misusing IQueryables. My domain is predominately in memory. Thank you for the explanation.
- 2y ago

hardwaregeek 2y ago

No but speed of lookup is definitely a limiting factor. And with rust goto definition also goes to the doc comment so I can easily read the docs in my IDE

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 ago
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!
- maccard 2y ago
  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)

IshKebab 2y ago

I don't need to turn it off to find out - I've worked in enough untyped languages (Python, Ruby) or badly set up ones (C++) where code intelligence tools don't work to know what it's like, and none of your points are true. 1. I know where the reference docs live already. Auto-complete doesn't obviate that need. 2. Again auto-complete doesn't completely obviate the need to navigate by file name/path (though it does reduce it), so I already know that is valuable. 3. The speed of typing sometimes is a limitation. I'm not a slow typer but sometimes there are situations where you just have to type out something tedious, and you're not doing anything other than typing. Yes even with fancy Vim/multiple cursor editing. Auto-complete speeds that up a little, but Copilot sometimes speeds it up a lot. You should try it. For example for printf debugging, with copilot you can pretty much just type `dbg!` and hit tab. Much faster. You also missed some significant advantages: 1. go-to-definition makes navigation much faster 2. type inlays make understanding the code much faster 3. auto-complete makes looking up method names much faster (is it .starts_with or .has_prefix? .contains, .has, .any, or .some?) The only upside of not using LSP tooling is that sometimes it can bring your computer to it's knees, whereas plain text editing will always be fast. Easily worth it though.

aguaviva 2y ago
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.
- IshKebab 2y ago
  I'm not confusing anything. It's relatively common to call the use of dynamically typed languages without static type hints "untyped". I'm pretty sure you knew what I meant and are just trying the classic "you used this word in a way I don't agree with therefore you're wrong".
  - 2y ago

brabel 2y ago

To think that some people are still writing code like in the 70's. Not using productivity tools is just hurting you. I don't know what sort of misplaced sensation of superiority doing things the hard way may bring to you, but please don't give bad advice like this to young people. If they want to experience writing code without the help of modern tools, they can just use one of the so many languages whose tooling sucks: Nim, D, Odin, Zig come to mind (not criticizing them, but they still have a lot of work to do, and I know that they're all investing on doing it because yeah, everyone wants it). Nearly every single developer who uses those tools complain about tooling if they have used better tooling before (e.g. Rust, Dart, Java, Kotlin, C#). When I have top-notch tools, I can write code that's a lot more advanced than when I don't (and I know that too well because I still insist on using those languages with bad tooling, unfortunately for me as it's a pain sometimes), because everything becomes much, much easier: docs, navigation, inline warnings, auto-suggestions (for languages that you're not too familiar with that's a godsend, love IntelliJ for Java, Clippy for Rust, for example). You actually learn from those things (as opposed to continue learning things that don't matter). Don't be a software ludite.

aguaviva 2y ago
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.
- 2y ago

mrweasel 2y ago

Turning off especially the autocomplete would be a good exercise for many. I've worked with developers who relied on the autocomplete in Visual Studio to the point where they'd wear down the tab key. They'd rarely consult the documentation and do endless type conversions or attempt to construct the objects required for the API that sort of sounded like what they needed. I think meeting developers like this will make you dislike autocomplete. If you know what you're doing though, it is amazingly helpful and can save you many wasted hours on silly syntax errors.

matwood 2y ago
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.

jckahn 2y ago

This a fun idea, but honestly… who has the time for that? I’ve got features and bug fixes that need to be delivered quickly. Taking the slow road (especially if intentional) puts a target on my back for dismissal. If keeping my job requires relying on the latest tech and tooling, that that’s what I’m going to do.

vbezhenar 2y ago

Here's my take. One of my hidden superpower that I often see others are missing is navigating library code. Especially in new language. I don't like reading docs. Very rarely docs are good. Usually docs are incomplete or outright wrong. So I never read them unless absolutely required. I just navigate library, skimming through its source code. Whether it's standard library or third-party library. I failed this approach with Scala and it was main reason that I abandoned this language. Its collections were so absurdly overcomplicated, that I decided this language is doomed to collapse under its own weight. Apparently I wasn't very wrong. 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. So it's not absolutely universal approach, but generally it works. And of course it requires "jump to definition" editor feature.

lelanthran 2y ago
> 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.