> Not only do I avoid using LSP features, but I’m also opposed to their use. While they can help with navigation, they may prevent developers from experiencing and addressing the underlying structural issues in their code.
LSP by itself will not prevent anything. LSP (using the terminology from OP, but any IDE really) is just a tool like any other which allows you to do things faster. It doesn't matter how organized your code base is, it will never be as fast to find some definition as hitting a keyboard shortcut (please don't use Ctrl+Click, my gosh... learn the keyboard shortcut for things you do often like this). I want to see docs for a function without moving my eyes from the code I am currently writing. I want to be able to jump back and forth between definitions without interrupting my chain of thought, see function definitions inline instead of having to jump to the file it's defined on.
When you have to manually search for files and then Ctrl+F to find functions, lookup docs in a web browser (which I hear is how people who don't use IDEs still do that), or manually run a linter/compiler to see warnings in your code, you're just being really inefficient. I can't understand that at all. Why don't you use automation to help your job when the whole point of your job is automation?
Keeping the code organized is still good advice, but has nothing to do with using an IDE.
Of course that are good things and maybe I wrote in a too much harsh way.
Linting features and autocompletes are nice, also autocomplete features are nice to have.
The issue that I pointed mostly resonates with the idea that depending on LSP is the big issue.
I personally use Neovim with minimal stuff, I run lint and tests manually and not automatically, because it feels to me like push notifications taking my attention elsewhere, so I go to fix them later after what my intention is already expressed in code.
But agree and dyisagree that "Keeping the code organized is still good advice, but has nothing to do with using an IDE.". It should not be based on IDE, but an IDE on the hands of an inexperienced dev may lead to some comfort that should not be there.
I reviewed many code written by junior people, and very often I see people adding code in random places that later may let the application to be hard to follow and everything "seems fine" to them.
Other smell is like, but "it is so easy to rename a variables with my IDE" even though I believe that refactoring is nice to be done, but if we keep changing names so often, why don't we read the code that is being edited to understand well its intention and maybe realized that a big chunk of code should be split and the name choice will be completely distinct once proper refactor is made.
My point is not about avoid automation, is about having a dependency on that because the code is not manageable to people anymore, but manageable by automation mostly.
> I reviewed many code written by junior people, and very often I see people adding code in random places that later may let the application to be hard to follow and everything "seems fine" to them.
As someone who got their start in edit/Notepad, it wasn't "productivity boosts" that made me bad at code architecture when I was inexperienced.
This reads a lot like the old assembly language programmers (I was one) who stuck their nose up at C programmers for not knowing how computers worked because it was too high level.
The entire purpose of computers is to automate things and reduce complexity
It’s the same in every supported language since it is autogenerated from service definition files. I chose the Python version because it is all on one page. Would you rather memorize thousands of functions across hundreds of classes? Should AWS “reduce complexity” by getting rid of services and functionality?
Would you rather have an auto complete IDE or have to look up the web reference?
I’m sure it’s more complex to run S3 at scale than to build out the data center I did as part of my job to store 4TB worth of data in the early 2000s.
I would much rather run a 4 line CloudFormation template and do it in less than a second over it taking months to do it in house.
I started my programming in assembly in the 80s, should we go back to that too or should we keep using compilers and interpreters?
Should we keep programming in C or should we use manages runtimes with garbage collection?
yes to all of that. In other words, we need both. We need the low-level stuff to do things nobody has ever done before, and the high-level stuff for the things we do every day.
The parent commenter would say that we shouldn’t use an IDE to navigate through the massive code base to make sure records submitted from the railroad yards were in compliance. What alternative would you suggest?
Intellisense for Visual Studio has been out since the mid 90a
I remember when it came out. It changed my life. Libraries without docs were suddenly discoverable. I didn’t have to memorize things, I just had to remember the gist of things. It let me focus on the important stuff. Still, today, before picking up a library, I will read over the whole thing so I know what is possible; but I don’t need to memorize it.
> I reviewed many code written by junior people, and very often I see people adding code in random places that later may let the application to be hard to follow and everything "seems fine" to them.
But is that because they're following their IDE, or is it because they're junior developers? I also see that sort of issue regularly, and as someone who is very happy with their LSP creature comforts, it's still something that I have to call out and teach.
I think you're reversing cause and effect a bit here, in the sense that you're trying to argue that IDEs cause developers to be less thorough and diligent, and to care less about good code organisation. In practice I suspect it's the other way around: the people who are more likely to be diligent and get their code organisation right are the same people who would take more care in choosing exactly which tools work best for them. That is to say, it's not that IDE users are worse at code organisation, it's that the people who are worse at code organisation tend to use IDEs.
I think the idea is that very powerful IDEs and other tools make it very easy to manage complex and disorganized codebases, the downside could be that nobody would care about cleaning up that codebase. At the same time powerful IDEs make it somewhat easier to clean up messy codebases so living in a mess is a choice.
When you have to manually search for files and then Ctrl+F to find functions, lookup docs in a web browser (which I hear is how people who don't use IDEs still do that), or manually run a linter/compiler to see warnings in your code, you're just being really inefficient.
It's inefficient the first time but you quickly build a working memory and a deeper mental model of the code, which becomes even more useful in the future.
Why don't you use automation to help your job when the whole point of your job is automation?
That sort of thinking will get your job automated out of existence.
Why spend your life doing something a computer could do for you?
The goal of programming is not to write code (however much I enjoy that part), it is to solve problems.
I don't think copilot et al is anywhere close yet though. They are occasionally useful when working with popular APIs you use very rarely, or when you need to write some very repetitive code. Other than that, I feel like it's mostly a monkey typing plausible but incorrect code on my screen everywhere I go.
Why spend your life doing something a computer could do for you?
Why spend your life doing _anything_ a computer could do for you? Why even live, if you're going in that philosophical direction?
I don't think copilot et al is anywhere close yet though.
Unfortunately, many of those in management already think it is.
The less people use their brains, the more easily they will be replaced, and the worse the product they'll produce. Unless you want to lose your job and let society drown in mediocre software (which you will no doubt need to use), do not hand over your agency to the machine.
I switch back and forth between using autocomplete/LSP in an IDE and plain-jane vim. Autocomplete isn't the end-all-be-all of productivity you're making it out to be.
I've only found it truly useful in a codebase, language, or library I'm unfamiliar with or haven't touched in a long time.
It doesn't do much for me most of the time as I'm usually thinking or walking around the code, but the codebases I'm in usually are extremely easy to jump around in with fzf.
Properly naming functions/classes/modules goes a long way.
Writing the code doesn't generally take a great deal of time once I know what code needs to be written, so there's little value to be gained in optimizing that part of the process. I can think while I type, after all.
We are not paid to “code” we are paid to use our knowledge of the technology ecosystem to add business value - either save the company money or to make the company money.
Back in the 2000s for me part of that job was to lead the buildout of a data center with a SAN that took up a whole room to hold 4TBs. Now I do that with 5 lines of yaml in a CloudFormation template.
My job was not “automated out of existence” by not having to provision a data center as part of it.
Is it inefficient? Possibly. But I would argue trying to get me to use an IDE and all of the other new fancy tools is more inefficient. My flow works for me, I can navigate through projects and find exactly what I'm looking for pretty quickly, to the point where people who watch me do it comment on how it just looks like a blaze of text to them. And I've found that trying to use IDEs and other tools doesn't make me more efficient, it just slows me down.
I want to be clear, I don't think my workflow is the best, most good, better than everyone else's. But it is mine, and it's the one I'm very proficient and productive with. Vim, tmux, and an assortment of command line tools isn't the right workflow for everybody, but I would argue I'm as, if not more, productive than most people I know using that latest fancy IDE tools.
> Why don't you use automation to help your job when the whole point of your job is automation?
Because I don't see that as automation, I see it as things getting in my way. My brain is set in its ways, and when I try to use tab completion or other nice editing things that people like I feel so slow, I feel like the computer is putting blockers in my way, because I know exactly the line I want to write, and popups and tab-complete break that flow for me.
All power to everyone who can handle that and prefer it, but it's not for me.
> And I've found that trying to use IDEs and other tools doesn't make me more efficient, it just slows me down.
I am sorry to insist on this, but you're clearly mistaken: it's literally impossible for your grep workflow to be faster than hitting `Cmd+b` (IntelliJ MacOS shortcut to go to definition if you're on a symbol, or to see usages if you're on a definition).
> when I try to use tab completion
You don't use tab-completion even on the terminal?
> and popups and tab-complete break that flow for me.
It's very easy to turn off popups and make auto-complete only show up when you explicitly request it. In fact, that's the first thing I do on my IDEs. I highly recommend spending some time changing the IDE settings so that you're happy with how much "automatic" stuff it does. The amount of help an IDE gives is just immeasurable. I do sometimes have to write code without one and it feels like walking on glass. Even running a particular test, for example, is difficult, while in the IDE you just, again, hit a shortcut while your cursor is on the test. I know approximately how to do that from the terminal, but ffs that's useless knowledge to have when I just don't have to write code without an IDE at all, and using the terminal would take minutes (even if you're super fluent in it, as you're forced to come up with a regex for the particular test you want to run or just type the entire name, without assistance) rather than a fraction of a second, while distracting me from what I was even trying to do. This is one example, I could give hundreds more.
When I'm coding, most of my time is spent thinking about the right structure, organization, or solution. Or, debugging something that isn't acting as expected (which, again, is mostly thinking).
I spend comparably little time actually writing the code.
If there is an IDE available that works well out of the box, I'll certainly use whatever automation is available. But often it is broken, incomplete, slow, inaccurate, etc. and rather than spend countless hours fine-tuning some automation / LSP workflow that is going to break when I move to a different project anyway, I just deal with whatever features are missing.
This also has the advantage that I can quickly move to other tools, other languages, other computers, other companies, etc. without requiring days of setup and re-accommodation.
I do have a pretty good memory, which is probably a large part of why this is effective for me.
>> If there is an IDE available that works well out of the box, I'll certainly use whatever automation is available. But often it is broken, incomplete, slow, inaccurate, etc. ...
I think you are unduly harsh here. As a longtime emacs user and who switched to IDE recently (ones that come from JetBrains) my experience hasn't been what you mention. Yes there is a bit of time (not huge) to get adjusted to the shortcuts and efficiently navigate the code, but post that the IDE ecosystem is not as broken as you allude to.
If I'm working on a small hobby project by myself, or some open-source stuff, sure! I agree the Jetbrains stuff is great, I've been using them since 2001 with IntelliJ IDEA.
But most of the large industrial codebases I've worked on at FAANG companies break IDEs one way or another - either because of the build process, or the size of the codebase, etc.
I find the more plugins I add to vscode to do all of the automation, keypresses become more and more sluggish. It seems like it wouldn’t be noticeable — we’re talking about milliseconds.
But I find there to be a world of difference between every keypress being processed as I touch the key versus slightly after it.
With enough experience on a given language you just of internalize a lot of the common linter rules.
I use ctrl-space to activate autocomplete when I need it, but I find when it pops up automatically to be maddening.
I’ve been using AI autocomplete more and more, though it’s a real mixed bag between seeming magical and guessing the completely wrong thing.
> vscode to do all of the automation, keypresses become more and more sluggish
The problem is VS Code then. Try IntelliJ, they spent ridiculous amounts of engineering to make typing as fast as Vim.
> I find when it pops up automatically to be maddening.
Me too, the first thing I do in my IDE is disable that. I love autocompletion, but I want it only when I need it. Now, that's completely different from just saying I don't need autocompletion at all.
> though it’s a real mixed bag between seeming magical and guessing the completely wrong thing.
Agree completely. Sometimes I am totally amazed at how it knew exactly what I wanted to write. But sometimes it misses the mark for sure. This tech is just going to get better though, so I like being able to use it while it improves and notice the difference with every new model.
I'm not sure I understand what you're saying there, but in a discussion about being maximally productive, old laptops with 8GB of RAM just don't come into the equation.
> It seems like it wouldn’t be noticeable — we’re talking about milliseconds.
Yeah, I've used xterm for so long I found it a pain a few years ago when I had to use gnome-terminal, because keypresses have enough latency to be noticeable. I never expected that from a terminal.
> it will never be as fast to find some definition
The fastest definition is the one you never need to look up.
In the absence of "coding aids" like function lookup, people (are forced to) write code that is inherently better-organized and easier to conceptualize.
> When you have to manually search for files and then Ctrl+F to find functions, lookup docs in a web browser (which I hear is how people who don't use IDEs still do that), or manually run a linter/compiler to see warnings in your code, you're just being really inefficient. I can't understand that at all. Why don't you use automation to help your job when the whole point of your job is automation?
To each his own. I use the tools depending on the project. Meaning: most greenfield stuff (even at work) and my personal projects, I can handle with just Vim, a handful terminal tabs---where I grep, run linters (which send out OS notifications), and compile---and a web browser. The main dayjob codebase with all its 10+ years of legacy I wouldn't even dare look at without an IDE.
That said, I find the UX of IntelliSense + autocomplete to be extremely distracting (and don't get me started about Copilot). It's just a necessary evil because, distracted as I am with them, I am simply less productive in the dayjob codebase without it.
Hence, really, your Kung Fu is no better than mine, nor vice versa.
Automation is not the point of programming. Think hard about this. It's the most important point. Code/build/hack to create more work for people to do, not less. It's thanatos. People need to unlearn "programming==automation" before it's too late. Everything we do as programmers should be done with "create more work" as a mantra.
I see where you're going but for me "create more work" doesn't quite capture it. In my mind there's a pretty clear distinction between computer work and human work. Computers are good at fast, precise calculations and following complex procedures repetitively without variation. Humans are good at lateral thinking, constructing narrative and drawing non-obvious connections.
Coincidentally, humans are generally really bad at the things that computers are good at and vice versa.
I think our job is to build systems where the computers are doing the computer work, which frees up the humans' brains and time to do the human work.
So not creating more work per se, maybe creating the opportunity to do better work?
Sure, increasing the quantity or quality of human output works. My point is that overfishing is a concept that might be applied to programming and other human endeavor if those doing the fishing could only think a bit more and coordinate, and leave a few fish in the sea for next year. We soon learn labor's lumpier than we prevuously thought.
I think I prefer to focus on humans vs a productivity metric. Consider overfishing. Easy to imagine overfishing being driven by a desire to max short term productivity. One has to think beyond the bounds of quarterly or annual metrics, at that point it isn't clear what the abstract construct of productivity buys you. Slavery increases productivity. I don't want that. I want humans to have freedom and meaningful work and well functioning healthy societies. Are those things "productivity"?
LSP optimizes writing the code. Yet debugging, reviewing and reading other people code take significantly more time than writing. If code is organized badly and go-to-definition or even moving the mouse to trigger the tooltip is required when doing those tasks, it makes the whole experiences worse.
I would actually phrase that as “LSP optimizes for understanding” (which is of course important for writing code).
For example, when doing code reviews I routinely pull the branch down and look at the diff in context of the rest of the code: “this function changed, who calls it?”, “what other tests are in this file?”, etc. An IDE/LSP is a powerful tool for understanding what is happening in a codebase regardless of author.
"just a tool" is always the excuse for allowing a crutch to make you weak and directionless.
If it's really "just a tool", why so defensive?
Sorry. I know I'm a dick. But come on man, don't pretend the effects of crutches doesn't exist. It's silly to try to deny something so obviously observable all day every day, in all possible contexts not just coding.
Are Soldiworks, Fusion360, etc crutches that have made engineers "weak and directionless" or are they utterly indispensable tools that have drastically increase their capabilities and productivity and enabled them to create things they otherwise could not?
LSP by itself will not prevent anything. LSP (using the terminology from OP, but any IDE really) is just a tool like any other which allows you to do things faster. It doesn't matter how organized your code base is, it will never be as fast to find some definition as hitting a keyboard shortcut (please don't use Ctrl+Click, my gosh... learn the keyboard shortcut for things you do often like this). I want to see docs for a function without moving my eyes from the code I am currently writing. I want to be able to jump back and forth between definitions without interrupting my chain of thought, see function definitions inline instead of having to jump to the file it's defined on.
When you have to manually search for files and then Ctrl+F to find functions, lookup docs in a web browser (which I hear is how people who don't use IDEs still do that), or manually run a linter/compiler to see warnings in your code, you're just being really inefficient. I can't understand that at all. Why don't you use automation to help your job when the whole point of your job is automation?
Keeping the code organized is still good advice, but has nothing to do with using an IDE.