This is a good question. It's an initial reaction, the fast thinking part of my brain. I suspect it triggers a sense of fear. Here are a few ideas as to why:

- They will think I'm either too slow or not working hard enough. - They will ask me to do it faster which may or may not be feasible. Pushing back on this may be hard. - The question itself adds extra pressure. Someone is waiting for me. - I feel like I'm being watched. - I feel like I'm being micro managed.

The anxiety doesn't last long. Once my rational brain kicks in I move past it quickly. I do wonder though if these small moments of anxiety build up over time.

Interestingly, when I wrote this original post I was thinking about when product managers ask this question rather than a direct manager. I haven't experienced this anxiety when communicating with my manager. The dynamic between engineers and PMs is an interesting one. I don't think the tension between the two groups is talked about enough.

I agree with your opinion. When someone is behind it's almost never because they aren't working hard. However, it's difficult for an individual to make that distinction. This is especially challenging for junior engineers. As I've become more senior this has been less of an issue.

I think schedules are either Parkinson's Law (work expanding to fill time) or things too tightly scheduled and about to fall apart. The only optimum is getting the schedule accurate, which causes anxiety.

The other problem is that programming is not simply "development", it's research too. Research can be a bottomless hole, and it's also really hard to estimate how much research is needed.

For example, maybe I just want to add an icon to my social media site that says this was fact checked. That doesn't seem too hard, but it also is, and it's complex enough that it's patented by LinkedIn.

> The other problem is that programming is not simply "development", it's research too. Research can be a bottomless hole, and it's also really hard to estimate how much research is needed.

This. As a programmer, I've never been able to successfully explain to my managers about this. It always ends up being a blame on me instead for "not properly assessing and estimating the effort".

This will continue to be a challenge because humans are simply not great at estimating. I have had success by explaining to managers that a big part of my job is to help them manage risk. In order for me to do that properly I typically need more information than is initially present so that I can give a high confidence estimate. I might say something like, "I can give you a low confidence ball park estimate right now but if you give me a few hours to research then I can greatly increase the confidence level."

After all, you know the least about a project at the beginning therefore no one should have a high degree of confidence in estimates given then.

Yeah, this was how I was trained to do it. A ballpark estimate on the spot at best is around 30% accuracy. I normally wouldn't give an estimate unless I can break it down the work into less than 4 hour chunks. Proper estimates also contribute to work done as it involves the design, but it's normal to spend a few hours doing estimation.

Trained managers are familiar with the cone of uncertainty, though.

But what I really mean is stuff on the level of powering a toaster with a car battery. It's certainly possible, but nobody has documented on what they did, and there's a very high number of uncertainties as neither were designed to perform this way.

I think you nailed it by pointing out how overlooked the research part of development is. Technical folks often understand this but it can be a challenging concept for people who have not worked as a developer. They can have a distorted view of the research to coding ratio. I imagine they often believe that writing code takes up 90% of a developer's time when in reality time spent researching and thinking is the dominant activity.

It's a common stressor because it's obviously going to be used to assess your job performance, and you need to put effort both into reporting accurately and making you look good. It can get excessive, depending on the quality of management. I've seen bad software managers essentially demand that devs live demo everything they're working on, three times a day, with no notice.

I find good managers are capable of measuring progress without demanding frequent "status updates". It varies from job to job, but I find getting frequent, small PRs (even to dev branches) works well.