I'd definitely appreciate some 'next steps for the working programmer' that aren't a deep dive into math. What we need to be able to do is realize what sort of problem we're facing, how to describe it, and maybe what solutions might look like or where to learn more about them.
At a certain company, we were dealing with a limited number of phone numbers that could be used in on-line ads to get people to call for more information. Reuse the numbers too quickly and you wouldn't be able to track what people were calling about. Having too many idle numbers cost money.
Seemed like an interesting problem to me and it looked like "queuing theory" even if I didn't know the details. I suggested we could probably figure out a way to optimize our usage of the numbers. Blank looks and "let's just use 10 numbers per client and see how that goes".
I'm definitely someone who's wary of coding up a big, complex solution as the first iteration, so I could live with "let's start with a number", but I think that needed to feed into a further iteration using the knowledge we gained and a bit more thinking about the problem.
Adam Smith's words about specialization apply to programming too.
One of the best places I ever worked, I sat right next to a guy doing computer vision algorithms. He had a PhD, and was extremely smart and knowledgeable and fun to talk with.
He also wasn't the most... practical programmer, and I was able to give him a variety of suggestions about how to improve his code, and of course I had ideas about data modelling and web programming that he didn't know much about.
Neither one of us knew much about the details of the firmware, or the optics (mirrors and lenses and such) that another colleague was working on.
I guess the point is that for some of us, the point is that we're probably not good candidates to become domain experts, but knowing enough to find help is probably a good move.
Not learning math because it's not what you want to specialize in is self-defeating. It's like not learning to read and write, or save money, or communicate with other people, because it's not what you want to specialize in.
Math isn't a domain. It's the technique of abstraction we apply to any domain to make it tractable for computers, and it's the technique of reasoning we apply to any domain to figure out where our thinking has gone wrong. At least, any objective domain — except in rare cases, math isn't that useful for figuring out why your wife feels you don't love her anymore. But for you to program something on a computer, someone needs to mathematize it first. This can be done well or badly.
At a certain company, we were dealing with a limited number of phone numbers that could be used in on-line ads to get people to call for more information. Reuse the numbers too quickly and you wouldn't be able to track what people were calling about. Having too many idle numbers cost money.
Seemed like an interesting problem to me and it looked like "queuing theory" even if I didn't know the details. I suggested we could probably figure out a way to optimize our usage of the numbers. Blank looks and "let's just use 10 numbers per client and see how that goes".
I'm definitely someone who's wary of coding up a big, complex solution as the first iteration, so I could live with "let's start with a number", but I think that needed to feed into a further iteration using the knowledge we gained and a bit more thinking about the problem.