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.
I've seen some overly excessive pair programming initiatives out there, but it does baffle me why less people who struggle with this do it. Take even just 30 minutes to pair program on a problem and see their process and you can reveal so much.
But I suppose my question is rhetorical. We're laying off hundreds of thousands of engineers and maming existing ones do the work of 3-4 engineers. Not much time to help the juniors.
I hoped this might be like an externalization of g3doc. Nope.
Instead, I started reading through one of their highlighted examples --- the Go repo (https://codewiki.google/github.com/golang/go). This might be the worst high level overview of Go and its repo I've read. Mostly accurate but unhelpfully verbose, spending lots of words on trivia, and not at all making a compelling pitch for Go as a language or toolchain, how to use it, or how to work on it.
I was just looking through the Go example as well. For a first attempt its ok. I don't think its accurate to criticize that it doesn't make a case for using Go or teaching how to use it. It's attempting to be a more useful contributing.md. I think it does a decent job at that. Enough that you could find an area of interest and feel confident to start reading and understanding it yourself.
It just doesn't seem to be worth the effort though. I see myself using something like this for ~30 minutes to so I don't feel lost when getting started. After that it becomes significantly less useful.
Also, the video wasn't particularly helpful and if I have to here an AI voice say how fantastic something is again, Im going to unplug it (jk future overlords).
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 recently took 10 months off before my current gig. I did little to no coding, mostly just recovering from burnout and doing some side fun stuff. No one batted an eye about the break when I started job-searching again --- I think breaks like that in tech are pretty normal.
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.
My involvement started in the lead-up to OAS 3.1 so I don't have any insight into the Smartbear/OpenAPI Initiative hand-off. Yes, the decision to be vendor-neutral is part of the reason the ecosystem is so fractured. But most technical standards are vendor-neutral and work just fine.
OpenAPI also has the problem of not providing any guidance on what the tooling ecosystem ought to look like, regardless of who implements the tools. You want enough leeway to encourage innovation, but if you don't put out _anything_, you get... well... this. Lots of tools that don't all fully implement things, and not much in the way of interoperable points of hand-off between tools beyond the format. And when many tools leave off some feature or another (most egregiously, external referencing - down the line in this blog post I'll actually show a concrete solution for that), just sharing the format isn't enough.
I'm hoping that this approach I'm sharing through these blog posts will help us start to shape the ecosystem more. For Moonwalk if nothing else (although I'd love to get 3.x into more of an interoperable state- let's make life better for people working with things now, not just years down the line).
> but with the requirement that there wouldn't be official tooling offered with it --- arguably to protect Smartbear's investment in Swagger
That kind of seems backwards. If there was a official tooling, it would be Smartbear's (who else would provide it?) This clause actually seems to be designed to limit Smartbear's ability to use OpenAPI to push their products (and at the same time push OpenAPI as a credibly vendor-independent spec).
> Compare to gRPC/protobuf, where the specification and tooling have been developed together.
Yes, because it's a protocol pushed by one company, not pretending to be independent.
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: andrew.j.gunsch@gmail.com
+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?
