They would still line up, wouldn’t they? Or am I misunderstanding how the texture healing would work… Would they not take the same total amount of space?

Engineer I guess… Thief is the objectively better enterprise programmer option but I don’t know why I always forget about it and just write a ternary ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

Xiaomi makes Android phones, what would they get out of trying to make iPhones look better.

Most likely explanation is the voltage difference people have mentioned

This makes a ton of sense and I think you probably solved this mystery for me.

“Oh I need to iterate over something, and keep track of new information as I do it, therefore I should be able to create ‘dynamic variables’ as I progress.”

I distinctly remember asking this question during a 100 level programming class but I just can not remember why I’d ever want to do this?

What problem could I have possibly have been trying to solve where this would seem like the answer.

That’s just how federation works. You’ve federated with an instance/user so now your self hosted instance will be updated.

Is there a reason you’re concerned about the requests? The payloads should be relatively small, and unless you’re running on some really old hardware, one request a second with a small payload should not have any noticeable impact.

I have indeed. We even practice pure TDD and won’t accept PRs without test coverage, but it doesn’t change the fact that sometimes bugs happen, and when they do it tends to be much more effective to work through the problem with a debugger than make guesses at what things need to be logged, or poked into or whatever.

If what you’re doing works for you, more power to you, but in my opinion I’d never give up a tool in my toolset because it makes me far more productive than I’d be without it.

I feel like you’re missing out on a ton of awesome features by not using a debugger? Step backs are super useful, inline/live commands save you from re-running the code to see a different value, you can change values on the fly.

And it’s nice to say “think about your code more” but when you’re working with large teams, on legacy codebases, you don’t often have the opportunity to “think about your code” because you’re trying to decipher what someone wrote 3 years ago and they don’t even work with the company anymore.

https://youtu.be/FM7Z-Xq8Drc

Everyone got put into a cube and they just had to outlast the other people, while doing some challenges.

My problem with trunk based development is I feel like people treat it as the solution to a problem that is fundamentally a developer culture problem.

You need to commit small changes, frequently, which requires you to only change small sections of the code and make incremental changes, something which can be a difficult habit to get used to.

This is really the main benefit of trunk based development, and it’s something you can get with feature branches as well, you just have to make sure everyone on your team starts reducing scope of their features and merging in smaller and smaller features sets.

There’s nothing inherit in the trunk based development model that stops someone from sitting on changes for a month, never pulling, and then trying to pull and ending up with a bunch of conflicts anyways. So it really feels like “yeah use trunk based development” boils down to “integrate continuously” which can be done with a branching model.