kyshoc

no citation, but I wanted one of these as a kid and remember them being around $100-150 USD in the early 00s

+1. I can also recommend his new book “Staff Engineer: Leadership beyond the management track”.

To split this hair a bit, I think “code quality” has two definitions:

1. the degree to which the code can be trusted to operate correctly and in a fault-tolerant way (i.e. “yeah that API endpoint will give you a 5xx about 2% of the time, sorry about that, just retry!”)

2. the degree to which the code optimally models the problem it’s solving, as well as how flexible it is as priors/needs change in the future and whether optimal languages/frameworks/patterns are used to solve the problem expressively.

The former has obvious customer implications — if your webapp craps out every ~20min of usage, or your API silently drops data when it can’t persist something to a data store, that’s bad, you will lose customers (and you deserve to!). Conversely, lacking in the latter could slow you down as you iterate, but you’re just as likely to not need to touch that code for a while if you’re off building new views/features/what-have-you.

I think the “don’t worry about code quality” folks are generally trying to beat it into technical founders/builders’ heads that the thing they’re building is ultimately being judged as a product, not as an engineering project... but that doesn’t mean that reliability and performance aren’t part of what may make your product valuable.

Out of curiosity, how long is the term on the lease?

> why aren't most messaging apps peer to peer [...] it's literally the point of messages: sending from one person to another.

Messaging apps are more like postal services — "please deliver this message to $person" — you're describing driving across town to drop something in a mailbox directly. A peer-to-peer messaging system wouldn't have many benefits over an E2E-encrypted one (in a centralized E2E-encrypted service you already enjoy technical guarantees that the courier can't peek inside the metaphorical envelope), but would have several usability drawbacks that would drive away casual users, which the sibling comments mention.

Driving away casual users has its own problems: you might drive them away to insecure services ("ah fuck it, this thing doesn't work, I'll just DM them on Twitter"), and the lack of casual users will make your remaining users stand out in traffic analysis (e.g. state agency says "hmm, askxnakjsn is using SuperEncryptoP2PMessenger, better go make sure they aren't a dissident").

OTOH, optimizing for a highly-compliant police force could set you up for trouble if they end up executing orders that a less compliant force would refuse to follow on moral grounds.

> calls a 1 hour meeting, [...] but now they feel the need to pad the remaining half hour with whatever

that's a wild way to run meetings — in my current organization, finishing a meeting ahead of schedule (when appropriate) is celebrated as "giving time back".