Semi on-topic mindset related note: be careful about going too far in the direction of elegant "mathematical" thinking. It's good to have certain mental techniq

Semi on-topic mindset related note: be careful about going too far in the direction of elegant "mathematical" thinking. It's good to have certain mental techniques available to you, but real world problems require a certain suppleness/flexibility of mind and willingness to deal with exceptions that don't fit nicely into logical molds. (unless you work entirely in theoretical spaces -- then it's ok because there's no difference between theory and practice) As someone who was for many years enamored with theory and mathematical elegance (I drank from the wells of lambda calculus and category theory in hopes of discovering something that would set me apart), I had to unlearn much of it to actually make progress in my work. When faced with new problems, I found myself trying too hard to find an elegant solution, and when I couldn't, I was paralyzed. My more resourceful colleagues on the other hand managed to ship yucky but working solutions -- which eventually got less yucky. I learned that sometimes you have to let go of the ground-up mathematical-derivation type of thinking, and just release practical yet inelegant solutions into the wild, collect data, and then iterate. As one iterates, some solutions will tend toward elegance and others will not -- some problem spaces are just naturally messy and the solution needs to reflect that. If you've ever worked with an ERP, you'll understand how hard it is to unify competing concepts, yet that's what an ERP does with varying degrees of success. (everybody hates ERPs, but different people hate it for different reasons, and on the whole they kind of work) Take something like Category Theory for instance: it seems like it should lead to amazing elegant solutions, but in practice it's rarely used -- and Haskellers might disagree with me here -- to design solutions (except in rare cases like LINQ). Instead, it's often deployed as a post-hoc gloss to explain solutions that have emerged by trial and error (like SQL perhaps). Its utility is often usually retrospective, i.e. either to verify correctness or to add rigor to existing solutions. p.s. don't underestimate the value of experience + good taste in producing good thinking. People who design good abstractions are not always deeply mathematical people, but instead are people who have good intuition, like Anders Hejlsberg (architect of Turbo Pascal, Delphi, C# and Typescript), Rich Hickey of Clojure fame (who actually trained as a musician), etc. Guido van Rossum (Python) once said he probably couldn't have designed Python when he was 17 because at that age he didn't have enough experience and good taste in programming languages -- which is why most programming language designers tend to be over 35.