Career in IT?
- Thread starter Energize
- Start date
IT Support can be interesting and challenging, as long as you are 3rd line or above ... below that it can be soul destroying. How good3rd line is to work for will vary enormously dependent on who you are working for (which will then vary your responsibilities).
I'm always surprised though how poor the output of some so-called architects and consultants are though.
Personally I'm 4th line which means I do very little Support and quite a bit of interesting stuff
What's 4th line support? I thought that was usually "external" support - ie. working outside the organisation (ie. for a 3rd party software supplier, supporting an off-site software/hardware installation).
Which means you are really 1st line support for that 3rd party supplier...
They are far from long gone; a certain large education IT supplier ships the majority of its coding work out to India, among other things.
Whatever you do, make sure whatever IT job you get is different to any IT related hobbies you have, or you'll never do your hobby again.
I wouldn't recommend IT to anyone if they were setting out on a career path thesedays though, despite loving my job!
I wouldn't recommend IT to anyone if they were setting out on a career path thesedays though, despite loving my job!
Soldato
- Joined
- 10 Oct 2005
- Posts
- 8,706
- Location
- Nottingham
Nope.
In our organisation 4th line sits above 3rd line and Projects in an "Engineering" role. We take rare escalations from 3rd line but most of the time we are defining and documenting standards, reference architectures and cookbooks, reviewing (and rejecting!) architect's solutions for technical correctness and supportability, investigating new technologies and seeing if (a) we want to use them and (b) if they are supportable, and finally coming up with our own solutions for things.
Escalations are still made to external suppliers by 3rd line but we tend to deal with escalations where the cause cannot be tied to a specific problem or supplier. On the Unix side this is pretty rare, (I've been involved in a couple this year). Either that or Project has hit something and they are not sure how they should proceed ... at which point we can provide advice etc on how to move forward.
IBM doesn't take graduates on in specific fields, they come in on a graduate scheme which is designed to give them experience in as many parts of the project lifecycle as possible in a short time. Once you're through that it's up to you to find a project that suits what you want to do.
Thare are virtually no networking jobs in IBM itself these days, there are a handful of solution designers out there but everything else has been outsourced.
Soldato
- Joined
- 6 Nov 2002
- Posts
- 9,949
- Location
- London UK
We have a same sort organisation in our Company; they are not popular, too disconnected from the business needs and seem hell bent on justifying their positions by attempting to find fault with everything and slowing down anything productive.
Associate
- Joined
- 29 Jun 2004
- Posts
- 2,282
- Location
- Rainham, Kent
I've spent the past four months since getting my degree attempting to get my foot in the door in an IT role but getting nowhere.
Without sufficient experience you'll really struggle, it's the old catch 22 situation -
no experience = no job, no job = no experience.
Without sufficient experience you'll really struggle, it's the old catch 22 situation -
no experience = no job, no job = no experience.
Soldato
- Joined
- 10 Oct 2005
- Posts
- 8,706
- Location
- Nottingham
It is quite easy to be look on in that way but it is an important area as it prevent things getting into an absolute mess which then blows SLAs as well as costing large amount of money and resource time to sort out. You can't just make up large infrastructure projects on the fly and expect them to be supportable.
In the last couple of months I've has input into a SAN migration which decreased the Unix resource requirements to <5% of what they were originally and also been involved in developing an infrastructure to address our patching needs whcih will save significant time for Support.
We tend to only delay things when they haven't been designed properly in the first place (normally due to architects trying to avoid doing their jobs properly).
But we deal with infrastructures for a lot of different parties, not just our own, so it's slightly more complex than a normal single company.
Strange organisation, seems a bit disjointed. Surely it would make sense for the project team tasked with selecting and coming up with the solutions to encompass ALL the people needed to get the solution delivered (including reviewing it...installation, etc...)
Still I never really understood the hardware side of it all, certainly not why they seem to make any solution 100x more complex than it needs to be!
Soldato
- Joined
- 10 Oct 2005
- Posts
- 8,706
- Location
- Nottingham
Strange organisation, seems a bit disjointed. Surely it would make sense for the project team tasked with selecting and coming up with the solutions to encompass ALL the people needed to get the solution delivered (including reviewing it...installation, etc...)
Still I never really understood the hardware side of it all, certainly not why they seem to make any solution 100x more complex than it needs to be!
Not disjointed at all.
Solutions Architect does the high level design
Technical Architect does the detailed design
Projects Team implement
Support Team support
The Solutions Architect has a high level overall knowledge of a reasonable number of technologies where as the Technical Architect has more detailed knowledge in various areas and in the setup of a selection of Customer estates.
We just define what elements can be used by the Architects and how they can use them following the policies and standards set by ourselves and our CTO department. We also check that the Architects are doing what they should and that what comes out the other end will work and be supportable by making sure things are being implemented properly.
The Project team receive the hardware and software they require and implement as per the design with reference to our cookbooks on how to configure things. Once they have built the system(s) they then go through an acceptance process into support.
Moving too much into the Projects area has caused way to many issues in the past and led to things being agreed to and implemented which should have never happened. Particularly when the infrastructure may be being used across multiple Customers.
The Projects team will also being working on multiple projects at once for different project managers, (we have >70 solution/technical architects last I heard who produce a lot of things to be implemented).
Ah, it's *those* sorts of projects.
So the "projects team" are just dumb implementers of whatever has been designed. And then the support team just have to deal with the problems afterwards...
I enjoy meeting IT people with "architect" in their job title and threatening to turn them in: http://en.wikipedia.org/wiki/Software_architect#Architect_metaphor
So the "projects team" are just dumb implementers of whatever has been designed. And then the support team just have to deal with the problems afterwards...
I enjoy meeting IT people with "architect" in their job title and threatening to turn them in: http://en.wikipedia.org/wiki/Software_architect#Architect_metaphor
Back on topic...
Web development is really merging into "normal" desktop application development. Especially with the emergence of ASP.Net MVC (now on Beta 3, check it out if you haven't already). That combined with the MVVM style of WPF development, means that skills are now pretty transferable between the two.
There's more demand for just "developers" rather than "web developers". Developers are expected to be multi-faceted these days. I'd spend time learning WPF (much more complex than ASP.Net/MVC) and all the associated tools that come with it (such as Expression Blend, etc).
That's if you are not an idiot and go the .Net route, obviously.
Web development is really merging into "normal" desktop application development. Especially with the emergence of ASP.Net MVC (now on Beta 3, check it out if you haven't already). That combined with the MVVM style of WPF development, means that skills are now pretty transferable between the two.
There's more demand for just "developers" rather than "web developers". Developers are expected to be multi-faceted these days. I'd spend time learning WPF (much more complex than ASP.Net/MVC) and all the associated tools that come with it (such as Expression Blend, etc).
That's if you are not an idiot and go the .Net route, obviously.
This makes me wish i could actually move up from 1st line support!
Its about as challenging as Velcro shoes!
Just try avoid 1st line support all you can! You start and get stuck there and as stated earlier will destroy your soul!
Theres nothing more fun than been underpaid over worked and with no opportunities to work up or get training!
honestly? :/
Back on topic...
Web development is really merging into "normal" desktop application development. Especially with the emergence of ASP.Net MVC (now on Beta 3, check it out if you haven't already). That combined with the MVVM style of WPF development, means that skills are now pretty transferable between the two.
There's more demand for just "developers" rather than "web developers". Developers are expected to be multi-faceted these days. I'd spend time learning WPF (much more complex than ASP.Net/MVC) and all the associated tools that come with it (such as Expression Blend, etc).
That's if you are not an idiot and go the .Net route, obviously.
It's confusing trying to work out which areas to focus on, in a lot of web dev job postings I see list things like, .net, ASP, JAVA, SQL, MYSQL, C#, along with the front end markup/scripting languages, it seems that there is a demand for such a wide variety of languages from competing organisations, my uni web dev module focused on JSP and JAVA servers.
Soldato
- Joined
- 16 May 2008
- Posts
- 2,580
- Location
- Bristol
Best advice is to concentrate on the aspects of the job which are relevant regardless of the technology used.
Things like:
Good OO design skills, SOLID principles, etc (applies equally to C#/Java)
Good development practices; source-control, unit testing (including mocking frameworks), continuous integration, etc...
These are the sorts of things that are rarely covered in comp sci. type degrees...and if they are...I've never had a fresh grad. come in who is up to speed in any of them. They can all code...to a degree...but writing software is not all about churning out code.
Some links:
SOLID: http://en.wikipedia.org/wiki/Solid_(object-oriented_design)
Source control: git http://git-scm.com/ Mercurial: http://mercurial.selenic.com/ Subversion: http://subversion.tigris.org/
Unit Testing: http://en.wikipedia.org/wiki/Test-driven_development
Continuous Integration: http://cruisecontrol.sourceforge.net/ Hudson: http://hudson-ci.org/