Readit NewsInstead, 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.
Many big tech companies have inclusion training calling this question out as inappropriate on the grounds it provides an opportunity to introduce bias.
I also wrote a more detailed blog about my experiences and advice for a break if it's useful! https://gunsch.cc/2024/04/06/sabbatical-review.html
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.
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.
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.comWhen I was at Lucidchart, I helped convert the 600k line Closure codebase to TypeScript. [1] In fact, Lucidchart still uses Closure (for minification+library, not typechecking).
There are better approaches available in 2023, but Closure Compiler will always have special place in my heart.
[1] https://www.lucidchart.com/techblog/2017/11/16/converting-60...
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.
Hmmm. Is there any way to distinguish between these two categories? Because I agree, if someone is delegating all their work to an LLM or similar tool, cut out the middleman. Same as if someone just copy/pasted from Stackoverflow 5 years ago.
I think it is also important to think about incentives. What incentive does the newer developer have to understand the LLM output? There's the long term incentive, but is there a short term one?