In 2014 I worked at a company that switched to Git and then started measuring LoC to assess performance/involvement. Engineers took to committing/removing things like node_modules directories to make the data meaningless.
It still happens, even today, quite a bit.
jaw dropped. since then i'm committed to being the biggest office space corporate schmo possible. let me cog it up, keep payin me 6 figs, lettin me work at home full time.
I agree with you 100%.
Spot on. Talented engineers can usually be picky and change job if they don't like the environment, but not everyone has this option. There's plenty of developers who are stuck in shitty companies (lack of skills/experience, or struggle with interviews, or just live in places with limited opportunities). And the longer you stay in a bad place, the harder it gets to escape it. 2 years ago I was the hiring manager for a few open positions and I was honestly shocked by some candidates. So many "senior devs" that despite having 5-10 years in the industry wouldn't have passed the interview even if they applied for a junior role.
It's very easy to have a distorted view of the industry if you are privileged enough to have only worked in great tech companies. I'm guilty of this myself, making friends with other devs in my city was definitely eye-opening for me.
The business I worked at was a typical office, like the one you saw in Office Space. Departments had their own TV screens on the wall that showed performance of individuals in a department; the sales department had a screen that showed who was making the most sales that day.
After we'd pretty much finished working on the web apps that supported these TV screens, the CEO met with me and a colleague to tell us how good a job we did. Then he said:
"You know, you're the only department now that doesn't have a performance monitor. Maybe we out to get one for you. We could base it on lines of code."
My coworker and I were speechless at first, but we started laughing because we thought it was obvious that he was joking.
"What's funny? Why are you laughing?"
We quickly stopped laughing when we simultaneously realized that our boss was not kidding! I said we'd get right on it in the next sprint, and he told us that sounded good and left. I'll never forget that look on my coworker's face.
Poisoning the well, I like it.
Edit: And they quit right afterwards.
Telling someone that it only took me an hour to eliminate an hour of someone’s work every week doesn’t go far.
Even worse, someone else now has to explain "why they did it wrong to begin with" regardless if the replacement technology existed or not at the time of original process creation.
Also making more money is better, because it means growing the company with more employees and more job safety for everyone.
Most companies aren't like that though. Know your company!
Also consider if you can run out of money before growth kicks in...
The maths is simple. If my margin is 1%, and you make me an extra $100, I keep a buck. If you save me $100, I keep that whole $100. If I'm smart, I can use that to drive my prices down, and take more market share without reducing my margin.
Obviously it becomes less clear if your margin is >20% or so.
From what I understand a lot of product teams at FB have nearly frictionless development tooling for their use cases so the pressure is to produce volume.
[1] Unless there are multiple skeezy companies in Menlo Park.
$JOB-2, admittedly about 4 years ago now, the good manager with a background in software left for a better opportunity and was replaced by someone who's background was management. With no insight into the subject matter, they fell back on whatever they thought they could quantize.
Got numerous things like that, though my team lead and our project manager did a great job of shielding the team from that crap, we still occasionally hear it come up in group meetings and the like.
I even got a task handed directly to me, bypassing everyone above me, to "estimate how much it would cost to migrate all those linus apps your team has to windows. They'll run better there". Just the windows licenses alone would have cost us about half the existing server costs since we were using AWS instances. Also included a line item that included recruitment costs for a new developer, and verbally informed him that it would likely involve hiring a new team, as the existing team was hired specifically as linux developers.
The smart thing to do is to regularly keep your manager updated on what you're doing, especially if they don't come by regularly and ask you.
Especially if you are WFH.
Meta-metrics might be much more helpful, though harder to come up with, quantify and monitor. Things like defect rates, user reported incidents, user satisfaction, stuff like that.
Things that cannot easily be gamed from within the development process and that are still directly linked to the success and economic viability of the product and its development methodology (though on a higher level).
Code is often improved by removing code.
Task completion would also be abused, because it's too vague. It simply shifts the burden to the one formulating the task (e.g. preventing holes in the specification like missing performance or hardware requirements).
Exaggerated example: if the "task" is to automatically deliver a report containing certain data and formatted in a specified way, the easy way might be an implementation that stalls the DB server for hours with deeply nested FULL OUTER JOINs on non-index fields.
The task would be completed quickly and arguably correctly, since neither runtime nor memory requirements were explicitly specified...
But you said it yourself, any system is going to be abused...
Out of sight, out of mine <== don't let that happen to you
I don't believe it is any coincidence that the highest compensated engineers I know also are highly visible through their own efforts.
I'm curious if this is "everybody knows this person isn't doing any work, here's a blindingly obvious metric to use to defend this move to HR" because HR orgs often hate things that don't have metrics attached, or if it's "I don't understand what this person is doing, and I don't see any commits, so it must be nothing"?
They were a senior engineer that spent a lot of time coaching the rest of the team, and less time on their own personal work. The commits data point, in my opinion, should have been the beginning of a conversation that ended with the manager asking this person to adjust their priorities. Instead it was presented as an accusation that the person wasn't getting their work done, which ultimately lead to them feeling insulted and quitting.
That could be completely wrong, of course. But would it surprise you?
I've been fortunate recently to not work in orgs where mentoring and collaborating like that is looked down upon - instead, it's encouraged - but my ongoing struggle is to figure out how to quantify it.
I've got two similar but distinct motivations for wanting to quantify it:
* If I have a manager who looks less favorably on it, I want to be able to demonstrate my worth; but also,
* If I'm spending most of my time trying to mentor the rest of the team, I want to see how well I'm doing - and I want to be able to change things and see if it results in positive or negative changes
Sadly I've completely failed at coming up with how to quantify this so far. It all comes down to qualitative peer feedback/manager feedback...
[0] As a technical person, I try to practice the reverse of this: if someone asks for a feature or claims there's a bug, I try to dig until I fully understand why they're asking for what they're asking. So I think asking for similar curiosity and depth from a non-technical person is fair.
Assuming there's some kind of constant ongoing engagement with one person or group, I'd expect an immediate dip in velocity as your productivity goes elsewhere, then it growing, and maybe evening out to before-engagement numbers (approximately), as they reap the benefits of learning from a senior engineer. Then, as you're able to return to normal duties and they're able to apply the lessons, you should see velocity greater than before the engagement. That delta should be somewhat quantifiable and, ignoring other variables, should represent the benefits of coaching.
There's also huge value in the increased job satisfaction for both mentor who enjoys mentoring, and a mentee who is learning. That should show up in any kind of employee satisfaction survey, or retention numbers.
If anybody can push commits to the repo, then it's a useful metric. Finally, this sort of action should be take after the manager has worked with their report, by having somebody else help them, or put them on a different project.
Now if there's 5 drawings with different colors, or asking "what color do you want it?" leads to a 5-week email chain...
I don't think you grok what's happening. Some middle manager sees a shade of red on his screen in a PDF, and the dev is expected to reproduce the content in that shade of red. There are simply too many variables.
Even if you have access to the PDF, the red will often be rendered differently by the browser than it is by the PDF engine.
I've had middle managers tell me to "fix" a web site because the colors looked different on his office CRT than it did on the laptop screen of a person in another building.
trivial to fix
Everything is trivial when someone else has to fix it.
I discovered that bug report after our designer noticed at a glance walking behind me (I use Firefox) that the colors on our site were far darker than she intended, somewhere around 2017-2018 (that bug was opened in 2010).
I've left companies because of devs like that. People who just stand in the way of getting the software to do the correct thing. I do not understand what makes these people tick.
No, No you don't.
They absolutely use lines of code metric at my company. I don't miss any chance to tell my manager it's complete bullshit. His answer: "Engineers are supposed to write code, just like construction workers are supposed to build houses."
If you give a construction worker a design to build a wall, and the worker is given 2,000 bricks that must be used to build the wall, then, yes, of course the worker must lay down all 2,000 bricks to build that wall. However, if I am asked to build a computer-simulated model of said wall, and if there is a way to build the model with 200 lines of code that looks and performs identically to a model built with 2,000 lines of code, then, yes, of course I am going to build the wall with 200 lines of code.
I hope you find better pastures.
And I can assure you, they were not judged on the number of views or pages on their drawing, or on the number of variables in their structural calculations.
It took 23 minutes for that rule to dissappear after my lines of code metric jumped 250,000k
Whats nice about the proceduralism is you can document that the steering committee only meets once a week on Tuesday afternoons and change control meets on Thursday. And everyone knows the automated test suite on DEV takes about half a working day. So if a change can't be worked into the schedule in less than a day, it'll never pass CI testing before the change control meeting so it'll take more than a week.
Whats bad, is mgmt would like you to complete multiple changes perhaps at the same time which always complicates the change control process especially if change #7 failed last week so company policy is to roll everything back and now we have 13 changes, two weeks worth, to complete next weekend. Also whats bad, is knowing its a corporate nightmare to make any change, why did I make a mistake to begin with of having the buttons swapped or a misssspelling or whatever.
I find the big metric now a days is backlog. Lets see the number of request tickets decrease this week instead of increase. That leads to intense pressure to roll multiple problems into one ticket.
There was a time when I thought this video was funny:
These days I can only look at it and think "the expert is terrible at calm confrontation and good communication. There would be no problem if he had developed those skills."
It is important to rule out miscommunications. Contradictions often are not obvious to the requestor. It also helps to understand, which of the contradicting requirements can be dropped to resolve the problem. Sometimes the problem is just a small feature which made it to the requirements, because no one considered it a problem.
That doesn't mean, I haven't gotten requests which were as silly as in the sketch and had discussions along the lines shown :) And of course, I never hesitate to speak up about actual issues.
Getting sensible requirements is not only on the expert.
But the expert is the one who can know if the requirements are sensible.
In requirements gathering, the whole job is to hear people's attempts to describe their problem and figure out what problem they actually have.
By definition they don't have your expertise, or they wouldn't need to talk to you.
So, of course they will say contradictory things and use terms completely incorrectly - they cannot do anything else. That's why they hired you.
The expert in this scenario gets hung up on their incorrect language and gets flustered and stymied, telling them "What you want is impossible!"
What they _said_ is impossible. It's our job to persistently, patiently, calmly help them understand their needs, without judging them for needing our help.
I'm not particularly good at it, but I understand the mission.
The problem is lack of trust in you as the expert and possibly a lack of self-awareness (they think they understand).
A manager/client should make mostly strategical decisions like: We should solve this problem, here are the resources. And almost never tactical.
They also shouldn't even care or look at LoC. They shouldn't be worried about metrics of 'effort' at all.
I found your phrase "lack of trust in you as the expert" a little jarring because (again, in my personal experience) considering the developer to be a domain expert is somewhat of a foreign concept. I suspect/hope the situation is better elsewhere in the industry. :-)
> I suspect/hope the situation is better elsewhere in the industry. :-)
I do freelance, client work. Alone and in (very?) small teams. Typically my/our clients only have a superficial understanding of everything technical (if at all). Trust often needs to be earned.
One way to gain trust is being creative/optimistic and explaining feasible possibilities and strategies. Another one is being pragmatic and not selling them something they don't need, or might not need.
And then the most important one is to have conversations about their problems and wishes. Showing that you understand them by asking questions and writing a specification. And explaining your (iterative) workflow: "Let's figure this part out after we've done this other part." I guess this is the "domain" part of the process.
My experience is that if trust is in danger then the work is less valuable, less fun and less sustainable. Indications of this are things like we discussed before and similar:
- Trying to measure effort instead of rewarding value.
- Nitpicking, bikeshedding and other distractions.
- Overstepping their expertise (typical for UI design, a bit less for programming)
Now most of my interactions are good but sometimes I get the above. We're actually discussing of doing more upfront communication work in the offers and initial discussions to prevent these things (even by filtering out clients/collaborators) and to set a tone. Because again, this is unsustainable on multiple levels and it never ends well...
My leader isn't a technical person by a long shot. Instead they focus on getting people that they can TRUST on their team. Yes, sometimes it means we have to go back and 'fish' for metrics to throw the business. But we do notice that the less we chase metrics (and, yes, the arbitrary goals set out by the company as a whole) the more productive we really are.
I was on a browser team. A fellow co-worker decided to add the Fullscreen API to it which means not just add the API but first discuss it in the relevant standards committees.
I'm pretty sure he thought, and so did management, this would be a 2-3 month project at most. IIRC though it was like 18 months, maybe longer.
Some problems that aren't obvious at first
* What is fullscreen mode? Is it a mode for the page, a mode for an individual element? What?
They eventually decided it was for an individual element
* What happens to the CSS above that element when none of its parents are being rendered?
I'm sure that took a while to argue over. Like if it was position: relative or absolute and suddenly it's parent is no longer displayed. What if the parent has CSS transforms? Okay, you say we ignore those and consider it the root element. Okay so does that mean none of the other styles from the parents apply like color or font-family? If some do and some don't we now have to go through every CSS property and decide if it does or does not continue to inherit. I don't actually know the answer to this.
* You have a DOM A->B->C->D->E. C asked to go fullscreen. While there E asks to go fullscreen. User presses ESC or whatever to exit fullscreen. Should it pop back to C or A? Does it matter if E is a video element and they clicked fullscreen? What if C is an iframe does it matter?
* Testing across all devices that support it requires all new testing infrastructure because going fullscreen is effectively something that happens outside the page not inside so testing that it actually happened, that a user can actually exit it correctly, requires entirely new test systems that were not there for previous APIs. Then multiply by 5 at least (Windows, MacOS, Linux, Android, ChromeOS, ...)
And so even though I'm sure everyone ended up understanding that, it turned out to be way more work than anyone expected. Yet, in the back of their minds it was arguably always "this is taking way longer than it should, goals not met" or at least that's how it seemed to be perceived.
This made me realize that working in a purely engineering team can sometimes be a perk. Not because technical people are "better", but because it leads to fewer frustrations like this one.