Hacker News Reader

Comment by freedom2099 | Hacker News Reader

freedom2099

That is not at all what the article was about! It was never stated that you should be late or take too much time in doing tasks… it was about using more wisely your time (if the sizing claimed the task needed 5 days to be done and you are done in 2 maybe you could have spent more time thinking about the design or if everything is ok try to using the extra time to generate value in other ways instead of rushing towards the next task)

View on HN

Who establishes that sizing? I’ve yet to see anyone who can accurately estimate their own tasks let alone someone who can estimate that for others.

In agile, I think a great time for reflection is between sprints.

Also, I’m super fast but I’ll instead take frequent small breaks in the middle of work (read hacker news, write up documentation etc). There are other times to reflect than between tasks.

on this topic, I would like to add this:

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

by Frederick P. Brooks

ISBN 13: 9780201835953

ISBN 10: 0201835959

https://www.biblio.com/9780201835953

I read that twenty years ago, and it is still relevant.

Just curious, do you have any other recommendations that are more or less timeless?

SYSTEMANTICS. THE SYSTEMS BIBLE / How Systems Work and Especially How They Fail

https://archive.org/download/the-unwritten-laws-of-engineeri...

I had a colleague that can be considered brilliant engineer and I believe could be doing all kinds of exciting hard projects and work in the top tier companies. When our manager decided to leave the company, he went along, for a job which in my view is nowhere near his maximum abilities (although he might argue otherwise), quoting the 'Be as particular as you can in the selection of your supervisor.' rule from the above book (which is relevant to the other thread in this topic).

You decide as a team.

Concepts like story points and processes like agile sprints are intended to create a more realistic estimate of the work a team can deliver. The process comes with tradeoffs; it won’t work for everyone. So then it’s up to them to bring it up during retrospectives and decide to either change the process or… not.

It’s important to understand that working on a team means that you just don’t get to have all the nice things that you would working individually. You gotta approach it with that mindset.

And you ask the "stakeholders" you are producing for.

If you still want some perfection, ration it out on an easier schedule and use incremental perfection as "treat" for the stakeholders over time while you get something for it at each incremental delivery.

Outsourcing task estimation to the team still doesn't solve the estimates are broken issue. I've not seen estimates get meaningfully better in an environment where the team collaborates on establishing the expected time for a task.

It’s not perfect, and importantly doesn’t claim to be. It’s something in the absence of other ways of estimation. Use whatever works best for your team.

Nit: It’s not “outsourcing” in any meaningful definition of the term to have the team responsible for executing a task come up with estimates.

Writing documentation is work, taking small breaks is normal, not cheating.

In the office coffee, smoke, chat breaks were the norm, now people feel the need to justify 5 minutes of YouTube.

Sounded more like if you get it done early, wait until the due date to hand it in. Them use the extra time for other stuff.

Exactly. Then divide the saved time on things you can learn from, that you enjoy or to prep for things that can for your advantage (e.g. G-jobs).

Reply on news.ycombinator.com