I took away the exact opposite - this is yet another example of not needing to know the right math. In the end, he can study up a bit and/or seek out a friend who does know, but be got the hack done without it.

This is how it works with my wife and I sometimes. I write a lot of code, and she either fixes or writes or advises me on the bit I need to work much better.

I admit we can't run the world or write good code without math, but some of us have strengths in other areas.

tl;dr my matrix algebra is fuzzy too.

First of all, "getting away" with something by relying on someone else to know what you don't know but need to use is hardly a virtue. If someone wants to work like that, to each his own. The problem I have is people telling the next generation that since you can "get away" without math, that it isn't important to take it very seriously as a programmer.

Second of all, like you said, you can get the "hack" done without math. I would say the less hacks you have to use in your programs the better, and the best practice is to code at a high enough level of generality that you don't need any hacks at all. Without math, so much time is spent (or wasted) tinkering around, and you don't often end up with the optimal solution. Whereas a strong math background lets you skip all that tinkering, because you are able to properly plan a solution before you even write a single line of code.

I think for programmers the constant state of learning (code techniques, browser quirks, new tools, new libraries, new algorithms) takes the edge off of learning "a bit of linear algebra" for one little part of your program. Would it help to really know linear algebra in and out? Sure, but that list of things worth learning is near infinite and the times you'll need linear algebra like this is quite small.

Web developer especially need to get their sea legs and be comfortable working on unstable ground all the time - it's inherent in the kludge we call web standards. So if you take a list of all the things a web developer needs to know to be effective, let's just agree "high math" isn't going to be near the top of that list.

There's something to be said about time investment. You're suggesting that tinkering takes time. If I want to keep current on all the math I learned in school, I'd have to invest a significant amount of time in addition to the time I already invest in keeping up-to-date with languages/frameworks/platforms/algorithms/datastructures/databases/etc.

How often would I use this level of math? I know I use the others on an almost daily basis. Coming up with something I need linear algebra for, though? Few and very far between. Maybe you use linear algebra often, but most of us don't have a need for it.

And if you disagree, then I think you should actually know abstract algebra, number theory, topology, etc., so that when the next problem comes along, you can 'quickly come up with an optimal solution'.

Sorry if this comes off as snarky, but I'm not sure of a better way to explain it. To me your comment sounds like:

"I have been walking through mazes my whole life with my eyes closed, and I make progress by feeling the walls with my hands. In order to get through each maze I need to remember lots of facts about how the walls in the different mazes feel when I touch them. If I opened my eyes now, it would take too much time, and be too painful to adjust to the light. I never tried to open my eyes, and even though a lot of people keep telling me it's a lot easier to get through mazes with your eyes open, I think they are wrong. Besides, the few and far between times I get stuck, I can always ask one of the people who can see where I should go next. And if you think I need to keep my eyes open, then the next thing you are going to tell me is I should use my sense of hearing and smell too."

Is that really the best you can do? That analogy has absolutely nothing to do with baak's point.

If you must reword and put his entire argument into a bad analogy, try this one:

"I've been walking through mazes all my life. This one time, I had to recognize a particular brand of poison flower, but I didn't know my flowers very well because flowers are rare in the maze."

And the answer?

"I asked my friend who was also in the maze: 'Is this flower poisonous?' He said yes. I said okay. We skipped the flower and moved on."

Pretty much this. Except you should also add that while he dedicated time to learning poisonous flowers that are encountered almost never, I spent that time getting in shape to move through the maze quicker, a skill/attribute used way more often.

Probably majority of most software engineering is "getting away" with it as defined in this context. Which is trying to accomplish a goal with imperfect knowledge about the methodology.

If the majority of someone's engineering involves concepts and tasks that one is 100% knowledgeable about, I'd argue that that person has reached a stale state and shoudl probably seek out other challenges.

Specifically, I'm NOT saying that math is not important.

I'm saying that there's nothing at all wrong with getting by with imperfect knowledge in a domain if the process of "getting by" means expanding your knowledge in that domain.

Everyone learns on the job. I don't see the difference between brushing up on linear algebra from school, and learning that new framework or language or software suite.

It's not a virtue to not know matrix algebra, but it's not particularly un-virtuous either. I have great respect for mathy engineers, but I also know the world needs its Jobs's and its Wozniak's, and it needs them to work together.

This is very wise +1

Absolutely not. Yes, you might be able to hack something with outside help but knowing math it is the mind set that would allow you to build something like this in the first place. You can imagine solutions to problems because you might visualize how they can be solved.

When you don't know what you don't know, you end up wasting countless hours trying to rediscover the solution to an already-solved problem. I know I have.

Two sides of the same coin. Whether you know math or someone on your team does, no good programming is getting done without it.

If your point is that it can be useful, then yeah, point made. If your point is that it is so useful that all programmers need it desperately, sorry, a single place where a more complex understanding of math might (we'll never know) have yielded a better product does not go anywhere near being a point to be made.

I loved all sorts of math while in school, have forgotten almost all of it, and have had to use almost none of what I learned in such a direct way as this. I definitely wouldn't argue that it's not important, but you are overstating it based on an outlier.

I find my math background to be extremely valuable in programming, but this is only sometimes because I use any actual math. Most of the advantage comes from being able to reason about abstractions more effectively. Similar to what you'd expect from a good CS background, which I'm sure most programmers would agree is useful.

While I agree that it's good to exhort one another to learn as much math as possible, I feel compelled to offer myself as a counterexample in the "getting away with it" argument.

My formal math education ended with calculus in high school (and college) and then probability in college. Never even took linear algebra, something I've always intended to remedy. I did rock Phil 160A, but that's not really apropos.

Anyway, on to the counterexample:

My first company was math-heavy, doing some pretty sweet web-scale analytics (in 1998!) pushing those matrices into SVD and then some crazy orthogonal rotation routines to make the results more human-readable. I was the only engineer for the first year plus, and the lead engineer for the lifetime of the company (1996-2002). One of the founders was a stats genius, old school, and he designed all of the analytics routines although I ended up implementing them. There is no way I could have ever approached his level, regardless of how much undergrad (or grad-level) math I had undertaken. If that company had been founded by a bunch of CS grads thinking "oh, sweet, I know some big data algos" I don't think we could have pulled it off. He had decades of psychographic analysis under his belt, informing all of our choices, and heading off any number of dead ends. But, even with my limited math, working with him, I was certainly able to implement the relevant bits in a performant manner.

My second company - which I founded - involves, essentially, zero math. (big surprise) Sure I know my CS algorithms and data structures and making educated choices like "should I use a bloom filter here?", but in the end our company deals almost exclusively in business processes that don't happen to need much math. And we're quite successful, with a great 10-years-and-going-strong history as a SaaS vendor.

Point being, there are tons of business problems that don't actually require big math to solve them. What they do require is a deep understanding of the problem space. If you're working on solving a real-world problem, and you've got some spare time, I'd argue that you are better off understanding every last frigging detail of that problem than you are doing some catch-up work in linear algebra. Sure, it may turn out that the solution you need requires sophisticated math - and, to your point, you may not even know that solution space exists if you ain't got the math - but that's secondary to the deep understanding in the first place.

Software is a big, complicated place full of layers upon layers of really complicated stuff. Some layers are full of math, especially when it comes to examples like the OP's. Other layers, however, are not - they are instead full of rules and processes that are based on RFC compliance and real-world knowledge ("oh, Exchange actually does it that way").

I, personally, think the OP took the right path in implementing a solution he understands rather than one which he'll never be able to debug down the road.

In this case the slope method is better and simpler than the cross product method.

    def slope(p):
      return (p.y-oldMouse.y)/(p.x-oldMouse.x)

    isInRange = slope(menuBottom) <= slope(newMouse) <= slope(menuTop)

My thought too. What are the supposed advantages of using linear algebra for this problem?

Edit: my guess is divide-by-zero conditions.

For the 0.1% case where he actually would have needed math, he got away with it and just asked a friend. Nothing wrong in focusing on the 90% of the 90/10 and asking for help if you're in that 10% part.