please could you take a moment to read my question.

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Usually depends on the experience level of the individual. Ever hire someone to do the above things who didn't know what they were doing? They typically fail. Then the company has to call in someone who knows what he/she is doing to undo what the first person did, then complete the project.

Oh my goodness. I honestly can't believe you even have to ask that question. It's changed a LOT. Back when I started in IT a little over 10 years ago, things were so different. Now we've got malware, AD, SANs, virtualization, and a slew of wireless technologies used for different things. No more Windows NT, Windows NT Workstation, Windows 95/98, OS/2 Warp, or Novell 3.11. Where we once used dedicated links, we now use tagging over a shared medium. Where we once used dial-up connectivity, we now have broadband. Where we once sent things in the clear, we now use encryption. Firewalls were almost an afterthought in 1998; they're absolutely required today. We used to travel from site to site to fix things; now we can administer from the other side of the world.

Just think of *everything* we can do now that we couldn't do back then. We still have to learn *how* to do all that stuff.

You've never discussed an infrastructure project with your typical CEO, have you?

"I want to implement Buzzword. It'll save us tons of money!"
"Sir, we can't implement that technology - it's incompatible with our systems and our software."
"Nonsense. Make it work, or I'll find someone who will!"

You may not think scope creep and delays happen with infrastructure projects... but they do, all the time. Many drag out forever. Some don't drag out forever only because the bosses start requiring admins to work round the clock to get a project done. Happens all the time for projects that require that the user be logged off... so the poor admin has to support the users all day, then when the users go home, they stay up all night to implement something... and pray it all works when the users come in in the morning so they don't have to work 48 or 72 hours straight.

As a network admin, I had to learn new methodologies/ideologies every week.

You might think so, and you might be right. But at the end of the day, you work with a few technolgoies and few apps, including the ones you are creating. We work with all the others. They don't install themselves, they don't implement themselves, and they don't administer themselves.

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Just to tack on to what BM said....

In the short time I've been around I've seen job requirements change drastically. It used to be that a database admin would do just that, administer the database. Now a database admin has to know much more. Most DBA positions now require a thorough understanding of SQL, performance tuning, and if you're in the open source world a good understanding of perl, python, and possibly even some C/C++ because stored procedures are written in those languages in Postgres.

As far as system administration goes technology in this area moves very rapidly. I'm in a small environment and I have to understand at least a dozen different technologies, as well as research and try out all new technologies we are looking at for the future.

Like I said, programming takes a very in-depth knowledge of basically one area: development. I agree that it's a very difficult proposition to do well. But, it's also a very difficult proposition to keep up with multiple technologies at the same time. The requirements for each area are different, but both require constant commitment and learning to be successful. The system admin just has to learn a far wider variety of things than a programmer does.

Also, it's no secret that most places don't really consider a person to be really vetted as an admin until they have 5 or 6 years of experience. That's the same amount of time you say it takes to become a competent programmer. There's a reason that the time frames are very similar. It's because the learning requirements are very alike as far as the amount of knowledge that must be attained. A person can only stuff so much into their brain at a time, and it doesn't matter if that's knowledge of programming or knowledge of systems.

Try programming something critical in Java on Monday, having to do the same in C on Tuesday, exploring a language new to you on Wednesday and having to implement it on Friday at the same level you worked at in Java and C. All the while you are having multiple interruptions that take you away from your main task. Most programmers I know would just throw their hands up in frustration and ask how they are supposed to get anything done when they have to switch gears all the time. Well, that's the every day life of the systems admin. It's multi-tasking taken to a very high level for most admins.

 

I didn't say infrastructure projects never fail, only that they don't fail as often or on as large a scale. The fact that you are basically assembling and configuring largely known components that have 1000's hours of testing significantly de-risks the project, this doesn't happen to the same degree with software.

Yep theres been a lot of changes, I'm well aware of that. However some aspects have changed little, Oracle and TCP/IP is still very recognisable, if you learnt TCP/IP v4 and SQL 92 that would last you for 10+ years no ?

Yes I have.

Again I didn't say they never fail, just the likelihood of failure is lower and when they do the typical IT project an admin will be involved in will probably fail in a less spectacular manner on average.

Theres been many numerous foul ups by EDS for instance in various systems, however these are not your run of the mill infrastructure project for a corporation.

Well I can think of RUP, SSADM, WilfsBrook, ShaleorMellor, Agile/XP, DSDM, Yourdon, UML, OOAD, Booch/Grady, RAD, Scrum, Prince2 and a few more.

Now for admin theres maybe ITIL ? Ok now theres various compliance initiatives like Sarbanes-Oxley etc but I've worked in environments where I'm also expected to know all of these too...

The systems I work on also can have many components that you would recognise, as well as lower level ones that you might not. Identity Management, Relational Databases, LDAP, PKI, E-mail, ESB, DTC, ORM, various parsers and compilers, Web browsers, Web servers, firewalls, load balancers, web proxies, content caches/Edge, CMS, DMS, CM, BI, Reporting, Metrics, Portal, Workflow, ETL, virtual machines, calculation engines, CRM.

Thats just for my current project, i've encountered a lot of other stuff on other projects. Not all programmers can live in a box and just focus on one routine any more, thats if they ever did...

 

Computer programming or system administration requires constant steep learning especially as technology evolves and changes so frequently.

At work we have started building a SAN believe me it is like trying to solve a jig saw puzzle and requires expertise from outside to configure and setup why we have to learn fast to get a hang of things.

To be honest anyone in IT that does not keep up with the changes in technology relating to their field of work would become obsolete its as simple as that. So yes programming or system administration both has their stress pointers in terms of having to keep up with constant learning of new technology.

 

The point is, that neither can the system administrator. We have the same type of learning curves, only they have to done on-the-fly with constant interruptions to go handle something else. The fields are different, there is no mistaking that, but at the same time, different isn't always easier. As I pointed out earlier, the time periods before people are normally considered to be a "journeyman" in their chosen fields are the same for both system admin and programmer. That ought to tell you something about the learning required in both areas.

Funny thing is, in the HVAC and Refrigeration service industry you're not considered a journeyman until you have at least 10 years of experience. The computer geeks look at that area and think their job is much more technical and harder. But, having been in both the computer and the HVACR business I can tell you there is a lot to learn in both fields if you want to be really good.

 

You don't think so; being in network administration and seeing tons of failed projects, I disagree.

"Assembling the components" isn't where network admin projects fail, mate.

But Oracle and TCP/IP are such a small portion of a network admin's job responsibilities. If you learned TCP/IP v4 and SQL 92, that would get you just about nowhere in 10 years. To be a network admin, you have to know that... and about 1000 other things. If you can only subnet and run SQL queries... you won't be able to be a network admin these days.

Freddy's right: a programmer has to focus on one thing: development. That one thing is HUGE, yes. A network admin has to learn a thousand little things. Just as difficult... but in a different way.

Then you would agree that infrastructure projects quite often fail due to a misunderstanding (or complete lack of knowledge) about a technology, right? If not... you haven't spoken to many CEOs about many infrastructure projects. I worked as a consultant who performed IT services for a variety of companies (cleaning up behind techs who didn't know what they were doing), and I've seen the slew of CEOs who think they know about technology (who demand the impossible).

So... spending millions on a SAN failover project and having a paper admin mess it up... I don't guess that's failing spectacularly enough for you, I guess.

Ah, yes, those ARE your run-of-the-mill infrastructure projects. What do you think we do all day, eat donuts? What do you think a run-of-the-mill infrastructure project is? Rolling out a dozen PCs?

Methodologies for programming have nice little names. Methodologies for network admins are what we do on a daily basis... a method for rolling out software... a method for rolling out hardware... a method for malware control... a method for locking down a network... a method for troubleshooting a failed network... or a failed device... or a failed piece of hardware... a method for file storage... a method for server access... a method for AD implementation...

Dude... that's just a LITTLE bit of what we have to consider on a daily basis.

Amazing! We work with the majority of those too! And more!

Dude, I'm not saying that network administration is harder, and I don't believe I could change your opinion. I'm saying that you shouldn't discount it because you think we aren't handling AS complex a job as programmers are. Cause we are, mate. You might not understand what we do... but it's just as difficult.

BosonJosh worked as a network admin, then as a programmer. I eagerly await his viewpoint on the matter, as he's probably one of the few here who can truly weigh in on this topic with authority.

Never said programmers lived in a box. But neither can admins live in a box and focus ONLY on TCP/IP and SQL anymore...if they ever did. ;)

 

That's very much how it is. Rep given!

 

Ok we indeed don't seem to be getting anywhere so this is the last I will say on the matter.

At last something we can agree on ! By the way are you from Oz ?

Maybe not, thats my point you will at least end up with largely functioning infrastructure no ? How often are completely the wrong bits of kit bought ? How often is 100% of the project canned including all assets ? This is not a competition, I think you should be proud to work on more successful projects.

My point was that while there may be hiccups infrastructure roll outs largely seem to succeed, I was talking about failed traffic control centres, national databases and back end settlement systems spectacularly messed up by EDS. I do not think the largest single factor in any of these was infrastructure.

That was exactly my point, in some areas the seperation can be artificial, sometimes I write install guides for admins, sometimes they write them for me.

I'm not discounting your work or intelligence, merely indicating I feel infrastructure probably has a 'smoother' career path shall we say. Also again with the mateyness...

I work with architects that have diverse backgrounds, one is currently working on a major infrastructure project, hes has been a programmer in the past. Heres a quote from him :- 'infrastructure is easy', now I don't necessarilly agree, but I do respect the guy and he has 20 odd years of good experience, so that opinion does not seem uncommon.

 

No - I'm a Merican!

mmm... No. That's the point. You can end up with a largely non-functioning infrastructure... and if you want to just "go back to the way it used to be", it'll usually end up costing the company huge.

I can't give you statistical data. But the wrong bits of kit are bought quite often. iSCSI SAN? Oops... you bought a fibre switch. Gonna have to purchase a compatible switch! Oh, great, here's the new switch... wait, you expect THAT much throughput? Should have gotten a fibre SAN...

New AV? Wow, it's great... problem is, it won't run on half the computers in the company because of all the LOB apps running on it consuming system resources. Gotta upgrade them all. Oh, look, here's our new PCs. Hmmm... wait a second... I'm getting errors with one of our apps... oh, crap, they're not compatible with Vista... let's install XP. Uh-oh... there aren't any XP drivers for this new hardware...

All... the... time... particularly with techs that don't have enough experience. And we're ALL there at some point in our careers.

I *did* work on successful projects. That's because I often came behind techs who *didn't* know what they were doing. I've seen the aftermath after the "old IT consulting company" was dismissed and we were called to fix the problems.

My projects weren't the problem.

Your experience is different from mine. I've seen plenty of infrastructure projects fail.

I haven't seen any programming projects fail... but that's only because I haven't worked with a bunch of programmers. Just about the only place I've worked with programmers were the in-house programmers at Transcender and Boson... and those projects worked.

...uh... does it bother you?

I have no idea which is smoother. I only see the networking side. The last time I programmed anything was in a national BASIC computer programming competition. So I couldn't tell you which career path is smoother. Nor can you, if you've never worked in network administration.

Again, I would like to hear Josh's opinion, as he's worked both sides.

I guess it depends on his definition of infrastructure. If, like you, he believes its just connecting wire A to port B, then yeah, infrastructure is easy. But network administration is much more than that.

 

I'll add my 2 cents onto dmarsh's and BM's points.

"I work with architects that have diverse backgrounds, one is currently working on a major infrastructure project, hes has been a programmer in the past. Heres a quote from him :- 'infrastructure is easy', now I don't necessarilly agree, but I do respect the guy and he has 20 odd years of good experience, so that opinion does not seem uncommon."

"infrastructure is easy" Maybe he's just got the experience and skills that make his job easy to him. Plant someone else in that role, and I'd suspect they'd have a different opinion. In fact, YOU try to do that role and see how "easy" it is.

As someone who's done both programming and network administration, neither is "easy" to someone who doesn't have the aptitude for it, and neither is extremely difficult to someone who does have the aptitude for it. Both have their own challenges (and their own rewards).

I've seen infrastructure projects fail, and I've seen programming projects fail. To say one is easier is minimizing the impact that each role has. Both are necessary, and both are rewarding.

Whether network admins have a "smoother" career path is debatable. In either career path, a reasonably intelligent person can perform "passable" work in either field within 1-2 years. But, you would not be truly proficient at that job in 2 years unless you're doing the same mundane tasks each day. Then, yeah, it probably would get pretty easy pretty quickly. But, who would want to do the same job day-in and day-out?

Back to the OP's question. Picking one or the other based on salary would be ridiculous. You'd get burnt out on either one if you're not passionate about it.

 

...and I think that nails it!