Developers should only be given spec’d out tasks with detailed use cases and an explanation of exactly what should be done.
Yep, sounds like someone with 3 YOE alright. Perfectly reasonable perspective for someone at that stage of their career.
Detailed explanation of what should be done?
That assumes that the user and ever stakeholder knows what the problem is, how best to solve it, and what technical options exist to meet them.
Which is to say the mindset is “I’m a mechanic, tell me what to do” and not “I’m an engineer. Let’s see what the problem is and then figure out what the real underlying problem is”
Lol. Nice.
In my decades doing this, I can honestly say I enjoyedboth times that happened for me. It was nice.
Twice? Nice!
In my experience it does not go without saying that a project needs a goal. Not a list of acceptance criteria or next steps, but WHY are we doing what’s being asked. It’s staggering how many times I’ve seen entire projects without a clearly defined goal or problem statement, and after 3 months the work was shelved. Management simply shrugged it off as, “That’s business for you – targets move,” when plenty of people on the front line were unsure what the point was and it would’ve taken a 10 min convo with the intended audience to learn that the feature was nowhere in their top 10 and they’ll never use it.
