Hacker News Reader

Comment by khazhoux | Hacker News Reader

Yes, your bosses have been too incompetent to notice.

Yes, if you only put in 5 hours, you are not delivering at your full potential. You are very unlikely to be delivering "10x Developer" work. I have no idea what your company size is, but I would wager that the top developers at my workplace land 10x as much code as you (and solid, well-tested, and efficient code).

Yes, you are lazy. I don't know what else to call doing the bare minimum. I'm not passing judgement and I'm not angry at you for it. But everything you've described can be summarized as "I'm lazy and I get away with it."

If, on the other hand, you tell us that your manager has explicitly signed off on you working 5-10 hours a week, then would this not be laziness but rather a fantastic job arrangement.

View on HN

Eh, I've had multiple managers and all of them have been happy with the bare minimum.

I would not call that lazy. There is literally no reason to work more. Rather, I would call working more "passionate."

Let's normalize not selling your soul to your employer out of some misplaced sense of pride.

> Let's normalize not selling your soul to your employer out of some misplaced sense of pride.

That's a bit dramatic, I'd say.

The reason people can get away with working one hour a day is simply because software development is so abstract, that it can never be estimated or tracked accurately. This guy takes advantage of that, by giving his co-workers the impression that he's actively solving problems, when he's just kicking back and doing something else all day.

And respectfully, I suspect your managers were either not actually happy with someone literally delivering the least they could, or they were incompetent.

Maybe all of his coworkers are doing the same thing.

> You are very unlikely to be delivering "10x Developer" work.

The OP never said he thought he did. He was speculating if perhaps the reason he got good reviews (for a "1× developer") was because he is a "10× developer" delivering at 0.1× of his capacity, which works out to "1×".

Since when delivering 10x more code is objectively a better performance?

If we're talking about point samples, then no, it's not a good measure of performance. You may spend weeks fixing a single line in the kernel, meanwhile someone else cranks out hundreds of lines of verbose but straightforward UI code every week.

And also, we can all imagine a developer who cranks out gigantic commits by padding their comments, or just being verbose, or writing bad complicated code, or even just by moving code around to get big commit numbers. I'm not talking about that.

I'm saying, if you compare apples to apples, and look at a long time horizon (i.e., look at the total of an engineer's contributions over 6 or 12 months), then I claim that yes, generally speaking, there will be a correlation between productivity and LOC. I don't see how it could be otherwise. Software is code.

Edit: Hopefully it's clear that above only applies when comparing a pure-developer to a pure-developer. If your job also includes code reviews, writing design docs, etc, then obviously your LOC goes down.

I completely agree that using a median LOC over 12 or so months is much more representative. My point was that many times, especially when you are a senior programmer, you have a ton of other stuff to do like making or curating issues in Jira / GitHub, produce or edit documentation, make onboarding guides, introduce dev tooling, and many more. Normal coding can seriously take a back seat for literal months when you are senior and yet you still produce a lot of value.

So yep, with your clarification I am fully with you. As long as we measure people over a long enough timeline then yes, LOC can be an accurate metric. But a lot of other things have to be taken into account as well.

Perhaps not objectively, but PRs will often be reviewed during performance review season. So seeing someone at 10x less than someone else is a major red flag, as long as the quality of PRs is roughly equal.

I get where you are coming from but I still disagree that we should try and game the system like that. Instead our peers and CTOs should grow the "realism" brain lobe.

This hits even closer home to me because I am about to get evaluated this Monday and my PR performance has been pretty sub-par in the last 3-4 weeks -- I've been put in a project that has been abandoned for like 3 years and only recently picked up again and 90% of what I do is documenting and taking notes and creating GitHub issues; coding is sadly still a low priority activity because there's still chaos.

But you know what? I don't care anymore. Let them fire me if they use broken metrics. I am doing my work very diligently and I am making sure the project will be in a better shape after me. If they can't appreciate that then I am not bothered by such people viewing me negatively. They are in the wrong, not me.

LOC is just one within many signals your manager and organization should use in their review. If you have low LOC because the project was in chaos, or was still being designed and organized, etc... those would all be fine justifications to me as a manager. In fact, those would be problems for me to solve -- to make sure you are in an environment where you are able to be productive.

If, on the other hand, you were on a "smooth sailing" project, and didn't have any code delivered in the last month, that would be a red flag to me, which we would need to talk about.

I agree with that, yep.

It’s unfair to quantify it as amount of code, it might be excellent but longer programs and complexity isn’t always better for debugging, understanding, and maintenance even if performance is better simpler code that is lazier isn’t always worst.

Absolutely. I have a longer comment elsewhere in this thread to that effect. There are certainly plenty of Dragon-level bugs that takes weeks to debug, and then it's a single-line fix. A guy on my team once spent something like a month to figure out that the the race-condition in our application runtime was due to a fixed-sized array in linux kernel's library table. It was a one-line patch, and a hell of a debugging exercise. That guy rocked!!

But all things more-or-less equal, if one guy is landing 15 lines of code in the repo a month, and everyone else is landing hundreds a week or whatever, then that guy better be able to show that he is actually tackling really tough problems.

Yeah it’s really unfortunate that volume is spoken of as a good measure, like the failed idea that programmers need to write an amount to be considered productive. You can hire an inexperienced lawyer for less money and have the case take longer and maybe get more money, or they can be experienced lawyers who still know intricacies but need more time, effort, and work for a higher payout.

You get a quick experienced lawyer who charged you a lot more per session, you get advice that cuts down on busybody work and your case is simplified and you move on with your life to spend time doing other things.

Complexity is a trade off. It’s often seen as more work, but more work isn’t always better.

To run with your analogy, the OP's example is more like a lawyer you hire to do a job, and they do the job well and completely, just by filing a standard form on Monday morning... and then bill you for 50 hours. The job got done so there's no problem, right?

(* like all analogies, this one's obviously not perfect)

Reply on news.ycombinator.com