Motorola's legal terms claim to strip owners of their right to sell their device

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.

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

Edit: Keep posting and we'll get you to your "goal" lol

>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.

But if this is the cost of rewriting isn't that the argument for having documentation? I mean I'm not running into well written code and I'm just told to add my thing to it. But to do that I need to interact with... well... a house of cards. Because the person before me wrote fast, not well. I do hear a lot of people say that they write their code so well it doesn't need documentation but I've only run into code that is clear pretty rarely. Though every time that happens, they also have documentation available.

Thanks for the clarification with power users. As one, I have no issues with this response. I know we always want more but I get the tradeoff for usability. Only thing I'd say is that, depending on what's being programmed, exposing API can often be all I need and typically doesn't do anything for the average user. But that's often not reasonable so I totally get this one.