5 ms·

Not a single mention of the word requirements. Software developers generally have two jobs: to figure out what to make, and to make it. They have to build the

Not a single mention of the word requirements. Software developers generally have two jobs: to figure out what to make, and to make it. They have to build the right thing, and to build the thing right. I don't put much stock in an article like this that doesn't even mention requirements engineering.

MattGaiser 6y ago
Whether this is part of your job probably depends on how your team is structured. I have yet to be on a team where the part about building the right thing was the engineer's role. There was a product owner or project manager for those decisions.
- onion2k 6y ago
  There's two sides to requirements. There's the functional "what is required to fulfil the user's need?" part which is very much in the product owner's domain, but there's also the non-functional requirements like "The feature must not compromise security" and "Performance metrics can't fall below X". Those parts are defined by the engineering team. Building the right thing is product, building it the right way is engineering, and they both feed in to defining the requirements for a feature.
  - Natsu 6y ago
    It seems to me like you basically need a programmer who has experience doing the actual job to specify what's needed. I've seen things get morphed from what the users need to what management wants and end up badly misaligned. You're also right that there's a gulf between what users ask for and what can be sensibly implemented due to security, etc. considerations. E.G. wanting SSL to just work and ignore all cert changes magically just isn't ever going to be secure.
- temac 6y ago
  You can, and should, write requirements and in more general all kind of specifications / high level pictures / architecture diagrams, for when you won't be around anymore, or even just for your future self. Maybe even more for your future self than for when you won't be around anymore, given that will impact you if you don't even if you are selfish, whereas you could just quit and not care anymore about remaining or new people. Of course you should not be selfish, but even if you are, write requirements.
marcosdumay 6y ago
Hum... Empathy, problem solving, communication, creativity, patience, humility and self confidence... What else is lacking for requirement gathering? I can't think about anything else. In fact the article is so generic it could fit any job. It basically says: be a well rounded person.
- temac 6y ago
  > Hum... Empathy, problem solving, communication, creativity, patience, humility and self confidence... What else is lacking for requirement gathering? Actually gathering and maintaining the fucking requirements in a useful way.
  - watwut 6y ago
    This is funny because it is true :D
swyx 6y ago
i don't put much stock in a comment that dismisses the article out of hand on an arbitrary requirement. ironic.
throwaway889900 6y ago
Probably because requirements engineering is a farce. I don't think I've ever worked with a set of requirements that wasn't ludicrously out of touch with actual engineering and prompted all the engineers to essentially ignore any requirements given to them, outside of very high level ones.

MattGaiser 6y ago

Whether this is part of your job probably depends on how your team is structured. I have yet to be on a team where the part about building the right thing was the engineer's role. There was a product owner or project manager for those decisions.

onion2k 6y ago
There's two sides to requirements. There's the functional "what is required to fulfil the user's need?" part which is very much in the product owner's domain, but there's also the non-functional requirements like "The feature must not compromise security" and "Performance metrics can't fall below X". Those parts are defined by the engineering team. Building the right thing is product, building it the right way is engineering, and they both feed in to defining the requirements for a feature.
- Natsu 6y ago
  It seems to me like you basically need a programmer who has experience doing the actual job to specify what's needed. I've seen things get morphed from what the users need to what management wants and end up badly misaligned. You're also right that there's a gulf between what users ask for and what can be sensibly implemented due to security, etc. considerations. E.G. wanting SSL to just work and ignore all cert changes magically just isn't ever going to be secure.
temac 6y ago
You can, and should, write requirements and in more general all kind of specifications / high level pictures / architecture diagrams, for when you won't be around anymore, or even just for your future self. Maybe even more for your future self than for when you won't be around anymore, given that will impact you if you don't even if you are selfish, whereas you could just quit and not care anymore about remaining or new people. Of course you should not be selfish, but even if you are, write requirements.

marcosdumay 6y ago

Hum... Empathy, problem solving, communication, creativity, patience, humility and self confidence... What else is lacking for requirement gathering? I can't think about anything else. In fact the article is so generic it could fit any job. It basically says: be a well rounded person.

temac 6y ago
> Hum... Empathy, problem solving, communication, creativity, patience, humility and self confidence... What else is lacking for requirement gathering? Actually gathering and maintaining the fucking requirements in a useful way.
- watwut 6y ago
  This is funny because it is true :D

swyx 6y ago

i don't put much stock in a comment that dismisses the article out of hand on an arbitrary requirement. ironic.

throwaway889900 6y ago

Probably because requirements engineering is a farce. I don't think I've ever worked with a set of requirements that wasn't ludicrously out of touch with actual engineering and prompted all the engineers to essentially ignore any requirements given to them, outside of very high level ones.