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