> It also ends up happening that they work on the wrong thing because no one is around at night or weekends to answer basic questions that may unfortunately not be in the ticket.

I know the comment came from a good place and you meant well. The situation you describe of “developers working on the wrong thing” can and sometimes does happen, however, as a manager the effective way to handle those situations is to address the root cause. Is it because the task is too big, not enough details, is it too early in the project that the requirements haven’t really surfaced organically? You want your team to be autonomous, you want to empower your team to make mistakes and at the same time actively minimize the chance for mistakes by greasing “things” so people around you can be more effective.

There are few things as negative for a team performance as an insecure manager that needs to be making tactical decisions for the team as if developers were little kids.

I'm sorry, but I don't think that's what they were saying at all. To me, it sounded like they were saying that when a developer works alone at nights or on the weekend, they cannot ask other members of the team, or the person who originally filed the ticket, any questions. Thus, if the ticket is vague, or if they have a question about a part of the codebase they are less familiar with, they have to spend a lot of time trying to divine the answers themselves when they could just walk over or message their colleague for the answer on a normal work day. Spending three hours rederiving trivial knowledge that other members of your team already know (such as which package something is in, or the exact set of inputs that reliably reproduce a bug), IS spending time on the wrong things.

I agree that a manager shouldn't micromanage to the point that they believe developers cannot be productive without their manager physically present, but that is not what they were talking about. The comment isn't about the developer needing their manager's insight or guidance, but about the developer needing the expertise of the rest of the team, which they will not have access to at nights or on the weekend.

> To me, it sounded like they were saying that when a developer works alone at nights or on the weekend, they cannot ask other members of the team, or the person who originally filed the ticket, any questions.

I think in response to the OP, the user identified the "problem." I've worked places where the above was the norm, and other places where if ticket showed up in front of a developer and required additional clarification (from QA or other developers) this would be covered in detail during sprint retrospectives, with the intention of making sure that the team works hard to make sure that this never happens. It can blow estimates not only for the given task, but can have cascading effects as well.

That said, this might not be easily attainable or the best practice for all organizations, but I think I prefer better processes over evening and weekend work.

This is a very commendable default approach. Let me suggest that there are also people who just happen to be that way naturally.

I for example seem to almost need this kind of rhythm. Yes it is spiky and sometimes a bit chaotic. But also very intrinsically motivated, which can sometimes lead to high impact solutions.

A good way to deal with this tradeoff is writing more text and less code. Text which is off-base is much more valuable than code that does do wrong things or things in a wrong way.

But I have to say that I work alone or in small teams, which requires less technical coordination.