I'm surprised to see so many HNers come out against counting lines of code. Sure, it's imperfect and this developer got screwed, but how are managers supposed to make informed, data-driven decisions on what the right course of action is? Many of us extol the virtues of A/B testing landing page designs and gathering deep metrics and analytics but turn around and slam managers for making decisions based on line code counts.
Your post is a logical fallacy. The fact that a bad metric exists does not mean all metrics are bad.
To address your specific fallacy, the output of coding is heterogeneous while the output of teaching is homogeneous. If I code today, it's a realtime optimization system. Tomorrow it might be a search product. When I taught, the output was always the same: students who understand calculus.
The post is a parody. It points out the flawed reasoning used in the parent.
It appears you are claiming that when you taught the output was the same each day. Each day you taught your students learned calculus and understood it. Each day you may have taught an aspect of calculus but the topics varied from day to day. Furthermore, assuming undergrad level, it can't be believed that each of your students understood each topic you taught.
The dichotomy you've laid out between programming and teaching is not apt.
The output was the same each semester, not each day. It was the same for me and the guy down the hall. It was the same for every person teaching calc 1 between the last curriculum change and today.
Not every student understood every topic. So what?
Then the output isn't the same if not all students had the same outcome. Furthermore you used day as the time period when talking about programming. I assumed as a matter of consistency you meant to use roughly the same time period for teaching. Every semester I teach calculus is different. Two different people don't teach the same way even if the curriclumn is the same.
Your statements here strengthen the parody. Merge sort is the same for everyone, right? So let's just go by lines of code. The outcome is the same.
A mistake in wording on my part - I should have said "the desired outcome is the same". Sorry for the confusion.
Two different people don't teach the same way even if the curriclumn is the same.
So what? The goal is the same. It is meaningful to measure whether my students know more or less calculus than yours.
If the goal of programming were to re-implement merge sort over and over then it would be an effective metric to count the number of correct merge sort implementations.
The inability to compare a realtime monitoring system to a web scraper is what makes programming harder to measure.
But in many cases one can measure programmers by output. For example, at Styloot, one task we have is building web scrapers. They all have a pretty straightforward (and identical) goal. An effective metric for programmer performance on this task would be to measure the # of scrapers written or (better) the # of items correctly scraped.
See also quant traders - the goal is homogeneous (increase profit, adjusted for risk), and your code is measured by how well it achieves that goal.
Your post is a logical fallacy. The fact that a bad metric exists does not mean all metrics are bad.
Yes.
That was, to some extent, my point :-)
That and the fact that many HN folk will have encountered management doing dumb things like equating velocity or cycle time or lines of code with productivity. Which may explain their aversion to simplistic metrics like this.
To address your specific fallacy, the output of coding is heterogeneous while the output of teaching is homogeneous. If I code today, it's a realtime optimization system. Tomorrow it might be a search product. When I taught, the output was always the same: students who understand calculus.
Really? I can easily see it from the opposite point of view. When I code I'm just delivering running-tested-features. When I teach (which I have done, and still do) every student is different - they often start from radically different positions of attitude, aptitude and existing knowledge.
