Comment by ryandrake
14 hours ago
> Screen a lot of resumes and you'll get tired of seeing "Boosted revenue by 23% by decreasing deploy times by 64%." This communicates nothing useful and we all know that revenue going up 23% YoY was not attributable to this single programmer doing anything at all.
This is the "quantify everything" mantra career coaches have been repeating for decades. As the story goes, no company is going to care that you refactored the FooBar library in order to make bugs in the DingDang module easier to fix. You have to only write down things that moved some quantifiable business needle like revenue or signups, even if the link to that needle is tenuous. Obviously, this ends up penalizing hard working, talented devs who don't happen to be working in areas where wins are easily quantifiable.
Some quantification is very helpful. We're going to have a very different conversation if the architecture you built was serving 1 million users as opposed to 1000 customers.
It's the useless quantification that turns resumes into noise, combined with making claims that you changed revenue by yourself.
> You have to only write down things that moved some quantifiable business needle like revenue or signups, even if the link to that needle is tenuous. Obviously, this ends up penalizing hard working, talented devs who don't happen to be working in areas where wins are easily quantifiable.
Every hiring manager knows this game and sees right through it. You can't read 1000 resumes with claims of "Increased revenue by 13% by" followed by something that clearly was not the reason revenue increased 13% to become numb to it.
Nobody believes these.
The somewhat useful quantifications are things like "Reduced cloud spend by 50% by implementing caching". This can spark a conversation about how they diagnosed they issue, made a transition plan, ensured it was working, and all of the other things we want to hear about.