6 ms·

It is weird to me to see people talking like this. Throughout my 10+ year career as an SE, all the way from junior level to senior-plus, customer- and product-m

by tomc1985 4y ago

It is weird to me to see people talking like this. Throughout my 10+ year career as an SE, all the way from junior level to senior-plus, customer- and product-mindset thinking has been seemingly mandatory. Like how would I even write the software if I didn't understand what they wanted? What would I even do/what should I even write? We need to remember at all levels that it is people that use this stuff. Coincidentally, we are also people. So we should all be able to think as them. It is weird to me to be separated from my stakeholders. I can't say I really like having a PM in between me and them, other than having them sit in meetings instead of me.

MattGaiser 4y ago
> Like how would I even write the software if I didn't understand what they wanted? What would I even do/what should I even write? Whatever the ticket says. I have done plenty of work that I couldn't tell you where it fit into the product or what button one would click to make it run as we otherwise had unit tests to verify it.
- korijn 4y ago
  It sounds incredibly demotivating. Is it?
  - papito 4y ago
    I save that passion for personal projects. After all, the work is buying someone else a nice house and the new electric Delorian.
    - korijn 4y ago
      Well, unless your product makes a real positive impact on people's quality of life or the environment. :) Maybe I'm just fortunate to have such an employer. (Of course my CEO also gets rich in the process, but that's not the only "mission".)
  - egeozcan 4y ago
    Why should it be demotivating trying do something perfectly as requested? Many of us, including me, come from freelancing, and perhaps that trained many to answer most customer requests with "ok but what you really want is...", but in a company where there are people doing that as their job... Why bother? Actually I would even go further and argue that too many passionate developers talking product management in every refinement meeting is a big inefficiency, and depending on the company size, sometimes even one is one too many.
    - aidaman 4y ago
      lol because developing products that users want/work well for users is 100x more important than writing code.
      - egeozcan 4y ago
        Protecting the environment and sustainability is also 100x more important than that. Do we ever draw a line where our responsibilities end or as developers do we have to gather knowledge and make the best decisions until we reach singularity or the heat death of the universe? Delegating is okay, or you burn yourself out.
  - MattGaiser 4y ago
    Not at all. There are plenty of technical challenges that must be resolved within that. I can be fascinated by the plumbing without really understanding what the data is for. A lot of it is also personality. I am odd. Very odd. At times Sheldon Cooper odd. Know the exact seat I want on a 787 vs an A220 odd. That makes my empathy for users awful. I will spend tons of money on pain points in my life that make everyone else think I am nuts. I will completely ignore areas of life that are top priorities for most people. I obsess when making decisions and willingly read reems of documents to figure out all the rules. There are so many things that I do that normal people do not do. Because of that, I cannot create mass market products.I do not think anything like a typical user. I know my limits there.
    - korijn 4y ago
      That's fair! Thank you for the insight.
    - tomc1985 4y ago
      Empathy/sympathy are important factors here. As a fellow weirdo I do not see my weirdness as an excuse for being unable to 'walk a mile in their shoes'. There are lots of people around us constantly transmitting their emotional status, I see no reason to not pay attention to that.
      - MattGaiser 4y ago
        I have consistently found myself unable to do it well, so I outsource it. People may transmit, but I do not receive it with any meaningful accuracy.
    - aidaman 4y ago
      just because you're odd doesn't mean you can't empathize with others. that's a huge cop out.
  - krageon 4y ago
    Fundamentally any feature request is just an engineering problem. Sometimes they're interesting, sometimes they're not. If you trust whoever makes these issues on your board (or whatever it is you use), why would it be demotivating? You know you're building stuff folks want, because making sure that's the case is what the person making those issues is trying to do. If you can't trust your coworkers, every workplace is demotivating.
    - korijn 4y ago
      This is a fair argument. Thanks for engaging.
- tomc1985 4y ago
  That sounds disastrous. "Whatever the ticket says" is often ambiguous, poorly-written, or just plain wrong (in terms that the request is documented incorrectly and the requestor is not actually asking for what they want). Sometimes someone with technical inclinations gets too smart and thinks the solution is X when it is really Y. In my personal experience, it is much easier to clear this up going to the requestor itself, rather than asking a PM to clear it up. I ask them high-level questions like, "so, what is it that you really want here?" to try and suss out what the actual deliverable is. But I agree that if you have too many projects on your plate this is untenable. But then devs having too many projects on their plate is a pretty poor situation and is indicative of bad management.
  - MattGaiser 4y ago
    It is only disastrous if the PM screws up. It is certainly more brittle though as there is a single point of failure. You also need devs willing to persist in a social endeavour in the face of uncertainty until they get something solid and many are not.
    - aidaman 4y ago
      nope it's always disastrous. PMs don't know how to code.
leeroyjenkins11 4y ago
Because we are supporting too many products as it is and they are always asking for more? I get snippets from users, but I support so many different types of users and roles, it would take probably 6 months of only training to have a rudimentary understanding of all of those roles and the products we support that they use. And we implement SAFE "agile" and most of the time it seems like we are insulated from actual users. I got in hot water because I had the audacity to talk to a user because the client kept changing the flow after the inception meeting that ended up being the client solutionizing the project.

MattGaiser 4y ago

> Like how would I even write the software if I didn't understand what they wanted? What would I even do/what should I even write? Whatever the ticket says. I have done plenty of work that I couldn't tell you where it fit into the product or what button one would click to make it run as we otherwise had unit tests to verify it.

korijn 4y ago
It sounds incredibly demotivating. Is it?
- papito 4y ago
  I save that passion for personal projects. After all, the work is buying someone else a nice house and the new electric Delorian.
  - korijn 4y ago
    Well, unless your product makes a real positive impact on people's quality of life or the environment. :) Maybe I'm just fortunate to have such an employer. (Of course my CEO also gets rich in the process, but that's not the only "mission".)
- egeozcan 4y ago
  Why should it be demotivating trying do something perfectly as requested? Many of us, including me, come from freelancing, and perhaps that trained many to answer most customer requests with "ok but what you really want is...", but in a company where there are people doing that as their job... Why bother? Actually I would even go further and argue that too many passionate developers talking product management in every refinement meeting is a big inefficiency, and depending on the company size, sometimes even one is one too many.
  - aidaman 4y ago
    lol because developing products that users want/work well for users is 100x more important than writing code.
    - egeozcan 4y ago
      Protecting the environment and sustainability is also 100x more important than that. Do we ever draw a line where our responsibilities end or as developers do we have to gather knowledge and make the best decisions until we reach singularity or the heat death of the universe? Delegating is okay, or you burn yourself out.
- MattGaiser 4y ago
  Not at all. There are plenty of technical challenges that must be resolved within that. I can be fascinated by the plumbing without really understanding what the data is for. A lot of it is also personality. I am odd. Very odd. At times Sheldon Cooper odd. Know the exact seat I want on a 787 vs an A220 odd. That makes my empathy for users awful. I will spend tons of money on pain points in my life that make everyone else think I am nuts. I will completely ignore areas of life that are top priorities for most people. I obsess when making decisions and willingly read reems of documents to figure out all the rules. There are so many things that I do that normal people do not do. Because of that, I cannot create mass market products.I do not think anything like a typical user. I know my limits there.
  - korijn 4y ago
    That's fair! Thank you for the insight.
  - tomc1985 4y ago
    Empathy/sympathy are important factors here. As a fellow weirdo I do not see my weirdness as an excuse for being unable to 'walk a mile in their shoes'. There are lots of people around us constantly transmitting their emotional status, I see no reason to not pay attention to that.
    - MattGaiser 4y ago
      I have consistently found myself unable to do it well, so I outsource it. People may transmit, but I do not receive it with any meaningful accuracy.
  - aidaman 4y ago
    just because you're odd doesn't mean you can't empathize with others. that's a huge cop out.
- krageon 4y ago
  Fundamentally any feature request is just an engineering problem. Sometimes they're interesting, sometimes they're not. If you trust whoever makes these issues on your board (or whatever it is you use), why would it be demotivating? You know you're building stuff folks want, because making sure that's the case is what the person making those issues is trying to do. If you can't trust your coworkers, every workplace is demotivating.
  - korijn 4y ago
    This is a fair argument. Thanks for engaging.
tomc1985 4y ago
That sounds disastrous. "Whatever the ticket says" is often ambiguous, poorly-written, or just plain wrong (in terms that the request is documented incorrectly and the requestor is not actually asking for what they want). Sometimes someone with technical inclinations gets too smart and thinks the solution is X when it is really Y. In my personal experience, it is much easier to clear this up going to the requestor itself, rather than asking a PM to clear it up. I ask them high-level questions like, "so, what is it that you really want here?" to try and suss out what the actual deliverable is. But I agree that if you have too many projects on your plate this is untenable. But then devs having too many projects on their plate is a pretty poor situation and is indicative of bad management.
- MattGaiser 4y ago
  It is only disastrous if the PM screws up. It is certainly more brittle though as there is a single point of failure. You also need devs willing to persist in a social endeavour in the face of uncertainty until they get something solid and many are not.
  - aidaman 4y ago
    nope it's always disastrous. PMs don't know how to code.

leeroyjenkins11 4y ago

Because we are supporting too many products as it is and they are always asking for more? I get snippets from users, but I support so many different types of users and roles, it would take probably 6 months of only training to have a rudimentary understanding of all of those roles and the products we support that they use. And we implement SAFE "agile" and most of the time it seems like we are insulated from actual users. I got in hot water because I had the audacity to talk to a user because the client kept changing the flow after the inception meeting that ended up being the client solutionizing the project.