Computer Science for people who hate math — an occasional series

I am a software engineer and I hate math.
Actually, I probably don’t hate math, but I am intimidated by it and I don’t understand it as well as I would like.
I came to programming later in life and as such it is very hard for me to remember even the relatively simple math that I last encountered in high school a couple of decades or more ago. Add in the fact that I never understood it that well to begin with, was intimidated by it, and generally didn’t have teachers that took the time to explain it in a way that I understood … Well, it all adds up to some serious math anxiety.
So, this occasional series of articles is for all those who, for whatever reason, start hyperventilating whenever they see an equation, have become software engineers by perhaps some non-traditional route, and who know that they just don’t think the same way as all those software engineers with computer science degrees. Perhaps most importantly you find yourself at the point where you really do need to understand this math stuff better than you do already. You are more than a junior, but feel that you can’t quite make the leap to a strong intermediate level programmer without cracking this whole math thing.
You have probably watched countless videos, done more than a few tutorials, and read all manner of blog posts on computer science topics. You may also often feel that after a short overview that most resources have you suddenly jumping from 2+2=4 to a discussion of Fermat’s Last Theorem. This is discouraging. Actually, as a Brit, I tend to understate things, so let me rephrase that for my fellow Americans: This is depressing, devastating to the ego, and can cause you to seriously question your choice of career.
As a side note: I have a special loathing for any learning material that claims to be “easy” or “introductory”, but starts off with an assumption that you have a strong background in math and overuses the phrase “from this, it is trivial to show that <insert something that is NOT trivial, and is offered without so much as a footnote of explanation>”
My goal is to learn with you and to try to share my imperfect understanding of computer science topics as I figure them out. I will try to explain absolutely everything without assuming that you know anything beyond very basic algebra. That’s because I myself had forgotten things like what logarithms actually are, and hate having to Google every other symbol to understand an equation.
I will get things wrong, and that’s okay. When I do, I will correct it, explain why I misunderstood, and I’m hopeful that will help others understand why it’s actually “A”, not “B”. I welcome comments, corrections, and better explanations. When I don’t understand a comment, or correction, or explanation, I will ask all the dumb questions that nobody likes to ask when they’re supposed to be a programmer already but just not quite getting the whole math side.
Part of my reason for doing this is because I believe that it is imperative for the software industry as a whole to welcome diversity of thinking and reasoning styles. Small steps have been made to improve (or at least pay lip service to) diversity in a number of areas, but there is still the strong belief that a good software engineer is one that thinks in one particular way. Group-think is a problem. Having diversity of thinking and reasoning styles makes better software.
However, all that said, to quote Scotty from Star Trek: “Ye cannae change the laws of physics”. And so that means that we do have to be concerned with things like efficiency (if nothing else, efficient code literally saves energy). That means using the right (data structure) tool for the job and the best (algorithm) method for getting it done. You wouldn’t use a hammer drill to dig a hole and you wouldn’t start digging your hole by pouring concrete over the entire area — and this is why, despite my commitment to diverse thinking and reasoning in technology, we still need to get our heads wrapped around data structures and algorithms.