4 ms·

The article doesn't say who should be asking these questions. I hate to say it, but sometimes "ordinary" software programmers (the most dangerous are the kind

The article doesn't say who should be asking these questions. I hate to say it, but sometimes "ordinary" software programmers (the most dangerous are the kind with just a little experience but not enough to know that they don't know) will start to feel that they should be asking these questions of the people asking them to build something. It's a good sentiment, but often (especially when there are sales/competitive/pre-emptive/other factors) at play, they're straying a little into "too big for your britches" territory and should just build what they're asked to. Leave the questioning to the engineers who both know how to build it in their sleep, and understand why it's needed...

jbf1001 7y ago
As a counter-point, I think it is good to also consider that even the wrong people asking the right questions is better than no one asking them. I think discouraging fledgling developers from asking these questions is a short-sighted choice. I believe a better choice is to have an environment where they can be guided to the right answers, even if they are "too big for their britches".
codingdave 7y ago
But how do you expect junior devs to get those skills, if your response to them when they try is, "Stay in your lane."
preommr 7y ago
For any business, the people responsible for a managing a project will also be the people that are both experienced and informed about various important factors that come from being at the level both related to the business and in terms of management skills. If a new dev asking a questions is enough to derail a project there were bigger issues at play.
duxup 7y ago
Everyone should be able to ask, that's how they learn, and sometimes that guy down in the trenches knows something that is in the plumbing that other folks don't automatically know.
closeparen 7y ago
At my employer, engineers at every level are accountable for their work's business impact more than anything else. It is always your responsibility to understand and be convinced of the value of what you're doing, and to escalate your concerns or transfer out of the team if you're not. "The product requirements were ill-conceived but I executed them well" will not save you at performance review time, even if you're a new grad. A competent PM has considered these questions carefully, and most of their thinking should be written down and circulated before the project starts. They will happily discuss lingering questions with anyone interested.
poulsbohemian 7y ago
I'd like to better understand your angle / experience here... it seems to me like death march projects start when questions don't get asked up front and/or developers put their heads down and do what they are told instead of being proactive in heading off challenges.
Supermancho 7y ago
These are product-centric questions. > What business risks or blockers exist? Thats not a question that's readily available to developers, nor is it relevant until the project comes up in planning.
- waynesonfire 7y ago
  why not? developers are a key part of a business and shape it. they should certainly be paying attention to managements initiatives and what risks or blockers these may present to the project at hand. this would encourage alignment and clarification.

jbf1001 7y ago

As a counter-point, I think it is good to also consider that even the wrong people asking the right questions is better than no one asking them. I think discouraging fledgling developers from asking these questions is a short-sighted choice. I believe a better choice is to have an environment where they can be guided to the right answers, even if they are "too big for their britches".

codingdave 7y ago

But how do you expect junior devs to get those skills, if your response to them when they try is, "Stay in your lane."

preommr 7y ago

For any business, the people responsible for a managing a project will also be the people that are both experienced and informed about various important factors that come from being at the level both related to the business and in terms of management skills. If a new dev asking a questions is enough to derail a project there were bigger issues at play.

duxup 7y ago

Everyone should be able to ask, that's how they learn, and sometimes that guy down in the trenches knows something that is in the plumbing that other folks don't automatically know.

closeparen 7y ago

At my employer, engineers at every level are accountable for their work's business impact more than anything else. It is always your responsibility to understand and be convinced of the value of what you're doing, and to escalate your concerns or transfer out of the team if you're not. "The product requirements were ill-conceived but I executed them well" will not save you at performance review time, even if you're a new grad. A competent PM has considered these questions carefully, and most of their thinking should be written down and circulated before the project starts. They will happily discuss lingering questions with anyone interested.

poulsbohemian 7y ago

I'd like to better understand your angle / experience here... it seems to me like death march projects start when questions don't get asked up front and/or developers put their heads down and do what they are told instead of being proactive in heading off challenges.

Supermancho 7y ago

These are product-centric questions. > What business risks or blockers exist? Thats not a question that's readily available to developers, nor is it relevant until the project comes up in planning.

waynesonfire 7y ago
why not? developers are a key part of a business and shape it. they should certainly be paying attention to managements initiatives and what risks or blockers these may present to the project at hand. this would encourage alignment and clarification.