Comment by daltonpinto

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.

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.

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.

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.

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.

> 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.

"the whole point of your job is automation?"

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.

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.

"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.

I'm curious what you do when you encounter issues in a 3rd party dependency, or (since it sounds like you do dev-ops work) in an infrastructure process or tool whose code you didn't write? I use auto-complete and LSP features pretty heavily myself in my day-to-day development work, but when debugging an issue, I sometimes run into issues with a 3rd party library, or a kubernetes component, or whatever, and it's necessary to jump into those codebases and understand what's going on, whether the bug is with the library or with our own integration, whether it's more expedient to patch the dependency or write a workaround in our own code, &c. And in those cases, I generally do not have a LSP running, or my editor properly configured beyond basic syntax highlighting, and I have to rely on, presumably, the same techniques that devs who don't use LSPs at all employ in their day-to-day work: being able to quickly read and understand other peoples' code, being able to approximate jump-to-def with find/grep/ag/rg, being able to effectively trace datatypes and control flow through multiple definitions/files, being able to take effective notes to improve my working memory, and so on.

I do think - my pet theory - there is two sorts of « good » code :

- The solo programmer’s code : it’s smart, small, straightforward, does what it needs to do and it benefits from being able to fit in the author’s head but it would be a team’s nightmare, hard to add unanticipated features.

- The team’s code : it’s verbose, full of boilerplate, follows strict programming patterns and rules, is easier to modify/add features. Anyone in the team can add or maintain parts but give it to a solo programmer and it would become a nightmare to just maintain.

For a long time in my career, I opposed the two. Being too straightforward and not strict enough in a team setting is often a recipe for disaster in the long term. In the contrary, being too professional in your solo project is often the way to abandon it.

Being able to write those two types of code is an incredible skill - that I mostly don’t have.

I’m sorry to say that some of the gnarliest and most boneheaded codebases I worked on were ones where I was the ‘architect’.

It was a startup environment and hectic, but I had total control over everything, more or less.

Just to say that having the luxury of a greenfield start doesn't mean you'll end up with a nice result.

> All these IDE+- things may be nice-to-have but most soon become crutches, and then you cannot live without them.

There's a bit of "silly flexing" and projecting here but not entirely without merit. At regular intervals I'll actually turn all my IDE features off just to give myself a refresher. I would imagine that if you took away most IDE syntactical sugar, the vast majority of relatively competent devs could adapt in short order to it.

To me it's the equivalent of using an IME to type Chinese, but occasionally I'll just sit down and physically write the characters on pen/paper. Do I need to do it? Not really, but I enjoy how it forces me into a state of uncomfortableness.

> Then the trend to pollute untyped-languages' codebases with so-called-"typing" noise, because "it would be IDeditor-friendly". Form over function

I honestly have zero idea what you're trying to say here. You mean Typescript or using JSDocs to inform type expectations? What exactly is the issue?

These kinds of arguments get "trot out" all the bloody time. Whatever I grew up with was the most ideal - whatever came after is just a crutch.

For that matter, why are you using a high-level language like Javascript or C#? Don't you know that it's a crutch and gets in the way of true programming understanding? You should be using magnetized needles to etch machine code directly onto disk platters.

"Just turning off syntax coloring freaks recent developers.. even quite good ones.. i observed it."

Because it really does make code much easier to read and there is absolutely no reason whatsoever to not use it.

> pollute untyped-languages' codebases with so-called-"typing" noise

Yeah, this is going to be extremely controversial: your so-called untyped language actually has types in, and they're important, but only the program can see them at runtime because you've not written them down anywhere.

The real solution to "repeating myself writing down types" is Hindley-Milner inference, which dates back to 1958, and more languages should use it!

> "All these IDE+- things may be nice-to-have but most soon become crutches, and then you cannot live without them, and only walk their walk, not yours."

... and?

Cars have automatic chokes, power assisted steering, hydraulic brakes, airbags, seatbelts, auto-dimming mirrors, self-running wipers, and it's fine. People argue that driving a stick-shift is more authentic but even they use syncromesh and clutches, they don't complain about how rubber tyres are for wimps and they use cartwheel-style metal bands wrapped around wood. They don't complain about having a differential instead of fixed drive to the axel.

A plain editor relies on terminals displaying multiple lines and updating them, filesystems for storage, an OS, a keyboard, ASCII or equivalent, maybe virtual memory management and TUIs and "then you can't live without them"! (scream emoji). But so what, it's not a problem, nobody seriously programs on punched cards because they don't want to become dependent on screens and keyboards.

You can make a case that artisan craftsman furniture is better quality than Ikea furniture but that's not because the artisan avoids factory machinery and uses hand tools, it's that the artisan spends more time and effort and takes longer (and needs to charge a lot more money). If you want to make the case that the artisan shouldn't use tape-measures, laser levels, power sanders, power saws, dust masks, wood glue, clamps, they should use a pencil behind the ear, a thumb's width and a handsaw because that's how they learn the True Nature of Wood(tm) then maybe you're just posturing and gatekeeping, or have some sort of Amish-style religion.

Calling power tools 'crutches' is so you can imply that people who use them have disabled themselves. Instead it's like saying people who commute 20 miles to work in a car are using the car as a crutch because you can just walk 5 hours each way and that's more real. It's embarassing that people are so desperately trying to claim both "I don't use power tools because power tools are for weak babies and I'm a STRONG MAN" and in the same breath "my editor can do everything an IDE can do, it isn't inferior, it is a power tool!".

> "Just turning off syntax coloring freaks recent developers.. even quite good ones.."

Just turning off thermometer and oven temperature controls freaks recent cooks ... even quite good ones. Are you going to make the case that restaurants would be better if all cooks worked like your grandma with a log fire who had learned the right feel of heat for bread, cake, or roasts? No? Because that's obviously silly? But what if those developers one day in 2025 find themselves on a monochrome screen, with no shades of gray and no underlines or italics and no option to buy an alternative, hah what then?! Isn't that obviously also silly? NB. you didn't remove paragraphs or punctuation or capital letters from your comment, maybe you're just not a good writer and need these assistive crutches?

> I have no idea how those projects fit together because the actual logic is spread out.

There are two kind of mazes:

- those that are so tangled up that you can't make out any kind of structure.

- those that are so regular that you can't make out any kind of structure.

> For my personal side project hobby work it's all in one file.

Ok, so this is work, but:

    find . -name '*.cs' -type f -print0 | wc --files0-from=-
    1035617 3438912 47446211 total

Not many editors are comfortable with a million line document that's 47MB. And that doesn't include generated code (which I very rarely need to look at, but is right there under F12 if I do)

The bane of "functional. No such thing as objects or classes, just a bunch of shotgun spread state fragments.

Cargo cult runneth strong on web.

> I work with someone that navigates the tree structure of all our directories every time they need to look for something

Counter example: I’m working with LSP dragging codebase where basic code lint takes 45s. My colleague takes a break after each change so that their code navigation starts working again.

Inefficient people are inefficient.

Not using LSPs isn’t guarantee of efficiency just as using LSP isn’t one. Different strokes for different folks - one has to accept consequences though (more automation means less presence, but it’s everyone’s own choice to make).

Adding on, I find that the people who manually navigate everywhere rather than using the IDE navigation features also don't use IDE refactoring features.

When people say "just organize your code well", this isn't something that happens perfectly on the first time, it's something that evolves as the codebase grows. IDE features reduce the barrier to reorganizing as we better understand the problem domain or as the solution grows.

My experience is that those who don't take advantage of their tools produce worse output, even if they believe they are producing better output, the organization they've created only works in their mind and not for their teammates or other people who later inherit the project.

When I mean organized it means having a structure that segrates responsabilities.

It could be applying DDD or some other pattern with that makes sense to the team.

If you are using a framework like Rails, learn well its conventions, follow them and change what your team likes and made it clear to all team members.

Also learn well SOLID principles and OO (of functional programming, or whatever you are using) and make it obvious that your code fits well your choices.

In other words, if some file (class, template, whatever) should have a single responsability, and by that, it should be obvious where that will be placed.

It has more than one responsability? How you can split it? And once it is splitted, it should be obvious where it should belong as well.

> Of course I agree that code should be organized logically, but I wonder if you could expand on what you mean. Do you drill down into finer and finer directories of detail, code units, classes and functions?

from the parent (i am not the parent)

> I try to follow the logic and structure of the project in a way that feels natural and easy to follow later.

in my own experience it applies to everything in a codebase.

what the end state looks like completely depends on the problem domain at hand, and the tools used to solve the problem.

how to make a codebase “intuitive” is learned, not taught. understand the problem domain, understand the tools in use, then refactor, refactor, refactor, refactor until it makes sense.

> I work with someone that navigates the tree structure of all our directories every time they need to look for something

sounds like they have yet to learn how the code modules are organised.

possibly because the modules are not intuitively organised, possibly because there’s a lot of code, possibly because they just don’t care and don’t mind the mental break of mindlessly looking for the right module.

>You might even get a bit of a Conway’s Law effect by committing unnecessarily to a specific, onerous work style.

I don't find it onerous at all. I consider it the same kind of responsibility as writing tests and documentation. And I certainly don't think Conway's Law applies, since for my own projects I'm generally creating deep hierarchical call graphs while being the only person in the "organization".

so `utils` is pretty much the 'junk-drawer' of the kitchen then ;)

Of course, but there is a difference between programing using sdk/library/api and some glue, and actually engineering some self standing solution, and everything in between that. I belive blind programer wouldn't fare well in fast churn ci/cd every minute startup, but would be amazing in embedded space with multi year release cycles.