Lines of code for a bugfix is a really bad proxy for effort required.
You should estimate how much time it would have taken a human
Lines of code for a bugfix is a really bad proxy for effort required.
You should estimate how much time it would have taken a human
30 seconds or a minute? Look at the diff he links to: https://github.com/datasette/datasette-agent/commit/a75a8b72...
Every browser has an inspector that can show you which element is causing overflow. You walk through the tree, find the offender, and add min-width or overflow. Zero tokens, just like in the old days!
Now, granted, because the garbage LLM code he’s working with has CSS inside HTML inside JavaScript inside Python (I wish I were kidding), finding the styles in his codebase might’ve taken a minute. But even then!
Yeah looking at that diff it should be very quick. My point was mostly that it was a bad metric, not if was correct or not in this particular case. I'm sure everybody's had a bugfix that took days to debug and it was just a couple of lines to fix.
Or sometimes a fix is obvious, but because it requires changing the code of a dependency, it's actually quite tedious to implement.
I was thinking of this too. It did all that what not only for a single line that is a simple thing even for someone new to web coding. That's to say the process matters more.
> Zero tokens, just like in the old days!
because you zero rate your own human attention, which you should value
Alas, LLMs require more attention, not less.
A small diff /= a small change! They are completely separate things. Quite often a small diff is hours of actual work. Even in this case _finding_ those lines could have taken work - we don't really know.
Did you actually look at the diff, though? That’s the kind of change you make 10 times a day while working on frontend. It is a tiny change.
I looked at the screenshot and for the rest of the article wondered if it would be as simple as `overflow-x: hidden`.
And to my surprise it was.
This would’ve take a frontend dev 10 seconds to deduce and another 10 seconds to confirm.
The thing that puzzles me is that I would expect overflow-x: hidden to result in text typed into that textarea being wider than the page and being invisibly truncated on the right hand side.
But that's not what happens. And in fact, when you start typing in the textarea the horizontal scrollbar vanishes - it's only there when the textarea is empty.
Am I misunderstanding anything here? Seems like it's some weird Safari bug, since Firefox and Chrome don't have the problem.
It probably has to do with other styles assigned to the textarea, maybe the ::placeholder as it hides when typing (I assume on focus)
In any case. In the screenshot the scrollbar is inside the textarea as it aligns with the resize control on its right. This is basically all the info needed to deduce the textarea overflow is the culprit.
But could be that the overflow-x is just a bandaid hiding the issue causing the overflow in the first place, like crazy styles on the placeholder.
I mean - that looks like a pretty easy CSS fix to play around with in developer tools, and I'm not even a frontend person. Maybe a few minutes max?
5 minutes if you know CSS. And if you don’t, about the time for you to ask someone that knows CSS. In the worst case, the amount of hours to learn CSS.
So if you’re doing web pages, learn CSS.
Generally, if you’re doing something that directly involves X, learn how X works.
ADDENDUM
In most jobs, you’re going to be involved in only a few distinct technologies, learn those well and life is going to be easier. And most are transferable to the next job.
ain’t no one learning all of that