razorfen

Their new appointment of leader for their Xbox group suggests that they intend to wind down that business unit in time. The founder of the Xbox team has commented that he believes it’s the beginning of the end for Xbox, for the exact reasons of this thread.

This has become a personal debate for me recently, ever since I learned that there are several software luminaries who eschew debuggers (the equivalent of taking an oscilliscope probe to a piece of electronics).

I’ve always fallen on the side of debugging being about “isolate as narrowly as possible” and “don’t guess what’s happening when you can KNOW what’s happening”.

The arguments against this approach is that speculation and statically analyzing a system reinforces that system in your mind and makes you more effective overall in the long run, even if it may take longer to isolate a single defect.

I’ll stick with my debuggers, but I do agree that you can’t throw the baby out with the bathwater.

The modern extreme is asking Cursor’s AI agent “why is this broken?” I recently saw a relatively senior engineer joining a new company lean too heavily on Cursor to understand a company’s systems. They burned a lot of cycles getting poor answers. I think this is a far worse extreme.

Can anyone explain how they maintain backwards compatibility on formats like this when adding features? I assume there are byte ranges managed in the format, but with things like compression, wouldn’t compressed images be unrenderable on clients that don’t support it? I suppose it would behoove servers to serve based on what the client would support.

> phishing resistance (with UX that supports that) and low-level security audits of encryption software and hardware

Pardon my ignorance, but isn’t this saying “we can’t rely on reducing the likelihood of breaches, we should focus on reducing the likelihood of breaches”? Your recommendations are no more deterministic than the methods you eschew.

> Also the code should be written "for the now", not for "that future feature it would be awesome to have someday like making it compatible with every other library X, etc.".

The folksy software adage for this is YAGNI. (You Ain’t Gonna Need It)

Phoenix is robbing Peter to pay Paul with regards to water. Phoenix survives thanks to extreme planning measures and water diversion from the Colorado river, but that’s not going to be tenable in the next 30 yrs. There is almost no well or groundwater, and before the constant diversion of water, the city of a Phoenix consumed some order of magnitude more water than they were able to restore.

My point is, anyone who lives in an overpopulated desert and says “we don’t have a water problem” should be taken with a grain of salt.

Nor do they necessarily have the ability to do discretionary prioritization of certain bugs or features, even if they did see it.

You may not be in one job forever, and you can move between about 10,000 tech companies through a long career if you are in the Bay.

I don't completely disagree, but his point about the irrelevance of SOLID, OO, and Java in this supposedly grand new age of FP programming ignores that OO is still the pre-eminent paradigm for most applications and Java is remains one of the largest and most utilized languages in the world. Also, I would say that excitement around FP has waned more than it has for Java.

It’s the first I’d heard of this axiom. Can you give an example of that in a real architecture?

I think about a central server with multiple terminals on a network. There the node is the beefy boi and the terminals are just I/O devices. Kind of similar to what MightyApp is doing - except with fewer privacy concerns :)

ITT: a non-controversial opinion shared by most programmers.

Print debugging is fast in many cases and requires little mental overhead to get going.

But for some/many systems, there's a huge startup and cooldown time for their applications - and compiling in a print, deploying the service, and then running through the steps necessary to recreate a bug is a non-trivial exercise. Think remote debugging of a deployed system with a bug that requires select network and data states that are hard or impossible to replicate in local/dev.

For things like this, being able to isolate the exact point of breakage by stepping through deployed code, and doing immediate evaluation at various points to interrogate state can't be beat.

This post strikes me as either (a) a younger programmer who still thinks that tool choice is a war rather than different tools for different jobs (b) someone making a limp effort at stoking controversy for attention.

Remember: "CTO" sometimes means "I am the technical founder of a 3 person company"

In the uuid case, the person had no choice. Remember, these are principles, not laws, and at some point your system is making concrete choices. Choosing UUIDs isn’t necessarily a OO design problem. He was just highlighting how expensive it can be if you require changes to your fundamental classes to extend or change behavior. In the identifier type case, it’s rare that folks abstract this stuff away. Though: I do know a LOT of systems that use synthetic identifiers for this exact purpose, as larger enterprises tend to deal with many more different identifier types from different integrations, from a DB type that can’t hold new identifiers, because IDs need to be sharper/distributed etc. So yeah, it’s a principal, and one should choose if it’s worth the upfront cost for its benefits.

OCP though more commonly refers to: 1. Building small, universally useful abstractions first 2. Extending behavior of that abstraction or system by writing new code rather than changing published code directly.

This is trivial when you have a few patterns under your belt. Template factories, builders, strategies, commands. I mean, while it’s not the best idea in most cases, even just inheriting a parent class and giving a new concrete new behavior is still better than changing something fundamental to the system.

Like has been said 999 times in this thread, software isn’t black and white. You have to make choices about where you go concrete and where you abstract, and gauge that against risk factors. A somewhat complex class you expect to go away in a couple months? Make it a god class that anyone who wants to can scan through. A fundamental class that will be used by hundreds of developers and underpin most operations in a production system where 5 minutes of downtime costs tens of thousands of dollars? It’s worth the upfront cost to build with these standards.

The public plaintext emails are not a good idea. Scrapers will gobble these up and spam those emails into oblivion. At least put them behind a captcha.