[daltonpinto]

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 like something out of a Yoda or Mr. Miyagi lesson. Skeptical, I asked his colleagues if he was truly able to code or if he was just exaggerating. To my surprise, they told me not only was he capable, but he was the best programmer they had ever worked with. They said no one else came close to writing code as organized as his.

That conversation changed my perspective. Ever since, whenever I’m unsure where to place new code, I don’t think about DDD or any specific methodology. Instead, I try to follow the logic and structure of the project in a way that feels natural and easy to follow later.

Later in life, I met two other blind programmers and heard similar stories about their ability to produce well-organized code.

To bring this back to the original question: I view LSP/IDE features the same way those programmers view "visual aids." Code should be organized according to a clear and logical structure that makes it easy to navigate.

Relying on features like Ctrl+Click to find where things are located worries me. Why? Because it can mask structural flaws in the codebase. If we can't intuitively figure out where something belongs, that’s a sign the codebase lacks structure—and that should motivate us to refactor it.

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.

[brabel]

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

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

[raydev]

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

[lttlrck]

I'd wager it wasn't the lack of "productivity boosts" either?

[scarface_74]

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

[iamwil]

There is the very real possibility that automation masks complexity, not reduce it. And that’s what he’s saying.

[scarface_74]

I used this as an example before, the AWS SDK

https://boto3.amazonaws.com/v1/documentation/api/latest/inde...

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?

[withinboredom]

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.

[MrJohz]

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

[onemoresoop]

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.

[userbinator]

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.

[continuational]

Good riddance?

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.

[userbinator]

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.

[mithametacs]

I don't want to write any code. I want to think about the design of the program and have it pop out of my head fully formed.

The latter gives me dopamine. The former gives me carpal tunnel.

[lttlrck]

For myself, the code is the journey. There are times though when I'm not fully invested in the problem, that I really just want to skip that part.

[mithametacs]

Sure code can be cool for the same reason hip-hop is more than just the meaning of the words.

The typing is the rhyme scheme. The algorithm is the rhythm.

[sly010]

> The goal of programming is not to write code (however much I enjoy that part), it is to solve problems.

Right, which is exactly why autocomplete is not a huge help.

[jpeggtulsa]

That makes no sense whatsoever. Autocomplete helps you speed up the writing of the code so you can focus on solving the problems more often.

[redserk]

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.

[marssaxman]

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.

[scarface_74]

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.

[dkuntz2]

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.

[UltraSane]

IDEs are neither new nor fancy. I find it really amusing how many programmers spurn IDEs. It makes me think of a engineer refusing to use CAD.

[brabel]

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

[avalys]

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.

[sateesh]

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

[avalys]

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.

[mikeocool]

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.

[brabel]

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

[xigoi]

> The problem is VS Code then. Try IntelliJ, they spent ridiculous amounts of engineering to make typing as fast as Vim.

I presume that does not apply on an old laptop with 8 GB of RAM.

[nsteel]

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.

[Izkata]

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

[wyager]

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

[yallpendantools]

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

[greentxt]

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

[cookie_monsta]

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?

[greentxt]

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.

[mazambazz]

I think everything could be summed up even better to just say that the goal should be to increase productivity.

[greentxt]

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

[HenryBemis]

Automation is bad for you, but it's "good for business". The least they need you, the better it is.

I assume this is where 'automation' comes in, reduce dependence to the meatbags (us, humans)

[fpoling]

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.

[ecoffey]

> LSP optimizes writing the code.

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.

[antihero]

LSP optimises consumption of other code and reading/exploration of code. It's especially useful with types.

[Brian_K_White]

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

[UltraSane]

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?

[kapitar]

This is one of the features I like most about F#, after some years experience with it. The project is structured with a specific file ordering, and there's no forward referencing. Similar within a file/module as well, most of the time.

So to understand a project, you start at the top and work your way down, you wont encounter anything you haven't come across yet as you go.

Ironically, this 'feature' so annoyed me when I first came across the language in 2015 or so, that I put it down after five minutes and forgot about it for years.

[ozim]

You are lucky to have small code base or one that you write mostly?

With 6 other devs on the team and 5 apps our team supports there is no way I get code well organized especially when as a senior I have devops stuff to deal with meetings, explaining features to business, checking up support tickets and random stuff happening all the time.

I don’t know the code base and there is no way to keep up.

While I have to dive in and fix shit ASAP or when I get to code review I have to fix some less experienced guy code. Or write part of code when proposing architecture solution, because just telling people “I am right do it my way” does not work until I write piece of code and then they understand.

Language server and ctrl-click is my bread and butter because that is the fastest way while also going slow enough to understand context.

[nimih]

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.

[ozim]

Well yes I still do lots of grepping and just search in all files if needed. It is not exclusive but if I can use good IDE features it helps to be quicker.

I also have notes I write down where search is must have as my notes are not structured anyway.

[UltraSane]

nearly instantly searching through vasts amounts of data is one thing computers are amazing at and it is absurd not to leverage this capability wherever possible.

[yodsanklai]

> a good programmer should organize software in such a way that every piece of code has a clear and logical place

How many programmers have the luxury to organize the code in the way that exactly suit them? most of the time, I work on code I didn't write myself. In the past, I used to try to refactor but I grew tired of having to justify why it's useful. Nowadays, I just deal with the code the best I can, and LSP is a big help.

[pjerem]

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.

[kapitar]

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.

[zelphirkalt]

This matches my experience as a non-blind programmer. If the code is not well structured, I have issues finding things by intuition. The mental model or map does not work. Then I rely on searches or various kinds. It is annoying, and one can't always change this, when working on a non-restructuring MR. Others relying ore on LSP might not even see this issue.

[thunderbong]

This HN thread was posted on Reddit and that programmer commented [0].

The full comment -

> Oh hey this is me. My typical setup is two terminals: one for vim, one running the compiler and other tools. I just make edits, then invoke the compiler, in a loop. As for finding a definition, most of the time I'm just familiar enough with the code that I know where it is. But when I don't, usually a well designed grep command will do the trick.

> The why: my job involves frequently doing development in environments I don't have much or any control over, and often don't even have Internet access. Over the years, I just learned to work with the basics (vim and a shell) since I can't take my favorite IDE with me to these different environments.

> Additionally, my vim configuration just involves setting up tabs to be 4 spaces and turning on line numbers. Having a complex config just became too much to try to keep in sync across environments.

[0]: https://reddit.com/comments/1hld3s4/comment/m3ladrs

[svilen_dobrev]

some colleague some time ago argued that one can write code without much/any spaces, because, "you can see, it's colored differently".. sounding like, "i am breathing".

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.

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

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

And another observation from many experiences.. any kind of generated code alienates its users, i.e. programmers. Yet to see how current LLM-ical trend scores in this.. As of last interview, "we need software curators, not programmers"

have fun!

[vunderba]

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

[neonsunset]

I'll have you know that among GC languages C# gets you the closest to "using a magnetized needle and a steady hand"!

[UltraSane]

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

[pjc50]

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

[zahlman]

IMX, people who use the term "untyped language" generally: a) use languages with Hindley-Milner inference; b) don't consider things that can "only the program can see at runtime" to qualify as "types".

[pjc50]

If your language lets you add a number to a string or divide a dictionary by a boolean, that's .. exciting, but also the sort of thing that produces https://www.destroyallsoftware.com/talks/wat

[teddyh]

Those “Wat”s are mostly the result ot weak typing, (as opposed to strong typing) which is an entirely orthogonal concept to static/dynamic typing. Don’t confuse the two concepts. Older languages which first started to experiment with dynamic typing also tended to use weak typing. But as things progressed, weak typing was considered less good in serious languages, while it was still expected in “scripting” languages, and Javascript was designed with that principle. Nowadays we have more or less decided that weak typing is almost always a bad idea, and Python is an example of a modern dynamically typed, and also strongly typed, language.

[zahlman]

True, but also irrelevant. Python is strongly, but dynamically typed. You cannot do the things you describe in Python, but it's still considered "untyped" in that framework because it performs its type checks at runtime.

[rootnod3]

Yeah, but even there, if one were to use no LSP or other completions, Hindley Milner doesn't help while editing as you won't see the inferred types. It comes down back to good naming and the compiler at the end.

[wing-_-nuts]

Yeah this is probably someone that doesn't like type script or type hints in python. If you're slinging dynamically typed code for your own personal project, go nuts, but if you're working with a team that 'typing noise' really helps

[jodrellblank]

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

[camgunz]

You're erecting a pretty detailed strawman here. It's not that "raw dogging" code makes you a better developer; it's that specifically jump-to-definition and autocomplete make it too easy to create code bases that may as well be huge bags of functions and classes, and that skipping the mental work of organizing the code limits the fidelity of the mental model you can build.

[adambatkin]

Programming languages are complicated. Their standard libraries are extensive. Real world application are usually not trivial, because they often model real world processes, and the real world is messy.

Anything we can do to make writing software easier and more reliable, and reduce cognitive load, is going to benefit the software developers who are involved, and will make the systems better.

I'm sorry, if you can't jump-to-definition then you are wasting the company's time. It's something that all developers need to do and there's no reason we should be wasting time navigating a codebase when what you are looking for can be found instantly.

Same with autocomplete. I can type very fast, but autocomplete can type faster. Plus with the size of most APIs (even the ones built in to most programming languages) I have better things to spend brain space on. Is it list.empty(), clear(), empty(), truncate() or something else? With autocomplete I can find the function in want in 3 seconds (and read the docs inline, so I can tell that empty() doesn't empty the list, it tells me whether or not the list is empty) without lifting my fingers off my keyboard. Should I remember which is which? Maybe, but I don't care, and a jump between languages frequently enough that it's not worth the effort to keep track of silly things like that That's a contrived example, but hopefully you get the point.

[camgunz]

We're SWEs; the temptation to min/max ourselves is quite high. And it's not a bad impulse! I'm a Vim user; I've obviously invested a lot of time in editing efficiency (e.g. I'm great at looking up docs in the terminal). Oftentimes when I need to code I can't dilly dally. I also prefer a style of dumping out an implementation as quickly as possible to prove/disprove the idea, which of course requires a lot of editing efficiency.

But the way I've gotten here is by assiduously removing things that slowed me down. Sure popping docs in your editor is faster than switching to a browser, but just remembering is even faster. If your goal is really to not "waste the company's time" then you're putting the standard library, your dependencies, your app, etc. into Anki and memorizing. Since almost nobody (some people are and bless them) is doing this, I think we should admit we're fully in the realm of personal aesthetic preferences here.

And I take a broader view of the whole thing besides. I start from the perspective that engineers are whole people with histories, futures, goals, features, interests, and opinions. For example, Go wasn't built with autocomplete and go to definition. You're more or less arguing that Rob Pike should've been forced to setup VSCode. I think that's an express ticket to pissing off and burning out your engineers; just like I'd never micromanage Pike to that degree, I'd never micromanage you to the point where I'd force you to learn Acme.

The value we bring to our companies isn't just the speed with which we crank out code. The value our companies give to us isn't just a salary and benefits. We have more nuanced and complex human needs, and sacrificing those for extreme coding efficiency may provide short-term gains, but the long-term effect is pretty grim (ponder for a moment working at a company that actually cares about efficiency to the degree they'll micromanage your editing workflow).

[UltraSane]

I find it so ironic that a surprisingly large fraction of computer programmers are such curmudgeonly Luddites spurning the most basic tools that make their job easier. Meanwhile engineers are using Solidworks to model mechanism that would be nearly or actually impossible to create without it and then running a finite element analysis to verify it is strong enough and using selective laser sintering to create prototypes for testing and then using MasterCAM to optimize the machining process and then sending it to a $300,000 5 axis milling machine with automated tool changer. Then the part's dimensional tolerances are verified using a $200,000 Coordinate Measuring Machine that is calibrated using gauge blocks made using laser interferometry and accurate to plus or minus a few hundred atoms.

[croes]

It hard to cook without knowing the temperature, it’s not that hard to code without syntax highlighting.

In your examples white on smoke white text would be the better analogy

[card_zero]

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

Or you're William Morris, who was kind of ridiculous and pretentious, but was making a valid point at the same time.

https://en.wikipedia.org/wiki/Arts_and_Crafts_movement

[samsquire]

I greatly enjoyed this comment of yours daltonpinto. Thank you.

I do not rejoice with code bases where every file has no logic or code in it but there are hundreds of methods and files with everything spread out. I have no idea how those projects fit together because the actual logic is spread out.

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

[lloeki]

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

[daltonpinto]

Exactly!

Not because it is split it means that was well split.

If you can reason where something should be, it may be badly organized.

Even single file projects can be organized.

If is small enough and makes sense, why not?

But even in a small file, how is it organized? Utility functions maybe at bottom so you keep business logic together and visible? Maybe some other logic to make it cleaner? The way functions are named follow some convention? What about variables?

I once read one opinion that software developers had more in common to artists and writers than engineers. Writing code is like an art of expressing yourself well to your peers in a way that a computer will also execute what you meant, not the opposite.

The computer can understand whatever entangled mess you write, other people (which may include your future self) may not.

[samsquire]

A word cloud could be a useful navigation technique if the words were clickable and the sizes of words could be customized.

They could also link to other word clouds

Generated and updated automatically

[pjc50]

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

[emj]

A 100G file was ok in those editors even with syntax highlighting. That is an extreme because saving did take some time but there are ways to optimize for that would it ever become popular. IMHO 640K per file is enough for everybody.

  dd if=/dev/urandom bs=1M count=100k| tr -dc 'A-Za-z0-9\n' | fold -w 130 > largefile.c

[teddyh]

For Emacs, there’s a package for editing very large files: <http://elpa.gnu.org/packages/vlf.html>

[zahlman]

Thanks for the hint about `--files0-from`, BTW. I thought I needed `xargs` for this.

[samsquire]

We need tools that process command line output and large files and create tables of contents dynamically based on rules of architecture or comments and allow efficient navigation. I need overlapping buckets or tags.

I've been thinking about it lately but what I've seen in IDEs is not what I want

I liked OpenGrok

[WillAdams]

Are you willing to do that by hand? Have you heard of the author of _The Art of Computer Programming_ and the technique he created: Literate Programming?

[jschrf]

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.

[mckn1ght]

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?

I work with someone that navigates the tree structure of all our directories every time they need to look for something. It is painfully slow to watch and if you ask me, they produce fairly spaghetti architecture. Some of that could be a lack of familiarity with the idioms of our platform and its available SDKs.

But I ⌘ click all the time as well as quick-open right to the class, variable or function I need to work with, and I feel like I still organize things better. I’m constantly fixing the weirdness and proposing even more things that should be improved.

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

[xlii]

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

[daltonpinto]

It is not about speed, is about quality.

When I met the other 2 blind people, one of them joked that yes, they were very organized, but because they had to be, unlike us, being not organized wasn't an option for them.

I don't question the ability you may have to deliver quicker results, but I bet that your incentive to organize stuff is smaller than what your friend has.

Maybe he will be more inclined to refactor that than you and take even more time, and that maybe it pays off. Of course, I have no idea of your deadlines or if you are in a rush for MVP in search of market fit.

But this also follows those lines of: "wanna go fast go alone, wanna go further go together".

I value more quality than speed, but also understand that sometimes speed is what is needed.

[rerdavies]

Needs more RAM?

I've been doing work on a Raspberry Pi project, which got large enough that it took forever to get code nav back after an edit.

I switched to using VSCODE remote from a beefier machine with 32GB of memory (and an admittedly better processor). Editing response is now under 10 seconds. Sweetness and light! And even the compiles (which still take place on the Pi) run about 6x faster.

[xlii]

Nope, we are working on beefy machines. Problem are circular dependencies that trigger recompilation multiple times and macros sprinkle on top.

We’re refactoring it and get there eventually but without LSP and types (stack is dynamic) there is only so much that can be done.

[tubthumper8]

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.

[daltonpinto]

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.

[dijksterhuis]

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

[daltonpinto]

Not only learned, but it changes with time.

When reviewing code, the reviewer responsability is not only to make sure that it works, otherwise tests and its coverage would be enough, but they aren't.

If a reviewer sees that something does not fit with the convention that the team agreed, it should be questioned and also teached or discussed (if some new addition force the team to do so).

You don't need to know all the code base by heart, but how to follow it and place it.

Something like, does your team uses DDD? Where code that interacts with database should be? And how? How your templates are done? Do you use presenters? When? How? Any other patterns?

[zahlman]

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

[tekkk]

I myself coined a term "kitchenware principle" that I have applied to my codebase as well. You put forks and knives adjacent because they serve similar utility and common purpose. Same with plates, cups, weird gadgets in separate drawer.

You should organize your code similarly and with as little fanfare. They are just tools, dont get clever with them. Sometimes, you get too many forks in same holder so you have to divide them but again, common sense prevails.

[dvektor]

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

[tekkk]

Certainly and nothing wrong with it. Just have to make sure no forks get lost in there. And I myself have started to prefer more intellectual "lib"

[sn9]

My understanding of successful blind programmers is they basically are forced to write code in a way that fits in their head, and this is the essential feature of good code.

I'd be interested in more concrete examples of what specifically you're referring to though.

[Phlebsy]

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

I had a similar conversation with a blind classical guitarist before I ever played, which was echoed by my instructor when I started to learn a few years later. Something along the lines of "If you don't know a piece of music to play it with your eyes closed then you haven't practiced it enough for a performance."

I'm not sure I follow the same idea with not utilizing available tooling in software development, but I do believe that most developers would benefit from intentionally going 'back to basics' and limiting their use every so often and shining a light on what you might think you have a solid grasp of but are actually at the limit of your unassisted capabilities.

[wruza]

I fully agree with the idea but disagree with the… submission to the norms.

We rarely talk about it and it’s also the constant source of teamwork issues. Look, if our code needs structure to be observable, it lacks structure in the first place.

Languages and editing methods — not talking IDEs here, it’s more fundamental — are still “empty file canvas, paint anything” model. That must be stopped.

These structural issues are analogous to malformed xml issues. They should not exist normally. We could start with e.g. better isolation/visibility systems than “files with exports”, then address lack of annotated TOCs for projects and modules. Then replace files with something more database-like. Theeen we could talk about someone breaking a nice structure. Because this structure only exist in a human’s mind, blindness only serving as a bitter “equalizer” to it.

[dataflow]

> Relying on features like Ctrl+Click to find where things are located worries me. Why? Because it can mask structural flaws in the codebase. If we can't intuitively figure out where something belongs, that’s a sign the codebase lacks structure—and that should motivate us to refactor it.

This argument sounds nice in theory but it seems to have some serious fundamental flaws w.r.t. "how do you code without an LSP":

- What do you do about dependent names? i.e. names that resolve to something different based on various conditions in the code? They might be defined in multiple places conditionally, their default definitions might be overridden for particular cases (and you'd have no idea if you just saw the default definition - think "template specialization" if you write C++), they might have different definitions on different platforms... do you seriously want to explore the entire codebase manually with all the compiler flags to figure out what something resolves to?

- What do you do about code that you can't refactor? Like third party code?

- Not every question the IDE/LSP answers is of the form "where does this belong". What do you do about things that aren't names? Like say, there's a quantity calculated at compile time and want to know its value? I'm not talking Math.PI here, I'm talking about something like STACK_BUFFER_SIZE. It can easily be something like (sizeof(T) + sizeof(U) * 4) / sizeof(void*). How much of your life do you want to spend simulating the compiler in your brain vs. having it just tell you what it already knows?

etc.

[registeredcorn]

Regarding organization, I heard an interesting perspective that may be worth consideration that I would like to hear your input on. The opinion went something like this:

> Well written, clean code is amazing. It is also an issue because the second features or specs change, you have to undo/redo the work you just did! Further complicating things are two other real-world concerns:

> 1) Looming deadlines might make the time needed to express "best organized" code to either be executed suboptimaly, or outright incongruities, leading to confusion due to parts A, B, and D being expressed very well, but C, and E-J are left looking wonky.

> 2) It can foster a "Don't touch" mentality. "Oh, Bob (the pro) wrote that! Better not mess with it. I'll work around it with a hack-y solution." Basically it's a suggestion that, "In order to write very well organized code, you have to be an excellent programmer. So what do you do if you work with subpar to average programmers?" It would almost seem to suggest that by writing well organized code, you are giving yourself even more work, because it is intimidating or too daunting to other programmers who aren't at that same level.

I'm not sure how much I agree with those points, myself. I kind of feel like they are a cop-out, a kind of excuse to go with less thought out designs. I do see, however, that as far as real world situations are concerned, managers and even fellow programmers might prefer "good enough" to be done with it. I'm not really sure what to make of it, but it does seem to make a kind of sense.

[scarface_74]

This is the AWS SDK for Python.

Everything is “logically organized” am I suppose to remember every method on every class?

The C#, Java, Go and other SDKs are the same (they are all auto generated by the same definition file)

It doesn’t matter how well structured a codebase is, once it gets large, you’re not going to remember every method on every class

[rnewme]

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.

[scarface_74]

How many large applications are made with no dependencies or frameworks?

In another life, I worked on a SaaS app around railroad car repair billing.

These are the industry requirements.

https://public.railinc.com/sites/default/files/documents/CRB...

And this doesn’t include addendums, regulation updates, industry norms, extra requirements by clients etc

No matter how well structured the codebase is, it will become large and had a lot of classes.

Not to mention the underlying .Net framework

Have you worked with either the iOS or Android SDK? Do you expect people to know that entire SDK and a sufficient large codebase?

Autocompleting IDEs are not a new concept. It’s been part of Visual Studio since the mid 1990s.

[rnewme]

I perhaps didn't express my point clear enough. If you're developing net framework, ios or android sdk itself, you're trying to be consistent and well structured, and you'll probably mostly work in one part of the code base. Then app dev will again use your structured expected layout as part of his structured system. The point wasn't to know the whole code base, but rather that it's made in a way that it makes sense how to use nth thing after you use first few.

I developed ios apps, and it's vastly different experience than android or flutter. And then that is not even comperable to JS and dozen build steps, standards, and libraries that are countless and all with different approaches to how they're structured and built...

[scarface_74]

And even if you make it consistent, using domain driven names, etc.

The method names are going to be different and not easily guessed. Why wouldn’t I use an IDE feature where I put a “.” at the end of the class instance and use autocomplete to tell me the methods? Why wouldn’t I use an IDE feature where when I rename a method, it automatically renames all of the references in an entire project?

Unless you are using reflection, this can be done in a provably correct way in a statically typed language?

[nickd2001]

" 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." sounds like very good advice to me. In the mid to late 1990s I worked somewhere that tried to do this with a big C++ codebase, because we didn't have IDEs (vi wasn't even vim at the time), unless you count emacs which some people were good at, not me at the time. I believe that IDEs are in many ways a backward step ,because they allow people to develop lazy habits and make a hideous sloppy mess of meaninglessly-named spaghetti, knowing that there's autocomplete and advanced search functionality.

[zkry]

This is a great tie in point. I've had simmilar feelings that a lot the conveniences we have as developers only end up letting us dig ourselves into ever deeper messes of complexity.

[zahlman]

I feel much the same way about how to write the code, but the idea of losing my sight is still horrific. I can't imagine having an easy time adapting to it and can very easily imagine giving up on coding.

[fnordsensei]

I wonder if this makes it easier for LLMs to navigate your code as well. They are effectively blind.

[sourcepluck]

Wow, excellent insight from these programmers. Very cool. Will be keeping this in mind!

[nox101]

sounds great if youre starting from scratch. I work on a project with 250k+ files I didn't create