Karl

Alright, y’all. The time has come. Most of my friends and colleagues have left. The algorithm is angertainment. And the new owner turned into another Rupert Murdoch. I think I’m done here. Karl Isenberg, signing off.

Ugh. This human is full of words.

TIL Blood Wine is made from farm worms. #LowerDecks #Spoiler

@julianhyde @rakyll If being able to tell the difference and switch between these modes is a requirement for being a good engineer, then I haven’t met very many good engineers.

@KarlKFI @rakyll In my experience it's a dialectic, not a divide. Good engineers can see both points and find a compromise. If you find yourself arguing an engineer you think is type A, it's likely that they think you are putting too much weight on the type B argument and are pushing back.

There are many engineering archetypes, but these two help me most when talking to leadership: - Engineers as application builders & integrators - Engineers as infrastructure builders If you hire an infrastructure builder to build applications and integrations, they will cause a ton of nuance and will fail, and vice versa.

@rakyll One of these takes out tech debt loans and then leaves for greener pastures when it comes time to repay them. The other makes everything cost more now to avoid pain later. Both are defense mechanisms. But the two types tend to drive each other crazy.

@rakyll There’s a bigger divide I run into more often. - Engineers who want to go with the first solution they come up with, and change it only when they have to. - Engineers who want to make sure they covered every edge case before shipping to avoid breaking changes.

Large?

I did not expect the skill tree in #DragonAgeVeilguard to be so much like Path of Exile’s.

@ibuildthecloud I think most the times I use errors.As it’s because I don’t control or can’t change the error type I need to catch. If you do own the error type, it’s often easier to split it into multiple error types and catch those with errors.Is.

@ibuildthecloud Yeah, errors.As is more rarely used. But when you do, you can usually hide it behind a well named function that extracts and tests the field values. That way the if statement reads better.

errors.IsNotFound(err) is by far the best style for error checking. errors.Is and errors.As just suck. Rarely, and I mean rarely, do I ever have to extract out values from errors, just check that it is it.

This assumes your customers deploy and operate your software. If you operate it as SaaS yourself and don’t open source the code, then go wild! Break your own dashboards and alerts! Just make sure you fix the important ones before they go filing P0 bugs and paging on-call.

Metrics are customer facing APIs. Don’t go adding metrics willy-nilly just because you think they might be useful. You are going to need to maintain those suckers forever to avoid breaking customer metric queries and alerts.

@mitchellh You are legion.

When I was in SF a couple weeks ago, a teenager on the street said "hey, you're that ghost terminal guy." There's now a generational divide in what I'm recognized for (if I'm recognized). As a broad generalization, younger folks see me as terminal person, older as infra.

Ever get half way through a refactor and just give up because the code is just a giant ball of tangled spaghetti?

@kefimochi What I did was change companies every 3 years. So I was never anywhere long enough to get promoted. Eventually it was obvious to a hiring manager that it was overdue. Not that I would necessarily recommend that as a strategy for quick advancement, but it did technically work.

One of those days...

Looks like you can alternatively choose Claude, o1, and the original Codex GPT-3. github.blog/news-insights/…

Oh hey, GitHub Copilot now works with Gemini, and it's 2 million token context. I wonder if the experience is better on Go projects with lots of vendored dependencies. cloud.google.com/blog/products/…

He did!

Did Other Boimler just do the Riker Maneuver?