What are some interesting thinking skills or strategies you've picked up from programming (or anywhere else, but try to stick to programming for now)
switch statements
switch statements require you to exhaustively consider all relevant or possible inputs (if you don't rely on default).
Interestingly, the notion that switch statements can require a default is reflective of the truth to the idea that when the stakes get high, we all fall back to our default level of training or function. This has global applications to our functionality and, by extension, the inputs (things,people/their methods,contexts) in our lives as well
I guess this may be more of a project management thing, but trying to figure out what the most important part of a task is, and getting that done first.
If I'm cleaning the bathroom, I do the sink, because if I have to stop, that's typically the grossest part.
When I'm doing my taxes, I do the stupid parts that I can't afford to get wrong first.
When I'm packing for a trip, I get the stuff I need day-to-day sorted out and in my carry-on.
I don't think these are great examples, but they mean something to me.
It's installed on a slight angle, so water pools in the soap holders and around the back of the faucet. If we don't keep it dry, pools fill with gunge.
Often when I'm working on some code, all my errors are because of something much different than what the error message is telling me. I've learned that often, most problems have a different cause and better solution.
I'm good at breaking down problems into small chunks and not getting overwhelmed by a big project. Do I have the motivation to finish these tasks? That's a different question.
Appreciating possible failures (pessimism, some call it) and being methodical, even if it's tediously methodical.
Interestingly, the notion that switch statements can require a default is reflective of the truth to the idea that when the stakes get high, we all fall back to our default level of training or function. This has global applications to our functionality and, by extension, the inputs (things,people/their methods,contexts) in our lives as well
You might be interested in the book Algorithms to Live By. It's not a masterpiece or crazy deep, but it's a pretty accessible look at a few applications of CS approaches to real world problems.
(1) Optimal Stopping
(2) Old people don't lose memory - they have so much of it that it slows their system.
(3) Procrastination can be seen as an efficient scheduling problem with wrong priority.
(4) Predictive Models - Gaussian, Power Law, Erlang
(5) Over-fitting - "It really is true that a company will build whatever the CEO decides to measure".
(6) Penalize complexity - Occam's Razor Principle
(7) "A bit of conservative, a certain bias in favor of history, can buffer us against the boom and bust cycle of fads"
(8)Over-fitting Examples - Military Training, taste buds
(9) Early Stopping - Appropriate for Uncertainty
(10) "The prefect is the enemy of the good."
(11) Continuous Relaxation for discrete optimization.
(12) Lagrangian Relaxation - "You don't HAVE to obey the law. There are consequences to everything and you get to decide whether you want to face those.
(13) Random Sampling - Miller Rabin Primality Test
(14) Charity - GiveDirectly uses random samples of review
(15) Bloom filters for search engine crawls.
(16) Simulated Annealing - Random restart hill climbing.
(17) Randomness - heart of creativity?
(18) Networking - Circuit Switching -> Packet Switching
(19) Exponential backoff
(20) AIMD - Additive Increase Multiplicative Decrease, TCP's Sawtooth
(21) Game Theory - Price of Anarchy. Selfish routing only has 4/3 as it's price of Anarchy that's how internet is working fine (infact 33% close to optimal).
(22) Price of Anarchy is very high in case of Prisoner's Dilemma.
(23) Tragedy of Commons - Pollution, Climate Change, Number of Vacations employees use etc.,
(24) Game Theory - Information Cascade.
(25) Vickrey Auction
Loops and recursion or just thinking iteratively in general. If you get this, then mathematical induction gets much more intuitive if you're studying math.
So if you have ever dealt with PLCs beyond the basics you know that timing/parallelism is a clusterfuck of misery and pain until you get to the point where you can master it.
I am pretty decent at keeping multiple things going as a result.
When I start a personal project I create a readme file that has a ToDo section and a Change Log section. Anything I think of that I might want to do I put under ToDo, break it into small chunks and prioritize it. When a task is completed under the ToDo section, I move it to the Change Log section. Easy to maintain, track progress, and documents both a Road Map and Changes all in one place. It also has a section for references to shared assets that need attribution. Actually to keep it simple the same document usually also has an about section, an installation section, and a usage section.