[gemstones]

The opposite is “set vague deadlines and don’t check in on their progress.”

You’ll be accountable for team deadlines regardless - would you rather be allowed to sail over a deadline you didn’t know existed and be reprimanded for it by higher ups, or have a clear picture of deadlines and someone checking up on progress?

[ukj]

I am always incredibly surprised when people are surprised when I miss deadlines.

I said I was going to do it for the following (rather good!) reasons.

It is around that time when I am usually informed that I have zero autonomy over such decisions.

Now I know.

If I am not allowed any autonomy then could you please be explicit and upfront with all the trade-offs I am allowed to make, all the risks I am allowed to accept and the technical debts I am allowed to accrue?

Oh, don't be a perfectionist! I am not - I have no autonomy on such decisions. Here's a list of known defects - tell me which ones I am allowed to ignore.

Аpparently I am a difficult enginer. Meanwhile the leadership is outstanding.

[vasco]

I've had 1-1's with about 500 engineers between working with them or interviewing them. I honestly think you are being difficult under this described situation, yes. I mention the number only in case you'd trust that you are not alone in thinking this but:

A competent professional understands from context the amount of time available, the absolute requirements of the role (ie regulatory compliance, internal engineering practices, whatever), and their own sense of "would I put my name on this crap" and then says a number.

If you hire a plumber he doesn't ask you if you give him 2 days or 2 weeks or if he should use copper or plastic or if he should bring his good tools or his bad tools. He just gives you a reasonable estimate and does a reasonable job. If he is asked for better, he knows how to make it more robust by spending a little more time or using better materials, the same way you should know to make it scale up to more users or spend time refactoring into some better abstractions. But there is a bar that he won't go under and no amount of company policy or explicit bosses are gonna fix the fact that at the end of the day, it's a professional's job to predict how they are going to go about their work and how long they think it'll take.

[ukj]

A competent project manager in this undustry also understands that software engineering is not plumbing.

And the variance in effort due to lack of standardization, technical intricacy and hidden complexity is orders of magnitude greater than plumbing so our initial estimates always suck. Most competent proffessional in this insdustry know that nobody knows how to do accurate time estimates on delivering complex software projects, so why don't you know this and why do you want me to lie to you about the crudeness of my estimates?

Frankly, I've worked with hundreds of managers too and you sound difficult to work with. You seem to have unreasonable expectations that are impossible to manage with facts.

[vasco]

I'd say that my teams tend to meet the goals we set for ourselves (lol biased) without spending that long on estimation. We have an idea of our normal throughput and can use that to be somewhat accurate, and nobody gets shit if something ends up being harder than what we thought it was from our investigation, sometimes there are truly new things that are harder to predict. In those cases we take smaller chunks out of the big problem and focus on that first.

Anyway thanks for the advice on how it came across, I struggle with how to give this sort of view on things without coming across judgemental and I guess I failed here again, but I was honestly trying to say that I've seen your view shared before and I think the difference between you and other engineers that tend to be easier to work with isn't skills, it's just a slight difference in approach. But there's many different dystopian teams with unreasonable expectations for me to say that I'd think any different had I had the same teams and bosses that you had. Take care!

[gemstones]

Eh, for the majority of cases, software engineering is more like plumbing than like R&D. There are exceptions, like building a new DB, or similar. But if the tools you need to solve the problem are postgres + Django + react, there shouldn't really be that much hidden complexity for you to uncover.

[ukj]

So the domain model has already been made explicit and is implemented for you? All the design choices have been removed from you? You don’t have to do any actual software engineering - just extending business logic? That’s nice.

Your trivialization of the complexity is laughable.

The tools are "standard". The data models aren’t.

It's like plumbing alright. With random, unknown substances in the pipes.

[gemstones]

Plumbers don't get to decide how the pipes were laid out in the houses they come and work in, either - technically those are unknowns that could throw off a job. Doesn't mean it would be professional of them to insinuate that the variation in each individual building means they can't give a good faith estimate for a job.

[nine_zeros]

> I am always incredibly surprised when people are surprised when I miss deadlines.

I relate with this. Any skilled engineer worth their salt know that there are going to be a lot of unknown unknowns. Slippage is 99% guaranteed.

What surprises me is that managers are surprised at slippages. Like, did they ever engineer anything in the past?

> If I am not allowed any autonomy then could you please be explicit and upfront with all the trade-offs I am allowed to make, all the risks I am allowed to accept and the technical debts I am allowed to accrue?

This question is the one that irks managers. Because in reality, they want to be "own" only the successful decisions, not the failures. And they dare not ever clarify anything because it may end up leading to a failure. BUT, they also want to penalize you for the failure.

Managers are the biggest cop out there are.