The Job the Wasn't There - A Lesson in Applying for Jobs

Hermione (made up name to protect her identity) was a student in my fast-track Web Developer class at SAIT in early 2017.  Like a lot of students I get in that course, she was anxious about obtaining work after receiving her diploma.

One day in between exercises, I showed the class several 'Careers' web pages of good, local web design companies.  One of those companies was Critical Mass, a company I had actually consulted with before.  I often recommend this company to students because they have a world class client list, they do internships, and I have experience with them.  That particular day, they happened to have an opening at the time for a Junior Web Designer, but no posted opportunities for internships.  I encouraged the students to apply for the Junior Web Designer opportunity and Hermione challenged me...

"How can we do that when we don't have all the qualifications in their list of requirements?"

I often get this question, and I had an answer. "You need to understand how a company creates a job description.  Many put it together as a list of qualifications for the perfect candidate.  Others will build the job description based on an existing successful employee in the company. They realize that most of the applicants won't match all of the qualifications - and this is particularly true in the IT industry. "

Hermione digested my answer, and piped up again. "But we're still in school and we have several more weeks before we'd be available to start working!  Does it really make sense to apply now for a position like this?"

"Absolutely!" I replied. "You never know what might come out of an application.  The hiring process for many companies takes several weeks.  There's usually a bunch of interviews for them to schedule and have, and then some planning and logistics around actually bringing the successful applicant aboard.  You never know what will happen out of an application."

She still looked skeptical.  I moved the class onto another exercise and didn't think too much more about it.

Several weeks later, I received the following email from Hermione:

"I took your advice about applying for jobs and I applied at Critical Mass for a 

Photo by Kaitlyn Baker on Unsplash

Junior Web Developer position knowing that I was NOT qualified and that they probably never call me back. Guess what? They called me back! They don't think I am ready for the Junior Web Developer position, but they want me to interview for their internship program. The interview is on . Which leads me to the crux of this email. Would you consider being a reference for me? And do you have any advice for this interview?"

I responded:

"Lol Excellent!  Good for you, Hermione.

Certainly I can be a reference (as a teacher) for you.

Probably the best advice I have for your interview is if you don't have the right answer, straight up tell them.  But then also tell them you'll have to answer (or know about whatever their asking you) tomorrow.  In other words, when you get home, you'll investigate it and get the answers.  

Bring a notepad to the interview and make notes about anything like that (so you look like you mean business).  Come with a couple of questions as well.  Research in advance anything in the job description you don't know about so you feel prepared.  Research the company a bit - know where their office is, ensure you can make it there on time, who are their current clients, some of the history, etc. 

Smile!  I don't know if you read my blog post about that, but smiling is HUGE.  If you can, try and get an interview somewhere else first to practice and get the jitters out (and maybe get a competing offer) 

Hope that helps!  Good luck!"

She replied:

"Thank you! I appreciate the reference and the advice.

I've been panicking a little, I really thought they would never call. I'm scrambling to get my portfolio site updated for the interview, as well as just get prepared in general. I do have a practicum lined up though, so no pressure...sort of."

In the end, Hermione got the internship.  She was nervous going into the internship because she didn't feel entirely qualified.  I told her not to worry and ask LOTS of questions.  She ended up successfully completed her internship and came out feeling better about it than she expected to.  It was a great lesson for her (and for me and all more students who I tell this story to) of how there are opportunities that you don't see in the job market.

EC2 and the AWS (Amazon Web Services) Free Tier - My First Experience

The Amazon Web Services Management Console

I had my first go-round with EC2 in AWS this last week in a real-life context.  I was teaching a class on Content Management Systems at SAIT, and I wanted my students to experience what its like to install WordPress and MySQL on a Linux VM.  I also wanted to personally get some experience with AWS, so I thought 'why not kill two birds with one stone?'

About 6 weeks ago I had purchased Amazon Web Services IN ACTION, written by Andreas and Michael Wittig and published by Manning.  It gave me a great primer on setting up my AWS account, my Billing Alert, and my first couple of VM's.  I leveraged that experience, crossed my fingers, spun up 18 VM's for my students, and hoped I wouldn't get charged a mint for having them running 24/7 for a few days.  It was a Friday around 1pm when I created them and gave them to my students to use.  Imagine my surprise when I checked my billing page in AWS on Monday and discovered they had only charged me $2.81!

I had clearly reached some kind of threshold as after that day I got charged, on average, about $8/day - for all 18 VM's.  They were charging me 2 cents per hour per VM, and some small data transfers.  Granted, I used a 'T1 Micro' - with 1 CPU, .613 Gib memory and 8 GiB storage.  Still, I was quite happy.

On the last day of class, I split the students up into two teams and gave them large web projects to do, and spun up a 'T1 Micro' for each team.  I gave them some scripts they could run to create some swap memory if they needed it.  They ran those scripts right away, and within an hour (with 9 people uploading files and content into those systems continuously) those T1 Micros CPUs pinned.  So I quickly imaged them over lunch and spun up an 'M3 Large' VMs (2 CPU's, 7.5 GiB memory) for each team and threw their images on.  I ran into one issue spinning up the new team VM's - I had to spin down the original Team VM's first before I could start the new ones because there is a limit/quota of 20 VMs on the 'free-tier' in AWS.   Aside from that and the changed IP addresses, the transition was seamless.  I was a happy camper and now that the students had responsive VM's, so were they.

My total bill for the week - $38!  A colleague pointed out that I probably could have added auto-scaling to those team VM's and increase the CPU and memory in place, without losing the current IP's.  He's right, I probably could have, but I didn't have the experience and didn't want to waste class time (and potentially lose the student's work) by trying something I didn't know how to do.  All in all, I was very impressed with my first run of EC2 in AWS.  It was very reasonable, responsive, and easy to use.  I'd definitely do it again.

The Perils and Pitfalls of OpenSource Software

Open-Source Software is the backbone of most of the internet.  Seriously.  For more than a decade, small business websites and main-stream web applications have used open-source software to develop their solutions.  Web projects (and frankly, most software projects in general) that don't have a dependency of some kind on an open-source component are the RARE exception to the rule.

Should we be concerned about this?  I think so.  Here's why:

1. Coders aren't implementing open-source code properly.  In my experience, any open-source code dependencies should be referenced locally.  Many coders fail to do this and reference external code libraries in their code.  What happens when that external 'point of origin' has a DNS issue, or is hit with a DDOS attack, or is just taken down?  Your site can break.
   
   Case in point - check out this article on msn.ca 'How One Programmer Broker the Internet'  In a nutshell, one open-source programmer got frustrated with a company over trademark name issue.  This developer's open-source project had the same name as a messaging app from a company in Canada.  He ended up retaliating by removing his project from the web.  It turned out his project had been leveraged by millions of coders the world over for their websites, and once his code was removed, their websites displayed this error:
            npm ERR! 404 'left-pad' is not in the npm registry
   I believe if developers had downloaded the NPM javascript libraries and referenced them locally on their servers, they wouldn't have run into this issue (as they'd have a local copy of the open-source code).
   
   Another case in point - I worked on a project a number of years ago that had dependencies on jakarta.org - an open source site at the time that was hosting a bunch of libraries and schemas for large open-source projects like Struts and Spring.  Some of the code in those projects had linked references to schemas (rules) that pointed to http://jakarta.org.  Unfortunately we didn't think of changing those links and one day jakarta.org went down....  and with it went our web site, because it couldn't reference those simple schemas off of jakarta.org.  After everything recovered we quickly downloaded those schemas (and any other external references we found) and referenced them locally.
   
2. Security  Do you know what is in that open-source system you're using?  Over 60 million web sites have been developed on an open-source content management system called WordPress.  Because it is open source, everyone can see the code - all the code - that it is built with.  This could potentially allow hackers to see weaknesses in the system.  However, WordPress has pretty strict code review and auditing in place to ensure that this kind of thing doesn't happen.  They also patch any issues that are found quickly, and release those patches to everyone.  The question then becomes:  Does your website administrator patch your CMS?
   
   Another issue I ran into related to security was with a different Content Management System.  I discovered an undocumented 'back-door' buried in the configuration that gave anyone who knew about it administrative access to the system (allowing them to log into the CMS as an Administrator and giving them the power to delete the entire site if they new what they were doing.  Some time later, I found out that some developers who had used this CMS weren't aware of that back door and left it open.  I informed them about it, and they quickly (and nervously) slammed it shut.   Get familiar with the code you are implementing!
   
3. Code Bloat (importing a bunch of libraries for one simple bit of functionality)  Sometimes developers will download a large open-source library to take advantage of a sub-set of functionality to help save time.  Unfortunately, this can lead to code bloat - your application is running slow because its loading up a monster library to take advantage of a small piece of functionality.
   
4. Support (or the lack of it)  Developers need to be discerning when they decide to use an open-source library.  There are vast numbers of open-source projects out there, but one needs to be wise about which one to use.  Some simple guidelines to choosing an open-source project are:
• How many downloads (implementations) does it have?  The more, the better, because that means its popular and likely reviewed more.
• Is there good support for it?  In other words, if you run into issues or errors trying to use it, will it be easy to find a solution for your issue in forums or from the creators?  
• Is it well documented?  If the documentation is thorough, or if there have been published books written about the project, you're likely in good hands.
• Is it easy to implement?  You don't want to waste your time trying to get your new open-source implementation up and working.  The facilities and resources are out there for project owners to provide either the documentation or VM snapshots (or what have you) to make setting up your own implementation quick and easy.
• How long has it been around?  Developers should wait to implement open-source projects with a short history.  Bleeding-edge isn't always the cutting edge.  Wait for projects to gain a critical mass in the industry before implementing them if you can help it.

Get Hired as an IT Newbie Part 2 - Soft Skills

I participated in a focus group this past week at SAIT where we discussed their 'Web Developer Fast-Track Program' and its relevance to the industry.  The goal behind the meeting was how can we make the course more relevant to the changes and continual evolution of technology that is happening in the industry so students are more prepared for positions when they leave.  The discussion was engaging and took some interesting turns.  Here's what I took away related to Soft Skills:

Soft Skills
Employers like student hires to be reasonably technically adept.  Their technical expectations aren't in the stratosphere.  However, they want their student hires to have more than just technical ability.  Students should be well versed in soft skills.

Soft skills is (to some degree I'm sure) an ambiguous subject for many students.  I can hear you thinking 'What do people mean when they say that??'  In the context of our discussion  yesterday,  it meant prospective IT employers in the focus group yesterday were looking for students to have, in addition to technical skills:

• An ability to communicate well with a client - verbally, directly in front of them or over the phone.  Also having the discernment to know when to send an email versus when to talk verbally.  Poorly written emails are notorious for communicating the wrong things - particularly negative feelings where there were none.
• An ability to know what good work is.  Does the design and function of a web site fit the purpose/company it was designed for?  For example, does a sales/marketing website have lots of good calls to action?  Does the site feel right?  Would 'Joe's Mom' know how to navigate and use the site.
• A can-do attitude.  Students will likely get the soul-crushing repetitive work that senior developers/designers don't want to do (or don't have time to do).  Students should accept this and be prepared to do it with gusto.  If you're in an interview and you don't have a clue about a technology they asked you about, reply: "I don't know about that, but I will know about it tomorrow" and mean it.
• An ability and desire to collaborate and work in a team setting.  Its a fact of the industry - if you want to work in an agency, you're going to need to be able to work on a team and collaborate with team members. 

Also discussed was: What habits should students have (or start to form if they don't have them)?

• Students coming out of school should love learning and know how to learn things/solve problems on their own.
• Students should be able to receive constructive criticism without responding with excuses about bad instructors, poor course material, or the speed at which things were taught.  You don't get much chance for excuses on the job.  Employers are looking to 'break even' economically on their student resource investment within 4 months.  

Get Hired as an IT Newbie Part 1 - Have a Good Portfolio!

I participated in a focus group this past week at SAIT where we discussed their 'Web Developer Fast Track Program' and its relevance to the industry.  The goal behind the meeting was how can we make the course more relevant to the changes and continual evolution of technology that is happening in the industry so students are more prepared for positions when they leave.  The discussion was engaging and took some interesting turns.  Here's what I took away related to portfolios:

Student Portfolios
15 years ago I had gone through a similar IT fast-track program and we had to do portfolios of our work for potential employers.  I wasn't aware of a single employer who looked at my portfolio and as
a result I haven't placed much emphasis on it in my classes.  BIG MISTAKE.

It turns out that prospective employers for SAIT students DO look at their online portfolios.... and generally weren't super impressed.  Here's why:

• Industry attendees said that a student's portfolio should reflect the position or career track that the students are looking to get into.  There should be evidence in the portfolio that the student tried on their own to investigate, explore, and work with technologies and code that interests them.  Posting student projects (with every student having very similar projects) doesn't help anyone in making a hiring decision.
• Prospective employers are not just interested in the technologies that students used, but also: 
• Thought processes that the students went through in completing their projects - why they chose to make certain decisions (for example, use a canned WordPress theme instead of design/develop their own)
• Challenges students encountered in design and development and how they overcame those problems in their journey to the completed project - Employers are interested in soft skills like perseverance,  the ability to google a problem and uncover a solution on your own, the ability to asking for help when you are stumped (not before you've tried googling the problem)... etc.
• Is the student willing to go the extra mile, put in some extra effort and explore interesting tools and technologies outside the classroom?  The industry was quite clear that this was one of the main things they were looking for  - a motivated individual with the right attitude.  This kind of motivation should be clearly seen in a student's portfolio.

There was also some suggestions during the focus group that students should be given the opportunity to provide constructive feedback to their peers on their portfolios.  A good critique is a gift.  Can students accept constructive feedback and use it to improve?  Could providing peer critiques give them a better perspective and more experience with what is good (design, code, functionality, etc.) versus what is not good.  We thought so.

Finally, here's a couple of links to student portfolios that 'make the grade' so to speak, in my humble opinion.  One was a student of mine this past semester, the other is a current student at the University of Calgary:

- Gary S. Jennings (former SAIT student)

- Carrie Mah (U of C student)

The Value of IT Certifications and Skills

After I've told my students at school how I finally managed to get a full time job in IT, they've asked me what I thought was the most important thing I did to get that job.  I've always answered 'getting my SCJP certification' (Sun Certified Java Programmer). It's been over 10 years since I started working at the job.  While I still maintain certifications are important for developers who are trying to break into the industry, I've become less enthusiastic about them and what they mean now that I have more experience. 

Having said that, I ran into a couple of articles today that I thought were very interesting:
15 IT Certifications That Can Get You a $100,000 Salary
30 Tech Skills That Can Get You a $100,000 Salary

Granted, the way these articles are written is 'just a little bit of' hype.  These skills and/or certifications aren't going to net you a 100k salary all on their own.  They need to be married with a resume that has several years of IT experience and related, well developed soft skills.

IT New Hire/Contract? Thoughts on IT On-Boarding

Being a contractor, I get to see and experience the on-boarding practice of different companies in different industries on a regular basis. This gives me an opportunity to provide a 'value-add' for the companies that I'm contracted with. Because of my fresh perspective, I can more easily pinpoint areas of opportunity for improvement in the first week on the job.

One thing that has always surprised me, and remained fairly consistent in all of the companies that I've worked with is that they don't seem to have the infrastructure ready for new hires.  I always seem to spend the first week doing one of the following:

• waiting for a computer or even a desk to sit at.
• waiting for access to my computer or to files, folders, applications, servers, etc.
• setting up/configuring my computer - installing required applications, setting up internal website bookmarks in browsers, etc.
• waiting for licenses for the applications I need to run to do my job.

I find this lack of organization dumbfounding.  HR knows that a new hire is getting on-boarded weeks in advance.  Similarly, the team/department should know as well.  I don't think there are any real good excuses for having new hires sit on their hands for the first week while everyone gets organized.  Bringing new hires on board should be a Standard Operating Procedure.

While I'm waiting for access or a license, I busy myself with looking for things that people with history at the company would view as the 'status-quo', but are really issues that could/should be considered problematic or improvable.

Opportunities like:

• Single Points of Failure.  (email server(s), monitoring server(s), shared drive(s), VPN access, etc)
• Lack of network segregation between environments (can I ping/telnet from a dev or staging server to production?)
• Misnamed or legacy names for servers or monitoring notifications that are understood by employees but a source of confusions for newbies
• Lack of templates for common documentation
• Lack of exportable outlook email rules that can be shared with the team
• Lack of exportable browser favorites that can be shared with the team
• Consolidating and organizing documentation (critical documentation in 12 different folders scattered through different directories is a recipe for confusion)
• Lack of Automation - continuous integration through to automating deployment.  Automating monitoring
• Preventing Fat-Finger errors (adding confirmation messages in start scripts)

Granted, not all of these will be applicable for every IT position.  Also, share your findings with your new supervisor and get his blessing before going and changing everything.  Suggest with encouragement, don't criticize! You don't to come across like your trying to relieve someone of their position.  You are there to make things better for everyone.

So, next time you are on-boarded for a new IT position, keep these things in mind.  Hopefully they can help both you and your new company.  Also, if anyone has some other suggestions of things to look for, please add a comment!

IT Professional - Know Thyself

What are you good at?  It pays to know - literally.  It will also make you happier and more productive on the job.

The more I work in IT, the more I see where I'm most effective. I also see in comparison where others blow past me in their individual skills.  It's important for multifunctional teams to have a good idea of different team member's areas of expertise.  Leveraging (knowing when and who to ask for a specific kind of help) these team skills can greatly improve the effectiveness of a team.

Here's some real life examples:

I'm rather weak on writing complex sql statements.  I can profile sql, and can get most sql work done.  But if I've got a difficult query I'm working on, I'll go ask my team mate who is an expert on putting together complex sql.  Later on, he'll ask me for help with a visual studio or server/service configuration related question.  Its a good, productive working relationship that keeps everyone happy.  The BA's are happy because the data looks right.  My PM is happy because my task was finished on time. And my team mate and I our happy because we both learned something and did it faster than trying to google for it on our own.

I'm great at problem solving software related issues - particularly in a domain I'm familiar with.  Whether it's missing permissions, configuration, network connectivity, everyone sitting around me will tell you I'm very, VERY persistent at solving problems that are brought to me.  My neighbor one cube west is fantastic at IIS/MSTDC/COM related bug/configuration debugging.   She also knows our software domain better than almost anyone else in the building - she seems to have it memorized.  When I have an issue with our software that I don't know how to fix, or a business related problem in the software,  I talk to her without hesitation.  Conversely, when she is stuck on an issue that she doesn't know how to solve, she will buzz it past me.  Again, a productive working relationship that makes everybody happy.  The business is happy they got their patch as fast as they did.  Once again our PM is happy, etc....

In meetings I will keep quiet and not say very much unless I feel there is an important point being missed.  I'm not super great at arguing a point.  I'm not the person that's always called on to go to a meeting to convince another group of people that 'our way is the right way'.  Part of this is my personality, part of it is my belief that there is multiple ways to get 'a good enough' answer for the problem we are looking to resolve.  However, we have another fellow in our group that will absolutely blow you away with his gift of logical persuasion.  He's the guy that gets sent to those 'convince the group' meetings.  On the other hand, I'm called on when diplomacy and a consensus is required.

Know what you are good at.  Seek to know what your team mate's strengths are.  Become a happier, more productive development team.

Newbie Advice

Having gone through an IT technical school, I realize they push a lot of information and technology at you. There's a lot to assimilate in less than a year (depending on the school). On this page I'd like to point out some technologies that perhaps weren't covered much in classes that are widely used by good shops in the industry, and also offer some career advice for the future. Before I delve deeper, let me say that this information is based on my experience, which is mostly on the Java technology side of the fence.

Technical Heads Up

1. Design Patterns. One thing many of the technical schools don't have time to cover in their curriculum is code design patterns. It doesn't matter if you doing .NET development or Java development, design patterns can really make a difference in organizing, maintaining, and the reusability of your code. A great book to pick up for an introduction on design patterns is published by O'Reilly and called Head First Design Patterns. If you don't have access to the book, a good place to start is to google some popular patterns that are being used in code now. Dependancy Injection is a pattern that is really big right now. Two frameworks that use it a lot are Spring and Google's Guice. Other pattern I've seen used frequently are the decorator pattern, the abstract factory pattern, factory pattern, the singleton pattern, and the proxy pattern.

2. Using a Repository. Using a repository, or a version control system, should be required by every development shop. Frankly, if you're in a company where they aren't using one, either push to get one installed, or start looking for another place to code. A repository is basically an application that functions as the premier source/bank/datahub/repository for all code. This application should be on a server with lots of disk space and accessable to all developers in the company. Repositories allow developers to manage code changes at many different levels allowing many developers to work on the same code base at the same time. Some repositories I've used in the past are Subversion, CVS, StarTeam, and Perforce. Googling any of these will give you more information.

3. Unit Testing. Unit testing is the development practice of coding 'tests' that validate individual classes or 'units' of code, to ensure they are functioning as required. This practice has developed over the past 4-5 years or so and has been found to be very effective in giving developers the confidence to refactor their code and ensure that it's functionality stays consistent over time. Some unit testing technologies are JUnit, JWebUnit, HttpUnit, DBUnit, and NUnit. 

4. Continuous Integration. Continuous integration is a process that automatically rebuilds and tests (with unit tests) an application or code base. Continuous integration employs an application like CruiseControl or Anthill Pro which is configured to automatically check out the code base from the repository, compile it, run it's unit tests, and sometime even deploy it to a test environment. It allows developers to check for integration problems in the code, and warns developers of broken code, allowing and reminding them to fix it ASAP.

Soft Skills and Career Advice

1. Change is GOOD. Once you've gotten your feet wet in the industry, being a Java developer in one company can mean something quite different that being a Java developer in another company. There is such a vast variety of Java technology that two Java developers can have quite different experiences in developing applications. Whole development processes and methodologies can be very different in differenct companies. One company could be flying by the seat of their pants, developing with not backups or repository, and manually pushing out code, while another is totally immersed in Agile methodology and outsourcing everything but development.... etc. Keeping this in mind, my advice is to not get comfortable in any one company but move around a bit - that is, after 18 months or two years at one place, get a different job. You'll be put into a position where you'll either learn a lot of new stuff, or you'll be mentoring. Either way, it'll be an experience that will likely teach you more then if you had stayed put. It'll also give you some motivation to brush up on your resume writing, interview skills, and expand you network. 

2. Walk & Talk While software developers, for the most part, end up working in cube farms, it should not mean that they need to stay in their cubby hole all day and do work. This may be just my style, but I find when I'm working on a big integration project or on a project with a lot of departments or teams involved, getting up and talking to people really helps things move along. Whether it's getting socializing a new means of managing your server configuration in the code base, or talking to a DBA about a script that you'll need to release with you new code, talking face to face is far more effective than emails, I've found. I generally use emails if I can't find the person, or I want to make sure there is hard documented proof about a decision that is being made, or if I want to include a bigger audience in my communication. Successful software development is more about relationships that a lot a people realize. Relationships are more apt to be cultivated face to face... plus it's good exercise.

 

Career Paths in IT

I've been teaching at SAIT again this week.  Generally before every class gets going in the morning I like to do a little 'blurb' on concepts or thoughts that aren't covered in the course the students get.  One of the things I find is that the vast majority of students (and the population at large for that matter) don't realize how many different career paths there are in just the software side of IT.  Guaranteed there are some students in the course that I teach who, by the time I get the chance to teach them, are very concerned they made the wrong decision by getting into software programming.  They don't feel like they are cut out for programming.  I try to put their fears at rest by suggesting that there are other opportunities for them - careers that can utilize the coding experience that they are getting, but allow them to use talents that they are more comfortable with.  Here's a list (by no means exhaustive) of some other opportunities in the software field.

- Project Management.  Project managers who have coding experience or at least a technical background are a step ahead of PM's who aren't techies.  I myself have considered taking some project management courses or getting my PMP, but thought the better of it after seriously thinking about what I like to do at work.  PMs need to have a great soft-skill set.  While I don't think I'd have a problem with that, I would missing troubleshooting/solving problems.  They also have to be politically savvy and have patience for meetings.

- Business Analyst.  BA's also need to have a great soft-skill set, as they need to be talking with everyone (the business, the developers, and the PM) and writing down the requirements.  It also helps if they are technically competent, and they enjoy documenting/writing.  For some reason in Calgary right now, there have been a lot of postings for BAs over the past 6 months. I just found out today that a variety of institutions offer certificates/diplomas for a Business Analyst career path. (NAIT and Mount Royal University are two local options)

- Quality Assurance.  This field has been growing a lot over the past 8 - 10 years, and frankly I don't think projects that I've been on over the past 5 years would have been successful without our QA teams.  QA experts need to have a penchant for detail and process.  They need to be able to understand the business and relevant business rules well.  Most of the QA people I've worked with haven't had a certification, but you apparently can get more info on a software QA certification here.

- Release Management.  This is what I (like to think I) specialize in.  We ensure that teams are using a continuous integration server and QA has the builds they need for testing where and when then need them.  We have two main goals: 1. Keep downtime in production to a minimum and 2. Keep lost man days in QA to a minimum.  I like release engineering because I get to see the whole picture - I have to understand the code and it's dependencies, I need to understand the infrastructure, and I'm responsible for the product getting through all the environments to production.  For me (being a bit proactive), this has also lead to automating deployments of database objects and datascripts, server configurations, and code, as well as installing monitoring tools to ensure that every environment is ready to 'rock'.

- Security Analyst.  These dudes make sure the good people have access to everything they need access to, and the bad people are locked out.  They spend a lot of time combing though logs and configuring IPSec rules.  They also perform software audits on code, all kinds of different tests on web sites, and network audits.  I wouldn't mind moving my career this direction in the future as they also need to have a pretty good idea of the whole system/infrastructure/architecture.  Great web sites for more resources on these types of positions are here and here.

Even more specialized positions:
- GIS (Geographic Information System) developer or architect or analyst.  Working with digital 2d and 3d mapping systems.  Having some limited experience with this at the ERCB (deploying mapping systems that display reservoirs,etc in Alberta) I think this is pretty cool stuff.
- Search Engineer (Search Engine Optimization specialist)  I've dabbled in this off and on for my clients.  You definitely need to be on top of your game and know how the search algorithms are changing.
- Business Process Specialist - there's lots of software to specialize in here.  Tibco, Agile Point, SAP, JDEdwards, etc.
- Document Management Specialist - Sharepoint, Edocs, Documentum, etc.  This involves the automated management of documents - not the writing of them, but their storage.  Government bodies and law firms definitely have a need for these kinds of systems.