cedarp.bsky.social

A.L. Goldfuss @ghoulpus.bsky.social [ View ] Jun 19, 2024 at 17:42 UTC

SCULLY: where are you? MULDER:

2 replies 2 reposts 40 likes

@cedarp.bsky.social [ View ] Jun 18, 2024 at 12:48 UTC

> “If this passes, we won’t be able to afford to live in our own communities,” said David Kafko [, real estate broker in support of maintaining broker fees]

the real estate industry extracting money from tenants is why neighborhoods are unaffordable in the first place

slate.com/news-and-pol...

0 replies 0 reposts 0 likes

@cedarp.bsky.social [ View ] Jun 16, 2024 at 16:57 UTC

I think that's it with vague thoughts about CI and testing. Wishful thinking and discipline are not strategies to address issues with a system of inter-connected parts.

0 replies 0 reposts 0 likes

@cedarp.bsky.social [ View ] Jun 16, 2024 at 16:55 UTC

Only when you get enough individual tests for it to matter should you start adding tooling that will start being smart about what subsets of the test suite should run when you have certain changes in the PR diff. Track when your diff strategy fails to correctly identify interconnected parts.

1 replies 0 reposts 0 likes

@cedarp.bsky.social [ View ] Jun 16, 2024 at 16:54 UTC

Decompose integration tests down into meaningful units. Don't spin up a database to make sure a function in the app server adds numbers together correctly. Test behavior intentionally and reduce any extra work you can.

1 replies 0 reposts 0 likes

@cedarp.bsky.social [ View ] Jun 16, 2024 at 16:50 UTC

Whenever the answer someone gives is "engineers should just be more disciplined" that's a red flag. Focus on the incentives (or disincentives!) for doing the thing. Never chalk it up to character flaws. Make tests run automatically. Make tests run fast.

1 replies 0 reposts 0 likes

@cedarp.bsky.social [ View ] Jun 16, 2024 at 14:39 UTC

Keep track of how long tests take locally and remotely separately. Keep track of how often tests crash locally versus in CI. Design your test suite to avoid using a database when a test doesn't actually need to serialize data for the behavior it covers. Randomize the order and parallelize.

1 replies 0 reposts 0 likes

@cedarp.bsky.social [ View ] Jun 16, 2024 at 14:34 UTC

Ask why someone doesn't want to run the tests. Do they require effort? Do they take time? Often that's enough. If you make something quick and effortless, the tests will take care of themselves. Go out of your way to build or document tools that run tests automatically as people work.

1 replies 0 reposts 0 likes

@cedarp.bsky.social [ View ] Jun 16, 2024 at 14:31 UTC

Again, do we FORCE the test suite to run on every push or commit? No. But pay attention to the incentives that prevent that from happening. Does the test suite require manually maintaining and resetting a database or message broker? Is the test suite slow?

1 replies 0 reposts 0 likes

@cedarp.bsky.social [ View ] Jun 16, 2024 at 14:24 UTC

CI problems benefit from shifting things to the left. Catch as many issues as you can as early as you can. The later in the process you can catch an issue, the more likely that issue is getting caught very late, requiring rework, or when it's already gotten to production, costing you real money.

1 replies 0 reposts 0 likes

@cedarp.bsky.social [ View ] Jun 16, 2024 at 14:05 UTC

So you can't blame the author of the PR for not running the tests. It isn't their fault, even if they ARE lazy. If the system makes running tests locally hard or impossible, it's not a discipline issue.

1 replies 0 reposts 0 likes

@cedarp.bsky.social [ View ] Jun 16, 2024 at 14:03 UTC

Models help us understand things, but they don't capture everything. We love to ask "what was the root cause of why this system broke?". Nobody's asking "what was the root cause of why the system worked today?". It sounds insane to even ask!

1 replies 0 reposts 0 likes

@cedarp.bsky.social [ View ] Jun 16, 2024 at 13:42 UTC

Root cause analysis is strictly a simplification of how a system did something bad once (and maybe can be extended to how it would do the bad thing again in the future). You reduce it to a simple model so that you can recommend a change.

1 replies 0 reposts 0 likes

@cedarp.bsky.social [ View ] Jun 16, 2024 at 13:37 UTC

So we're left with "discipline". We tend to shame people for opening a PR that breaks a test. "You should have run these locally first." The actual solution is to treat this as a system. You don't fix systems by ignoring that it's a system. There is no 'root cause' of a problem in a system.

1 replies 0 reposts 0 likes

@cedarp.bsky.social [ View ] Jun 16, 2024 at 13:33 UTC

prepush hooks have the same problem, but they make it easier to work locally. You can actually record a history of changes, but you still can't share them at the critical time when you actually need help from a coworker.

1 replies 0 reposts 0 likes

@cedarp.bsky.social [ View ] Jun 16, 2024 at 13:32 UTC

Precommit hooks slow down local development time and make it impossible to collaborate. People who think precommit hooks are the solution never consider that checking in buggy code is actually a good thing. "Hey this change fixes one bug but crashes this test, can you take a look?"

1 replies 0 reposts 0 likes

@cedarp.bsky.social [ View ] Jun 16, 2024 at 13:30 UTC

So -- ideally everyone is running tests locally and they don't run into surprises when their PR's run of the test suite finds bugs. The fixes that people tend to think of are: precommit hooks, prepush hooks, and discipline. These all suck. 🧵

1 replies 0 reposts 0 likes

@cedarp.bsky.social [ View ] Jun 14, 2024 at 14:33 UTC

why the fuck do they have a cop barking orders at jurors checking their phone before orientation

1 replies 0 reposts 1 likes