Comment by hyperpape
7 hours ago
I studied math through college before learning to program as an adult and becoming a software engineer, and I strongly disagree.
I don't know how to say this in a way that won't sound insulting, but I don't mean it to be insulting. Programming, even systems engineering, is a surprisingly shallow field.
I don't mean that it's easy--it's not, it can be incredibly difficult. Difficult and deep are just different concepts. Difficult refers to how challenged you are. Depth, at least as it appears in math, is closer to a structure where concepts build on each other so that if you don't understand one concept, you can't understand further ones.
Programming can be difficult, and it can be intricate, but it is rarely deep in this fashion. Being deep in this way isn't the most important thing.
If I go into an area of programming that I don't have a lot of experience in (graphics, or the linux desktop environment), I will not be particularly useful, and it will not be easy. But I'll not experience the same type of impenetrability I experience when I try to read a paper on topos theory.
One more way of putting it: people are giving the example of TCP. You can spend a decade learning about TCP (or SQL semantics, or web standards). But what is happening is that you're filling in gaps in your knowledge. Meanwhile, in math, you do four years of undergrad, and even if you're a strong student at a typical university, there are topics that are still years away from you being able to touch them.
Computer science is a mix. Parts are deep, parts are shallow. Parts just are math. The odds that I can read a dissertation in computer science are decent. For math, they're much much much worse.
> Programming, even systems engineering, is a surprisingly shallow field.
I agree, and I don't think we should be at all ashamed of this.
The beauty of programming is that we can produce incredibly complex and powerful things by manipulating a small set of simple constructs together. There are only a few core tools--iteration, conditionals, etc.--but they can be snapped together into much more capable configurations.
Good programming is the art of deconstructing complex behaviour into these few constructs, and that's really fascinating.
I agree, and I don't even know math.
Most of things that are impenetrable in programming aren't about... programming. They are about some actually complex field like math being applied to programming.
For example, a library that does stuff with geometry. You need to know geometry to understand the program, but the program itself will never be complicated. It's the geometry that is complicated.
In cryptography, it's not the program that is complicated, it's the field of cryptography. In AI, it's statistics.
In graphics programming, math is the most impenetrable part, not programming anything. You can be a very good programmer in the sense that you know how to architect information systems and still fail to write a shader because shader programming requires you to know what a "dot" product is and you haven't heard about that since high school.
I'd slightly disagree. Here's an example of a programming task that is incredibly complicated:
Your job is to maintain and modernize a system while delivering a constant stream of new features. Your system is several million lines of code, with some multi-thousand line classes, a rulesengine that can trigger nearly unlimited effects at any time, a persistence system that's weirder than anything any of your friends have ever worked with, and hundreds of customers delivering tens of millions in revenue who use the system in incredibly varied ways.
You can't stop to rewrite the thing, you can't just throw features out there and pray, because you'll cause regressions and your existing customers will hate you. You have to fix the thing as you're building on top of it.
But where I agree is that there's no single deep concept that unlocks it all, it's not like you'll fix it by reading a textbook about it. It's complicated, and it's going to stay complicated, no matter how long you work on it.
[dead]