jim

Nice. Can we expand the idea to things that make programming nice, fun, or overall enjoyable?

First post of good code will be a picture of an empty file.

I don't like karma. It incentivizes short, meme-y posts since those are things that get gets a lot of karma.

Probably 100 more chapters of no progress, then a spin off where they are married with a kid but he still won't admit that he likes her because he hasn't beat her in shogi.

Just sit back and enjoy the ride.

Yeah that's a good point. It's telling that inheritance is by design difficult to change unless you follow very specific rules of good OO design patterns.

I guess it's easy to write bad code in any programming paradkgm but inheritance makes it easy to screw up.

Yes! Loot boxes are awful for children (and even adults). Glad to see the Dutch doing something about this, and I hope others follow as well.

Most of us have bad memories of over-complex hierarchies we regret seeing, but this is probably due to the dominance of OOP in recent decades.

This sentence here is why inheritance gets a bad reputation, rightly or wrongly. Inheritance sounds intuitive when you're inheriting Vehicle in your Bicycle class, but it falls apart when dealing with more abstract ideas. Thus, it's not immediately clear when and why you should use inheritance, and it soon becomes a tangled mess.

Thus, OO programs can easily fall into a trap of organizing code into false hierarchies. And those hierarchies may not make sense from developer to developer who is reading the code.

I'm not a fan of OO programming, but I do think it can occasionally be a useful tool.

Ahhh! Such a nice chapter. I liked how she just has shogi on her mind all the time, which is keeping in her character.

Not a big fan of this series but I do like the character design. Thanks for sharing.

I don't want to victim blame here, but both "Logan Paul" and "crypto" together is just screaming scam. That being said, I hope the victims get their money back, though from the article, I doubt it'll be anytime soon if at all.

If the work I'm doing is on a feature branch on remote or locally, why does it matter to the rest of the team? My integration steps can be done on a server instead of locally. TBD forces teams to collaborate synchronously since changes are pushed straight to trunk. Rebase or squashes are irrelevant here.

Another poster put it great: TBD is trying to solve a culture problem. Feature branches and pull requests into main is much more flexible. The only time TBD make sense is for small teams - like 2 or maybe 3. And even at 2, I'd much rather create feature branches that merge into main.

Precisely. In practice, trunk based development just means your branch is local instead of on remote.

I've heard good things about hg though I haven't used it myself. Git has the biggest mindshare that I never bothered even checking. Might as well use it and move on.