Comment by LegionMammal978 | Hacker News Reader

Comment by LegionMammal978 | Hacker News Reader

Parent Full thread

LegionMammal978

I'd be a bit wary of taking 'simplicity' as a goal. Some people read that and think to write shorter, cleverer code instead of longer, more straightforward code which might have a few redundancies. (E.g., people often praise FP languages and Lisp-like languages for their very flexible control flow, but adding custom abstractions can result in shorter code that is difficult for newcomers to understand.)

On the other hand, too much modularity and factored-out code can also obscure the behavior of a program, even if each module has a well-defined role and satisfies its interface. (E.g., big Java programs can have hundreds of classes with small method bodies and lots of calls to other classes and interfaces. If you see an interface call, but the object came from somewhere several classes away, then good luck figuring out which implementation gets called.)

I'd say that the ultimate moral is "Keep the flow of logic and data relatively linear (or at least, no more complex than it needs to be to solve the problem). Avoid dicing it up between a dozen different spots, or performing crazy stunts with it, so that only an expert can understand what's going on. And just because some logical constructs (like dynamic dispatch) are unwritten doesn't mean they don't create mental load."

I think it's fine if code is difficult for newcomers to understand (of course, to a point). Most programmers are taught in C-like languages and paradigms. Using FP (ML-like) languages is already "difficult to understand".

The question then becomes: how large is the disconnect between the "theory" in the mind of the newcomer(s) vs. the "theory" they need to be useful in the codebase -- and is this gap worth it?

For example, programming with explicit effects (i.e. `IO`) or even just type-safe Futures. There's not too much difficulty with simply getting started, and it builds up a general theory of effects in the newcomer, which would presumably be useful in many contexts of the codebase even outside of async effects, e.g. error-handling with `Either`.

Everything is difficult for newcomers to understand. Newcomers should be helped to learn new things. Every programming language will be incomprehensible to non-programmers. That's not the target audience.

One dev's "you've just gotta learn how we do things" is another dev's "holy hell why does this codebase have its own mind-bending do-everything hyper-abstractions that don't exist outside this organization". (I'm thinking not of the basic concepts of popular FP languages so much as the powerful abstractions they can be used to create. Though if a company invents its own language, that can very quickly enter the 'overly large gap' range.)

I agree that there's a spectrum here, but IME it's very easy for existing devs familiar with everything to underestimate the gap between newcomers' knowledge and their own, or to overestimate how much it's needed. In the worst case, you end up with brittle spaghetti 'abstractions' where the old-timers swear up and down that everything is perfectly sensible and necessary.

(I've personally seen this kind of overestimated necessity twice, in the context of API design. In both cases, the author of a public library published a new version incompatible with the old version, under the justification that users really ought to learn and pay attention to the fine details of the problem space that the library is solving, and that changing the API is a good way to force their hand. But from an outside perspective, the fine details weren't really important for 99.9% of use cases, and it isn't practical for every dev to be conscious of every tradeoff and design decision in the whole stack.)

> the worst case, you end up with brittle spaghetti 'abstractions' where the old-timers swear up and down that everything is perfectly sensible and necessary.

i had this at last place. all previous members of the original team were gone. it was myself and a part time dev (1/2 days per week).

writing new tests would take longer than writing a change - not because we were writing a significant amount of tests. because the “factory” spaghetti code god class used to create all tests was just a nightmare.

got to the point where i just focussed on manual QA. was faster for each change (small team helped there).

and rewriting from scratch on 20k existing LoC for that repo wasn’t gonna work as we just didn’t have the people or time.

basically — we didn’t have time to deal with the bullshit.

keep it stupid.

for the love of everything good and sacred in the world, please, i beg you, keep it stupid (addressing this generally, not at the parent).

it’s easier to get it right, quickly, when it’s done stupidly.

—

i now want to have a moan into the vast empty space of the interwebs:

the data/mental model for the whole thing was just wrong. split tables for things that had a 1:1 relationship. code scheduling for worker tasks spread across multiple services. multiple race conditions i had to redesign to fix.

oh and no correct documentation. what was there was either wrong or so high level that it was essentially useless.

and roll-your-own-auth.

apparently thus was all done under the clean code cargo cult. which tracks cos there were so many 10 line methods everywhere which meant jumping around constantly.

> but adding custom abstractions can result in shorter code that is difficult for newcomers to understand

I’ve worked at places where the lead would abstract everythiNg possible, it made tracing the flow not just difficult but almost intentionally obfuscated. When calling him up on it he would sing the principles and say it’s the source of robust code. I’m sure out 100 customers appreciated that.

I do appreciate your comment on keeping the flow right, I would add to that I guess by making sure your domains and boundaries are well established and respected.. mistakes will always happen, but if they’re “gated” by domains, the person who fixes it will definitely buy you a beer/coffee.

Reply on news.ycombinator.com