91–100 of 234 posts
The whole premise of the post, that coders remember what and why they wrote things from 6 months ago, is flawed. We've always had the problem that understanding while writing code is easier than understanding code you've written. This is why, in the pre-AI era, Joel Spolsky wrote: "It's harder to read code than to write it."
> The engineer who pauses to deeply understand what they built falls behind in velocity metrics. This is the most insidious part. It's not even that bad code gets deployed. That can be fixed and hopefully (by definition) the market weeds that out. The problem is that the market doesn't seem to operate like that, and instead the engineer who cares loses their job because they're not hitting the metrics.
Of course, there are counter examples but there's a disconnect between the production of something and the selling of it with almost opposing goals. Given unlimited money and time, many engineers, arts, etc will write and rewrite something to perfection. Constraints are needed because the world doesn't operate in a vacuum and unless we all live in a utopia, we have to compete for customers and resources. Constraints…
This is a common trope, but in my experience many engineers I met know that's not how a business runs. Dealing with the constraints and weighing them out is one of the essential skills of any engineer. Knowing when a product is just good enough is one of the things that make you senior.
I think we might as well just go all in at this point: "LGTM, LLM". The industry always overshoots and then self-corrects later. Therefore, maybe the right thing to do is help it get to a more sane equilibrium is to forget about the code altogether and focus on other ways to constrain it / ensure correctness and/or determine better ways to know when comprehension is needed vs optional. What I don't like is the imposs…
Now you could say that expectation has to change but I don’t see how—the people paying you expect you to produce working software. And we’ve always been biased in favor of short term shipping over longer term maintainability.
> When circumstances eventually require that understanding, when something breaks in an unexpected way or requirements change in a way that demands architectural reasoning, the organization discovers the deficit. Maybe it's because I work in such a small team on a still-starting project, but even with the chaos of LLM-generated code, I can't imagine such a case as above that the LLMs couldn't also address. Great read…
have you worked in a 10-15 year old codebase? because I honestly doubt that LLMs can cope with that.
The whole premise of the post, that coders remember what and why they wrote things from 6 months ago, is flawed. We've always had the problem that understanding while writing code is easier than understanding code you've written. This is why, in the pre-AI era, Joel Spolsky wrote: "It's harder to read code than to write it."
Meanwhile some stuff Claude wrote for me last week I barely remember what it even did at a high level.
I think we might as well just go all in at this point: "LGTM, LLM". The industry always overshoots and then self-corrects later. Therefore, maybe the right thing to do is help it get to a more sane equilibrium is to forget about the code altogether and focus on other ways to constrain it / ensure correctness and/or determine better ways to know when comprehension is needed vs optional. What I don't like is the imposs…
https://www.benguttmann.com/blog/double-it-or-cut-it-in-half...
The article very much resonates with my experience past several months. The project I work on has been steadily growing for years, but the amount of engineers taking care of it stayed same or even declined a bit. Most of features are isolated and left untouched for months unless something comes up. So far, I managed growing scope by relying on tests more and more. Then I switched to exclusively developing against a s…
I think we might as well just go all in at this point: "LGTM, LLM". The industry always overshoots and then self-corrects later. Therefore, maybe the right thing to do is help it get to a more sane equilibrium is to forget about the code altogether and focus on other ways to constrain it / ensure correctness and/or determine better ways to know when comprehension is needed vs optional. What I don't like is the imposs…
The productivity boost entirely depends on the way the software was written. Brownfield legacy projects with god classes and millions of lines of code which need to behave coherently across multiple channels- without actually having anything linking them from the written code? That shit is not even gonna get a 20% boost, you'll almost always be quicker on your own - what you do get is a fatigue bonus, by which I mean…
Code has become cheaper to produce than to perceive. Which means fixes can go in faster than it would require to first grok it What’s missing in literally every single one of these conversations is testing Literally all you have to do is implement test driven development and you solve like 99.9% of these issues Even if you don’t go fully TDD which I’m not a fan of necessarily having an extensive testing suite the cov…
When you need to implement something yourself, you have to make decisions when faced with the reality of turning ideas into code.
An AI agent sometimes surfaces these; and sometimes it just makes a choice.
The risk is tests just embed these decisions as policy in code, without there have been proper consideration.
Often there's a core ambiguity in a conception somewhere, and because of the limited context of an AI, it can implement things one way and then another for the next feature, without actually hitting the inconsistency.