>> _Anecdotally, I've replaced OOP with plain data structures and functions._

I think this is why FP is becoming more popular these days but I'm not sure some people get why. The problem with OOP is you take a data set and spread it all over a 'system' of stateful (mutable) objects and wonder why it doesn't/can't all fit back into place when you need it to. OOP looks great on paper and I love the premise but...

With FP you take a data set and pass it through a pipeline of functions that give back the same dataset or you take a part of that data out, work on it and put it straight back. All your state lives in one place, mutable changes are performed at the edges, not internally somewhere in a mass of 'instances'.

I think micro services et al try to alleviate this by spreading the OO system's instances into silos but that just moves the problems elsewhere.

IME microservices solve engineering process problems (i.e. synchronization, enforcement of interface boundaries, build and test scale issues), not technical problems in the product.

I agree, very true when used for purposes as you noted. I guess my point was more about using them as a way solve the underlying problems a large OO system can develop. Microservices enforce you to package data sets for transport, it's very functional if you only take the data and transport into consideration, the mess can still happen within the microservice though.

"A radio built like this, with individual subsystems connected together, is much more understandable."

Yes! this has been my experience too, building something from first principles and given some tools and direction to experiment you get the chance, and experience, to really learn. I've been looking for resources like this for building amps but they're either small signal or the whole design. You understand how they work but not where and what to change if you wanted to tinker or build your own.

I totally agree and recently wrote a piece about this and how I came to the same question: "what can we learn?" https://github.com/MickDuprez/Protocol-Driven-Development

Even if you do use micro-services you still need a protocol!

A short, self-contained design article I wrote after rediscovering the original, 'actual' intent behind Smalltalk's message passing.

The power of words! Nothing new here really, it's the old systems/process vs goal story but actually I felt that one word make a cognitive shift, for me at least :)

Sveltekit I've only just begun the journey but I'm sold! After trying everything from Smalltalk/Lisp, PHP, ASP.Net and React et al and even bare bones web components, Svelte and Sveltekit has hit a sweet spot for me as a one man band. It handles both server and client side in one app and can be fine tuned to get the most of both server side and client side rendering.

For desktop I mainly use C# on Windows but would love to dedicate more time to Smalltalk, a very cool concept and language.

You're correct in that carbon dioxide exhaled is a key factor and it's because it's the by-product of burning energy and rebuilding the body (mostly at night so get good sleep too!) What this means though is there's no easy way, you either need to build a faster metabolism or exercise more.

Of course, eating less helps too as you're not storing more energy than you need. It's a balance. As pointed out in other responses, eat less carbs/sugar (no soda or bottled juices!), eat only good fats (non manufactured) and don't eat anything in a packet/can that has numbers in the ingredients. Frozen or canned vegetables are ok if they're 'plain' without sauces etc. Basically, eat real food.

Buy smaller plates. My partner has a uncanny ability to fill up a dinner plate no matter how big so I ask her to give me the smallest dinner plates we have and don't mound them too high :) If I'm still hungry I've found just a regular hand full of peanuts takes away the hunger pangs. This helps between meals too, plenty of water also helps.

The book 'The Toyota Way' and a book by Shigeo Shingo (helped develop the TPS) - 'Kaizen and the art of creative thinking' changed the way I think about completing tasks or achieving goals. While they are more based on manufacturing the lessons hold up well for any discipline. Basically, once you realise that everything has room for improvement (nothing is ever perfect!) and it's consistent small changes/improvements that make things better, it takes the pressure off trying to do things exactly right the first time. Treat tasks/projects as experiments, come up with a few hypothesis, pick one, do it and asses how it went and what can be improved or throw it away. At least you're getting stuff done and you might just end up with something better than you would by trying to force a perfect job/product from start to finish.

It's not the smart phones, it's the social media app's on them. I don't remember anyone staring into their nokia 3110 every 5 minutes (except for a quick game of snake in the waiting line perhaps :) )

"slow is smooth, smooth is fast"

The trick is to keep moving (doing).