You already didn’t.

Let’s be real here, they weren’t shut down for being an emulator, they were shut down for charging money and making bank, while also planning a parallel paid online service. All the other emulator projects are trucking along just fine, even if Nintendo hates some of them for decades by now.

Bad dragon printer

Most of the entries were just funny, the last one is a nuke:

70. I heard that the only real application for that technology was child pornography. How did you hear about it?

Git is mainly tracking and saving changes, which works great for text, but not that well for data (especially binary). You won’t lose your data, but the Git repo will keep growing too fast.

The big question here is: How often does the data change? If you just use it as a convenient format and rarely change things, it should be fine. Though as mentioned: It might make sense to export to SQL before putting it in Git then. As long as the size is reasonable too (Not storing gigabytes of data).

Alternatives can be other sync services (Dropbox, Seafile, …) to keep your Git repo lean or even better: Set up a SQL server so the data is always in the same spot. Of course that depends on if you have internet everywhere you work (but you probably do).

I’ve worked in a company that used linear code most of the time. And at first it felt really easy to read and work with. If you wanted to know what happened, just jump to the entry point, then read over the next 200 lines of code, done. No events, no jumping around between 10 different interfaces, it worked at first.

But over time it became a total mess. A new feature gets added, now those 200 lines get another if/else at several spots, turns into 250 lines. Then a new option is added that needs to be used for several spots, 300 lines. 400 lines. 500 lines… things just escalate.

You can’t test that function and bugs sneak in far too easily. If you want to split it up later into new functions it’s going to be a major hassle. There also was no dependency injection or using interfaces, other classes were often directly called or instantiated on the spot. Code reuse was spotty and the reused functions often got 5+ parameters for different behavior.

It was horror after a while.

The company I work for now uses interfaces, dependency injection, unit tests, but all the way down a function might still have 50 lines tops or so. It’s slightly tougher to find out where things happen, but then much easier to work with. You need a certain balance either way.

This would actually work well with a tag system. Like you have predefined content warning tags. “Porn”, “Nudity”, “Gore”, “Violence”, “Sexual assault”, or whatever might be in the text/image/video. Users could then filter tags in their settings.

Defining the tags and enforcing them in communities would probably be the biggest hurdle.

You never heard of pair programming?

With juniors Tim would pretty much be training them and nudging them on to write better code.

With seniors, like the short article says, it’s more a sparring match, trying to find the best solution. You also find a lot of edge cases when someone else works with you together.

I haven’t been in a company yet where they have a full time floating position for pair programming, but if it’s a senior doing it I can see how it’s very beneficial for product quality.