The only thing I'm getting better at with experience is my ability to say upfront that I'm not able to do the requested task.

It's worse when I say "I am gonna try and do some research".

Four weeks later "The task is beyond my skill right now 🤷‍♀️"

This is the way.

Manager: Can we do X in Y without any Z?

Juniors: yes, I can do that.
Mids: yes, but it'll take some time.
Seniors: nope.

@C0D4 Conclusion: let a junior do it.

Managers almost always see coding as a manufacturing process while in reality it most often actually is research and development. Therefore there are three types of tasks: Roughly known time, sortof unknown time and likely impossible. I mostly do unknown time tasks and bug fixing (which in my own code is often a known time task).

Don't just say no. Say whether you think the task being impossible or whether you likely just would have to research it and therefore don't really know how long it would take.

If you always say no to tasks you don't know how to do, you require out-of-band time to learn new skills. If you learn by doing you mix getting the theoretical knowledge while also getting experience in actually doing it on thje job. And you can learn to do things for which there are no tutorials.

That said, it all doesn't matter for code monkeys. They are expected to replicate what they learned and aren't leveling up anyways...

@Oktokolo For sure. I'm on several projects right now, and one of them is interesting since it's a stack I have absolutely no experience with, but the PO is very technical. The result is that he will ask me for an estimate and I can immediately say I have no idea and I'd have to look at it first. Then we agree on allocating a certain amount of hours to just start working on it before reporting back. Then we iterate like this as needed until I can give an estimate or we decide to reject the task. Despite me not having the right skills, that particular project flows pretty well due to that communication.

If you had given me the same task when I was straight out of school I'd have said "Should be easy!" without skipping a beat, then having to report back 2 months later with "So it turns out -".

@ltlian: Communication might indeed be key - i still never do that though...

the next big step is saying upfront: “the requested feature makes no sense “