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

Sysems Analysis

[miyako]

I see a lot of negative comments here, and so I thought I would post something that his hopefully helpful.
Firstly, I have to say that a lot of the comments here should be heeded, Computer Science is a hard science, and is as mathematical as any other hard science, and more mathematical than some. In light of this, you should first think about you're statement that you do not care for hard science or mathematics. You may find that this is not true, instead you may find that what you really find is that you are primarily interested in those areas of mathematics and science which directly relate to computer science, and find it loathsome to be forced into required math and science courses which you do not see as directly related to CS. If this is true, then I urge you to push forward, you will often find that at the beginning of you're education, things seem disjointed. It is not until you near the end of you're education that those disperate elements of you're education begin to form a cohesive whole. If, on the other hand, you decide that hard math and science is not for you, then you should seriously consider changing you're major.
Computer Science is not the only technology related field of study, and it is not the only vector to working in a technology related job. I would say that you may consider looking into Computer Information Systems, which focuses less on algorithms and hard programming, and instead takes a look at how systems work together at a higher level, desiging those systems on that higher level, and resolving computer and business sytems into a cohesive and useful technological infrastructure for business. This will mean that you won't do much hard programming, though there may be some programming involved. Instead, as you expressed a desire for, you're focus will be on communication within a buisness. Writing documentation on the design of the system, interacting with people, departments, managers, and users. You act as a lieson between the developers and admnistrators and the business side of things.
I'm in a very similar situation as to yours, except I started out in CIS and realized that my interest in mathematics and hard science meant that I should have chosen CS instead of settling for CIS as my major. I'm getting ready to graduate this term and I have to say that I would suggest you don't make my mistake, and find the major that really suits you.
If analysis and design does not suit you, you may also consider other fields such as working as a technical writer, a technological reporter, or (if you're evil) working with marketing. There are a lot of areas where people need someone who can act as a translator between technological people and systems and others.

"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