371–380 of 652 posts
There are a non-negligible number of my coworkers who don’t use the licensed LSP implementation and they write all their code in vim – or worse, gvim through a VNC. It’s very easy to tell that their code quality is worse.
Earlier quoted context omitted.
I don't use autocomplete, either. Most of what an LSP gives you is more data to scan semantics faster. > every line of code is a liability. every line of code needs to be thought about. every line of code is precious. I personally think this is ridiculous. It's code. It's just formal instructions. You process them and move on. It's not describing the face of god. If you need to think so much write less clever code.
Code is read more often than written. It's not make the computer do something and done. The right kind of clever results in "oh, it can be that simple?", not "what the hell is that line noise?"
The shell is my development environment. I open up new terminals and shells willy nilly. I find cli tools like find/fd/grep/rg are useful because I rarely need to find only the definition of a function, but rather other call sites too, to find out how it is being used. I think being surrounded by the code and being able to slice and dice it leads to a certain kind of familiarity that a tool that takes you right there…
Personally, my recent work has been: short term freelance work, new code bases, a variety of programming languages including ones I haven't previously used, problem identification and solving, and mature code bases where you'd only write a couple lines of code a day.
In that context an IDE optimizes a tiny part of the work, while getting in the way for everything else.
I'll add that when I worked on a greenfield Java project as part of a large team, I absolutely used an IDE (IntelliJ at the time) and couldn't imagine working differently.
is this the most efficient way to code? probably not. but it involves zero yakshaving, which I no longer have the patience for.
I liken this to asking people who don’t use a GPS how they drive and if they have every intersection memorized. It’s not about absolute knowledge of a codebase, but intimate familiarity. I also don’t think it’s a coincidence most people in the comments seem to be using some flavor of vim. I think using an editor designed before these tools were available will make it much easier than afterwards. I’m not sure I’m the…
I find people who drive with sat nav often don't learn almost anything about their route (they don't have to! is the whole point!)
I at least orient my navigation north side up so I have a basic clue what I'm doing.
A friend of mine looks at navigation before driving, then turns it off.
Earlier quoted context omitted.
I've found cursor tends to muck up system internals and such when I use shells in it. There is a lot going on under that hood -- would prefer it work as a VS Code extension so it has some guardrails.
Have you tried the Clive or Continue extensions? AFAIK Continue is somewhat like Cursor. I prefer Clive though, it's become an important part of my workflow - although perhaps even more important is knowing when not to teach for it.
Earlier quoted context omitted.
Code is read more often than written. It's not make the computer do something and done. The right kind of clever results in "oh, it can be that simple?", not "what the hell is that line noise?"
That doesn't mean you stare at it in stupefied awe. If you can't remember what you're working on you close your computer and walk away.
the point i was trying to convey with the phrases was my ideal attitude when writing code.
this code matters. lets think about it, get it done right and not throw it over the fence for the poor schmuck who comes along in two years time after we’ve all left.
i’ve been that schmuck. it was horrible. i don’t want to put other people through that. ever. (this is now my stuff, but hopefully explains some of the attitude).
our attitudes, intentions and motivations count when it comes to code quality. look after your code and it will look after you.
that’s what i feel. you feel different? that’s fine.
This question reminds me of the first time I met a blind programmer. I asked him how he managed to code, and he replied with something that stayed with me: a good programmer should organize software in such a way that every piece of code has a clear and logical place. The organization should be so intuitive that anyone could build a mental model of the structure and navigate it easily, even without seeing it. It felt…
> 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…
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.
Earlier quoted context omitted.
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 m…
> I'm not trying to write code faster, my own experience is that writing code faster leads to shitter code. I'm wondering who these programmers are who are sitting down for eight hours a day, pumping out perfect code at 200wpm without any breaks. I suspect they might not exist.
Earlier quoted context omitted.
> 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…
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 attent…
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.