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?"

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.

Electronics requires a solid math background

[blanchae]

A lot of people don't realize it but electronics requires a good solid understanding of mathematics. As you progress through the levels of electronics: technician, technologist, engineering technologist, engineer, the required math component increases.

If you are interested in technology, there's some fields of study that most computer geeks aren't aware of: Broadcast Electronics Technology and Telecommunications Technology. Both are typically 2 year programs at a technical institute. Broadcast engineers (actually technologists) deals with the installation, repair, maintenance , design of radio, television and video/audio production facilities. Here's a link to the Southern Alberta Institute of Technology's (SAIT) website on the Broadcast Technology [broadcast.sait.ca] program with a nice short video.

Telecommunications conjours up ideas of phone systems but it is much more than that. In 1996, a milestone occured in telecommunications. It was the first time that more data then voice was transmitted via the phone networks. Telecommunication is the backbone of the Internet!

Every ISP, MAN or WAN ends up running through the telecommunications system. Computer networking ends at the router where it connects to the phone system, then the data magically appears at the destination router. The movie Warriors of the Net [warriorsofthe.net] refers to the telecommunication's network as the Wild West where networking runs wild with little rules! Quite the opposite is true but it illustrates the point on how little is known about telecommunications from the computer industry.

Every residence, business and government office has a phone system and data communication network that connects to its head or branch office. There is a major convergence going on where cable companies are offering voice service and data service along with their cable service. Phone companies are offering data and video services on their networks including cell phones. It is truly an interesting era!

Here is SAIT's Telecommunication website [telecom.sait.ca] that I am currently updating to include VOIP and PBX labs based on Astericks software. And ys, I am biased as I am an instructor at SAIT teaching these disciplines.

Good luck in your search, I hope that this information opens your eyes to other possibilities.

Professional gamer!

[mnemonic_]

Seriously though... if you like writing, you could become a tech journalist. You know, like the guys who write for Wired, Popular Science, ExtremeTech, PC Gamer magazine etc. You could be covering E3 or benchmarking video cards and combing through the data. Or you might be at a future Apple WWDC reporting on Mac OS XI (eleven or "zye"?), or in Cambridge meeting some MIT prof about his flying car. Eventually perhaps you'll author a definitive history of SGI (it truly was an amazing company). I wouldn't call these serious "tech" jobs, but it sounds like you want to get paid to have fun related to tech, preferably involving journalism. Tech journalism would bridge your interests pretty well I think.

And hey, your /. submission was accepted, congrats. You're already published. Well, kinda.

"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

Re:Algorithms are mathematics

[bensch128]

If the only things you dislike are vector calculus and complex analysis -- hey, join the club. Fortunately, very little computer science needs those.

Heh, depends on what you want to do:
If you want to write accounting software and device drivers, then you don't need calculus, linear algebra or analysis. Otherwise, you better get on with taking the upper-division math and psyhics classes. I've been trying to read papers to understand new algorithms and I keep bumping into the problem of the writers using notation and mathimatics which are more complex then simple linear algebra and geometry. Basically, solutions to programming problems and algorithms become simpler and more elegant the higher the level of math you can apply to them. Eg. If you need to do a 3D engine, it easier to use matrics and quaturnians then simple linear equations. (Faster too.)

Also, corner cases can be generalized with higher math as well.

Cheers,
Ben

PS. I used the above example because a REAL cloth-simulation program (industrial strength) used simple equations to do all of the simulation and rendering work. It was a nightmare to look at.

Re:It's not the math, it's the maintenance

[jthill]

Standard qualifications for actual programmers: one part detective, one part historian, one part clairvoyant.

Working on IBM mainframes, I used to tell people I read manuals for a living. IBM have seriously good manuals.

A little math helps sometimes, but for the vast majority of practical problems the math is done; graph theory and Markov chains were fun, but I never needed them. More important is a feel for what's going on under the covers of your runtime library; Knuth's belief that you really need to start with assembler seems exceedingly strange to most people today, but in real life that's the nitty-gritty, not math. Maybe not start there, but until you understand at least one you don't really grok computers.

IT can be a real challenge; a good admin deserves serious respect. If you sit in front of a screenful of code and you don't feel your brain engaging, IT could be a good way to go.

Re:We are programmers because we don't like math..

[ndb82]

I think this is probably the most amusing explanation of Laplace transforms I've ever heard. Really, though, it's not that hard, was it? Every degree at my school requires differential equations, but you hear a LOT more complaining about infinite series in calc 2.