Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am trying to update my resume, and I would like to count the number of "product releases" that I was directly involved in with a company. It would seem to serve as a performance metric.

The problem is that I was working on the backend of a very large distributed system, like along the lines of Hadoop or other huge database. We had regular 6-month major releases and other minor releases. My manager kept saying that we "shipped" these releases, but "shipping" a product to me sounds like releasing single pieces of software, like Microsoft would ship Office 11 or something.

Any ideas on "product releases" for backend service engineers, or any other type of performance metric?

share|improve this question

closed as off-topic by Snowman, gnat, MichaelT, Kilian Foth, durron597 Apr 7 at 13:08

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – Snowman, gnat, MichaelT, Kilian Foth, durron597
If this question can be reworded to fit the rules in the help center, please edit the question.

Shipping releases to production for a SAAS system is just as good as shipping a golden disc. It's all the same, I worked a place where we did both often at the same time and the process was basically identical. –  Jimmy Hoffa Nov 27 '12 at 19:09
Unless you are a release engineer, it seems odd to use the number of product releases as a performance metric. If I'm looking to hire a developer, I'm not particularly concerned about whether their last company released software quarterly or annually or weekly (or, heck, daily) when I'm evaluating productivity. An equally productive developer might release software every few days in one organization and every few months in another. Of course, the amount of code in a quarterly release would be much bigger than the iterweek release. –  Justin Cave Nov 27 '12 at 20:56
I agree with Justin - the number of releases is really just a reflection of how your organisation manages the software development process and in my mind is not a useful metric. For example at my previous employer we did weekly releases on a particular service, whilst at my current one the releases happen at most once every three months - so by this metric my productivity has dropped massively in this job. –  Jon Malcolm Nov 28 '12 at 11:01
The first two lines of your second paragrapgh "working on backend of.." seem to be, with a little bit of editing, exactly what you should add to your resume -- as well as how many 6-month major releases you did, of course. –  Marco Dec 4 '12 at 21:36

2 Answers 2

Technical interviewers are more concerned with ability than counting releases

Counting releases is a silly metric, like counting commits to a repo. You are far better off describing how you solved difficult scaling problems for a data operation that made demands on Hadoop.

share|improve this answer

Since there's no standard size of a release, the metric doesn't mean anything useful. You'd be better describing the features or improvements you worked on -- and more importantly, your exact contribution to them. If you just want a single number, why not just the number of months or years you worked on the project?

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.