Passionate full stack web developer, course author for Educative, book author for Packt, he/him.
Find my work and get to know me on my Linktree: https://linktr.ee/thormeier
Very well written and important article, thank you for this!
I also think that neglecting the "why" can be very harmful to the product. We as devs need to be active, but it can often generate frustrations for people working on the conception and the design. I imagine a well thought-through (albeit, for the sake of the argument, unnecessary) feature people spent werks on refining. When it comes to implementation, probably the last thing you want as a UX or business expert is a technician, who only learned about the feature moments ago, questioning all of your work.
I also remember reading an article ages ago that quoted a atudy about how different levels of detailing in prototypes made people question different things. If the design is already pixel-perfect, people might question if a button should be primary or secondary, whereas a lo-fi wireframe made people question the existence of the button. And that effect also very much takes place when it comes to implementation: an early idea is questioned on a more fundamental level than a very detailed ticket that covers every single edge case.
I think for people uncomfortable with asking "why" for whatever reason, both of these points further inhibit progress towards building the right thing. A more sustainable approach would be to advocate for early involvement in the process.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Very well written and important article, thank you for this!
I also think that neglecting the "why" can be very harmful to the product. We as devs need to be active, but it can often generate frustrations for people working on the conception and the design. I imagine a well thought-through (albeit, for the sake of the argument, unnecessary) feature people spent werks on refining. When it comes to implementation, probably the last thing you want as a UX or business expert is a technician, who only learned about the feature moments ago, questioning all of your work.
I also remember reading an article ages ago that quoted a atudy about how different levels of detailing in prototypes made people question different things. If the design is already pixel-perfect, people might question if a button should be primary or secondary, whereas a lo-fi wireframe made people question the existence of the button. And that effect also very much takes place when it comes to implementation: an early idea is questioned on a more fundamental level than a very detailed ticket that covers every single edge case.
I think for people uncomfortable with asking "why" for whatever reason, both of these points further inhibit progress towards building the right thing. A more sustainable approach would be to advocate for early involvement in the process.