Comment by default-kramer | Hacker News Reader

Comment by default-kramer | Hacker News Reader

Parent Full thread

From the article

> I routinely come across developers who are the real deal: they’re conscientious and judicious in an unwavering way. They set a standard for themselves and do not compromise on it. Whether that’s a deliberate thing or whether they’re just built that way, it’s humbling to witness. If there’s a flaky test, they investigate it and fix it. If there’s a bug they spot in the wild, they make a ticket, and maybe even fix it then-and-there. If a new feature doesn’t gel well with the existing code, they refactor the code first rather than hacking the feature in. They’ll dive as far down the stack as necessary to get to the bottom of something. None of these things are necessary but great developers know that if they don’t address a problem early, and properly, it will only cost them more time in the long run. [... and more.]

This sounds like a great definition of not-lazy, and it does not mention long hours anywhere. My anecdotal experience is that I usually only have 20-35 not-lazy hours to give per week; any further hours per week are much less potent. Right now I'm working 24 hours per week and I think my employer is getting a great bargain: they don't have to pay me for hours that would likely be lazy.

> This sounds like a great definition of not-lazy, and it does not mention long hours anywhere.

Your definition of "not-lazy" by it's very nature relies on systematically working overtime.

Investigating and fixing flaky tests is either explicitly covered by a ticket, and thus a part of run-of-the-mill tasks, or something a developer does in unscheduled tasks by going above-and-beyond including in work hours.

Finding a bug, creating a ticket, and working on it is not proof of non-laziness as that's a part of the basic job description.

Refactoring a feature is either tracked by a ticket and covered in normal ticket-assignment processes, thus not a demonstration of lack of laziness, or it's something you do in your own time.

You have to clarify where you find the time to do all that "above-and-beyond" stuff because it's either normal work done on normal company time, which surely doing the normal/bare minimum is not proof of not being lazy, or it's going the extra mile, which is certainly not done during normal office hours.

I guess I've been lucky to work for companies that don't try to squeeze their developers so much. In my career, there has usually been time available to do things "the right way" (up to reasonable constraints of course).

> You have to clarify where you find the time to do all that "above-and-beyond" stuff because it's either normal work done on normal company time, which surely doing the normal/bare minimum is not proof of not being lazy, or it's going the extra mile, which is certainly not done during normal office hours.

At every company I've worked for, I've had time for "above-and-beyond" stuff during normal office hours. That's just how low expectations are in my neck of the woods. Or maybe I'm outrageously talented and I would still excel working on some elite FAANG team... but I doubt it.

Yeah, but that diligence takes time, and now you have to work on extra hours to keep up performance metrics with the rest of the team.

If I worked at a place where I was penalized for "only" putting in 40 hours of solid work per week, I'd be energetically looking for a job elsewhere.

> If I worked at a place where I was penalized for "only" putting in 40 hours of solid work per week, I'd be energetically looking for a job elsewhere.

I think you didn't understood the problem. No one is talking about penalizing people for only doing 40hours. The problem is that code quality is never prioritized or allocated time, so you either live with it or you go above and beyond and you deal it yourself on your own time. If your team is bounded to KPIs which you don't build up by refactoring bad code or diving deep into code issues or tracking weird elusive bugs, either you are forced to pull extra hours to no fall behind your team or your performance will clearly be awful.

> The problem is that code quality is never prioritized or allocated time, so you either live with it or you go above and beyond and you deal it yourself on your own time.

This is not an inevitability, though. It depends on the temperament of the company you work for. A slight majority of the companies I've worked for didn't mind allocating time for that sort of thing at all (but they did expect you to make a business case for it).

Reply on news.ycombinator.com