Why is it taboo to study both Networking and Programming?
I am MCSE 2000 certified and have an AAS Programming. Currently working in a Call Center I am curious as to why the two different departments do not work together.
I have found the networking department does NOT like you studying programming yet most of the networking errors are in the programs. Isn?t it wise to learn a little of both so that you have knowledge as to what causes certain errors and whether there is a quick fix for the problem?
I understand the divisions of IT are completely separate, but shouldn?t they work hand in hand?
they are both huge fields. It's like studying civil engineering and electrical engineering at same time. They might have a few courses in common but pretty much totally different and wouldn't do much good study both, as you wouldn't use on same jobs.
Sure you can detect bad programs that overload net but you didn't write those programs if you are the network guy detecting overload. If you did you were too busy to be messing with the network infrastructure or running packet sniffers, except maybe testing function could have some crossover.
The "master of none" fear.
You'll find this not only accross fields, but within them.
NOBODY trusts someone who says that they know both the "C" family and the "VB" family.
There are a FEW folks out there that can master both, but it usually means that a person is good at one, understands the other and has mastered neither.
The FEAR that you are coming accross is that you will pick up JUST ENOUGH knowledge to be dangerous.
The old addage "A little knowledge is a dangerous thing" is absolutely true in our field.
In the corporate world, mostly, the disciplines are cealry defined - but lower down the scale, in the world of the SME, where more than likely if they *have* and IT dept, it is one man responsible for everything.
In my own present role, for example, I wrote all of the internal core IT software systems, replaced the original Macs with W2K server and XP workstations, even physically installing the LAN infratstucture.
Looking at other replies, I could be accused of being a 'master of none' which would probably be true - however 'a little knowledge is a dangerous thing' is certainly not - If I know enough to know that better specific expertise than I have is needed, then that resource is bought in as and when needed, or advice sought, like on here, for example.
My guess is that your supervisor or enterprise is the issue. It's certainly not the market.
Could not agree more. I found at my last place of work that it held me back, as because I had a knowledge of both areas, I found myself in neither department, but was instead stuck in the same support department for over 4 years. I in effect made myself "too" useful to the support department.
I find that knowing both tends to get you into trouble because in the end someone feels undermined that you are doing their job. Granted knowing both sides of the fence does improve efficiency and is a huge benefit towards the company. Just, when you take matters into your own hands and go against another department wishes for the common good of the company then there is **** to pay. I guess it comes down to job security and self worth.
Information hoarders don't like their wellsprings tapped.
Specialization is another way to implement the time-management technique of giving a task to the one best qualified to do it. The benefit is that it gets done faster once it is started. The cost is that your resource may be overloaded, and a person who has time to do the task is twiddling their thumbs. So, it isn't a question of who can do it, but rather who should do it. That is why you give network tasks to the network team, and programming task to the programming team.
This is different than hoarding information for job security, which is definitely a bad thing with respect to continuity, auditing, and training!
Because programmers hate IT because we never allow their network traffic heavy applications into the production and IT hates programmers because they roll out buggy code that isnt properly tested and those of us on the front line have to deal with it.
If you are in IT then you definately need to know how to script, a form of programming...I guess. Lol.But as far as programming for a solution solver isnt really the answer. Its faster to reinstall the application to sit at the customer's desk going through code for an hour.
In a perfect world programmers will work side by side IT so that the code gets properly tested and rolled out on time.
programmers wouldn't be plagued by business groups constantly shifting requirements, changing specs, demanding that a six month project be delivered in three weeks and having to clean up the 'outsourced' project that doesn't do half of what it promised and has error messages that look like they were written by elmer fudd.