Live data from Hacker News

You've only added two lines – why did that take two days?

mrlacey.com

111–120 of 522 posts

Re: You've only added two lines – why did that take two days?

#111
post #5

Do people actually have fights like this with management at their companies? Not trying to knock the author, but I'm just surprised anyone would actually hear this kind of comment in 2020. I'd think by now any and all metrics tying lines of code to productivity would be long dead.

Yes. The industry moves at a snail's pace, and is very different from what you'd read on HN. A huge % of dev jobs are still using old software/processes, with managers that haven't written software in 20 years, if at all. 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 mak…

sounds about right to me. i've had product managers argue that we fix bugs fast enough that we should not actually try to implement real solution (python2 to python3 upgrade). This lady is like 'every py2->py3 bug takes less than 2 hours to fix. Why would we do the solution that takes multiple sprints?'

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.

Re: You've only added two lines – why did that take two days?

#112
post #5

Do people actually have fights like this with management at their companies? Not trying to knock the author, but I'm just surprised anyone would actually hear this kind of comment in 2020. I'd think by now any and all metrics tying lines of code to productivity would be long dead.

Oh, very much so. I don't think it's a matter of how "old" the industry is - there will always be people who have never worked with software folks or are familiar enough with the ecosystem not to make the assumptions stated in the article.

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.

Re: You've only added two lines – why did that take two days?

#113

A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…

> They simply don't understand that the backend functionality is what's doing the bulk of the work

Even people who ought to know better don't understand this.

Re: You've only added two lines – why did that take two days?

#114

A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…

[deleted]

Re: You've only added two lines – why did that take two days?

#115
post #89

A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…

Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. When you do, it can easily confuse folks who aren't deeply involved in your project ("haven't I seen this already?") and can hurt team morale because they never get a "shipped it" moment that feels good. More to the point: enforcing this rule incentivizes teams to build things in small, shippable components. Nobody…

> incentivizes teams to build things in small, shippable components.

Isn't this a bit of a fallacy? Not everything can be broken down into chunks of work that fit into a single sprint.

There's a reason I stopped bothering with Scrum a while ago, and this is high on the list.

Re: You've only added two lines – why did that take two days?

#116
post #35
post #29

Earlier quoted context omitted.

I wouldn't say it is better, just different. Both have value. If you find a way to save millions, that might be quite worthwhile, because that might be easier than building something new that makes millions of dollars. It's all about ROI.

People shouldn’t downvote him. He’s right. i’ve done lots of small things to save time and money in the past. Management really doesn’t value it as much as making money or working on more visible projects. Telling someone that it only took me an hour to eliminate an hour of someone’s work every week doesn’t go far.

Someone was building an empire by having employees do manual data entry instead of parsing json files. All the way up the mgmt tree there are fewer direct reports. Nobody ever gets a job title promotion by having fewer direct reports.

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.

Re: You've only added two lines – why did that take two days?

#117
post #5

Do people actually have fights like this with management at their companies? Not trying to knock the author, but I'm just surprised anyone would actually hear this kind of comment in 2020. I'd think by now any and all metrics tying lines of code to productivity would be long dead.

> Do people actually have fights like this with management at their companies?

There was a time when I thought this video was funny:

https://www.youtube.com/watch?v=BKorP55Aqvg

Re: You've only added two lines – why did that take two days?

#118
One of my favorite contributions involved two commits: one that added 5 lines, another a bit later that removed a different 5 lines. This was after more than a week of building tiny models to understand how the system might behave. Thankfully I was on a team that appreciated it, although the reduced load on on-call quickly drove the point home :)

Re: You've only added two lines – why did that take two days?

#120
post #89

A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…

Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. When you do, it can easily confuse folks who aren't deeply involved in your project ("haven't I seen this already?") and can hurt team morale because they never get a "shipped it" moment that feels good. More to the point: enforcing this rule incentivizes teams to build things in small, shippable components. Nobody…

Also, never use the word "done" in any context in a meeting like that. Do not even say: "I'm not done". They won't hear the "not". Say, "Development is still in progress" or something similar. I got chewed out for something being released (where it was found to be broken) to a customer because I said something like: "I'm about 80% done with testing, but I haven't run into any issues yet." They released it even though it wasn't ready, and both the customer and I found that there were issues in that last 20% I hadn't reached.
Post reply on HN