Very strictly speaking.

Follow up hit: https://mstdn.ca/@AlisonCreekside/113816803043367005

It depends on the problem, language, framework and what the options are. If at all possible, write stuff without touching upstream code. If you’re working in a modular, pluggable system, there’s a lot you can do this way. In Android specifically, you can do a lot by writing components that plug into the Intent framework. When it comes to modifying upstream code, you use whatever facilities the programming language offers to minimize the lines of code changes. Ideally only modify upstream code by adding a single line in a module. E.g. write a separate Java module, import it into the upstream code and call it in a single new line in the appropriate block. Then do your work in your module, import and call additional things as needed. Surround the added line with consistent labels in comments. Enforce this in code review and ideally automation. When a code drop comes, git can often automerge such additions. When it can’t, the merge tools make it very clear where your changes are as they aren’t intermixed all over the upstream code, making the merge work easier. There were some clever tricks with branching that I don’t recall. You could even write your own tooling to help with any of this. There’s clever things you can do with the build systems too. None of this is too complicated that a competent software team can’t figure out if given the direction and time to do it.

“We’re under attack from the front left and front right. Respond accordingly”

slow-clap

There’s also difference in how much work the maintenance of forks is depending on how they implement new features. There are many ways and the easiest ones are typically the least maintainable. Designing those features in order to minimize maintenance work when new code drops from upstream can dramatically change the equation and therefore the fork viability. I’ve worked at an Android mobile OEM and dealt with code drops from Google and Qualcomm. Every OEM essentially maintains a fork of Android and deals with a massive set of changes with every Android release. Implementing stuff by straight modifying Android source files lead to huge maintenance workload. After going through a few code drop cycles we devised a set of strategies that drastically decreased the effort needed.

Absolutely true.

Users often have no idea what they actually want.

This is really important and often underemphasized. People don’t reflect on why they feel they want X or Y. We don’t know if it’s some objective reason or a product of an arbitrary decision some other software maker taught us. Famous example for this is pinch-to-zoom. The first people who tried it on the iPhone found it seriously unintuitive and even difficult. Apple spent a lot of effort teaching people to pinch-to-zoom. Then you have the case where we don’t even know what we might like if we haven’t experienced it. The do-what-people-want mantra runs into these and other rrlated problems and projects that live by it often aren’t the best things out there. Good projects typically do a mix of both. Human-computer interaction / UX are legitimate research disciplines for a reason and they’ve yielded very useful heuristics to produce better software.

It’s how we do.

Yes

This sucks. I was about to sub and contribute.

Was wondering whether to do that or not, but screenshots are not accessible. That’s why I linked.

They don’t need the very best to make profit for a very long time, especially in a friendly regulatory regime. Check IBM for reference.

They own the social media market and have enough capital to acquire any plausible competitor, as have done in the past.

Losing top talent is only a significant price to pay if the firm or its competitors are still building new stuff that affects their bottom line. Meta is happy raking in the social media-ad profits. Google is happy raking in the search-ad profits. They’re all busy getting more money out of the markets they’ve monopolized, not competing.

And NDP. Gotta get rid of Jagmeet. Can’t wait for a leadership race. Would’ve been nice to do it along the LPC race but alas.

LMAO, employees are about to find out why a union would be a good idea. Gotta speedrun growing class consciousness.

Time to organize and elect a union-friendly LPC leader. If such a candidate enters the race.

Well to me that doesn’t fit the “it’s default” description.

While looking at that, I couldn’t see lemmy.world on that page. I found that join-lemmy.org now excludes instances with >30% user share in order to dampen centralisation. Which makes sense I guess.

I don’t see it on that page. Going to “See all servers” lists “lemmy.ml” at a random position in the list. Looking at “Join a server” and using “Generic” or “All topics” also lists it in a random position. Am I missing something?

Default where?

Wow that change is from June 2023.

Karen Finnan with the Kitsilano Coalition for Children and Family Safety said they are not opposed to having supportive housing in the neighbourhood.

Can’t make this up.