Choosing Careers in Technology?

Salandarin asks: "Until recently, I was convinced that my destiny involved a degree in CS, stemming from my love of video games. I've really enjoyed what I've found so far, and I enjoy the art of programming and the study of algorithms. However, from what I'm told, more advanced study requires a strong knowledge of mathematics. Mathematics, much like the hard sciences, are not my interest. Although I'm not ready to abandon CS just yet, I'm starting to examine other options. I enjoy the world of technology more than any other, and as such I would really like to stay here, no matter what field I choose. I am specifically curious about jobs that involve some form of journalism, writing, and/or communication, but I'm open to everything at this point. What other careers are available in technology, for a person like me?"

Comments

"Mathematics" may not be what you think...

[Jerf]

I can't quite tell where you are from your question; you could be a high-school-aged person getting into programming, or an early college student. I'm assuming that's true, as you probably wouldn't be asking if you were on the verge of graduation from college.

It is true that you need some good mathematical foundations to truly excel. It is also true that those who never realize this rarely make it much past "mediocre", by my admittedly-high standards. However, the math you need to be good at may not be the math you are thinking.

When most people say "math", they're thinking Arithmetic (the manipulation of numbers with few or no "variables"), some Algebra, and maybe Calculus. These maths are nearly useless for day-to-day programming, unless you are dealing with a clear and obvious exception, like game engine programming, writing a CAD program, etc. This is not to say they are completely useless; at the very least they are brain exercise of a calibre hardly attainable anywhere else, and that's nothing to spit at. But in general, this sort of math is not useful to programming, and you can be borderline atrocious at all three of those disciplines and be fine.

What you really need to be good at is "discrete math", which at best gets mentioned in high school cirricula as "sets" and then ignored pretty thoroughly after that. It's still true that what you do in the classroom doesn't bear much resemblence to programming (I've only had to do something even remotely like a proof two or three times in 10 years of programming), but the things they are trying to test you on do matter a lot. Think of it like the exercises you'll do on a basketball team or something; you're not going to do a lot of running straight to half-court and right back again 20 times in a row in a real game, but it's good exercise. And you can still be good at playing basketball even if you don't do the exercises, but you'll be better if you do.

Some examples of things that the discrete math theory will talk about that I find many people are very weak on:

• Understanding the "domain" and the "range" of a function, and thus how to manipulate the domain and range of the function, and to verify (at some level) that the complete domain and range are covered. Concrete example: For every function you write in C that takes a pointer, you need to know what happens when a NULL pointer is passed in, 'cause it will be, sooner or later. Maybe you choose not to write code to handle it, but you need to have thought about it and made that choice, not let ignorance or poor thinking make it for you. Failure to do so is a failure to consider the entire domain of the function.
• Working boolean expressions in 'if' statements; can you write the logical negation of (A&B)|(C&D)? Considering that's literally a homework problem, I've witnessed several of my co-developers screw that up in practice and then not notice, because the particular cases they tested happened to work right.
• On that note, a gut feeling for how treacherous discrete math constructs can be. If you've got an if statement working on 6 true/false values, you really need to be careful that all 64 combinations do what you expect, not just test 5 of them and call it a day.
• Understanding data structures, in particular when a tree is called for and when a graph is called for. (It's important to understand list vs. hash and a couple of others, but this is the one I see a lot of people missing a lot more often, and often it's not a matter of slowing the program down but of it being a buggy, fragile piece of junk, in a way a much worse problem.) In my experience, people start with trees, then badly kludge semi-graph-like features on top, breaking the whole system and ending up with something that still has all the complexities of a graph, but all the features of a tree, plus a couple, and usually buggy. They might as well have gone straight for graphs, but they are tricky buggers, which is why people avoid them in the