[TMNT]

As others have mentioned....

IT Security is where it's at. You will always have a job in that field and it pays big time $$$.

[M_Six]

Our university is constantly looking for IT sec guys. The ones they hire get some experience and training and then move on to much higher paying jobs.

[elusive303]

You should start taking general CIS/CS classes and see which classes you enjoy the most. Whether it be infrastructure, programming, networking, databases, security, etc. Then take it up as a hobby, work on improving and learning even outside of class. You really need to be enjoying what field you're getting into. It's best for long term success and happiness. As long as you become damn good in your particular field you'll make a good salary(except for doing helpdesk/workstation support type stuff).

Regardless of what type of IT you decide to do, you should still learn how to code. It really makes a big difference how how effective you can be at your job. Writing scripts to automate things and building tools is essential.

Try to get an internship or work study at your school's IT department. It's the best way to get your feet wet and experience a enterprise level environment. It's a great head start to get some real work experience before you even get your degree.

That being said +1 for security. Like e92_sid I'm also a security engineer and love what I do. Being in security forces you to really break down and understand many different aspects of IT. It's challenging and rewarding at the same time.

[radix]

Originally Posted by Brey335i

IT != programming.

The IT guys I know are clueless about programming and that makes us code monkeys very angry when they try to tell us how to do our jobs lol

Originally Posted by SehrSchnell

IT has nothing to do with coding. I'm a programmer, and I leave the IT shit alone... Also, that photo was f@cking lame.

There are several jobs in IT which you cannot do well without being a good programmer. I work as a Unix System Engineer.

You can't even properly troubleshoot an application without a working knowledge of Unix library and system calls (e.g. interpreting truss or dtrace output [hell, you can't even use dtrace really without some knowledge of programming]).

$ uname -a
Darwin macbook.local 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug  9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64

$ sudo dtruss ls /dev/null | tail -20

read_nocancel(0x3, "Jan\nFeb\nMar\nApr\nMay\nJun\nJul\nAug\nSep\nOct\nNov\nDec\nJanuary\nFebruary\nMarch\nApril\nMay\nJune\nJuly\nAugust\nSeptember\nOctober\nNovember\nDecember\nSun\nMon\nTue\nWed\nThu\nFri\nSat\nSunday\nMonday\nTuesday\nWednesday\nThursday\nFriday\nSaturday\n%H:%M:%S\n%m/%d/%Y\n%a %b %e %X %Y\nAM\nP", 0x179)          = 377 0
close_nocancel(0x3)              = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/LC_MESSAGES\0", 0x0, 0x0)               = 3 0
fstat64(0x3, 0x7FFF6EFED090, 0x0)                = 0 0
read_nocancel(0x3, "^[yYsS].*\n^[nN].*\n(\0", 0x12)              = 18 0
close_nocancel(0x3)              = 0 0
ioctl(0x1, 0x4004667A, 0x7FFF6EFED5F4)           = -1 Err#25
ioctl(0x1, 0x40487413, 0x7FFF6EFED5A8)           = -1 Err#25
getuid(0x10F3F335D, 0x7FFF6EFED5F4, 0x7FFF6EFEDCB8)              = 0 0
stat64("/dev/null\0", 0x7FFF6EFED4C8, 0x1)               = 0 0
open_nocancel(".\0", 0x0, 0x0)           = 3 0
fstat64(0x1, 0x7FFF6EFED1E8, 0x7FFF6EFED2AC)             = 0 0
fchdir(0x3, 0x6, 0x6)            = 0 0
fchdir(0x3, 0x10F418A00, 0x1B200)                = 0 0
close_nocancel(0x3)              = 0 0
write_nocancel(0x1, "/dev/null\n\0", 0xA)                = 10 0

For instance, what does fstat64(2) or getuid(2) do? If your application isn't working properly you might want to know what these things do. Say fstat64(2) reports Err #2. What does ENOENT mean? On most Unices the answer can be found in the comments in /usr/include/sys/errno.h.

Say you need to do a stack trace on a core dump to figure out where an application crashed and for what reason (e.g. SIGSEGV). Where do you find out what the hell a SIGSEGV is (Segmentation violation [/usr/include/sys/signal.h])? Of course you wouldn't really know that if you didn't know anything about programming Unix.

Performance tuning at the application level using profilers like tprof also require a working knowledge of Unix library and system calls.

Or take information security... how can you tell if an application is vulnerable to a buffer overflow exploit or format string attack if you don't know the difference between a scanf(3c) and and fscanf(3c). Being completely ignorant of good programming practices means you couldn't possibly be useful in a code audit.

[radix]

A good example of what I mean about IT security:

http://insecure.org/stf/smashstack.html

if you work in IT security and you can't understand what this paper is telling you, then you shouldn't be working in IT security.