4 ms·

>Why do you do it? Because I enjoy the process of making software. >Do you see this as enshitification? No, I see this as needing to make a trade off where t

>Why do you do it? Because I enjoy the process of making software. >Do you see this as enshitification? No, I see this as needing to make a trade off where the result ends up with one party gaining something and consumers losing something. >Just need to pay the bills? No, money is not a motivating factor. >can't find a different job? I have no reason to switch job, but finding a different job wouldn't be an issue. >Think "someone else will do it if I don't?" These companies are not masochists trying to exclusively hurt consumers. There are a lot of trade offs that happen between multiple different parties. A company is not going to be able to make the best possible product if in every single tradeoff they give priority to the consumers (you also can't make every single subgroup of consumers all happy with some things). Sure someone could execute on the tradeoff being made, but I don't need any kind of justification for me to stay at my job. I want to see all the relevant parties benefit from the existence of the product. If I disagree with a tradeoff being made I can raise that. What tradeoff to make is a hard decision that people don't always get right, sometimes they were missing available information and some information they may only be able to speculate on. In the future these tradeoffs can be reevaluated.

godelski 3y ago
Thanks for the response. Do you think these trade-offs are actually meaningful? I can see how they might be useful in the short term, but at least to me they seem clearly poor strategy long term. It is unclear to me what exactly is gained by such actions. It is mentioned that preventing users from destroying their devices is a motivation, but I think this is such a limited set of users and I'm not sure letting more technical users bricking their devices is going to result in reduced sales. It does also result in others fixing your code for you if they can debug and inspect them. (So many times I just want to fix shit code but it's closed) It seems hackers and motivated actors are always able to get in anyways so I'm not sure what the real cost is. I think you might see things differently.
- charcircuit 3y ago
  >Do you think these trade-offs are actually meaningful? Yes, and it can be frustrating when your person want as a user may be different than what will be best for the most people. I do think there are a couple issues. The first is that reevaluating something, making a different tradeoff, and changing the product can be very expensive. Even if it's not be expensive alone, the opportunity cost may be higher and engineers could be working on something more impactful. The second issue is that the product will often target the needs of the majority of needs which means that the needs of power users may not be listened to very well. The solution to these issues are competition and extensibility. The work of making a version of the product for niche users can be done by a niche company and that can work out.
  - godelski 3y ago
    I think these are reasonable points. But are they necessary? I'm a researcher, so not your typical programmer. But I'm wondering if there are some aspects that might overlap. I do program a bit differently from my colleagues. I know I'm going to change my code a lot and have to try a lot of different things so when I go into writing I prioritize flexibility. I know whichever direction I'm starting in is wrong and I'm gonna learn a lot on the way. It's a bit slower to start but ends up faster in the long run and ends up letting me parallelize a lot more (because I can get to a state where I submit jobs to run over different parameters and can rely on it running for days). It did definitely take a bit to get into this style, but I feel much better about my code now. Do you think these lessons I learned are relatable to the area you work in? To me the key difference is between short term and long term goals. Short term I am very hacky but it's just that that isn't sustainable so I imagine this is analogous to actual products. But it seems that it is addressing a similar problem of flexibility and changing directions. I also have the habit of documenting while I code because I forget what I did in a few weeks (side benefit, others can onboard very easily). And whenever I get handed code I find myself being more productive rewriting routines rather than using what was handed to me that has zero documentation and is typically made for a very specific use case. Do you have a different experience? Because I've been working in a group building a product and this has been my life for the last 6 months... I guess what I'm after is I have a predisposition to think more openness is more beneficial in the long run but closed is better in the short run. I also think the not listening to power users plays into this. I'm reminded of this post[0] where other users are mentioning similar experiences. I can attest that in my experience most bugs I've seen are system independent but have experienced being quickly dismissed with "unsupported OS" and closed. Including just using a different flavor of the supported distro. (or to read the docs despite referencing the docs in my issue) [0] https://news.ycombinator.com/item?id=28978086 https://news.ycombinator.com/item?id=28978086 Edit: Keep posting and we'll get you to your "goal" lol
    - charcircuit 3y ago
      To your first point flexibility is not free. You have to choose when to be flexible and when to make assumptions to make things simple. Flexibility can only reduce the cost of making changes, but not eliminate it entitely. >whenever I get handed code I find myself being more productive rewriting routines rather than using what was handed to me that has zero documentation and is typically made for a very specific use case. Their is a cost to rewriting code. Code can have all sorts of information and knowledge for handling things correctly baked into which makes rewriting hard to do at scale without having a strong understanding of the problem. I personally don't think code level documentation really matters that much in the grand scheme of things. The version history, being able to see why code is the way it is, is orders of magnitude more important and is where the real savings come from. >I also think the not listening to power users plays into this. There is a difference between not listening to power users and what I was saying about not designing software for power users when the goal is to sell to the mass market. Yes, power users likely know the biggest pain points and have insight on how to make the product better. Even if they are right in finding something that makes the product better for them, it is possible that such a change would make the product worse for the millions of normal users.

godelski 3y ago

Thanks for the response. Do you think these trade-offs are actually meaningful? I can see how they might be useful in the short term, but at least to me they seem clearly poor strategy long term. It is unclear to me what exactly is gained by such actions. It is mentioned that preventing users from destroying their devices is a motivation, but I think this is such a limited set of users and I'm not sure letting more technical users bricking their devices is going to result in reduced sales. It does also result in others fixing your code for you if they can debug and inspect them. (So many times I just want to fix shit code but it's closed) It seems hackers and motivated actors are always able to get in anyways so I'm not sure what the real cost is. I think you might see things differently.

charcircuit 3y ago
>Do you think these trade-offs are actually meaningful? Yes, and it can be frustrating when your person want as a user may be different than what will be best for the most people. I do think there are a couple issues. The first is that reevaluating something, making a different tradeoff, and changing the product can be very expensive. Even if it's not be expensive alone, the opportunity cost may be higher and engineers could be working on something more impactful. The second issue is that the product will often target the needs of the majority of needs which means that the needs of power users may not be listened to very well. The solution to these issues are competition and extensibility. The work of making a version of the product for niche users can be done by a niche company and that can work out.
- godelski 3y ago
  I think these are reasonable points. But are they necessary? I'm a researcher, so not your typical programmer. But I'm wondering if there are some aspects that might overlap. I do program a bit differently from my colleagues. I know I'm going to change my code a lot and have to try a lot of different things so when I go into writing I prioritize flexibility. I know whichever direction I'm starting in is wrong and I'm gonna learn a lot on the way. It's a bit slower to start but ends up faster in the long run and ends up letting me parallelize a lot more (because I can get to a state where I submit jobs to run over different parameters and can rely on it running for days). It did definitely take a bit to get into this style, but I feel much better about my code now. Do you think these lessons I learned are relatable to the area you work in? To me the key difference is between short term and long term goals. Short term I am very hacky but it's just that that isn't sustainable so I imagine this is analogous to actual products. But it seems that it is addressing a similar problem of flexibility and changing directions. I also have the habit of documenting while I code because I forget what I did in a few weeks (side benefit, others can onboard very easily). And whenever I get handed code I find myself being more productive rewriting routines rather than using what was handed to me that has zero documentation and is typically made for a very specific use case. Do you have a different experience? Because I've been working in a group building a product and this has been my life for the last 6 months... I guess what I'm after is I have a predisposition to think more openness is more beneficial in the long run but closed is better in the short run. I also think the not listening to power users plays into this. I'm reminded of this post[0] where other users are mentioning similar experiences. I can attest that in my experience most bugs I've seen are system independent but have experienced being quickly dismissed with "unsupported OS" and closed. Including just using a different flavor of the supported distro. (or to read the docs despite referencing the docs in my issue) [0] https://news.ycombinator.com/item?id=28978086 https://news.ycombinator.com/item?id=28978086 Edit: Keep posting and we'll get you to your "goal" lol
  - charcircuit 3y ago
    To your first point flexibility is not free. You have to choose when to be flexible and when to make assumptions to make things simple. Flexibility can only reduce the cost of making changes, but not eliminate it entitely. >whenever I get handed code I find myself being more productive rewriting routines rather than using what was handed to me that has zero documentation and is typically made for a very specific use case. Their is a cost to rewriting code. Code can have all sorts of information and knowledge for handling things correctly baked into which makes rewriting hard to do at scale without having a strong understanding of the problem. I personally don't think code level documentation really matters that much in the grand scheme of things. The version history, being able to see why code is the way it is, is orders of magnitude more important and is where the real savings come from. >I also think the not listening to power users plays into this. There is a difference between not listening to power users and what I was saying about not designing software for power users when the goal is to sell to the mass market. Yes, power users likely know the biggest pain points and have insight on how to make the product better. Even if they are right in finding something that makes the product better for them, it is possible that such a change would make the product worse for the millions of normal users.