Hacker News Reader

" Software engineers have a duty to identify and inventory the value they create for an employer, rather than just listing all of the tools they use. And if those engineers can’t talk about the value they create, they should take a big step back and ask if they’re actually adding value at all."

I don't think that's realistic. If you work on some backend or infrastructure how do you measure your value? Maybe your department can do it but not the individual.

My company has a reward system for this kind of stuff. When I look at the awards they make some sense in production because they often can show direct cost reduction. But how do you measure the impact of using Jenkins? Most likely you will have to make up some BS numbers.

You don’t have to measure it though to add it to your CV, instead of list of technologies used.

What other value is there other than money when it comes to resume?

The kinds of things I look for in evaluating senior candidates are things like:

- Payments flow kept going down because of lack of reliability in our CI, so I rebuilt the job queueing system to get to 99% reliability

- Most of our business is outside of the US, so we invested in better CDN routing, got a 50% improvement in our web TTIs

- We weren’t able to deploy code often because of our monolith, so we moved to a service-oriented architecture in order to speed up development

If candidates can’t justify why a project happened and why it helped either the company or their team, then that candidate isn’t a senior engineer, they’re just someone taking marching orders.

The impact of Jenkins could be:

- Reduced the average time from pull request to deploy from 6 days to 1.5 days (efficiency gains)

- Increased the number of deploys from 1x/week to 4x/day (output gains)

- Reduced the number of production quality incidents from 36/month to 3/month (quality metrics)

- Enabled the team to ship XYZ Project 90 days earlier, which enabled an new $10 million annual revenue stream for the company.

If one has to "make up some BS numbers" then one either doesn't understand what Jenkins is good for, or doesn't understand how to identify and measure the positive benefits of Jenkins. And that's kinda my point.

edit: I should also mention that yes, it's on your employer to help you account for this as a backend/infrastructure engineer. If not, they're kinda stacking that deck against you and you should speak up!

I guess the main problem in my company is that they want to have money saved as the main input for the awards.

That's a great list in theory, but what would it really mean?

- Pull-request-to-deploy is simply a latency, not a throughput factor, and may or may not correspond to business value.

- Number of deploys (without looking at features/deploy) doesn't necessarily measure business value

- 36/month -> 3/month meaningful statistic, made up numbers

- "Ship product 90 days earlier"- You can't really objectively prove when it would have come out otherwise

Other problems include - usually the engineers are the ones who are collecting and researching these metrics so it's a conflict of interest: an engineer is never going to mention the downsides of their work in such statistics.

I'm saying if I saw those "facts" on a resume (or as a manager) I'd ignore them all; they don't sound objective at all to me but more like good sounding pseudo-truth to give a low-competence manager something to work with.

I think you'd be shocked to find that on any results-oriented resume, it's nearly impossible to objectively prove essential and sole causation of positive results. A sales rep bringing in $10mm/year in deals is a great achievement, and a hiring manager may ask about the details, but just because you needed marketing, a good product, and biz dev to warm the pipe doesn't mean that you are bullshitting when you claim those results and talk about your impact on them.

> usually the engineers are the ones who are collecting and researching these metrics so it's a conflict of interest: an engineer is never going to mention the downsides of their work in such statistics

Yeah, that's called effective self-marketing, and everyone does it.

> I'm saying if I saw those "facts" on a resume (or as a manager) I'd ignore them all; they don't sound objective at all to me but more like good sounding pseudo-truth to give a low-competence manager something to work with.

Thoroughly disagree, and I would hope as an engineer to avoid encountering hiring managers who would harbor a prejudice against engineers who can identify and speak cogently about the impact of their work.

The impact of using Jenkins should be easy to measure with metrics like "number of new version of the application released per week", "time it takes a commit to get released" or even "number of rollbacks caused by a buggy version".

With a continuous delivery pipeline setup you'll release often and the new version will work. And that's great from the business point of view.

> A management resume talks concretely about growing a team.

FWIW, this is also methodology-oriented, not results-oriented. Hiring people costs a business money. It only makes more money if they're effectively deployed and utilized. Hiring the right people is a critical task for any manager, but listing only hiring on a resume should be a huge red flag. A manager should be able to demonstrate how s/he was able to apply those hires to efficiently meet business goals.

This was an area of frustration for me at my last managerial gig. It was always a challenge to decouple headcount from influence in the minds of upper management. Too many teams just hired and hired and had very little accountability for delivering results commensurate with how they were resourced. We also had smaller teams that were delivering a ton of value to the company whose leadership was constantly marginalized because upper management didn't see them as representing as large a percentage of the engineering team.

You're absolutely right, and sorry for glossing it over there. Being able to hire is a competency, but deploying those hires for the success of the business and quantifying it is good performance.

I will say, however, that in highly competitive/politicized hiring environments, wresting away budget for hiring can be an indication of good performance, but that should be stated.

Maybe I'm at a disadvantage for doing this, but technologies are really only a minor detail of my resume. I focused it mostly on the things I actually did. My assumption was that this would be more important to people beyond the HR/recruiter part of the hiring phase. Also I prefer not to bullshit, and making my resume some buzzword laden list of technologies is off-putting lol

> Maybe I'm at a disadvantage

You would only be at a disadvantage for that if the recruiters looking at your resume were just looking for keywords. And in many cases they are, and that's where i've seen it useful to put your concrete accomplishments in the experience portion of the resume, and put all those keywords in a gutter or in some other section (even better, put it in a word cloud for that extra street cred!)