First, that this is challenging to scale across large orgs. Even if your plans produce high quality code, that isn’t true for everyone. I’m definitely struggling with slop code being collectively mailed to me for review my our 1,000 engineers that were told to use their AI subscription all at once.

I feel like we should be taking “prompt engineering” more seriously. And when people mail me code to review, it should also include the agentic workflow and plan. So that when code isn’t up to quality, and can have a discussion about the prompts used to generate it.

My second thought is related to your senior engineer comment. This isn’t surprising, because in most engineering orgs, seniority is completely unrelated to code quality. In fact, many orgs incentive the opposite: “senior” devs that push out buggy code quickly and push accountability downhill to the junior devs.

I still think that’s about accurate. Maybe it should’ve been 40%.

Everyone forgets that it was a pretty close election. Clinton could’ve won without the Comey announcement.

This is just some Disney suits being extraordinarily petty.

The fact that basically none of these multi-million dollar companies are vendoring their entire dependency tree.

At most companies, even ones worth millions of dollars, it would be impossible for them to rebuild their software if someone ripped a package off of npm’s registry or whatever.

We were deducted points for trivial syntax mistakes.

If these stories I keep hearing are true, then university programs have really taken a nose dive recently. This isn’t a “back in my day” thing, but within the past 5 years.

The pace of the purported decline makes me question if some of these stories are sensationalist. But I don’t know, I keep hearing about them.

Code references are less important inside Google editors, because we have a code viewer tool inside the web browser.

Most people read, explore, follow references, and share permalinks to the view-only tool. It’s a lot better than viewing code in GitHub. It’s super fast, is connected to language servers and can actually trace referenced, and overall has a million little features optimized for reading code.

We also have a code reviewer tool, and a separate tool to run and view CI runs.

So what’s left for the editor? Syntax highlighting?

I would tend to view code, run tests and CI, and review in separate tools specialized for their specific use case. The code editor was just a place where I would type in my changes.

I’d imagine this workflow feels weird to people who learned in one-stop-shop IntelliJ and GitHub world. But I can’t emphasize how much better these other tools were compared to GitHib. So a code editor that also lets me read, review, and test code didn’t really matter for me when I had a collection of smaller tools specialized for each individual task.

There is no “modern” alternative. If you read Reddit threads, C++ programmers actually believe that it’s a reasonable file reading API.

Most companies that I’ve worked at have just implemented our own on top of the OS syscalls. Which is annoying because it requires at least a Windows and UNIX variant.

Look, I like C++. I’ve been programming in it for years. But some of the stereotypes around C++ programmers are true. I still occasionally run into design decisions so untethered from reality that it still shocks me after all these years.

So a lot of code quality debates don’t matter for the typical enterprise app. While a dev spends their afternoon shaving off 100 nanoseconds in the hot path, a second developer on a deadline added a poorly thought out round trip that adds 800milliseconds.

This architectural problems are also more difficult to unwind later since they tend to have cascading effects.

1) Most bugs are integration bugs. Whereby multiple systems are glued together but there’s something about the API contract that the various developers in each system don’t understand.

2) Most performance issues are architectural. Unnecessary round trips, doing work synchronously, fetching too much data.

Debuggers and profilers don’t really help with those problems.

I personally know how to use those tools and I do for personal projects. It just doesn’t come up in my enterprise job.

Linus’s contribution is a great one. He learned from prior tools and contributions, made a lot of smart technical decisions, got stuff moving with a prototype, then displayed good technical leadership by handing it off to a dedicated development team.

That’s such a good lesson for all of us devs.

So why the urge to lie and pretend he coded it in a week with no help? I know you’re not saying this, but this is the common myth.

In reality, it was a collaborative effort between multiple smart people who poured months and years of sweat into the thing.

I seem to agree with you. The real story is a good thing and Linus made important contributions!

But he didn’t create git by himself in a week like the parent comments argue.

The parent comments are arguing that 17million for git 2.0 is insane because Linux wrote the original in a week.

Except that’s not true. He sketched out a proof of concept in a week. Then handed it off to a team of maintainers who worked on it for the next two decades.

It’s also not pedantic because Linus himself makes this distinction. He doesn’t say he coded Git and specifically corrects people in interviews when they this.

That’s only feasible when the people who open PRs are acting in good faith, and control both the quality and volume of PRs to something that the maintainers can realistically (and ought to) review in their 2-3 hours of weekly free time.

Linux is a bit different. Your code can be rejected, or not even looked at in the first place, if it’s not a high quality and desired contribution.

Also, it’s not just about PR quality, but also volume. It’s possible for contributions to be a net benefit in isolation. But most open source maintainers only have an hour or so a week to review PRs and need to prioritize aggressively. People who code with AI agents would benefit themselves to ask “does this PR align with the priorities and time availability of the maintainer?”

For instance, I’m sure we could point AI at many open source projects and tell it to optimize performance. And the agent would produce a bunch of high quality PRs that are a good idea in isolation. But what if performance optimization isn’t a good use of time for a given maintainer’s weekly code review quota?

Sure, maintainers can simply close the PR without a reason if they don’t have time.

But I fear we are taking advantage of nice people, who want to give a reasoned response to every contribution, but simply can’t keep up with the volume that agents can produce.

His main contributions were his ideas.

1) The distributed model, that doesn’t need to dial the internet.

2) The core data structures. For instance, how git stores snapshots for files changes in a commit. Other tools used diff approaches which made rewinding, branch switching, and diffing super slow.

Those two ideas are important and influenced git deeply, but he didn’t code the thing, and definitely not in 7 days!

One of the most pressing problems of our time is that these large corporations, on balance, have too much power compared to the electorate.

There seems to be a pervasive believe that the Python tooling and interpreter suck and are slow because the maintainers don’t care, or aren’t capable.

The actual problem is that there isn’t enough money to develop all of these systems properly.

Google says that Astral had 15 team members. Or course, it’s so hard to make these projections. But it wouldn’t shock me if uv and ruff are each individually multi-million dollar pieces of software.

If you’d like to invest a million dollars to improve pip, or work for free for 3 years to do it yourself, I’m not sure if anyone would object.

The language maintainers have added so many great features while maintaining backwards compatibility. And slowly but surely improved the JVM and garbage collection. So after toying around for a bit, I decided to write some personal projects in Java.

After a week, I gave up and returned to Go. The build tooling is still an over engineered mess. Third party library APIs are still horrible. I will never invest even 5 minutes in learning that horrible Spring framework when stuff like Django, Rails, or the Go ecosystem exist.

The community, and thus the online forums and open source libraries, still approach engineering and aesthetics in a way that is completely foreign and off putting to me.

With that said, I think Chromebook’s still hold a competitive advantage for public school contracts. It doesn’t matter that the Neo is pretty cheap and the best value. Contracts are signed based on what’s cheapest, period.

Also, a big blind spot for a lot of HN: this is going to be big in developing Markets. This is within budget for middle class Latin Americans in a way that even the Air isn’t.

Go’s core design philosophy is stability. This means backwards compatibility forever. But really, even more than that. The community is largely against “v2” libraries. After the first version is introduced, Go devs trend towards stability, live with its flaws, and are super hesitant to fix things with a “v2”.

There have been exceptions. After 20 years of the frankly horrible json library, a v2 one is in the works.

Most of the uuid concerns come from a place of concern. After the api is added to the standard library, it will be the canonical api forever.

There are surely pros and cons to this design philosophy. I just don’t understand why people who disagree with Go’s core goals don’t just use a different language? Sorry to take a jab here, but are we really short on programming languages that introduce the wrong v1 api, so then the language ends up with codebases that depend on v1, v2, and v3? (Looking at you Java, Python, and C#)

The real reason people learn English isn’t because it’s easy. It’s because they need to. As someone who is married to an immigrant, it’s not easy for them. They’ve just worked really hard over decades.

Americans will do fine learning Chinese if it ever becomes an economic necessity.