Breaking down Amazon's mega dropdown

of course.

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.

Set up the submenu system so in the event of a single line, it presents an invisible target, which is three lines high, with the submenu in the middle.

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.

This is really fantastic behavior, but content - the actual list items they show - is much more important for user experience. Why should "Amazon Cloud Drive" be a "Department"?

In the wild, I suspect I would quickly glance at the top level items and decide that this menu isn't useful for me. If I were searching for something specific (presumably the main use case) I'd jump over to the search bar. If I were just browsing, I'd jump to one of the 100000 other random things to look at on the homepage.

Somewhat related: I wonder if they thought about varying the top level list items by user.