4 ms·

Here's one more from me: count your liabilities. 1. Code is a liability. No code? No bugs. The best commit is one that removes unnecessary code. This includes

by orlp 5y ago

Here's one more from me: count your liabilities. 1. Code is a liability. No code? No bugs. The best commit is one that removes unnecessary code. This includes dependencies. 2. State is a liability. Multipliers for: hidden or non-obvious state, shared state, externally (by actors you don't control) accessible state, concurrently accessed/mutated state. Often the worst offenders are environment settings/configuration, such as Windows Registry, environment variables, installed dependencies, daemon services, etc, scoring full points. 3. All publicly observable behavior is a liability. Also known as Hyrum's Law: "all observable behaviors of your system will be depended on by somebody", or https://xkcd.com/1172/ https://xkcd.com/1172/. Huge multiplier for systems with a long expected lifespan, and another huge one if you guarantee backwards compatibility to paying customers. Program under this assumption, and if you can hide or control your internal behavior, do it. E.g.: maybe don't output results reliant on a HashSet order - sort them. None of these are hard 'rules'. Often the liability is necessary, or worth the saved effort or gained feature. But be aware of them, and minimize them where possible.

Cthulhu_ 5y ago
I'd add developers as a liability, notably bus factor; if you have only one dev that knows tech X or product Y, you need to get rid of tech X / product Y, or hire and train more people that know tech X / product Y. Don't keep adding new technologies to your tech stack, it increases complexity and bus factor. I'm saying this as a warning as well because I've witnessed numerous projects where they switched to a new technology or tried to rebuild their tech stack, only to go back once the consultants and self-employed folk got bored. They hired external people to accelerate without having them focus on handover and building up their own IT department.
kqr 5y ago
> E.g.: maybe don't output results reliant on a HashSet order - sort them. I would much prefer shuffling them in that case. Less expensive and reduces the size of the public API. (Returning items in a specific order, whichever it is, still is a sort of promise.)
- silvestrov 5y ago
  One gotcha is that some SQL databases automatically sort items when you do a GROUP BY. Then a few releases later the database switches from a B-tree to a hashmap for the GROUP BY internals and now your output is no longer sorted.
mitchs 5y ago
> "all observable behaviors of your system will be depended on by somebody" Ugh, a former team I was on had that to the extreme. We were customizing open source software for internal use. A lot of operators had (over years) developed scripts that would just SSH in and use a CLI to interact with the software, using regex to parse output. We once thought we were safe adding a new line to the output rather than modifying an existing output line. Nope, someone somewhere used a multi-line regex. Kicking everyone's automation out of the shells of those boxes was a multi-year project that is, as far as I know, still ongoing.

by orlp 5y ago

Cthulhu_ 5y ago

I'd add developers as a liability, notably bus factor; if you have only one dev that knows tech X or product Y, you need to get rid of tech X / product Y, or hire and train more people that know tech X / product Y. Don't keep adding new technologies to your tech stack, it increases complexity and bus factor. I'm saying this as a warning as well because I've witnessed numerous projects where they switched to a new technology or tried to rebuild their tech stack, only to go back once the consultants and self-employed folk got bored. They hired external people to accelerate without having them focus on handover and building up their own IT department.

kqr 5y ago

> E.g.: maybe don't output results reliant on a HashSet order - sort them. I would much prefer shuffling them in that case. Less expensive and reduces the size of the public API. (Returning items in a specific order, whichever it is, still is a sort of promise.)

silvestrov 5y ago
One gotcha is that some SQL databases automatically sort items when you do a GROUP BY. Then a few releases later the database switches from a B-tree to a hashmap for the GROUP BY internals and now your output is no longer sorted.

mitchs 5y ago

> "all observable behaviors of your system will be depended on by somebody" Ugh, a former team I was on had that to the extreme. We were customizing open source software for internal use. A lot of operators had (over years) developed scripts that would just SSH in and use a CLI to interact with the software, using regex to parse output. We once thought we were safe adding a new line to the output rather than modifying an existing output line. Nope, someone somewhere used a multi-line regex. Kicking everyone's automation out of the shells of those boxes was a multi-year project that is, as far as I know, still ongoing.