PM in sprint review, after some colleagues complained about having to develop requirements on their own:
you are software engineers, your main task is to design software systems. this is the tricky part. coding is easy... it's a stupid task, i could do it, my nine year old daughter could do it.

shall i feel a bit offended? also i think, he is wrong... i also design while i'm coding, i'm designing all the time.
also, i love coding :( this is the most satisfying aspect of my job.
but then again, i heard there are people who code without designing... even though i cannot imagine how to work like that at all.

Depends on the context really. I've seen some devs whine and moan as soon as they have to use their brains to work out anything beyond standard boilerplate (this is particularly the case with some of the ex-consultancy guys), and want the PM to list every tiny detail in the task description itself. If that's the case I'd say the reaction from the PM was justified.

On the other hand, I've seen PM's give the most vague requirements possible for something that's most definitely *not* easy to "just write the code", and then whine and moan when devs rightly push back and explain the complexity, and that they need clarity on these requirements.

In the end, it's about selling a solution. There are different phases, and given the cost of a bugfix vs. project phase, such as given in https://deepsource.io/blog/... , getting the requirements right is a pretty responsible job.

At that phase, coding is largely irrelevant. That's what systems engineering is about, way before the product even exists as prototype. That is, unless even the customer has no idea about what the problem is, then something like rapid prototyping or agile makes more sense.

Not saying that coding is easy because it does have its own pitfalls, but I try to get out of coding and rather do system level engineering. Mostly because if you only can code, then you will have to compete e.g. with Indian outsourcing companies to justify your salary. If you can gain experience in requirements engineering, I'd take that as great opportunity.

"Developing requirements" means talking to users and working out what they want.

That's a PM's job, not a software engineer.

Completely agree.
While I can imagine how just writing gluecode and boilerplate would be like (hell), I never met any dev that was doing just that.

I don’t quite get the part where he expects you to be not just a coder but a software designer. Because that is what you seem to see yourself as.

> it's a stupid task, i could do it, my nine year old daughter could do it

What a clown 🤡 It might be fun to watch him or his daughter to actually try it

I would rephrase it.

The PM is the coordinator and the relay point of messages between customer / client / upper management.

As a dev, you're responsible for the code you write.

Responsible always means that you should think about what consequences your actions have.

Thus you have to speak up if there are negative consequences or if you think there is something fishy - and you should always check wether the bug ticket / task description "matches" with the code.

Match in sense of making sense / being plausible / ...

Otherwise, delegate to the PM with enough details that they can communicate with the client and come up with a new solution.

-----

"My nine year old daughter can do it".

If your nine year old daughter can do it, should I be worried and call child protective services as you've employed her?

(yes, I'd most likely ask a question. Such comments always... Poke my bad side violently.)

Ah, Good old delegation.

We design software/code/system/architecture, yes. Design product, no; unless it's my product or startup.

"my nine year old daughter could do it."

No she can't and neither can you!