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

311–320 of 522 posts

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

#311

Post by gitgud »

newshorts wrote: post #9

The assumption that asking for more information to recreate the bug is a lazy tactic to get out of the bug fix is also a terrible assumption and discredited the opinion IMO. Often times asking for more information can speed things up and lead to a quicker resolution.

Yeah I thought that was really bad advice, especially for incomplete bug reports. There's literally no harm in asking for more information to fix a bug, except for your ego...

A 5 minute phone call or direct message can save hours of hunting and frustration trying to replicate the bug...

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

#313

Post by saghm »

Jtsummers wrote: post #177
eikenberry wrote: post #162

Earlier quoted context omitted.

Did you really get chewed out? That seems pretty much like a deal breaker for me. Managers are collaborators, not parents, and have no place talking to co-workers in such a diminutive manner.

Yes. He came to my desk a week or so after he okayed the release of the software and took me to a conference room. I don't know how long he chewed me out for because I was red with rage but too terrified of losing my job to say anything. I've experienced similar rage with only one other manager [1]. He was 3 levels above me in the management chain, I really liked the two above me (the test manager, as I was in test a…

> He was 3 levels above me in the management chain, I really liked the two above me (the test manager, as I was in test at the time, and the software manager) and the guy above him [0]

I happen to get along really well with the person three levels above me, but I can't imagine dealing with getting direct negative feedback from him. Honestly, more of my conversations with him over the years have probably been about things unrelated to work than work-related; we don't just hop over my direct manager and his boss unless there's a really good reason for it.

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

#314

Post by deathanatos »

Izkata wrote: post #305
detaro wrote: post #159

Earlier quoted context omitted.

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...

Oh, that's actually also pretty reasonable (sorta): https://bugs.chromium.org/p/chromium/issues/detail?id=44872 I discovered that bug report after our designer noticed at a glance walking behind me (I use Firefox) that the colors on our site were far darker than she intended, somewhere around 2017-2018 (that bug was opened in 2010).

Yeesh my blood started to boil just reading that.

I've left companies because of devs like that. People who just stand in the way of getting the software to do the correct thing. I do not understand what makes these people tick.

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

#316

Post by giancarlostoro »

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.

If hes talking about JavaScript an alert dialog is a single line of code so I dont think its that bad. Also as long as frontend and backend have agreed on what certain objects structures will be hardcoding shouldnt be an issue.

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

#317

Post by cma »

touristtam wrote: post #71
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.

Task completion should be the metric, not line counts, otherwise the incentive is creating the most bloated piece of software and the most comprehensive unit-test possible. Any system is going to be (ab)used by the employee to their benefit.

Task completion as a metric incentivizes hacky approaches that cause issues down the line. You can counteract some with strict code review standards, but a bad job requires a longer review, and then the reviewers start falling behind in their task completion metric.

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

#318

Post by caseymarquis »

Let's not forget meetings. Advising on sales. Talking with customers about new features. Helping out tech support and services. Traveling to customer sites to review specialized requirements.

Or the real reason it takes 2 days is that the code base is a big ball of unbuttered spaghetti with no tests.

I was lucky enough to be able to rewrite a couple of products from scratch with the benefit of hindsight. When the code is loosely coupled and well organized, it's rare for any of the reasons listed in the article to stall development. When the code base evolved unpredictably over a couple decades, the article is spot on.

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

#319

Post by beachy »

Most of the article is good, but this is weak:

> If some code is throwing an error, you could just wrap it in a try..catch statement and suppress the error. No error, no problem. Right? Sorry, for me, making the problem invisible isn't the same as fixing it. "Swallowing" an error can easily lead to other unexpected side-effects. I don't want to have to deal with them at a point in the future.

I actually did work with someone else who did this sort of thing, however it is certainly not the normal in my experience, not for anyone who takes any pride in their work.

Including this one really devalues the "it took so long because I'm so professional" message IMO.

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

#320

Post by renewiltord »

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…

I currently do the opposite and I think it's the right way. Do the part that can provide quick validation first. Usually that's the front-end. You can find out if you're making the right thing pretty fast that way.

What are they going to do? Fire me? I can go anywhere. They can't find me anywhere.

Post reply on HN