RIP Scott Adams

So, instead of finishing (or attempting to finish) the feature alone, and then working together, you work together initially, and finish the feature alone.

I prefer to turn this completely upside down with an initial burst of pair programming.

* You start the work with feedback
* Further work and polish builds on initial braintrust
* You sit together and synchronously ensure you think about the same problem

I don't like pull requests.

* Work is done without feedback
* You get feedback after you've polished and finished your work
* The person reviewing is not in the same headspace as you, easy to miss tings

We solve for this with iteration velocity. We're not bogged down with tech dept mudballs, and are able to keep moving forward fast.

But there's a limit to how smoooooth we need something to be. Spending hours to polish something we'll later throw away will kill us for sure.

A meme in the office these days that keeps us focused:

"We have a really great [insert technical solution]. Shame we went bankrupt before any customers got to use it".

There was no real reason to have this as a repetable, so now we add the `create trigger` statement alongside the `create table` statement in our versioned migrations.

Just had PostgreSQL locking issues in prod, caused by a repeatable migration in Flyway.

It's easy to forget the _entire_ repeatable runs when the file changes. This particular repeatable ran `create or replace trigger ` on most of the tables in our system, causing fun locking issues.

Very Plato dualism pilled

can't tell if it makes more internal or external. I think more external. It's "my" but it's also a separate outside thing that's not really you. "My brain" also ticks me off, as if that's some kind of atomic stand-alone entity

I also have a problem with things that is too much a thing. "My ADHD", or generally any "my" and a diagnosis, ticks me off. Like it has a spiritual life of its own.

XKCD 10k people every day etc. But clearly this team was heavily exposed to the issues with cross system comms over a network. They just didn't seem to care about the edge cases and the 1 of every 1000 operations that got botched.

Not sure what the sensible trade-off was in that situation.

At a previous gig, the integration platform team did not know about idempotency.

When we asked, they told us their network is sufficiently reliable, so we won't have issues with missing or duplicate data.

Still blows my mind when I think about it today.

Found an oddity in Kotlin today - the rounding mode for the BigDecimal divide infix operator is HALF_EVEN.

So, if you do BigDecimal("10075") / BigDecimal("100"), you'll get BigDecimal("101").

Fixed by using .divide directly and explicit rounding mode, but did not expect precision loss by default

You can run PostgreSQL with a RAM disk in local dev/test.

In RAM mode, our test suite only takes 20s to run, down from 1m4s.

This is such an obvious optimization that I wonder why we haven't thought of this before.

In docker-compose.yml:

environment:
PGDATA: /pgtmpfs
tmpfs:
- /pgtmpfs

reminds me of the good old Knuth saying about why he doesn't use e-mail:

> E-mail is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things

poopin