4 ms·

Isn't that interesting? The job of exploring a theory or model to such an extent that it can be expressed in computer code always seems to fall on the shoulders

Isn't that interesting? The job of exploring a theory or model to such an extent that it can be expressed in computer code always seems to fall on the shoulders of a software developer. Other people can write specifications and requirements all day long, but until a software developer has tackled the problem, the theory probably hasn't been explored well enough yet to express clearly in computer code. It feels like software developers are scientists who study their customers' knowledge domains.

BobbyTables2 5mo ago
Agree 100%. Even the most verbose specifications too often have glaring ambiguities that are only found during implementation (or worse, interoperability testing!)
Twisol 5mo ago
> It feels like software developers are scientists who study their customers' knowledge domains. I agree so much with this. It's why I feel so stifled when an e.g. product manager tries to insulate and isolate me from the people who I'm trying to serve -- you (or a collective of yous) need to have access to both expertise in the domain you're serving, and expertise in the method of service, in order to develop an appropriate and satisfactory solution. Unnecessary games of telephone make it much harder for anyone to build an internal theory of the domain, which is absolutely essential for applying your engineering skills appropriately.
- Terr_ 5mo ago
  > so stifled when an e.g. product manager Another facet of this is my annoyance at other developers when they persistently incurious about the domain. (Thankfully, this has not been too common.) I don't just mean when there are tight deadlines, or there's a customer-from-heck who insists they always know best, but as their default mode of operation. I imagine it's like a gardener who cares only about the catalogue of tools, and just wants the bare-minimum knowledge to deal with any particular set of green thingies in the dirt.
- LandR 5mo ago
  This is why at my current place we are not supposed to do any dev without an SME on the call. We do the development and share the screen and get immediate feedback as we are working in real time! It's great.
- eithed 5mo ago
  This might be an indicator that PM isn't doing their job; PM should be able to answer you questions regarding what the business wants (= people who you're trying to serve). Developers, by the nature of interacting with domain, do become experts in the domain, but really it should be up to PM what the domain should be doing business-wise.
  - Jensson 5mo ago
    If that is what a PM needs then there aren't enough good PM to warrant a PM role for most products, so just make software engineers do that in most cases. Edit: The main role of PM is to decide which features to build, not how those features should be built or how they should work. Someone has to decide what to build, that is the PM, but most PM are not very good at figuring out the best way for those features to work so its better if the programmers can talk to users directly there. Of course a PM could do that work if they are skilled at it, but most PM wont be.
    - eithed 5mo ago
      > not [...] how they should work So that we're on the same page, what I think should be PM responsibilities: If I have a user story: "As a customer I want to purchase a product so that I can receive it at my address" - PM defines this user story as they have insight to decide if such feature is needed. PM should then define acceptance criteria: "Given customer is logged in When they view Product page Then 'Add product to basket' button should appear", "Given 'Add product to basket' button When customers click on it Then Product information modal should appear" etc - PM should know what users actually want, ie whether modals should appears, or not; whether this feature should be available for logged users only, or not. How this will work shouldn't matter to PM; these are AC they've defined. Of course the process of defining AC should involve developers (and QA), because AC should be exhaustive to delivering given feature
      - imperfect_blue 5mo ago
        The problem, in my experience, is that most PMs don't add anything when it comes to drawing up the acceptance criteria. In your example of an order placement - the PM has no special knowledge of what is a good customer order flow. Developers are usually way better at coming up with those by the dint of experience and technical knowledge of the current codebase and make the appropriate speed/polish trade-off. PMs acts as an imperfect proxy for what the customer wants, making judgements off nothing more than their own taste. And though there are many great PMs, the taste of a PM is usually worse than that of developers and designers on average. IMO the main business reason they exist is for organization accountability and ownership, despite the often negative value they bring.
kstenerud 5mo ago
In theory, it's the same as in practice. In practice, it isn't.
tsunamifury 5mo ago
Sorry this is just the interior trapped nonsense that engineers find themselves in. Please touch grass Product designers have to intuit the entire world model of the customer. Product managers have to intuit the business model that bridges both. And on and on. Why do engineers constantly have these laughably mind blowing moments where they think they are the center of the universe.
- Paracompact 5mo ago
  I agree so much with the both of you, to the point it's difficult to avoid cognitive dissonance one way or the other. Software people do what they do better than anyone else. I mean obviously! Just listening to a non-software person discuss software is embarrassing. As it should be. There's something close to mathematics that SWEs do, and yet it's so much more useful and economically relevant than mathematics, and I believe that's the bulk of how the "center of the universe" mindset develops. But they don't care that they're outclassed by mathematicians in matters of abstract reasoning, because they're doers and builders, and they don't care that they're outclassed by people in effective but less intellectual careers, because they're decoding the fundamental invariants of the universe. I don't know. I guess I care so much because I can feel myself infected by the same arrogance when I finally succeed in getting my silicon golems to carry out my whims. It's exhilarating.
- 0xpgm 5mo ago
  We keep seeing things like cryptic error messages shown to end users simply because of the disconnect between the programmer and the end user. If the programmer gets to intimately understand the user's experience software would be easier to use. That's why I support the idea of engineers taking support calls on rotation to understand the user. Both can be true at the same time, a product manager who retains the big picture of the business and product, and engineers who understand tiny but important details of how the product is being used. If there were indeed perfect product managers, there would no need for product support.
  - tonyedgecombe 5mo ago
    >We keep seeing things like cryptic error messages shown to end users simply because of the disconnect between the programmer and the end user. A lot of the error messages I'd write were for me, especially those errors I never expected to see. The typical feedback I'd get from end users is "your software doesn't work". If they can send me a screenshot of the error I'm halfway to solving the problem.

BobbyTables2 5mo ago

Agree 100%. Even the most verbose specifications too often have glaring ambiguities that are only found during implementation (or worse, interoperability testing!)

Twisol 5mo ago

> It feels like software developers are scientists who study their customers' knowledge domains. I agree so much with this. It's why I feel so stifled when an e.g. product manager tries to insulate and isolate me from the people who I'm trying to serve -- you (or a collective of yous) need to have access to both expertise in the domain you're serving, and expertise in the method of service, in order to develop an appropriate and satisfactory solution. Unnecessary games of telephone make it much harder for anyone to build an internal theory of the domain, which is absolutely essential for applying your engineering skills appropriately.

Terr_ 5mo ago
> so stifled when an e.g. product manager Another facet of this is my annoyance at other developers when they persistently incurious about the domain. (Thankfully, this has not been too common.) I don't just mean when there are tight deadlines, or there's a customer-from-heck who insists they always know best, but as their default mode of operation. I imagine it's like a gardener who cares only about the catalogue of tools, and just wants the bare-minimum knowledge to deal with any particular set of green thingies in the dirt.
LandR 5mo ago
This is why at my current place we are not supposed to do any dev without an SME on the call. We do the development and share the screen and get immediate feedback as we are working in real time! It's great.
eithed 5mo ago
This might be an indicator that PM isn't doing their job; PM should be able to answer you questions regarding what the business wants (= people who you're trying to serve). Developers, by the nature of interacting with domain, do become experts in the domain, but really it should be up to PM what the domain should be doing business-wise.
- Jensson 5mo ago
  If that is what a PM needs then there aren't enough good PM to warrant a PM role for most products, so just make software engineers do that in most cases. Edit: The main role of PM is to decide which features to build, not how those features should be built or how they should work. Someone has to decide what to build, that is the PM, but most PM are not very good at figuring out the best way for those features to work so its better if the programmers can talk to users directly there. Of course a PM could do that work if they are skilled at it, but most PM wont be.
  - eithed 5mo ago
    > not [...] how they should work So that we're on the same page, what I think should be PM responsibilities: If I have a user story: "As a customer I want to purchase a product so that I can receive it at my address" - PM defines this user story as they have insight to decide if such feature is needed. PM should then define acceptance criteria: "Given customer is logged in When they view Product page Then 'Add product to basket' button should appear", "Given 'Add product to basket' button When customers click on it Then Product information modal should appear" etc - PM should know what users actually want, ie whether modals should appears, or not; whether this feature should be available for logged users only, or not. How this will work shouldn't matter to PM; these are AC they've defined. Of course the process of defining AC should involve developers (and QA), because AC should be exhaustive to delivering given feature
    - imperfect_blue 5mo ago
      The problem, in my experience, is that most PMs don't add anything when it comes to drawing up the acceptance criteria. In your example of an order placement - the PM has no special knowledge of what is a good customer order flow. Developers are usually way better at coming up with those by the dint of experience and technical knowledge of the current codebase and make the appropriate speed/polish trade-off. PMs acts as an imperfect proxy for what the customer wants, making judgements off nothing more than their own taste. And though there are many great PMs, the taste of a PM is usually worse than that of developers and designers on average. IMO the main business reason they exist is for organization accountability and ownership, despite the often negative value they bring.

kstenerud 5mo ago

In theory, it's the same as in practice. In practice, it isn't.

tsunamifury 5mo ago

Sorry this is just the interior trapped nonsense that engineers find themselves in. Please touch grass Product designers have to intuit the entire world model of the customer. Product managers have to intuit the business model that bridges both. And on and on. Why do engineers constantly have these laughably mind blowing moments where they think they are the center of the universe.

Paracompact 5mo ago
I agree so much with the both of you, to the point it's difficult to avoid cognitive dissonance one way or the other. Software people do what they do better than anyone else. I mean obviously! Just listening to a non-software person discuss software is embarrassing. As it should be. There's something close to mathematics that SWEs do, and yet it's so much more useful and economically relevant than mathematics, and I believe that's the bulk of how the "center of the universe" mindset develops. But they don't care that they're outclassed by mathematicians in matters of abstract reasoning, because they're doers and builders, and they don't care that they're outclassed by people in effective but less intellectual careers, because they're decoding the fundamental invariants of the universe. I don't know. I guess I care so much because I can feel myself infected by the same arrogance when I finally succeed in getting my silicon golems to carry out my whims. It's exhilarating.
0xpgm 5mo ago
We keep seeing things like cryptic error messages shown to end users simply because of the disconnect between the programmer and the end user. If the programmer gets to intimately understand the user's experience software would be easier to use. That's why I support the idea of engineers taking support calls on rotation to understand the user. Both can be true at the same time, a product manager who retains the big picture of the business and product, and engineers who understand tiny but important details of how the product is being used. If there were indeed perfect product managers, there would no need for product support.
- tonyedgecombe 5mo ago
  >We keep seeing things like cryptic error messages shown to end users simply because of the disconnect between the programmer and the end user. A lot of the error messages I'd write were for me, especially those errors I never expected to see. The typical feedback I'd get from end users is "your software doesn't work". If they can send me a screenshot of the error I'm halfway to solving the problem.