Quantity and Quality - How many line of code did you write?

We had a debate among managers: should we use quantity numbers to evaluate engineers’ performance? 1. Number of lines added/deleted/removed 2. Number of Code Review (CR) submitted, reviewed and approved 3. Number of tickets resolved 4. Number of bugs fixed 5. ... The irony of these numbers, like all other Key Performance Indicator (KPI), is that they can all be easily gamed and manipulated. The software that triggers the most bug fixes probably is the one you never want to use. What we want to evaluate is the “Quality” of the work. But, 1. Without quantity, can we really perceive quality? 2. With quantity, how do we measure creativity, innovation and brilliance? One of my favorite books: “Zen and the Art of Motorcycle Maintenance”, tries to build a whole metaphysics framework around quality - quality is the essence of life and the Universe. Quantity and quality are ONE, not two things. Quantity itself has no meaning, no purpose. Quality gives quantity purpose. But quality can only manifest through quantity. Quantity and quantity might have different dynamic in different stage of our career. For junior software engineers, quantity is crucial - you want to write a lot of code, 10,000 lines of production code a year at least, that is professionally reviewed, that deliver real values. I run marathon races. To prepare a marathon race, I need to get my weekly running mileage to 30+ miles gradually. On top of that, I deliberately focus on improving my techniques: pacing, breathing, running form, interval runs, recovery runs, core muscle and mental state. Without the base mileage, all these techniques are pointless. At junior engineer stage, on top of writing a lot of code, you want to pay attention to improving your craftsmanship: learn from the experts around you; read classics like “Clean Code”; attend conferences, do everything you can to get better on your trade. But when you move to senior stage of your career, quality starts to manifest more in your impact. One of my favorite Sr. SDE promotions was for an engineer dedicated to Performance Engineering. The technical evaluator outside KMS org had a concern that his “code contribution was less than a typical Sr. SDE in AWS”. I happily explained “His 10 lines of code reduced our p99.9 latency by 30%. Anyone can code that 10 lines but to identity which 10 lines to change out of the millions of lines of code we have, by analyzing mountain of logs and eyeballing hundreds of metric graphs - that is worth a Sr. SDE”. “Is it hard? Not if you have the right attitudes. Its having the right attitudes thats hard.” - Robert M. Pirsig