4 ms·
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
by freedom2099 5y ago
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)
- vlovich123 5y agoWho 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.
- 0des 5y agoon 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 https://www.biblio.com/9780201835953
- slowmovintarget 5y agoI read that twenty years ago, and it is still relevant.
- 0des 5y agoJust curious, do you have any other recommendations that are more or less timeless?
- vladak 5y agohttps://archive.org/download/the-unwritten-laws-of-engineering/The%20Unwritten%20Laws%20of%20Engineering.pdf 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).
- Splizard 5y agoSYSTEMANTICS. THE SYSTEMS BIBLE / How Systems Work and Especially How They Fail
- pm90 5y agoYou 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.
- yahn00 5y ago[flagged]
- xyzzy21 5y agoAnd 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.
- vlovich123 5y agoOutsourcing 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.
- epolanski 5y agoWriting 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.
- giantg2 5y agoSounded 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.
- xyzzy21 5y agoExactly. 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).