You break up things when it makes sense, not for the sake of it.

Having to jump out of the code you're reading comes with its own downsides and tends to compromise maintainability where you are increasing the shallowness of your code (same functionality, but higher api surface).

You break up things when there are benefits to breaking them and Unix provides a very sensible reference to this topic where plenty of syscalls run generously in the thousands or tens of thousands of lines.

Stanford professor Jon Ousterhout (among other things the author of the Tcl language, the Tk framework, the Raft consensus algorithm and many other things) has an entire paragraph in his book "A philosophy of software design"[1], on why the argument "functions should be short" is short sighted and should never be taken at face value.

[1] https://www.amazon.com/Philosophy-Software-Design-John-Ouste...

John Ousterhout also was leading a project called RAMcloud (I thought was interesting) that the article doesn't mention - [1], [2]. Also, he has a book on s/w design [3] which is short and nice, and is more of a collection of ideas rather than an approach, which I highly recommend.

[1] RAMcloud talk by J. Ousterhout:https://www.youtube.com/watch?v=lcUvU3b5co8

[2] RAMcloud paper: https://web.stanford.edu/~ouster/cgi-bin/papers/ramcloud.pdf

[3] A Philosophy of Software Design, https://www.amazon.com/Philosophy-Software-Design-John-Ouste...

A narrow interface handling a large number of concerns... makes the UNIX file API a "deep" module."

Seems self-explanatory to me. "Deep module" [0][1] is a well-defined term.

[0]: https://dev.to/gosukiwi/software-design-deep-modules-2on9

[1]: https://www.amazon.com/Philosophy-Software-Design-John-Ouste...

Wow, good for them teaching software engineering, and A++++ for the Ousterhout book <https://www.amazon.com/Philosophy-Software-Design-John-Ouste...>; I wish everyone would read it

Beware of this so-called wildcard person, as they are almost always a "tactical tornado"[1]:

> Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future. Typically, other engineers must clean up the messes left behind by the tactical tornado, which makes it appear that those engineers (who are the real heroes) are making slower progress than the tactical tornado.

[1] https://www.amazon.com/Philosophy-Software-Design-John-Ouste...

On that topic: I came to like John Ousterhout's notion (in [1]) of "deep" methods/classes/etc. He explains it like this: If you have a reusable piece of code, imagine drawing it as a rectangle. The width corresponds to the complexity of the interface, the depth corresponds to the complexity of the implementation.

Ousterhout is saying that we really want deep classes, i.e. the complexity of the implementation a construct hides should be considerably larger than the complexity it takes to use it. Which, at least to me, basically says "search for good abstractions". And what you're describing strikes me as a good way not to achieve that.

Of course, there's considerable wiggle room in that mental model, and one could still endlessly squabble about how (not) to break up the implementation.

[1]: https://www.amazon.com/Philosophy-Software-Design-John-Ouste...

Read extensively, practice your craft & don't lose your focus.

These books will help you day-to-day with your general programming knowledge...

> Philosophy of Software Design https://www.amazon.com/Philosophy-Software-Design-John-Ouste...

> The Pragmatic Programmer https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...

> Clean Code https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

> Mythical Man-Month https://www.amazon.com/Mythical-Man-Month-Anniversary-Softwa...

You’re right re: it’s early internals, and we probably both know people who still (mistakenly) complain about that. Conceptually the “everything is a string”(EIAS) model still holds though, even though it’s supported by dual-ported “objects” w native representation, and the running is often byte-compiled instead of string parsing. We’ve got early smart fans who saw the vision and possibilities like Karl Lehenbauer, Don Libes, Richard Hipp, and the current core team like Kevin Kenny, Don Porter, Donal Fellows, etc who deeply understand What Tcl Is, and strictly maintain it, even while pushing it ahead (TclObj, finally an in-core blessed object system, native database framework, Miguel Sopher’s(RIP) work on the stackless non-recursive engine (NRE) and coroutines that fell out of that work...

Back to Ousterhout though, you might dig his “Philosophy of Software Design”[0] book, or talks associated with it[1].

Lots to like in this space...

[0] https://www.amazon.com/Philosophy-Software-Design-John-Ouste...

[1] https://youtu.be/bmSAYlu0NcY

The book "A Philosophy of Software Design" should interest you then: https://www.amazon.com/t/dp/1732102201 It argues, among other things, that deep interfaces matter more than code complexity inside a module.

Highly recommended this book:

A Philosophy of Software Engineering:

https://www.amazon.com/Philosophy-Software-Design-John-Ouste...

This is mentioned as one of the symptoms/appearance of bad code: Shallow/Passthrough methods, which results deep call chains, adding up cognitive overload. The author in this book recommends deep module over shallow module, which tends to end up with more cohesive code.

I think the best single observation about cognitive load is in Ousterhout's book A Philosophy of Software Design[1]. In the book he promotes the idea that classes should be "deep", such that their top-level surface API is small relative to the complexity they hide underneath.

This applies to the microservice/monolith debate as well. And it basically boils down to the observation that having lots of shallow services doesn't really reduce complexity. Each service may be simple unto itself, but the proliferation of many such services creates complexity at the next level of abstraction. Having well designed services with a simple API, but hide large amounts of complexity beneath, really reduces cognitive load for the system as a whole. And by "simple API" I think it's important to realize that this includes capturing as much of the complexity of error handling and exceptional cases as much as possible, so the user of the services has less to worry about when calling it.

[1]: https://www.amazon.com/Philosophy-Software-Design-John-Ouste...

From the link, about comments:

  Use as explanation of intent.   Use as clarification of code.   Use as warning of consequences. 

Here's a link to a well-known recent book, half of which is pretty much about why those points are a real and frequent thing, and why code should be much more thoroughly commented than it's recommended by the usual philosophies.

https://www.amazon.com/Philosophy-Software-Design-John-Ouste...