Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The peril of laziness lost

bcantrill.dtrace.org

Post reply on HN
Print view View original

141–148 of 148 posts

Re: The peril of laziness lost

#141

Post by bdangubic »

marcus_holmes wrote: post #117
bdangubic wrote: post #112

Earlier quoted context omitted.

here’s one thing that somewhat worked for my team. when we first started using LLMs we decided to run the same process as if they did not exist, same sprint planning meetings, same estimation. we did this for 6 months and saw roughly 55% increase in output compared to pre-LLM usage. there are biases in what were tried to achieve, it is not easy to estimate something will take XX hours when you know some portion (for…

wow, great experiment. I'm amazed the whole team went through with duplicating everything for that long. Nice work :) I resorted to feels. After decades of programming, I know when I'm being productive, and I can reasonably estimate when a colleague is being productive. I extrapolate that to the LLM, too. Absolutely not an objective measure, but I feel that I can get the LLM to do in a day a task that would take me 2…

I did too also generally resorted to feels. However, as a team we decided that we need to convince ourselves that LLMs are both an accelerator as well as not introducing flaws in our process (regressions, performance issues, security issues...). My team is pretty awesome and we generally try not to "fall for FOMO" type deals, like "everyone is using ____, surely we must as well."

just like HN, we had team members that were hesitant to say the least in the beginning as well as team members that were "convinced" a lot earlier that LLMs can be a great accelerator to what we are doing. I would venture a guess that similar situation exists(ed) in many places. so we tried to figure out a way where it is not just portion of the team "putting the foot down" so-to-speak but more like "OK, lets see if this can be measured so that everyone (or lets say overwhelming majority) is on board." I wish I would read that more teams at least attempted this approach...

Re: The peril of laziness lost

#142

Post by glitchc »

dap wrote: post #126
glitchc wrote: post #59

Hard disagree with the initial assumption: Abstractions do not make a system simpler. Note: I would have added usually but I really do mean always.

I’m curious what you think an abstraction is. Even running “ls” involves several layers of abstraction: a shell, a process (abstracts memory), a thread (abstracts CPU)… you think it would be simpler if you had to deal with all that to list a directory (another abstraction)? Even bits are an abstraction over analog voltage levels.

You're taking it out of context. I'm specifically referring to abstractions introduced in the codebase to maximize code reuse, as per the OP's comment.

Re: The peril of laziness lost

#143

Post by suzzer99 »

HarHarVeryFunny wrote: post #81
wcarss wrote: post #58

Earlier quoted context omitted.

I agree with what you're saying about writing something twice or even three times to really understand it but I think you might have misunderstood the WET idea: as I understand it, it's meant in opposition to DRY, in the sense of "allow a second copy of the same code", and then when you need a third copy, start to consider introducing an abstraction, rather than religiously avoiding repeated code.

Personally, even for a prototype, I'd be using functions immediately as soon as I saw (or anticipated) I needed to do same thing twice - mainly so that if I want to change it later there is one place to change, not many. It's the same for production code of course, but when prototyping the code structure may be quite fluid and you want to keep making changes easy, not have to remember to update multiple copies of the…

> mainly so that if I want to change it later there is one place to change, not many

But what happens when new requirements come in for just one of the things? If you left them separate, it's an easy change of a few lines. If you created an abstraction, now you either have to add a bunch of if statements, or spend time undoing the entire abstraction that you spent X amount of time creating.

If a bunch of other code has built up around that abstraction, undoing it can become a serious chore. I've worked on apps that had way too many premature abstractions, and we just had to live with it because it would be too risky and onerous to try to undo them.

In my experience, it's generally an order of magnitude easier to add an abstraction to a mature app when you get tired of making changes in multiple places, than to remove one when the app evolves and you realize these things aren't actually that similar. Also when you wait to abstract, you might see a better way to do it, or how to reduce the scope so that you're using composition to share a bunch of smaller pieces vs. sharing the entire page/object/interface/endpoint/etc.

Obviously, this isn't a blanket rule. There's an aspect of soothsaying to guess which things might diverge and which are likely to spawn a lot more similar copies.

Re: The peril of laziness lost

#144

Post by ossianericson »

The friction Cantrill describes does not go away, it just moves. In my experience, if you don't do the "lazy" thinking before the model touches anything, you pay for it when trying to maintain something you didn't mentally build. The spec becomes the place where the laziness discipline has to live now.

Re: The peril of laziness lost

#145

Post by dap »

glitchc wrote: post #142
dap wrote: post #126

Earlier quoted context omitted.

I’m curious what you think an abstraction is. Even running “ls” involves several layers of abstraction: a shell, a process (abstracts memory), a thread (abstracts CPU)… you think it would be simpler if you had to deal with all that to list a directory (another abstraction)? Even bits are an abstraction over analog voltage levels.

You're taking it out of context. I'm specifically referring to abstractions introduced in the codebase to maximize code reuse, as per the OP's comment.

I don't think these things are as different as you think. I started at "ls" and worked down. If you work up, you get things like a "socket", an "object" within a programming language, a "linked list" in a standard library, an "HTTP client" within an application-level package. You can keep going up and rattle off lots of useful abstractions in application-level code.

There are certainly _bad_ abstractions that ought not to exist, which I think is what you're getting at. There are poorly built abstractions, and leaky abstractions. But abstraction itself isn't the problem -- abstraction is what allows us to build anything at all without being crushed by the sheer complexity.

Re: The peril of laziness lost

#146

Post by HarHarVeryFunny »

suzzer99 wrote: post #143
HarHarVeryFunny wrote: post #81

Earlier quoted context omitted.

Personally, even for a prototype, I'd be using functions immediately as soon as I saw (or anticipated) I needed to do same thing twice - mainly so that if I want to change it later there is one place to change, not many. It's the same for production code of course, but when prototyping the code structure may be quite fluid and you want to keep making changes easy, not have to remember to update multiple copies of the…

> mainly so that if I want to change it later there is one place to change, not many But what happens when new requirements come in for just one of the things? If you left them separate, it's an easy change of a few lines. If you created an abstraction, now you either have to add a bunch of if statements, or spend time undoing the entire abstraction that you spent X amount of time creating. If a bunch of other code h…

> But what happens when new requirements come in for just one of the things?

I guess it could happen, but that depends on your mental model when coding - if you're just pattern matching similar chunks of code (which are not being used in a semantically identical way) then all bets are off, although that seems a very alien concept of how someone might code.

OTOH, if you have a higher level mental model of what you are doing then it's not a matter of "this looks like common code" but rather "i need to do the exact same operation" (same inputs/outputs/semantics) here. Maybe I'm expressing it poorly, but I can't recall ever having to fork a function because requirements at two call sites just diverged.

Re: The peril of laziness lost

#147

Post by glitchc »

dap wrote: post #145
glitchc wrote: post #142

Earlier quoted context omitted.

You're taking it out of context. I'm specifically referring to abstractions introduced in the codebase to maximize code reuse, as per the OP's comment.

I don't think these things are as different as you think. I started at "ls" and worked down. If you work up, you get things like a "socket", an "object" within a programming language, a "linked list" in a standard library, an "HTTP client" within an application-level package. You can keep going up and rattle off lots of useful abstractions in application-level code. There are certainly _bad_ abstractions that ought n…

You're conflating system level abstractions with code-based abstractions. As a counter-example, introducing a factory constructor to handle object creation makes the codebase harder to understand.

Re: The peril of laziness lost

#148

Post by bcantrill »

theshrike79 wrote: post #132
rakel_rakel wrote: post #31

Earlier quoted context omitted.

https://xkcd.com/1053/ I recommend you go look at some of his talks on Youtube, his best five talks are probably all in my all time top-ten list!

The content of his talks is very good, but his habit of SHOUTING all the time just grates my brain the wrong way. I can literally see the veins in his neck bulging as he screams out his presentation.

That feels a tad unfair?
Post reply on HN