Archive for the ‘Career’ category

In Praise of Maintenance Programmers…

July 2, 2010

I know this is supposed to be a blog about development, but I want to spend a few moments in praise of a group of technologists often overlooked in the discussions of software development: maintenance programmers.  There has been much discussion about “rock star” developers, particularly from Joel Spolsky at Joel on Software.  And that’s great.  Any discussion that raises the social standing of programmers is a good thing!  But I want to talk about the unsung heroes of software development and IT – the maintenance programmers.

First, a confession.  This topic is slightly self serving, in that in my new day job, I am now a programmer in the maintenance group.  In fact, my recent trials and tribulations at work made me really appreciate how hard maintenance programming really is and how the skills essential to maintenance programmers are a little different than a developer.

The Obligatory Star Trek Reference

Using Star Trek as an example, I see developers as the Starfleet Engineers who build the starship and the maintenance programmers as the Scotty’s of the world.  Think about it – Scotty is always enlisted to perform miracles to make the ship work because Kirk (the user) wants it to do something it was never designed to do or has messed it up so badly that it needs heavy duty maintenance.  And Scotty usually has to perform these feats of miraculous engineering under extreme time constraints or without key personnel or resources.  Sounds like the kind of day I had every day for the last week and a half!

Obviously, Star Trek is fictional because Scotty always gets the accolades and praise…when was the last time maintenance programmers got praised for working diligently to fix a problem?  Usually it’s, “That’s nice, now here is my list of another 20 things for you to fix…”

Skills Essential for a Maintenance Programmer

  • Ability to Read and Decipher Someone Else’s Code – It goes without saying, that most of the time, maintenance programmers don’t actually write the code they have to support.  Nothing says you’re going to have a day of fun like digging into a steaming pile of…code.
  • Ability to Be a Forensic Scientist – Not only do you have to be able to read the code, you have to figure out how it actually works in the REAL WORLD.  Developers rarely see their code live in the world and don’t have to worry about pesky details like when the database table is locked because one process is doing something while another is trying to update the same table.  You have to make friends with every kind of debugger/trace tool that you can lay your hands on so that you can do a little CSI work on the culprit (the problem).
  • Ability to be Sherlock Holmes –  Hand in hand with the CSI work, you need to be able to logically deduce what is happening from the (hopefully) piles of evidence you have discovered.  Remembering that when you you have eliminated the impossible, whatever remains, however improbable, must be the solution,  goes a long way in maintenance programming.
  • Dogged Persistence – You have to keep beating your head against the problem until either you win or the problem miraculously disappears.  This is where the rubber meets the road…you’re the one who has to get it working for the users.
  • Being a Jack of All Trades -While it’s great to be an expert in a development language, once that code hits the real world, it is likely interacting with any number of other things out of your control (like it might have been in development) – like web services, networks, databases…you name it.  Knowing at least something about all of the elements of helps give you an appreciation for all of the possible areas to explore.
  • Intuition – Sometimes intuition is the best tool for trying to figure out what is happening.  This is sort of an addendum to the previous skill.  When you’re grounded in a varied background, you begin to make connections and improve your  intuitive skills.
  • Patience – You really need to have the patience of a saint to keep from going crazy.  Each roadblock that’s thrown up by the code or the production environment has to be either worked around or driven over.

The Stigma of Maintenance Programming

But let’s face it, maintenance programmers don’t get treated the same as developers.  Why?

  • They are not perceived as being able to grasp new technology – Maintenance programmers may seem like they don’t “get” new technology, but I don’t think that’s universally the case.  In my limited stint as a maintenance programmer, I have to understand a wide variety of things – XML, web services, C#, Java, JavaScript, SQL Server, and mainframe JCL to support the applications.  Sure there’s old technology, but there’s a good chunk of new technology that I have to learn quickly.  And usually without the training that the developers got so they could figure out how to develop the system.
  • Keeping things going is not as glamorous as building new stuff – This is universal it seems.  This happened at a previous employer. I’ve had co-workers and friends that never seemed to do well and weren’t looked on favorably by management because they went about the job of keeping things going silently and efficiently.  I know that some of peoples were on the list of people to be downsized because they weren’t producing new exciting work.  But they kept the business going.  If it were my business, I would have hired them without reservation because they were model workers.  Yet somehow, the idea of doing what’s needed to keep the business going is not as important as producing new things.  I don’t care how many new systems/products you develop, if you can’t execute on a day to day basis, it just doesn’t matter.
  • They are not “real” programmers because they don’t create anything – That’s simply hogwash.  Maintenance programmers are usually the ones who have to extend/recreate/totally rewrite the original application when the business needs (or the user’s minds) change.  They are the ones usually stuck with refactoring – now that’s a REAL programming task.

What Can Be Done to Fix the Maintenance Programmer’s Lot?

In reality, probably nothing.  As a business culture, we only seem to care about the next new thing.  I realize that business can’t just stay focused on doing the same thing all the time, but if you don’t have stable, dependable systems, all the new development work in the world is not going to keep the business going.  So, here’s my wish list for what could be done to help maintenance programmers:

  • Recognition for the important work that’s done – Sure, there might be some sort of celebration for a new project that was completed, but how about some sort of recognition for someone who finally fixed a long standing problem?  Came in in the middle of the night to get the jobs running?  Yes, I know it’s part of the job, but you know what?  So is delivering a project if you’re on the development team.  A little recognition would could go a long way.  It doesn’t have to be an elaborate thing: an email to the group praising someone’s efforts or a mention at a staff meeting. Although food is always good!
  • Rotate developers and maintenance programmers through projects – I think it would be great if one maintenance programmer could join a specific development project, while one development programmer took a tour of duty as a maintenance programmer.  I think it would have very many positives – maintenance folk get in on the ground floor and get to build something , they get to see the struggles that developers have in trying to create something from nothing, and they may get a chance to pick up a new technology.  Developers get to see what it’s like to have to support code over the long haul and deal with the inevitable changes that occur as the software is let out in the wild.  This may help inform their development choices later…especially if they know they may have to support it at some time.
  • Make sure that maintenance folk get the same training opportunities as developers – How many times have you seen this?  A new technology comes in and the people who are going to implement it get training.  Down the road, they move on or the system moves to the maintenance group…who now have to figure out how to support or even change this thing.  But there’s no training for the maintenance group because the company has already spent enough money training people…who are now completely consumed doing something else and have no time to help.  If it’s important in enough to train people to develop with a technology, it’s just as important to train the maintenance people!

So to all my fellow maintenance programmers out there:  keep the faith and keep doing what you’re doing to keep things running!

My Ideal Job

August 7, 2009

This started out as a completely different post – one about spending the last month (plus) in Unemployment Nation, but it occurred to me that I should be focused on what I want to do.  I decided that I’ve done enough wasting enough mental energy on my previous job and the way I was discarded…I mean let go. 

Since I’m now looking, I’ve been think about my ideal job.  I’m imaging a place called Utopia Software Company.  Here are some of the elements of Utopia Software Company:

IT/Development  Work is Either THE Product of the Company or an Integral Part of the Company’s Products – In my previous IT jobs, IT was always viewed as, either a necessary evil or a black hole where money was poured with nothing coming out.  When the inevitable tough times would come, IT would be the first on the block.  In my first job, I watched IT get chopped in third. Recently, my IT department of three employees was reduced to one contractor.  The companies I worked for had lots of intelligent people working for them.  Companies where technology (not necessary computer/electronic) are key. You would think that if they could give IT at least some of the resources it needed that there would be a big return for the business.  But what IT got was usually the shaft.

Also, IT had little or no clout within the organization.  Trying to get things done that were needed for the IT organization to work better was damn near impossible.  No one wants to hear that we need a new air conditioning unit for the computer/server room or that we need this or that tool to do our job more efficiently.  And when trying to get the attention of management, if it had to do with IT, forget about it.  As friend of mine said, “You can’t spell shIT without IT!”.

That’s why I want to be part of an organization that either makes software or view software development and the systems as a key part of their business.  IT would not be considered a second rate department, but critical to the success of the company.  I would like to feel valued and supported.

An organization that ACTIVELY supports learning – One of my biggest frustrations with my corporate IT career has been the lack of opportunity for learning, particularly for classes.  I’ve been part of two corporations who SAY they value learning, but I have not seen it pan out.  I have rarely been able to take training I need just to be able to do my job, let alone learn any new skills.  It’s a good thing I can pick things up quickly, because that has been the way I’ve had to learn almost everything.  I did have one good manager who really let me take a number of courses to improve my skills – that was nearly 13 years ago.  I’ve had almost zip since. 

I want to be part of an organization that really encourages learning and gives people the time and resources needed to learn and continue to learn.  Allowing people to take web classes while trying to continue to do support work doesn’t cut it.  If I’m supposed to be learning something, I want to be learning it and concentrating on that. Not trying to learn a new database technology while supporting applications, correcting data entry errors, and fixing printers.

Pay and Compensation

I’ve worked for two companies whose view of pay and compensation couldn’t have been more different.  One paid people in proportion to their performance – the percentage of your raise was clearly tied to your performance that year.  The other company SAID they believed in performance based compensation. But if you worked your ass off or just did what was needed, you might get the same 3.5 %.  The one company expected alot out of you, but actually gave you something back.  Most managers at that company would give you time off if you had to do night or weekend support.  The other company wanted you to work even more than the former, but you were lucky to receive a pittance of an increase and no time off if you had to give up nights, weekends, or even holidays for support.

I want to work for a company that rewards their employees for a job well done with meaningful increases.  If the company expects a great deal of their employees, the employees should expect a great deal in return.  And night, weekend, and holiday support work should be compensated by either time or money. 

Room to Grow

In both my corporate jobs, there really was no place else for me to go.  In my first job, the only way up was into management and at the time, I wasn’t willing to make the sacrifices (move away from my family) to make that happen…I’m still not ready to make that sacrifice.  In my last job, there was, at least on paper, more technical levels for me to pursue, but I knew that no one would want to have someone of that level working in the plant…apparently they didn’t even want to have someone of my level working at the plant…but I digress…

I want a job where there is a technical and management ladder.  I was a pseudo manager for a while (all of the responsibility, none of the power), and I’m not sure I was real great at it then.  I’ve learned a lot since then (particularly what NOT to do) and think I have a better mindset for being a manager, but I still like technical things.  I’m not sure I’m ready to go into management, so I’d like a position where I could advance either technically or managerially.

In Search of Utopia Software Company…

Am I asking too much?  Does this company even exist?  In Central New York (state)?  That’s the kind of company that I would like to build some day, but for now, I’d like to just see on functioning in the wild.  My horror stories of Corporate IT are mild compared to many I have heard with psychotic management and cutthroat politics – I’ve been spared that.  But wouldn’t it be nice to work for Utopia Software Company or at least in the IT department for Utopia where dreams can come true?