Comment by xur17
3 years ago
I've worked at companies that tried to have explicit 20% policies, and it worked okay for some period of time, but then became difficult to prioritize. That said, I've typically been pretty successful at casually using 10 - 20% of my time to work on random low hanging fruit (dev ergonomics, performance, etc). For some reason using a quiet Friday afternoon, or time between tickets seemed to work better than an explicit "work on whatever you want every Friday".
At my old place they just overestimated my tasks complexity by 200-300%. I wasnt going to be the one saying no... So i had plenty of time to fix whatever.
I've always been a fan of the under promise and over deliver paradigm in tech. Overestimating gives you nice fat error margins should something unplanned come up, you're not slaving evenings and weekends away trying to meet a rough estimate that someone turned into a deadline for scheduling.
Once you finish meeting minimum requirements, should you have that margin padding, you can then refine what's been created. Fix issues or shortcuts you may have taken, improve or optimize some portion that'll give significant improvement in experience, add some additional functionality you think would be nice to have where permitted (while the context of everything is fresh in your mind).
Ultimately what's delivered will more often than not meet minimum requirements so whomever requested the work will be satisfied. They may even be incredibly pleased and consider you a wizard for some of the improvements (they also may not want the improvements so be sure to keep those modular you can very easily slice them off if they're undesired).
This keeps everyone happy really. When you start trying to optimize on the estimates so they reach actual time or a little under actual time to pressure developers to do OT, that's when you get into toxic environments. If you give a little error margin developers will likely reinvest it in your application where it sparks joy in them meaning you're about to get the highest quality work, the stuff the engineer wants to do.
In my old workplace, I overestimated my tasks by 2x. Who was to question me? The PM who hadn't coded in 10 years? My manager who had never used Python before?
Lucky you.. in my experience the answer to your 2 questions is: yes. Having no or outdated experience doesn't stop them from questioning even accurate estimates and attempting to filibuster their way into us lowing them.
My take is that it's always going to come with an implicit expectation of some "business value" resulting if it's time granted to you by your management. If you say "let us hack, we could come up with something that makes millions of dollars!" they're going to wonder constantly when exactly you're going to come up with those millions.