I think that Agile in principle is a good idea, keep iterations small and work on the issues together and deliver working products. The missing piece I think is that PDCA (Plan/Do/Check/Act) cycle isn't being done correctly. The idea is not just to improve the product but to improve the process of creating the product.
This may mean you stray way of the path of the Agile system but that doesn't matter, the standard Agile process is just a starting point, it's your shop, create it how you like.
I like a saying from the LEAN manufacturing culture - "The Process is the Expert" but that comes with a caveat, each and every team member is a Process Engineer!
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.
>> _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.
"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.
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 :) )
Lua really is more of a 'scripting' language (like Python _used_ to be) designed to make API's/DSL's for your Game/Application so end users with minimal programming experience can 'automate' the application.
It's main purpose is as a wrapper over the native application functionality to help people with limited programming knowledge or experience automate their daily tasks, not to 'extend' or build the application. It's simple, clean and quick to learn, the API does most of the hard work for you, you just tack it together as needed with a script.
Thanks for the great site, it's a great reference for new clients when setting up there new file servers etc.
I'm currently doing a Zettlekasten (note/idea organisation) which uses a _similar_ principle, I think between this and johnny.decimal you could build a very custom but efficient system. Will have to ponder further :)
Cheers
I've read both of Christopher Alexander's (CA) books and Zen ATAO Motorcycle Maintenance (Zen). I think the way Zen talks about QWAN is a better description than CA's, I would call when things fit together and work together well 'Elegance' rather than QWAN.
Pattern Mining is one thing and very worthwhile (to find Elegance) but without Quality the end product will be average at best.
The Zen description of QWAN is more about 'what is Quality' or 'where does quality come from'. Yes, elegance plays a part in the overall structure but without QWAN it would be a pretty average 'object'. For example, the design of the car has an 'elegance' in its design but without the Zen 'Quality' would probably not be put together well and be unreliable and shoddy/buggy but it's still a car built with all the patterns.
Quality comes from the knowledge, experience, effort and undivided attention put in by the craftsperson creating the 'object' at a given point in time. The train analogy from Zen explains this well and it's basically about focus in the moment you are doing something. This produces Quality, nothing else. You could argue that the parts to make up the car example above would give it Quality and fix most of the issues in the final product. This is true but only if every step in it's production, from mining the minerals, design, drafting and manufacture were given with the same focus.
As far as software patterns are concerned I think we have strayed too far from inherent Elegance to strive for some other abstracted Elegance (inherent Elegance takes longer to control/master!). The computer is very simple at its low level core (how it computes at least) but we keep building languages to make it simpler at a much higher level and in the process have made things very In-Elegant in between these levels.
We had (and still have) languages that take on the lowest level and abstract it to a higher level very simply, the most obvious being Lisp and Forth but the lack of processing power made them untenable for their time. Both of these languages have the 'Elegance' CA discusses, you have complete freedom in creating the language/s and language features you need, put some Pattern Mining in with some Quality and you really have something!
There is plenty of good info in the other comments but the two things that help me are diet and meditation (I have Rheumatoid Arthritis and it also seems I have Gluten Intolerance/Celiac (cause/relationship??)).
I think with any chronic illness diet plays a big part as when your system is down the food we eat doesn't get processed as well as we like. That is, if you eat junk/processed foods your body can't deal with the 'artificial' components as well as it can real food (no or little human interference).
The side effects of poor food choices for me are lethargy and 'brain fog' along with exacerbating my body pain levels. On these days I no longer fight it and just rest. I recover much better/quicker this way rather than trying to fight through it.
Your illness can consume you at times and this can be quite depressing. Learning and practicing some type of mindful meditation can bring you back to some kind of normal, even just 10 minutes a day can make a big difference and I do notice this if I skip a day or two!
Great read, I kind of do this but on just one page in a notebook. Splitting it up into 3 'areas' (for want of a better word) makes a lot of sense and makes those notes a lot more useful, thanks!
I think a few commenters are missing the point or just skimming over the post. It's not about memorising a 'book' or subject by rote, it's about being able to consume, rearrange and remember the subject in a way that's more suitable to how you remember or think about things.
It not only clears your thoughts as you study (allowing you to move through the material quicker) but aids in recollection with better organised note taking.
Cheers
>> "In situation X I will do behavior Y to achieve subgoal Z"
I was pondering something very similar to this about 10 minutes before he talked about it only I was thinking about changing perspective for the given task, that is:
"what 'mode' do I have to be in to get this done?"
in place of 'Y'.
His short sentence is much more elegant than what I was trying to think but I think 'mode' also fits just as well.
Basically, I think we get too overwhelmed (emotion) with what we have to do and breaking it down into smaller chucks may not be enough. Breaking it down into modes or specialties might make it less daunting. We can all 'plan', 'study', 'code' or whatever hat you need to wear along the way and wearing them all at once, even on a small task can still be overwhelming.
For example, say I have a new coding project but I'm having trouble organising it into chunks as I'm new to the platform/API. What I can do is say "ok, I need to put my 'study' hat on and learn just an overview of how this all works" (study mode) then go back into 'plan' mode to reorganize tasks into further modes to complete item one ('hello world' app say), rinse and repeat.
great article, thanks!
I've stop/started using TODO's many times mainly because of the common problems you highlight in the article, I'm going to give them another go as this simple system will work.
I've often tried to use Trello, paper, sticky notes etc but they all lacked a process for management. This system keeps items where they need to be and they may actually get done, cheers.
I like a saying from the LEAN manufacturing culture - "The Process is the Expert" but that comes with a caveat, each and every team member is a Process Engineer!