> I can articulate precisely what problem I am trying to solve.
It's appropriate to put this one first because it shows up in so many of the problems that follow.
Easier said than done when there's a deadline pistol pointing at your head. You gotta get stuff done. Show progress. Writing any kind of specification is just a slippery slope to Waterfall, geez. There's no time of any of that namby-pamby talking to and watching users BS. They don't know what they want anyway! Real developers ship!!
"I can articulate precisely what problem I'm trying to solve" is not just on that person. It is a function of their collaborators – product/program/engineering managers and other engineers around them.
If you are in a culture where it is acceptable to send tasks at each other without much context, and with harsh deadlines, and with a perf management system that rewards execution under such conditions, then you will get precisely the opposite of someone who can articulate what problem they are trying to solve.
In fact you will get a culture where asking questions for deeper 'why' understanding will be seen as disruptive.
Excess time pressure is behind so many problems. It's the thing I'm always most concerned to manage when I start a new gig. That said, shipping early and often is one of the best ways to mitigate excess time pressure, because it helps build trust between stakeholders and the team. The longer the release cycle, the more likely it is that business stakeholders will get antsy and start doing harmful things.
It's appropriate to put this one first because it shows up in so many of the problems that follow.
Easier said than done when there's a deadline pistol pointing at your head. You gotta get stuff done. Show progress. Writing any kind of specification is just a slippery slope to Waterfall, geez. There's no time of any of that namby-pamby talking to and watching users BS. They don't know what they want anyway! Real developers ship!!