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

The book A philosophy of software design https://www.amazon.co.uk/Philosophy-Software-Design-John-Ous... Points out that TDD can inadvertently lead to tactical design rather than strategic design. In my experience, this can be true. I'd never noticed until it was pointed out.

Im on a team that is currently attempting shift left. One part of this has been an argument that testers should review unit tests. I think this is not a good idea. Unit tests tend not to focus on the behaviour of system as a whole.

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

Sounds similar to Ousterhout's Philosophy of Software Design!

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

The main point is that a software developer's job is to fix stuff so you end up introducing complexity, but you will have a much easier life if you realise when you're about to introduce more complexity, and try to minimise it by thinking about your implementation choices. KISS, I guess.

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.

The sense that the platform's interface (API, dashboard, Docs) create an interface of which I can gain a solid mental model. A "solid mental model" is knowledge which enables me to predict how the platform would my code/actions would make the platform behave, to feel confident in those predictions, and to be correct.

Why does this draw me to a platform? Because it leads me to think that I'll be able to use it to solve business problems[1] despite having non-infinite mental abilities[2]. That includes the ability to communicate about timelines with stakeholders.

What makes me think that about a platform?

- Well-written documentation, with appropriate amounts of the 4 types of docs: tutorials, model explanations, how-to guides, and references.[3]

- If applicable, docs which show how to write automated tests with the platform.

- Interfaces which do a good job of containing complexity. The information they require me to learn "pays its rent" for the space it takes up in my mind. The modules are deep enough to have solved problems that would otherwise take up my time.[4]

- An active community so that StackOverflow has a body of high-quality questions and answers.

[1] see https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

[2] see https://news.ycombinator.com/item?id=21303314

[3] see https://www.divio.com/blog/documentation/

[4] see https://www.amazon.co.uk/Philosophy-Software-Design-John-Ous... a concise book which is worth the £8 and 150 pages.

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

Philosophy Of Software Design is a recent work on the subject

Amazon: https://amzn.to/2Rpu6zX

Book review I wrote a while back: https://benmccormick.org/2018/12/31/book-review-philosophy-o...

Thanks everyone, the comments are much appreciated. Here's a list of books and other media resources recommended so far in the thread:

Robert C. Martin, Clean code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

Vaughn Vernon, various: https://vaughnvernon.co/?page_id=168

Steve McConnell, Code Complete: https://www.amazon.com/Code-Complete-Practical-Handbook-Cons... 2

Clean coder: https://cleancoders.com/ videos

Hunt and Thomas, The Pragmatic Programmer: https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...

Hitchhiker's Guide to Python: https://docs.python-guide.org/

Dustin Boswell The Art of Readable Code: https://www.amazon.com/Art-Readable-Code-Practical-Technique...

John Ousterhout, A Philosophy of Software Design: https://www.amazon.com/Philosophy-Software-Design-John-Ouste... This one looks particularly interesting, thanks AlexCoventry!

Kent Beck, Test Driven Development: https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...

Dan Bader, Python Tricks: The Book: https://dbader.org/

Ian Sommerville, Software Engineering: https://www.amazon.com/Software-Engineering-10th-Ian-Sommerv...

Svilen Dobrev, various: http://www.svilendobrev.com/rabota/

Another excellent resource is "A Philosophy of Software Design" [0], from John Ousterhout (known for Tcl/Tk, Raft, RAMCloud, Log-Structured File System). Like Niklaus Wirth, he is striving for designs that fight complexities and yield simple and powerful abstractions. This book is so much better than overrated books like "Code Complete" and "Clean Code" for a fraction of the page count.

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

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

Looks like it was just released!

For the Tcl internals, was this John Ousterhout's code or some other codebase? Have you read his new (ish) book on Software Design? [1]

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