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

“I’ll Finish It This Week” and Other Lies

arxiv.org

Post reply on HN
Print view View original

111–120 of 121 posts

Re: “I’ll Finish It This Week” and Other Lies

#111

Post by Dylan16807 »

BlargMcLarg wrote: post #52
Dylan16807 wrote: post #41

Earlier quoted context omitted.

While having the discussion could definitely be unpleasant and cause problems depending on how it goes, "having to spend time to push back that could be spent thinking about the problem" is a bit much. Half an hour isn't going to affect the deadline. The odds of "making a better idea later" aren't going to change significantly, either.

It isn't just half an hour. It's half an hour of being almost forcefully yanked out of the zone, which may lead to hours of lost efficiency. The idea that we just measure by the time it takes to talk to people plus a minor overhead, is part of why this is being normalized so often. Yet that idea has never been proven, and there is more suggestive evidence of the opposite. Nor has the value of such a "more accurate" e…

This discussion is part of planning that is already happening as part of the pre-work. There is absolutely zero need to take someone out of the zone to do it.

Re: “I’ll Finish It This Week” and Other Lies

#112

Post by pdimitar »

walterlb wrote: post #106
pdimitar wrote: post #81

Earlier quoted context omitted.

d) Tell my boss that THEY effectively suck at estimating and it will take 4 weeks. If they want less, I'll not sign under unprofessional work and they can get somebody else to do it.

My manager sometimes makes commitments to stakeholders on the spot when he agrees to take on the work, without consulting with the developer (me, in these cases). Often the requirements are not even clear yet. It's not comfortable to do, but I will jump in and veto his commitments right there if they are clearly not attainable. The stakeholders tend to be accepting of the fact that things are more complex to implemen…

Yeah, I get that blind enthusiasm sometimes but I've learned to control it. I show enthusiasm on my face -- and it's genuine! -- but I don't rush into promising. I found that to be the best balance because (a) people like it when you genuinely care and (b) you still don't come off as a pushover that accepts any demands for budget and schedule on the spot.

Re: “I’ll Finish It This Week” and Other Lies

#113

Post by tpoacher »

Foobar8568 wrote: post #86
tpoacher wrote: post #15

Honest question. Say you have a project. Your boss expects it can be done in two weeks. Let's say you are good at estimating your own velocity, and you estimate four weeks for that project. Do you: a) Tell your boss that you effectively suck and it will take you 4 weeks instead of 2? b) Tell your boss it will take two weeks and then blame delays when the deadline passes? or c) Tell your boss it will take two weeks, t…

I always do a, and that's why people think that I am slow and I don't have a great career...But at least I deliver stuff that works. At my previous client, I had a "IT supplier team lead" that kept promising stuff delivered in x days even tho that x months later, the stuff wasn't working. He was seen as a god. Nobody called on his bullshit but me, later on, management was telling me that I wasn't a team player, good…

yes, alas, that's exactly my point. The only peoply who are conscientious enough to go for (a) are also typically the same people who will pick up all the bullshit from people doing (b) and (c).

Re: “I’ll Finish It This Week” and Other Lies

#114

Post by tpoacher »

tremon wrote: post #46
tpoacher wrote: post #15

Honest question. Say you have a project. Your boss expects it can be done in two weeks. Let's say you are good at estimating your own velocity, and you estimate four weeks for that project. Do you: a) Tell your boss that you effectively suck and it will take you 4 weeks instead of 2? b) Tell your boss it will take two weeks and then blame delays when the deadline passes? or c) Tell your boss it will take two weeks, t…

Tell your boss that you effectively suck and it will take you 4 weeks instead of 2? No, I tell my boss that he sucks and it will take me 4 weeks instead of 2.

hahah, I like this.

Re: “I’ll Finish It This Week” and Other Lies

#115

Post by rurban »

halayli wrote: post #9

imo, the problem with estimates vs reality is that estimates don't include mental state. And just to clarify more about mental state, I am referring to being in the zone / flow, and individuals are healthy and experience normal stress / happiness levels. We assume and expect consistent productivity from ourselves. Anecdotally, In my 20 yrs experience, I've never heard a software engineer saying to their manager "add…

Overriding priorities has nothing to do with "bad mental state". It only has to do with changed priorities and scope.

Missed deadlines have to do with need to fix other more urgent stuff.

Re: “I’ll Finish It This Week” and Other Lies

#116

Post by swordsmith »

zikzak wrote: post #91
WhompingWindows wrote: post #85

Earlier quoted context omitted.

The solution for artists and writers is to work consistently. Obsessing about whether or not you're "in the zone" isn't productive. Instead, just get started, work every single day on your field. Seinfeld had a calendar and he had to write an X on every single day after he wrote jokes. I don't see why any high-functioning individual in any field couldn't learn something new every day.

This is also the solution for developers. You sit down and do the work. Some days are better than others. If you have rituals or strategies to maximize that productive time, that's great, but don't sit around waiting for the muse to inspire you. I find it helpful to have: - resumable tasks - I want to sit down and work, not sit down and figure out what to do - multiple projects - if today isn't a great day for intell…

> - resumable tasks - I want to sit down and work, not sit down and figure out what to do

I've found this indeed helps me get back to productivity. But at the same time, if I know what exactly needs to be done, it would be hard for myself to stop until it's finished. And that's when multi-day coding binge happens, followed by a few days of fatigue and low productivity. Kind a of a catch-22 for me...I wonder if there's anyway to be moderate about it.

Re: “I’ll Finish It This Week” and Other Lies

#117

Post by Gravyness »

torgard wrote: post #31
tpoacher wrote: post #15

Honest question. Say you have a project. Your boss expects it can be done in two weeks. Let's say you are good at estimating your own velocity, and you estimate four weeks for that project. Do you: a) Tell your boss that you effectively suck and it will take you 4 weeks instead of 2? b) Tell your boss it will take two weeks and then blame delays when the deadline passes? or c) Tell your boss it will take two weeks, t…

I go with a) every time. I would find anything else to be unprofessional. I don't "effectively suck", I disagree with them on the timing. I'll explain my reasoning, and if they cannot accept that, then it's out of my hands; they have chosen to cut corners.

Have seen companies fire people for that. Sometimes you can't afford that.

Re: “I’ll Finish It This Week” and Other Lies

#118

Post by hinkley »

halayli wrote: post #9

imo, the problem with estimates vs reality is that estimates don't include mental state. And just to clarify more about mental state, I am referring to being in the zone / flow, and individuals are healthy and experience normal stress / happiness levels. We assume and expect consistent productivity from ourselves. Anecdotally, In my 20 yrs experience, I've never heard a software engineer saying to their manager "add…

Energy.

I’ve seen a couple ugly conversations where someone didn’t understand why an engineer couldn’t do 2 tasks that take half a day/week/sprint in the same time interval, and it comes down to both of those tasks being very high maintenance, or requiring a high degree of concentration. It may only take 20 hours to complete but it sucks up 30 hours worth of energy. You need something brainless for the other 20 hours, not a second task of that ilk.

Re: “I’ll Finish It This Week” and Other Lies

#119

Post by hinkley »

DoingIsLearning wrote: post #14
xcambar wrote: post #11

Estimates are here to fail, but they're nonetheless crucial: * set an estimate, you'll deliver in 1.5x your estimate * don't set an estimate, you're losing total control over delivery (rarely for the better, even though that may happen) In other words, estimates are not a tool of delivery planning, but of risk management : they are here to help limit time dilation.

I will paraphrase a former Japanese manager who taught me a lot about designing for production: "Plans will always fail but we must always have plans."

All models are wrong but some are useful.

Re: “I’ll Finish It This Week” and Other Lies

#120

Post by zikzak »

swordsmith wrote: post #116
zikzak wrote: post #91

Earlier quoted context omitted.

This is also the solution for developers. You sit down and do the work. Some days are better than others. If you have rituals or strategies to maximize that productive time, that's great, but don't sit around waiting for the muse to inspire you. I find it helpful to have: - resumable tasks - I want to sit down and work, not sit down and figure out what to do - multiple projects - if today isn't a great day for intell…

> - resumable tasks - I want to sit down and work, not sit down and figure out what to do I've found this indeed helps me get back to productivity. But at the same time, if I know what exactly needs to be done, it would be hard for myself to stop until it's finished. And that's when multi-day coding binge happens, followed by a few days of fatigue and low productivity. Kind a of a catch-22 for me...I wonder if there'…

I am not able to do that now. I have a family that needs to be there. When I was younger, sure, I'd pull all-nighters. But those days are gone. When I work now,I have to use my time wisely and be laser focused. I also found when I was working crazy hours, the quality of the code wasn't great. I learned to sleep on problems, then I'd solve them quickly first thing in the morning.
Post reply on HN