undefined | Better HN

0 pointsKronisLV3y ago0 comments

> Creating those estimates alone is more than the sum of total work usually.

Then simply add those hours spent estimating things to whatever time management solution that you use personally (for insights into where your time goes each quarter/year) or that your company mandates (for basically the same thing). If it's an actual problem, then simply raise it as such later down the road and look for ways to streamline things.

Most of the time you shouldn't care about how much time something takes (exceptions exist, based on the industry/project, but many deadlines are made up anyways), merely that the time to be spent on the task has been approved and that you're not doing something that isn't documented/categorized, e.g. time that "disappears" by being spent on things that don't have any sort of visibility/basis for taking up your time.

If changing how a button works takes 2 hours but writing tests takes 4 and refactoring old code takes another hour, then let the record show exactly that. If unclear requirements cause you to spend another hour or two in meetings and talking to people who didn't document code or explain their changes in merge/pull requests, then let the record show that, too.

Of course, this might vary on a per-company/project/culture basis.

> Then the problem of convincing others is itself typically more than the sum of total work.

If others in the team don't want to fix these things, then they probably aren't as important/annoying as you think they are and therefore probably won't be prioritized so highly anyways. When there are really annoying/brittle API integrations, for example, most devs usually should back you up in your efforts in making things less horrible.

> Usually metrics aren't accurate enough to be able to prove these things anyway in my experience.

You don't actually need metrics that are completely accurate, because finding ones that are is seldom easy to do or even possible, or simply not worth the effort. Having something to the tune of "This API integration can be improved, the last 3 feature requests related to it exceeded their estimates by quite a bit" should be enough, provided that you can get the other people on board.

If you cannot, then it's probably an issue of the actual work environment/culture and/or soft skills.

0 comments

Groxx3y ago

>Then simply add those hours spent estimating things to whatever time management solution that you use personally (for insights into where your time goes each quarter/year) or that your company mandates (for basically the same thing).

Which sometimes means it doesn't happen because it's not valuable enough at any given instant to go through that multi-hour process, yes.

Lightweight tasks exist. As much as I generally agree with you, following your rules means you either do not ever do them, or you bloat them to multiple times larger than necessary. And correcting a company's task-management process as a whole is not always feasible either.

KronisLVOP3y ago

> Lightweight tasks exist. As much as I generally agree with you, following your rules means you either do not ever do them, or you bloat them to multiple times larger than necessary. And correcting a company's task-management process as a whole is not always feasible either.

Creating a short Jira issue and poking someone about including it in the current sprint should take about 10 minutes in total, if you want a decent description and are okay with occasionally not focusing on the "ceremonies" of sprint grooming too much, since as you say, some tasks are indeed small (and as long as this doesn't lead to scope creep, e.g. fixes/refactoring instead of new features this way).

Of course, that may always not be viable and i see where you're coming from - yours is also a valid stance to take and i see why focusing on an issue tracker too much would be cumbersome. Then again, in my eyes that's a bit like the difference between having almost entirely empty pull/merge requests and having a description of why the changes exist, a summary of what's done (high level overview), additional relevant details and images/GIFs of the changes in action, DB schema diagrams or anything of the sort.

I feel like additional information will always be useful, as long as it doesn't get in the way of getting things done (for an analogy, think along the lines of covering most of the business logic with tests vs doing TDD against a bloated web framework and thus not getting anything done - a few tradeoffs to be made).

j / k navigate · click thread line to collapse