Live data from Hacker News

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

mrlacey.com

391–400 of 522 posts

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

#391
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…

> Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done.

I've learned this adage years ago (I think it was from Spolsky), but nowadays I'm in a project (re)building an UI from scratch as a sole developer aaaand I made the same mistake.

I was doing some UI prototypes about activating a process, big green Activate button, opens up a confirmation dialog, spinners with some artificial / simulated delay because I didn't do the back-end, and it caused confusion with our tester because she was wondering if activation actually works.

I've got three options; remove the button for now (I should do that), partially implement the activation (changing a status in the back-end), or fully implement the activation (which has a lot more prerequisites).

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

#392
post #379

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…

While I agree, the feedback I get from a session like that is useless: "While you mentioned this during the demo, I noted: 1. Your state-drop down has only 3 entries. 2. There is a validation error 3. You get an error at the end. We need you to fix this ASAP !!!"

Yup, that'll happen, and if you omit it entirely you can get comments going "I'm not seeing this field!".

Would it be better to show no progress at all until it's completely done? I know agile methodologies tell you to demo regularly, but I'm more and more under the impression that they are to provide progress feedback / reports to management.

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

#393
I sympathize with this, but taking two days to add two lines of code is unproductive. Sorry, that's just not a lot of output. Two-day bugs happen, but they should be rare. The real question is: is this rare, or is it typical for this developer?

IMO the real problem is trying to evaluate an employee's productivity on the scale of two days. There isn't enough context to understand the situation.

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

#394

+2 lines? That's rookie numbers! https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

My personal best was -112,000 on a legacy project.

The code base was full of commented out code (the best case scenario as you know immediately it can be deleted), methods which had been deprecated and replaced with ‘myMethod2()’ and eventually ‘myMethod3()’ with all of them still in the class (and for extra fun, it wasn’t always the case that all references had been updated to the newest method), and thousand line blocks of code which static analysis helped me pick up were actually not possible to ever actually execute, etc.

Basically a static analyzer with an analysis mode for finding dead code just flagged pretty much the entire codebase.

And in the process I split a totally unrelated project which had been grown inside that codebase like a tumour into its own codebase.

Needless to say two weeks of my time invested really pepped up development velocity for that team.

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

#395

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…

Today I gave advice to wifes friend friend. Who wants to build something "like ebay or amazon". (but cannot programm and wants to contract) Well, after a while they understood, there is a small difference, between a website - and a virtual market place. Seriously, it is easy to forget, that for most people, all these technical things - is just dark magic in a black box. Which sometimes work and sometimes won't. And I…

FB Marketplace - or, you know, actually ebay or amazon - are all viable if said friend just wants to sell some shit online.

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

#396
post #248

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…

There was an old look & feel for Java UIs that made them look as if they were drawn on the back of a napkin, specifically as a reminder that the code was a work in progress: http://napkinlaf.sourceforge.net/

Yeah there's CSS themes that look like either sketches or with gratuitous comic sans as well.

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

#397
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…

> Engineers took to committing/removing things like node_modules directories to make the data meaningless.

Poisoning the well, I like it.

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

#398

Earlier quoted context omitted.

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 m…

Did you write something with fake data that trended upwards every week so all of you got raises and bonuses regularly?

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

#399

Earlier quoted context omitted.

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,…

Honestly, product managers should be told to fuck off when it comes to the engineering part of the job - they have their job, you've got yours. You stand for your product, they have to work with the reins they've been given (in terms of productivity of their team) without trying to micromanage it.

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

#400

I sympathize with this, but taking two days to add two lines of code is unproductive. Sorry, that's just not a lot of output. Two-day bugs happen, but they should be rare. The real question is: is this rare, or is it typical for this developer? IMO the real problem is trying to evaluate an employee's productivity on the scale of two days. There isn't enough context to understand the situation.

You CANNOT make any statements about whether or not a code change is productive / unproductive if you do not know the context. It doesn't work like that. Take any random commit on https://github.com/torvalds/linux/commits/master; most change just a handful of lines but I can guarantee that each of them represents a significant time investment in analyzing, documenting, discussing and testing the code change in question.

I mean I get where you're coming from, if your job is basic data wrangling (webapp -> rest API -> back-end -> database and vice-versa) then you don't need to put too much thought into it and just need the output. But that's only one part of software development.

Post reply on HN