Prologue
The first advice you are going to see in any Internet article on CV composition is to describe your experiences using the XYZ (did X using Y achieving Z) formula. Most of the authors explicitly state that the Z (result) component should be something measurable: increasing sales by 20%, speeding up the page load by 143%, reducing monthly cloud costs 10X, etc. But how often is our work actually quantifiable?
Let’s look into some typical programming and try to assess that. For a brief moment, we will imagine ourselves as a software engineer working on some of your common backend system — say, that of a bank (after all, banks count money, so we should be able to squeeze out at least some digits for our CV, right?)
Building stuff
The arguably most common sort of task is adding some functionality to a system. Let’s say you’ve built a whole service that handles loans: accepts customers' applications, presents to a back-office worker who can either approve or deny the loan, puts the money from internal bank deposit to the customer’s account, accepts and tracks monthly payments, etc.
We (IT specialists) can all agree that building such a system from scratch is by no means an easy technical task, one that can proudly put on a display in any CV. Not only would it require an implementation spanning across multiple internal systems (frontend apps, back-office worker interface, scoring system, audit, etc.), it would also need some extensive end-to-end testing in order to ensure the correctness of all operations.
But quantity-wise, what could you potentially write about this accomplishment?
Not real-world data
You can’t state that your system gives X loans a month or lends an Y amount of money every day. Even if such information is not confidential (which it typically is), how can one possibly attribute these numbers to their own work? These are numbers achieved by the whole enterprise: the marketing team that promotes your bank, the back-office team that decides how much risk a bank can take, the infra team that maintains the bank’s datacenter, and the list goes on. It is impossible to pick out a single person or department responsible for these metrics.
Not technical data
You also can’t provide technical metrics like how many RPS your service handles, how much bandwidth it utilizes, or how many rows its database holds.
Firstly, these metrics make no sense without context. What are the exact requests that we count and how light or heavy are they? Is such load really necessary, or are you actually at fault for using the resources suboptimally? Is the database with millions of rows actually ever queried?
Secondly, the technical details hold no connection to real-world value. The bank’s board of directors will not include them in their report. Who cares if a service handles millions of RPS, but actually loses money at the same time?
Not subjective data
What we actually readily have in our day-to-day work is some subjective metrics. They do the job of providing some feedback (back-office guys tell us that our service works good enough, the infra team tells us that the service is stable enough, the customer tells us that a service responds within a reasonable time, etc.), but how do we actually measure them to present in a CV — that without being biased and dishonest?
There certainly exist some methodologies that allow quantifying opinions and feelings (polls with opinion scales and alike), but no one actually uses them on a regular basis: that would be too costly. And even if someone did, the attribution problem would still stand. How can you guarantee that the customer satisfaction score grew from 6 to 8 specifically because of the feature that you worked on?
What to actually include
The reason why the example above works so poorly with the numbers is because we’re trying to measure the immeasurable by substituting (important) qualitative characteristics by (unimportant) quantitative ones. There are some jobs where qualitative characteristics are actually more important: say, a miner can increase their monthly coal output by a ton. There are also some situations in IT where quantity indeed is the deciding factor: maybe you’ve designed a 100-Petabyte distributed storage cluster that responds within milliseconds — such numbers are too impressive to omit them.
Still, most of day-to-day work in IT is rated in terms of quality, not quantity. Your code either solves the required task or not. It works either good enough or not good enough. It also probably has some bugs, but no one even knows whether these well be ever discovered or not.
So what I suggest is that we should describe what we achieved and how we achieved it, without over-focusing on numbers. Instead, it would sometimes be much more honest and interesting to write why we did some task, i.e. what exact problem we solved. Returning to the example above, I’d gladly talk with a person who wrote something like “delivered a large new system (written in Java and PostgreSQL) that handles the entire lifecycle of a loan”. The “why” in such case is self-evident (there was no such system, and they built it), and the statement is not overloaded with unnecessary details.
Epilogue
The advice to always include numbers in your CV is dated and harmful — not only it wastes everyone’s time on BS facts that have nothing to do with real impact, it also makes it more difficult for the potential employees and employers to connect. People who don’t come up with such facts are often ignored by the recruiters, resulting in further disconnect between the employers and potential employees. Let’s keep the numbers where they actually matter and normalize skipping them when they don’t.