Job as a Release Engineer

When I tell people that I work as a release engineer, I usually get a blank look. Then I explain the aspect of my job most people understand “I make programs that you double click to install software”. Then most people say something along the lines of “oh you’re a software engineer”. I suppose that’s true, but a release engineer’s job is somewhat more specialized and it involves duties that are quite different from most software engineers’ daily routine of fixing bugs/creating bugs. So, I decided to write a list of things I love and challenging about my job…..

Here are the things I love about my job: 

1. I am given a lot of responsibility and trust – Release engineers handle a lot of the critical systems like builds and version control in an engineering organization. Any screw up in those systems could potentially destroy a lot of other people’s hard work. So I learn to tread carefully and be an expert in these systems.

2. I learn a lot of random stuff – When you have to package builds for a bunch of different operating systems and programming languages you have to learn a bit about everything. I admit that I’m not an expert in any one programming language, operating system, or database, but I’ve picked up enough in the past few years to at least answer interview questions about a broad range of subjects.

3. I have an idea of the “bigger picture” – In my current company I was the sole release engineer. This means that I have to be aware of all the product releases and the plans for these releases. Generally I like knowing what’s going to happen in the grand scheme of the company I work for.

4. I know what my purpose is – Release engineers serve a specific function so the job isn’t that ambiguous. As I have written before, a lot of people are dissastified with their jobs because they don’t see the fruit of their work and they feel that it is pointless to work. Generally, I know what my deliverables are. So my efforts don’t seem so useless except when people treat me as a replaceable unit.

5. I work with a lot of different groups – Release impacts a lot of groups including support, documentation, QA, and development. This means that I have to talk to a lot of people to get a good release. This makes the job less boring in a way and exciting also.

6. I am special – When you search for software engineering jobs online most of the job descriptions are “software engineer” and the responsibilities section basically say that you will be a code monkey. There is nothing to distinguish one software engineer from another besides that they code different things. There are usually less job listings for the title of Release Engineer, and that usually means less competition and better compensation. So in terms of my career, I like being more specialized (Hope So !!!)

Now here are the things that are challenging:

1. The system administration aspects of the job – Setting up machines and monitoring their disk space, upgrading software, making images of machines and then deploying them on new machines that usually do not work right away. Sometimes power failures that mess up my fleet of build and test machines in mysterious ways. Basically, when you have to be a daily user of a bunch of different machines you generally end up maintaining them at least a little bit, and that could be little tiring.

2. Broken builds – At my company, I keep a hall of shame for those who broke the build, and then I got bored of taking down people’s names because sometimes they occur every few hours. Someone emailed me once and said, “you’re like a zookeeper”.

3. Telling people to fix stuff – I actually don’t like to send emails that tell people what they broke. However, this is really part of the job, too because the goal is to get a clean build every single time and I have to be whiny sometimes for the sake of product quality.

4. It is a tedious job – I think a good release engineer has to be somewhat obsessive compulsive to make sure a build contains exactly what is supposed to be there. In the most extreme case it involves manual inspections of hundreds of nasty code merge conflicts from various branches of code. If you ever used TFS for a large project with a bunch load of branches you might have run into this problem. I have done that before and it was painful. Then again, a lot of other jobs are also very tedious so I don’t think tedium is a unique problem.

At the end of the day, I am pretty happy to be a release engineer because it is an important job in any organization and I have a lot of autonomy to do my work. This job also helped me to develop my organization and management skills that I could use in the future.