Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mrlacey.com

Post reply on HN
Print view View original

321–330 of 522 posts

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

#321

Post by musingsole »

l0b0 wrote: post #268
kevsim wrote: 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.

So far I've worked in one place which didn't use version control in 2007, one place which had reluctantly started using version control just before I started in 2010, several places where automated tests were considered pure waste, where everybody had full access to production, where backups were untested, where one or two people held crucial knowledge which was not shared with anybody else, etc. The real world moves…

Devil's advocate: or best practices are rarely incentivized...because there's little to connect them with real, tangible value in an organization. Having fully linted, automatically tested code doesn't matter if the product isn't valuable and useful. And if the product is truly valuable and useful, it likely would be as well in the absence of these practices.

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

#322

Post by john61 »

caymanjim wrote: post #31

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…

Yes the incompetence in IT is astonishing. For a lot of folks IT is pictures that respond to clicks.

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

#323

Post by ravenstine »

alexbanks wrote: post #98
kevsim wrote: 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…

This reminds me of a story from my first job.

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.

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

#325

Post by hinkley »

BurningFrog wrote: post #61
0xEFF wrote: post #20

Earlier quoted context omitted.

It’s better to find ways to make more money than to save it. There’s a floor but no ceiling in much of what we do.

If your revenue can grow exponentially, that's probably the right priority. Most companies aren't like that though. Know your company! Also consider if you can run out of money before growth kicks in...

Companies that only ever learn to spend money to make money tend to flame out when their market matures. They never learned how to sustain.

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

#326

Post by T-hawk »

Jtsummers wrote: post #244
tardismechanic wrote: post #241

Earlier quoted context omitted.

> that's on them and you are absolutely 100% free to leave. Not if you are on an H1B visa ;-)

Well, that gets to my other lesson: Save money aggressively so I'm not beholden to any employer. It's harder when you're taking care of a family on one income (and not making FAANG money), but I saved aggressively when I was young and single. I never actually had to use that option, but I was in a position where I could have lived (as a single healthy guy with no debt) for 4-5 years without needing a paycheck. I woul…

Look up the 72(t) rule relating to a 401k. You can retire early and start withdrawals at any age without penalty, as long as you continue the withdrawals for sufficient time (the longer of five years or until age 59.5.) This fixes the "too much in the 401k" situation.

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

#327

Post by T-hawk »

Izkata wrote: post #297
dorkwood wrote: post #294

Earlier quoted context omitted.

> My main mistake was putting too much in my 401k Can you expand on this? I recently moved to the US and people keep telling me to get a 401k, but I haven't yet.

A 401k is specifically a retirement account - you pay an extra 10% for withdrawing from it before age 59.5, which should add context to the rest of their paragraph.

Look up the 72(t) rule relating to a 401k. You can retire early and start withdrawals at any age without penalty, as long as you continue the withdrawals for sufficient time (the longer of five years or until age 59.5.) This fixes the "too much in the 401k" situation.

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

#328

Post by gibolt »

bfdm wrote: post #309
kgermino wrote: post #266

Earlier quoted context omitted.

> Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. I take a different but similar approach when I run into situations where I want to get something small in front of a business user before it’s completely ready: I make sure it’s visibly broken in a way that doesn’t detract from my goal for the meeting. For example: I have a registration form that I want to talk th…

Honestly, that feels like a huge waste of your own time to game a broken system. And I'm guessing it is, but that it's a defensive move because the darker timeline is miserable. Sucks it has to be this way so often.

I've done this on quite a few occasions as well. It isn't necessarily time wasted, as you evoke a positive view from the client (progress towards the solution) and often get valuable feedback.

The alternative is that they think you are done, adding more pressure, and requiring more wasted time later explaining the mis-aligned expectations.

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

#329

Post by l0b0 »

snidane wrote: post #278

"My point today is that, if we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger." ~ Edsger Dijkstra

I'm sure Dijkstra could get away with saying that, but how would you phrase something equivalent to someone above you in the food chain without getting nuked from orbit in response? I can just see how the conversation would go:

PHB: You've only added two lines - why did that take two days!

Dev: Because it took that long to understand the requirements, understand the code, find the root cause, write a test to verify the root cause, and then 2 minutes to write the code to fix it. The resulting code verifiably fixes the root problem for at least reasonable inputs, with minimal code and thus minimal chance of a bug.

PHB: Why not add 50 lines of code and be done in an hour?

Dev: Because that would be enormously more likely to be buggy.

PHB: But it would fix the symptom, right? Don't let perfect be the enemy of the good!

Dev: 50 lines would not to be "good", it would be crap. And we would have to revisit that code in a week or a month.

PHB: But in the meantime we will have delivered, dammit! We're on a deadline, with three managers and five customer representatives breathing down my neck, and you're telling me you want to spend two days on something you admit could be fixed in an hour?

Dev: I never said I could, only that 50 lines would be a crap solution.

PHB: Are you calling me a liar? Or just an idiot?

[Continue until the developer is fired or gives in, loses hope in humanity, and starts planning their exit.]

Thankfully I have never worked with someone like that, but if the starting point is as bad as the first sentence above then it's only going to go downhill from there.

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

#330

Post by webreac »

ftio wrote: post #89
caymanjim wrote: post #31

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…

For me, the purpose of the "demo" is to get agreement on specifications and to remove ambiguities. This can also be used to reassure that the requirements of the client have been well understood.
Post reply on HN