Live data from Hacker News

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

arxiv.org

91–100 of 121 posts

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

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

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 intellectual pursuits and I keep getting interrupted maybe I'll do an admin task or fix some simple bugs. Also works for when something is stalled.

- acknowledge you cannot control everything - if the progress is delayed in ways the estimate didn't anticipate, document them and keep working

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

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

> There is a huge productivity difference between people that wake up in the zone vs any other zone

There is my secret. I am never in the zone, and neither is anyone else in my company since they’re asked for status updates, meetings and ‘war rooms’ every few minutes.

I guess the one positive is that it makes estimation easier :D

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

#94

Earlier quoted context omitted.

I (as a manager) always get a push-back when I try to impose my timelines on my team. Though we do have a healthy conversation as a result and we end up uncovering a bunch of unknowns which I then take it to my boss to inform them. When an engineer says they need 4 weeks instead of 2 it's my responsibility as a manager to get into the details, not as a way to micro-manage but to help my team be more confident about t…

> when I try to impose my timelines on my team As a senior developer, I don't like this sentence. If you want an estimate on a certain job, you ask your team. If you want to know what can be done in a fixed time-frame, you ask your team. I don't take "imposed" timelines well. In such scenario's, I make it very clear who is at fault when deadlines are not met (hint: it's not me or my fellow developers). When you push…

My "aha" moment on this was realizing the difference between estimations and commitments. If there is some probability distribution of how long a task will take, an estimation gets the median of that distribution. On the other hand, a commitment gets at least the 95th percentile of that distribution. Estimations are useful for general scheduling and resource management, while commitments are useful for having others waiting to get started as soon as a task is finished.

The biggest problem I run into is people not being clear (or not knowing themselves) whether they are asking for an estimation or a commitment. "How long do you think X will take?" sure sounds like a request for an estimation, but if they follow it up with "Great, I'll tell the customer it will be done by then.", they clearly were looking for a commitment instead.

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

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

Indeed, this is a standard cause of procrastination: the belief that our future selves will be more in the "mood" to do the work, while our current selves aren't. Unfortunately, in the future we will still be our current selves.

So, similarly, we give estimations based on this rosy picture of our future selves, who will somehow work the rest of the week in unbroken eight-hour stretches of concentration and flow.

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

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

In my case, I'm a "wee bit on the spectrum," so to speak.

The minus is that I don't relate with people on the same level as most. It used to be fairly crippling, but I learned to compensate, and these days, it's just a bit annoying.

The plus is a "flow" that is incredibly deep and productive.

I long ago, gave up on "scientific" estimates. They make good catbox liner; not much else.

Breaking a project into layers and explicit "packages" (modules) helps. It allows me to evaluate complexity a bit better; but it always ends up being my "gut." I've been developing software for more than thirty years, so it isn't actually a bad metric. I am a bit of a cynic and a pessimist. That helps.

But the thing that works for me the best, is "JIT estimates." I won't (as in refuse to) give an estimate for the long term. If someone has a project plan in mind, I will try to plan a scope that I "feel" will be doable within that scope, then reduce it. If it is just me, I'll reduce it by about 25%. If it is a team, I'll reduce it by at least 50%.

I will then avoid specific estimates until I start on a package/layer. If I think it will take longer than I'd like, up front, I may reduce the scope. It's easier when it's a small[ish], discrete, atomic job, as opposed to a months-long aggregate effort.

That said, in my experience, the boardroom will always have a classic waterfall schedule, and they are the ones that sign the checks. They aren't always thrilled with my approach. That's why I have waited until I'm running the show to do it.

I'm working on a project now, that is fairly ambitious. It's the kind of thing that usually requires a team of five to ten engineers, and I'm doing it on my own. Thankfully, a really significant part (the backend) is done, tested, and released (for a couple of years). That puppy took seven months. I've been working on a native iOS frontend for about five months, but took a break for almost a month, as I needed to give a class.

In this effort, the folks I'm working with have no choice. They have to abide by my schedule, as I'm the only one doing the tech work. They are actually thrilled with the speed at which things are coming together. I credit my "always ship quality" approach for that. It almost eliminates "QC surprises," and gives unmatched transparency.

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

#97
post #58

I interacted in a workshop with a person who taught about personal organization, and we had a phone session. I thought that it was important to fill your planning and calendar with fixed things. Instead she advised me to just plan week by week. I'm a freelance and honestly, it sort of feel better to be part of a bigger, organized group that tells you the things that are to do. When you're the only decider of your own…

I agree; regimenting your day is a poor substitute for short-term planning. It looks very orderly to have items like 9:00am, read email, 9:10am, Make sure Jira tickets are in correct states, 9:20am, respond to email, etc., filling your calendar from now until eternity, but it makes more sense to spend ten minutes at the end of every day planning the start of the next. Maybe you know your Jira tickets and email are in order and you can sleep an extra half hour. Maybe you have an important presentation in the afternoon and it would be best to spend 8am-9am nailing down the answer to a question you know will come up.

It's very hard but very important to stop working a few minutes early at the end of the day. You want to keep coding (or whatever) right up until the minute you need to stop, but that leaves you unknowingly disoriented at the start of the next day. You will either pick right back up with the coding, forgetting about everything else, or start aimlessly and waste the first hour of the morning trying to restore your awareness of priorities.

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

#98
post #10

An important thing I've learnt is that people over-estimate what they can do in a short time whereas they under-estimate what they can do in a long time. You probably wont finish that feature tonight, and that's OK. But you will have built something good in a year if you work on it a little bit consistently.

That's one of the big problems I see with enterprise agile development. Breaking up things into small independent parts never allows you to gain momentum on something. Pretty much everything I did that I am still proud of were done after focusing on the an issue for weeks or months until I/we had a very good grasp of the issue and built up the mental and code infrastructure to do cool things. You can't achieve this in 3 week sprints.

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

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

Regarding mental state: this study covers June 22, 2020 to the "present" (the paper is dated April 1, 2021, but I don't think it's an April Fool's joke). I suspect that people are to some extent calibrated to pre-pandemic expectations. I know I can't get things done like I could have in the Before Times, either because of mental state or because of more distractions at home than usual.

Figure 1(b) of the paper might suggest that people's estimates are worse on tasks that require flow, although I don't think there's enough data to be sure.

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

#100

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…

a) has the implication that you suck if you can't do it in two weeks. It's pretty sad that we can't state the cold, hard facts but have to lie.
Post reply on HN