P-Y

Watched "Bastille Day" on Netflix. Can't suspend disbelief: Canadian French accents in Paris. Seriously, film's got good actual French actors, then a random Quebec terrorist?!

Also who came up with "police encoulée" (bad french+bad accent) when "nique la police" was right there.

Today I was facing a gnarly somewhat mechanical migration and figured maybe I should try this AI thing.

First stab seemed ok, but many unrelated changes. So I said: revert, try again with no unrelated change.

Here's what the LLM responded:

"I micts\adelphia αsask齿ormaliy ibrahim郭 kepαt debug"

👍

Great writeup, just one note: this applies best to SDKs that are mostly focused on helping devs use an HTTP API.

Sometimes SDKs do a lot more locally (e.g. observability, payments with ui and security logic) and in that case that ladder towards automation doesn't really apply.

"the lower on the stack you go, the closer you get to laying bits down on disk, the more dependable and predictable our software has to be"

Sooo are we gonna talk about how the Linux kernel devicetree is a giant YAML file where typos are super easy 😉?

(sry couldn't resist)

Does that mean you're the "Danle wrapper" script?

Stop Calling AI a “Junior Engineer” They are tools, not teammates

Stop calling AI a "junior engineer"

blog.mmckenna.me/stop-calling...

Just witnessed Google Home responding in English with a French accent 🤯

Cool dad spotted!

For non French speakers, "La Pat Patrouille" is "Paw Patrol" in English, a hit with toddlers

of all my classes, i've prob used my stats classes the most. It's the thing i always recommend high school and college students double down on.

- In 2013 I joined Square & worked on the latest Square reader, which involved FFTs. Signal processing!

- In 2015 I created LeakCanary, which finds leaks in heap dumps. Graph theory!

- More recently I've worked on perf & comparing benchmarks. Stats!!

So glad I "wasted time" in these classes!

I graduated my engineering masters in 2009.

I knew I wanted to write code, and felt like non coding math related classes were a waste of time : signal processing, graph theory, stats...

I was fairly convinced I'd never need these for work.

This might be worth a little emphasis

🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️

I'm sure I'll do a blog post at some point, too, but. It's been a real weekend. I'll catch up sometime

I wasn't finished.

(though, if I'm being truthful, this one is way overdue and tastes more like port)

Socially acceptable since it's 8PM in France,

Yep I've used Wise lately as well, it's solid, though one transfer was declined and they sent the money back but didn't explain much.

Ugh that's bad. Yep I heard similar feedback for neo banks in general.

Load gen as bottle eck, nice classic! Wasn't this what Gatling was originally meant to solve (vs jmeter which didn't do that well)?

On the topic of neo / online banks, what are folks in France recommending?

I still have a really old bank account but now that I moved I want something both solid & modern. I don't want to with my "advisor" for 1 hour every time I need a change.

"This team is slow, they're slackers, let's set a deadline & push!"

=> If you shipped every day or week, the idea of deadline would sound silly => your deliverable is too big.

Deadline => pressure => shortcuts => bad code decisions => internal velocity will lower => then external velocity lowers

Shipping in smaller increments is about increasing external velocity, value to customers faster.

Code quality, complexity, writing tests: that's internal velocity, making changes faster.

We need both. But the things we change to improve one vs the other are different.

You might say team B delivered MORE value all at once when they ship a whole app after two months.

Maybe they did, or maybe they built the wrong thing. Speed of learning. When we don't know where we're going (which is always), it's better to ship in small increment & course correct.

=> The engineers on team B are making code changes faster.
=> The engineers on team A are delivering value & learning faster.

Two different velocities.

- Team A ships a new simple screen in a large old codebase full of gotchas that makes changes hard. Ships in a week.

- Team B builds a whole new greenfield app from scratch, making a ton of code changes every day, takes 2 months to ship a whole new app.

Which team has higher velocity?

We conflate 2 different things when we talk about "velocity"

- External velocity: how fast we ship features
- Internal velocity: how fast we make code changes

They're connected but different.

#AndroidDev

You should read this super cool blog from Tom!

This is a result of a month long investigation where he found a core bug in the Android Framework USB handling code that led to VM freezes.

engineering.block.xyz/blog/ending-...

#AndroidDev

This shouldn't have been closed. It looks like the bug was misrouted and didn't get attention. Thank you for including a patch. I've shared it with the right team to make sure it's reviewed.

Note that I provided a root cause & a fix (as I often do). It's maybe 20 minutes of human work to fix, plus review etc.

Most often these don't get to Google engineers, or it gets to folks who don't have the skill level to implement such a simple fix. There, I said it, it's a skill issue.

Just filed a bug on AOSP: "NFC HostApduService instances leaked by Handler$MessengerImpl binder stub"

issuetracker.google.com/issues/43345...

Will it get fixed, or will it get "shared with product and engineering team" and then closed as Obsolete two years later?

I'm taking bets!

#AndroidDev

Here's my workaround:

- Copy FixedWindowCallback github.com/square/curta...

- Then extend it, like here: github.com/square/curta...