As engineers we're measuring everything, all the time right? The point is 'wrote a web api' is worse than saying 'wrote a web api that handled 1M tx/hour' or some such. Even if the number in this case was exaggerated, it stands out and we have something to discuss in the interview phase.
And if the software you write works with money at all, put the amounts in there. Moving around large amounts of money shows trust from your existing company, and attention to detail.
> As engineers we're measuring everything, all the time right?
Is this mostly a joke? I've written plenty of APIs, but I have never load-tested them in isolation, never had to respond to underperforming latency or throughput metrics, or even face any feedback on software performance. In most cases, I don't know who uses the code I wrote, and no metrics from them ever make it back to me personally. For exactly 95.2% of what I've delivered, I couldn't tell you that I improved Foo by Bar units even if you held a gun to my head.
This is after years of delivering LOB software to clients in banking, manufacturing, and oil & gas industries.
I think it depends on work culture. We recently merged with an american corporate and their engineers are obsessed with measuring, pilots, ab testing, RFCs etc. It's so slow to work with them even on the smallest features. Poor 10% of users who miss out on awesome features for 4 months because we "need" a control group.
I think that the point of the parent poster is that often even when the work culture is obsessed with measuring, the people doing the A/B testing and careful study of the benefit to the company are quite separate from the people implementing the change; the information will be used in some decisions and flow to various layers of management, but the developer who built that feature won't necessarily even get a message when it eventually got chosen for widespread deployment or got abandoned after 4 months of being shown to a control group, much less getting the data on what the estimates of financial impact showed.
I'm not so sure about this. I support things and I've supported them over absurd growth periods for years. I've lost track of how many zeros are on the number of things per thing; it doesn't matter.
The process is: You're in charge of a thing, it grows, it breaks, you fix it, it grows, it breaks, you refactor it, it grows, it breaks, you fix it, it grows you replace it and shard it into N things, they grow, they break, etc. The metrics matter, but after a while it's just bigger and bigger but gotta work, so you just make it work.
Oh -- obviously I'm not an engineer -- I don't wear a striped hat and drive a train or sign blue prints.
And if the software you write works with money at all, put the amounts in there. Moving around large amounts of money shows trust from your existing company, and attention to detail.