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

201–210 of 522 posts

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

#201

Post by mcbits »

pkilgore wrote: post #140
mring33621 wrote: post #64

Earlier quoted context omitted.

Yes, very much like the time I replaced a getfakedata() method with a getrealdata() method and then management complained that it was much slower now.

After this (and a few emergent race bugs), I started burying the equivalent of setTimeout(() => getFakeData(), 1500) in my similar code. Best part is, I'm almost certain to beat 1500, so I've gotten compliments that it "feels snappier".

This reminds me of the infamous Speed-Up Loop. https://thedailywtf.com/articles/The-Speedup-Loop

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

#202

Post by neatze »

Jtsummers wrote: post #104
neatze wrote: post #76

Earlier quoted context omitted.

Where does program specification ends and where does program logic starts ?

Program logic error: // return the maximum value from an array return array.min(); Specification error: Only users with role X can access this content. [where X should've been Y] In the former case, a test should catch it (because the code isn't doing what we believe, per spec, it should be doing). In the latter case, only validation (confirming with customers) can catch it. Any test that is run against the code will…

What happens in case where specification is:

[User inputs X1, system displays Y]

On system crash user input was X2.

Is this specification or program logic error ?

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

#203

Post by AnimalMuppet »

chrisacky wrote: post #199
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…

I literally just had a discussion with a client last week about a feature taking 2months to develop.in my time this week I built the UI, with no backend, and she asked why I quoted two months when it looks like it's already completed.

Yes, it "looks like it's already completed" because you did the "looks" part. I get that you want to show them that part to get approval of the design approach, but it opens the door to misunderstandings like this.

Maybe as part of the demo, you should demo that it *conspicuously fails to actually do anything", to help reset unrealistic expectations.

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

#204

Post by symlinkk »

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…

To me it just sounds like your frontend has a better architecture than your backend.

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

#205

Post by seneca »

majormajor wrote: post #148
seneca wrote: post #52

Earlier quoted context omitted.

Completely valid question, and I think you make a great point here. A lot of baffling managerial behavior is because the manager is working in a baffling bureaucracy. Unfortunately, I think this situation was largely of the latter case, and maybe some motivations I'm not aware of. 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…

I agree with you on what a manager who doesn't know what they're looking at should do there. You gotta dig in and find out![0] 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 ma…

Well, just spit balling, but you should see it in team velocity. The effort you're spending coaching should show up in the output of your team members.

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.

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

#206

Post by csharptwdec19 »

kevsim wrote: post #36
WalterBright wrote: post #32

Earlier quoted context omitted.

Many people assume their manager knows what the employee is doing. They often aren't, meaning they go by what they can see, which is lines of code. 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.

That’s true. And I guess depending on the job/manager you could replace lines of code with “user-visible changes to app”, etc.

I've seen that abused all the way to management, where meaningless new features are prioritized ahead of bugs

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

#207

Post by reaperducer »

detaro wrote: post #159
touristtam wrote: post #74

Earlier quoted context omitted.

Try changing the colour and getting told it isn't the same shade of red as the drawings presented by the designer on his PDF presentation.

I mean, that's totally reasonable if that's the spec (not to mention hopefully trivial to fix). Now if there's 5 drawings with different colors, or asking "what color do you want it?" leads to a 5-week email chain...

that's totally reasonable if that's the spec

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.

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

#208

Post by csharptwdec19 »

duderific wrote: post #131
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.

They don't always make the comment out loud, but you can tell they're thinking it. 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."

"Okay. And when 5 years down the road you discover it's 10x as expensive to replace the floor joists. Why? Because you based the builder's performance on how many materials were in the house and as a result the piping in the basement is an overdone rats nest anyone maintaining the home has to work around."

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

#209

Post by csharptwdec19 »

dgb23 wrote: post #82
trav4225 wrote: post #65

Earlier quoted context omitted.

One would wish. Personally, I don't think I've ever worked under a manager who understood software development. It tends to be all about what they can see (GUI) or about nearly meaningless metrics on a dashboard (LOC, tickets closed, etc.). Again, just in my personal, limited experience.

The problem is not "manager/client doesn't understand software development". That's fine. 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 wor…

Bingo.

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.

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

#210

Post by tamrix »

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…

Don't blame your stakeholders or customers. These are all just communication issues and common ones at that.

Unfortunately communication for software projects isn't often discussed or considered valuable in this community but you can learn it like anything else in tech.

The hardest language to learn is the one that communicates with people not computers.

Post reply on HN