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!

	▲	redox99 an hour ago \| parent [-]
		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.

▲

philjohn an hour ago | parent | prev | next [-]

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?

▲

skydhash an hour ago | parent | prev [-]

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.