News for hackers. Stuff that matters.
Re:How should we handle an over-productive employee? by ryandrake on Friday September 09, 2022 @10:54AM (#32779995)
> The counterpoint to this is if you aren't specifically assigned tasks you're basically expected to go through the backlog to hunt for things to do. In most companies the backlog is never empty and so you don't really get any time for any of these ancillary tasks.

Yea, instead of thumb twiddling, just go fix some bugs! Every company I've ever worked at had 1. more bugs than could ever be fixed and 2. had an incoming bug rate faster than the team's fix rate, therefore the bug count perpetually grew. Some of these could be long standing bugs that annoy actual users that just perpetually get ignored by the company. Go fix one and make someone's day.

There is no such thing as a Software Engineer with nothing to do. When I read HN comments from software engineers who say things like "yawn, my work fits into about 6 hours a week, and the remaining 34 hours I just take it easy, maybe work on a side project, maybe horse around on Facebook..." my mind boggles! Where do you work where there are no bugs in the backlog to fix??

If there are really no bugs to fix, maybe look into cleaning up the code base. Turn a few compiler warnings on or run the static analyzer and go looking for trouble. Re-factor that gnarly part of the code that's always tripped up new employees. Add unit tests. Add integration tests. Automate some part of the build. Maybe work on a nicer bug dashboard.

Re:How should we handle an over-productive employee? by Kakashi4 on Friday September 09, 2022 @11:12AM (#32780190)
All the things you've mentioned if there's no bugs to fix sound really boring to do. They're also high effort, low reward (most of the time). I'd rather do something else that I enjoy, than do any of that since I'd get paid the same amount if I did it or not. Not everyone works on something that they're hyper passionate about, or that is very useful to people, to the extent that they'd work on it if they don't have to
Re:How should we handle an over-productive employee? by marssaxman on Friday September 09, 2022 @08:33PM (#32786515)
> All the things you've mentioned if there's no bugs to fix sound really boring to do.

It's a good thing different people have different preferences - cleaning up a gnarly, messy old codebase so it doesn't just work, but actually shines, is some of what I love to do most!

Re:How should we handle an over-productive employee? by Kakashi4 on Saturday September 10, 2022 @03:17AM (#32788576)
Yes that's exactly my point. Different people have different preferences so it's strange when the parent comment mentions that their mind boggles when other engineers say they don't have anything they want to do ¯\_(ツ)_/¯
Re:How should we handle an over-productive employee? by katrotz on Friday September 09, 2022 @05:20PM (#32785063)
Thats more a question of having a balanced team size, ownership and accountability.
Re:How should we handle an over-productive employee? by stackbutterflow on Friday September 09, 2022 @11:02AM (#32780082)
Common answer is you don't get paid more.
Re:How should we handle an over-productive employee? by Test0129 on Friday September 09, 2022 @11:07AM (#32780136)
As much as most people don't like to admit it this is also the reason I tend to not vigorously hunt for work in the backlog after hitting my requisite sprint goal plus a few points. Realistically bug fixing like a mad man is what makes us look at each other as good engineers. Managers, however, will see this and raise your sprint points next time making your goals that harder to achieve. Goodhart's law raises it's ugly head every time JIRA is used. Unpointed work can be seen as a boon (in the right company) but in most companies today working on something unpointed is "cowboy" and you're more likely to get in trouble for it. Even if the marginal benefit is positive.
Re:How should we handle an over-productive employee? by Frotag on Friday September 09, 2022 @12:43PM (#32781564)
Plus, I may have downtime to dumpster dive for old tickets but my manager / peers usually don't. So try to I avoid creating PR work for others unless the ticket is relevant to the feature-being-developed or a one-line fix.