Let's say you have a task to go through, how to you know when to stop? Be it because you reach dead end, or your solution is good enough that more optimization may not worth the time spend.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (8)
Interesting question, for me it all depends on the time I have to do a task. If I don't have much time I will make sure it works, and give it a quick refactor. If I have more time I will spend a bit more time making it work, possibly trying a couple of solutions before settling for one, then I spend a bit of time adding more tests and cleaning and optimizing the code. But in the end at work, more often than not, we're limited by time presures, short deadlines, and what not... so the deadlines of many tasks are defined by time unfortunately
Good point. Deadline is the absolute stopping point, and that is often the case since our time is rather limited. However, what if you complete the work sooner than expected? For the spare time left, is it productive to spend time the way you suggested? We may feel it worth writting more tests, try out other solutions, but it can potentially be a waste of time, isn't it?
Deadlines? I've never worked anywhere where deadlines actually mean anything. The work is done when it's done - deadlines are empty threats
Well, lucky you!! In our case we need deadlines at our company, this does not mean we always follow them. If a task has not been completed in the stipulated time we will give more time. Of course the tasks is done when it's done, but a tasks completion is a spectrum based on a multitud of factors, one of them being time.
I am the same boat as Keff, and it is not limited to the workplace, even my personal project has a deadline. When I say absolute stopping point, I mean a final deadline. Certainly, deadline is something that we can push back if it is reasonable (other factors are under consideration). Surely, I never want to keep pushing it back, there must be a stopping point somewhere.
If there is no deadline, then we will definitely suffer the consequence of procrastination.
If I start sooner and feel like the tasks is apropiately completed and tested I will usually move to another one. I try to not waste time if I can
It's done by defining "acceptance criteria". IE actual testable and tangible things.
These should be defined upfront, they could be changed during the process itself, but they should at least be defined initially, and removed if the need arises based on what is learned during implementation.
Let's say your task is to create an acceptance criteria, what would be its definition of done? If I'm an end developer, then following a defined plan by the higher up is a safe way to have stopping points. However, if we go a little bit "meta", then the question is "When is the acceptance criteria acceptable?" I often find myself getting into this kind of paradox.
What is your opinion on this?