Not only that, but how would engineers, for example, know how much money was saved or earned from blah feature or project unless that was explicitly shared with them? Time saved or usage can usually be measured by the engineer, but money is a lot trickier.
Like I'm able to say a speech application I made was used in over a million calls, because I looked at the database and saw that many call records in there. And I'm able to say that I set up an one-click 30 minute devops process for deployment that was previously done over the span of 4-8 hours manually with multiple engineers onhand in case things went wrong (and they often did due to user error), because I was physically present during those manual processes and could directly compare and contrast the time difference.
But I can't say it "saved the company X million dollars" or whatever because I wasn't in management and didn't have those figures shared with me.
At least not honestly. I could make some bullshit up (I don't, but I could), like you said, and how are you going to verify it? Do you think a past employer will confirm or deny those figures if you call? You'd be lucky to get much more than confirmation that I worked for them and what dates at this point, thanks to all the liability around it. Also there's no guarantee that they know (or remember offhand) themselves, maybe they weren't on that project.
So multiple engineers on hand for 8 hours - let's say 5 engineers. That's 5 person days. A deployment a month (cos anything that painful gets done less often) gives 60 person days, at something like 2x daily salary of engineer (assume 500pd for easy maths) and you saved company 60,000 usd a year whilst increasing reliablity and speed.
Nice one
> Like I'm able to say a speech application I made was used in over a million calls, because I looked at the database and saw that many call records in there. And I'm able to say that I set up an one-click 30 minute devops process for deployment that was previously done over the span of 4-8 hours manually with multiple engineers onhand in case things went wrong (and they often did due to user error), because I was physically present during those manual processes and could directly compare and contrast the time difference.
These are both perfect for a resume. They are quantified and measurable and would be interesting to talk about in an interview. For example, I'd probably ask you what tools you used to set up your 30 minute deployment process and what they were using before and how you managed such a huge gain. I would ask you how you built your voice application to scale to a million calls.
These are both great for a resume. They don't all have to involve money.
Like I worked on several games that didn't do well in the market (for various non-technical reasons), so I know I can't brag about saving money or time or usage for the company, but I learned a lot of skills by being on those projects, so I benefitted personally in ways that could help the prospective company out.
In fact I might have gotten more skills from those projects than that speech application, for example, despite that one being used a ton.
So I don't really have anything better I can say there than "did this this and this on the project, lead X number of people, etc", which are basically the 'responsible for...' bullets that everyone advises against including on a resume.
Also in case you're curious, I set up the process by using Octopus Deploy and several custom Powershell scripts after an audit of their existing processes and all the various information for all the servers, firewall settings, windows services, database snapshots and schema migrations, etc (there was a lot, each major system had like 40+ steps to it by the time they were done) etc.
Before the engineering director of the department would lock himself in his office and execute .BAT scripts one by one from a terminal and copy files and other things manually, while everyone else chilled in the main office, waiting (usually around 4-5 people). If anything ever went wrong, and usually it did, it would take several engineers to investigate and help revert things if necessary.
It was a mess. They knew it was a bad process, and had previously had another developer start investigating how to make things better using Octopus Deploy, and he gave up and quit the company and KT'd to me that it was impossible, no one was cooperating with him, he couldn't get the information needed, and well... I didn't have his experience and think he just didn't want to do it.
I had everything working for several processes (and we set up more and more over time after we had things working) in about the same time as he spent accomplishing very little (I started with his setup), and I didn't know anything about Octopus Deploy and barely anything about DevOps beforehand.
Mistakes can be golden.
Should I put this on resume and would it be in poor taste to quantify the results?
He just said:
>> that ended up being used to commit a (arguably) crime against humanity.
What about that makes you think that he knew what it would be used for?
"I'm the civil engineer who designed a large and complicated factory for the mass baking of ceramic products."
...
"I did not know the next government would start a world war and use them to gas Jews."
You seem to assume that everyone has perfect foresight. I assure you, even you don't have perfect foresight.
But if someone told me that they were a senior SRE at MindGeek, I’m inclined to hire them.
And also, as you said, the resume drives the interview, so they are good jumping off points and that's why they are there.
I was instantly put off - because while it might be true there’s just way too many variables to claim a 68% improvement was down to your design system.
Then follow up with the age-old advice:
Your resume should talk about results. Don't say "Created a new CMS for the company". Say "Created a new CMS for the company in Python that resulted in an ~70% reduction in website update times, from 1 hour to 18 minutes."
My take: I’m actually not convinced anyone cares too much about those numbers in a resume. Great topics to probe in an interview, but not much of a signal on a resume. Reason being: they’re easy to fluff and are almost always inflated bs.
I do agree with all of your other points