4 ms·

A good developer should ideally push their organization out of the ambiguous zone. Give feedback to whoever is writing requirements on the gaps. Otherwise, if

A good developer should ideally push their organization out of the ambiguous zone. Give feedback to whoever is writing requirements on the gaps. Otherwise, if you are in that ambiguous zone regularly, either you are pioneering some super new innovative area, or your organization isn’t very good at software development as a whole. One org I was at, the product managers constantly complained that developers couldn’t read their minds and automagically “know” all the non functional requirements, validations, etc. They were used to working with super senior devs who knew the space well, and could not adapt to devs who were more junior and also new to the industry vertical.

deleted 4y ago
[deleted]
m463 4y ago
Don't want to get out too early. I remember the waterfall model. Can't go back up a waterfall.
r_hoods_ghost 4y ago
My experience is that a lot of devs cannot or do not want to actually talk to users and learn how they use the software and what the need from it, and suggesting that they do this is considered an outrageous waste of precious dev time (I'm paid to code, not go to meetings). What's worse, is that a large part of the industry works to a set of tightly defined processes that are designed to buffer devs from users. I am talking of course about scrum, story points, product managers, scrum masters, product owners, rituals, etc. All the crap and layers of indirection that sit between devs and the people who actually use the software. Devs should be talking to and working with end users and building up an understanding of what users want and need from the software. I mean this literally. Actually sit with, work with, and talk to users, don't just communicate with them through an issue tracker. You sometimes see this in early stage startups, but even startups often end up designing for VCs or designing to be acquired, rather than designing for users. Yes users sometimes need training on how to communicate requirements, but it is up to devs to do this. Don't expect them to magically acquire this skill out of nowhere.

deleted 4y ago

[deleted]

m463 4y ago

Don't want to get out too early. I remember the waterfall model. Can't go back up a waterfall.

r_hoods_ghost 4y ago

My experience is that a lot of devs cannot or do not want to actually talk to users and learn how they use the software and what the need from it, and suggesting that they do this is considered an outrageous waste of precious dev time (I'm paid to code, not go to meetings). What's worse, is that a large part of the industry works to a set of tightly defined processes that are designed to buffer devs from users. I am talking of course about scrum, story points, product managers, scrum masters, product owners, rituals, etc. All the crap and layers of indirection that sit between devs and the people who actually use the software. Devs should be talking to and working with end users and building up an understanding of what users want and need from the software. I mean this literally. Actually sit with, work with, and talk to users, don't just communicate with them through an issue tracker. You sometimes see this in early stage startups, but even startups often end up designing for VCs or designing to be acquired, rather than designing for users. Yes users sometimes need training on how to communicate requirements, but it is up to devs to do this. Don't expect them to magically acquire this skill out of nowhere.