gunsch

A few months ago I was debugging a similar issue in a Go-based service layer, where frequent HTTP requests to the same domain kept making fresh TCP connections when I was expecting TCP conn reuse.

In this situation we were discarding the HTTP response without reading it before closing, which kept Go from reusing the connection. I didn't dig quite as deep as this post's author, but I imagine the same RST behavior was happening under the hood.

Pair programming! Get hands-on with your junior engineers and their development process. Push them to think through things and not just ask the LLM everything.

Sure, that's advised in interviews, where you're about to make a decision on someone's livelihood, hence the importance of reducing bias. That's a completely different context than in casual conversation at a social event.

I had the fortune of taking Erdmann's Python class at the University of Arizona 15 years ago --- a Python/Pylab/data engineering class aimed at materials science engineering students.

He was already getting into this kind of art spectroscopy at the time, and the things he'd showed us at the time that they'd already discovered were wild. IIRC, they had laid out many Rembrandts on the same large "scroll" of canvas, identified where they were painted relative to one another on the scroll, and even identified some paintings of unclear authorship by thing them to that same scroll.

It was not at all surprising to see him move to Amsterdam and keep working with the Rijksmuseum. I smile every time I see this work pop up.

I spent a few years building OpenAPI-related tools at Google, collaborating with Apigee.

One of the "open secrets" about OpenAPI's history was how Smartbear spun out the OpenAPI spec to be a community-managed spec, but with the requirement that there wouldn't be official tooling offered with it --- arguably to protect Smartbear's investment in Swagger. (it's been a minute so specifics are hazy but IIRC it was something like this). The tooling ecosystem feels pretty disjointed as a result.

Compare to gRPC/protobuf, where the specification and tooling have been developed together. Parsers, static analyzers, code generators, documentation tooling all happen in lockstep with spec development, and the ecosystem feels much more cohesive.

Engineering lead/manager looking for engineering leadership roles. Ex-Google (Staff SWE), have managed teams and orgs from 20 to 140 engineers. Looking for anything from managing a single team, to director-level, to principal-SWE type roles. Deep experience in platforms (internal teams, APIs and API platforms, SDKs, etc.), but also have experience in consumer hardware, streaming media, and all parts of the tech stack.

  Location: Seattle, WA
  Remote: open to remote, hybrid, or in-person in Seattle
  Willing to relocate: no
  Technologies: backend, frontend, infra/ops, client devices
  Résumé/CV: https://gunsch.cc/assets/img/resume-2023.pdf
  Email: [email protected]

+1. The comments bashing Closure in comparison to TypeScript feel like they're missing the timeline.

Closure brought modules, requires, compile-time type checking and optimizations to JavaScript years before TypeScript was on the scene. I wouldn't dare start a new project with Closure. But it was such a spiritual predecessor to what we have today in TypeScript, and has a special place in my heart too.

There are also government contractors who often pair with USDS doing this kind of work! Ad Hoc (my employer), Nava, Civic Actions, etc. are all part of a new generation of companies with related missions trying to bring modern software practices into the US government. While USDS is often on the inside cutting through bureaucracy, the contractors are often doing most of the technical build and implementation.

I happened to join Oink just before it fell over, and when it went down I managed to find some of the former members on a forum saying "hey, let's go build a replacement right away." I was only a budding PHP developer in high school, but managed to jump in with the right folks at the right time and learned a lot working on that site.

Couple stories from memory:

* What.cd started as a parallel effort around the same time, by a second group. I don't recall there being a significant motivation to have _two_ Oink replacements, just a lot of enthusiasm, and memes about "hydras" --- i.e. "you chopped off a head, but even more of us grew back".

* I remember us laughing at the "what" group for their name --- and supposedly hearing that they thought calling it "what" would act as a deterrent to being taken down, with a "confusing" name. But hey, they really took off in a way that Waffles didn't, so what do I know

* Waffles used tbsource (IIRC), which was a more standard torrent-site codebase to reach for at the time. It was fine, we made our customizations to it and did what we had to to get the site going. But What.cd's choice to implement a new tracker in Gazelle was a great contribution to the community.

* I miss the music discovery that came from the Waffles top-10 lists and from the forums in the community. Spotify has fully replaced music torrenting in my life (and probably many many others), but the community around music recommendations and sharing was so, so good and I haven't found something like it since.

* Helping stand up a music torrent site was a fun, probably ill-advised adventure of a young, pre-adult version of me. I've since professionally worked on DRM stacks on consumer media devices and on projects for the US Copyright Office, and had many good laughs about this trajectory. Karma, I guess?

It sounds like you're assuming "managing up" is about managers who don't know how to do their job. I don't think this article is saying that.

My best managers weren't ones who knew every detail of each project and could give unsolicited effective advice. They were ones to whom I could tell what was going on on my project, could ask for help, could tell them what I needed, and then rely on them to follow through on helping make that happen. Sometimes that was needing more time for a deadline, sometimes it was needing a mediation in a complicated relationship with another team, and sometimes it was using manager clout to go escalate a request for compute resources.

In any case, two-way communication is going to create a more effective relationship than expecting your manager to simply _know_ what you need.