This helped to understand how OOP was working under the hood (I was a teen at that time)
This post brings me many memories from Turbo Vision, Borland Graphics Interface, a simple assembly language, the flat memory hack, Turbo Pascal with its super fast compile time...
When I was a teen, I used TA precisely because of oop support :) it was a bit cumberstone compared to higher level languages, but worked quite well for the kind of stuff I needed (mostly display-related and IO libraries)
We used it for the kicks at the Uni. Never got to try that in prod because frankly the next time it came to using assembler it was 15 years later (and on another arch).
I can really recommend debugging with command-line gdb (inside a text editor, of course; we're not barbarians). The transcript that lets you look back at the past of your debug session really adds a new dimension to the debug experience that a plain IDE integration just does not offer.
By transcript, I mean every command and every response in the debug session. Usually, in the beginning, I do not know yet what I'm looking for, and set breakpoints at points that may be interesting, and when I reach the breakpoints, I look at variables. Later, when I reach the point where things have gone wrong, I can look at variable values now, but also at the result of every previous query. This helps me answer questions like: was this object here already in that queue over there when the previous request came in?
I can also attach the debug session to an issue in order for others or future me to understand what was happening then. In a purely GUI-driven debugger, I can copy&paste a stack trace of the final point, but the history is lost.
I think it just means inside your editor's terminal, where there's usually some modest integrations like it detecting a source/line reference and either jumping you there or at least making it clickable.
I cannot for the life of me get gdb to debug a remote in VS Code. The debugger runs, and breakpoints work and integrate, but the console is dead. '-exec print foo' does nothing.
Time travel to the late 70s and use the lisp machine debugger.
I always felt the drive towards mouse-driven tools in the PARC world (InterLisp/SmallTalk/CedarMesa) was actually a regression because of the loss of history ("how the hell did I get here?")
They also had a proper REPL, and the reason I stay with Java and .NET ecosystems, is because they are the closest we can get back to the Xerox experience, after the UNIX divergence.
Just learn a tool at a time. Ftrace, for example, is a nice tool to trace kernel events. It is not the coolest kid on the block, but simple enough for basic things.
Mermaid has explicit support for diagrams that look UML-ish (never mind the filled triangle arrowheads for inheritance): class, state and sequence diagrams. Graphviz doesn't do that easily.
PlantUML[0], which is built on top of Graphviz, does have support for UML and other services such as Gitlab do support direct embedding of PlantUML (which also means you can embed Graphviz, since PlantUML is an extension of Graphviz).
Remember when Blackberry succeeded in the market by calling their text-messaging device a "two-way pager" even though, technically, it was a mobile computer with modem and not at all a pager?
Chances are you'll fare best by hiding your earth-shattering new paradigm behind a veneer of familiarity. Then nobody has to know you have deep insights no one else has.
If you're at least a bit into home-lab tinkering, you could run NextCloud from a Docker container on your NAS or home server or RPi. For external access limited to your family's devices, you could use Tailscale.
But yes, you could just have Hetzner host it for you for a handful of Euros a month.
"Is my partner having a good time": Make your partners look good. That is usually a good idea in any team.
"Find the earliest end". That would mean don't ever maintain an old product because there's nothing interesting in it...
"Yes and" principle: you accept the ideas that your fellow players introduced and build on top of them. For example, "Backend moved their data store to a novel distributed document store they read about on Twitter -- Yes, And we'll let the frontend run in a JS-emulated Browser-in-a-Browser!". I see that being applied, but I'm not sure it's good advice.
Analogies work until they don't. They're a tool break down concepts or to help re-frame a way of thinking. When analogies stop being useful, stop using them. With that being said, I feel like there's some nuance being missed.
"Find the earliest end" is about keeping ideas flowing for creativity's sake. There is only so much mileage out of an idea before it becomes stale (exceptions withstanding [skip to about the 1 minute mark])[0]. The earliest end isn't permanent either. Troupes and groups revisit ideas all of the time.
"Yes and..." doesn't mean that every idea needs to run its course at the detriment of the group. It means to explore the idea to see if it leads anywhere fruitful. If it doesn't, bail. The Office[1] showcases this where Michael pretends to have a gun during an improv group. It ruins the flow of everyone else's idea, because his idea has a clear, expected ending. It's OK to see where a fresh-faced dev's idea might take the project. That doesn't mean they have creative control.
I see the "yes and" principle being about customer interaction. You never tell your customer they're wrong, you always agree with them and build on what they told you they wanted.
