Though I'm not a junior, I do lead teams with junior developers.
I feel *excessive overtime * in software development has been a huge problem for decades and I have been totally burnt out by it. My regret is letting myself be burnt out and not saying "no more".
I think there's a difference between overtime 'work' and self learning/improvement. Though that's a tricky subject...I feel your workplace should give you enough time to learn and grow. At the same time, there are limits, and I don't expect my employer to pay for my personal projects.
Regarding overtime work, I do think some overtime is unavoidable in development (especially in certain kinds of roles and companies), but junior developers should feel comfortable to stand up to managers and say no.
They should feel comfortable in setting certain boundaries and push back when they feel they are working excessive overtime. I do believe this takes experience and practice. It's hard to push back the first few times, but now, I don't think twice about it. My health is of primary concern. This doesn't mean I never do overtime, but I know my limits and will not cross it.
As a lead, I personally get concerned if I find a junior dev on my team is constantly working late hours to get their tasks done or always volunteering for overtime work. I feel it is part of the management and tech-leadership to step in and have a discussion about why a particular developer feels they have to work so much overtime.
The discussions are helpful because sometimes junior developers have fears that they are i) underperforming and ii) feel that simply putting in more hours to 'make up' for their slowness is the right thing to do. Those are just two of many examples I've come across.
Did it help my career? To be fully honest, I think there were some short term gains but in the long run I don't think it had a meaningful impact.
Thanks for answering! If that's fine, I have a couple of questions on some things you mention:
"Regarding overtime work, I do think some overtime is unavoidable in development (especially in certain kinds of roles and companies)" what kind of roles and companies did you have in mind?
As a lead, do you feel they perform well and have good quality code when they overwork?
Thanks for answering! If that's fine, I have a couple of questions on some things you mention
No problem, I'm happy to answer other questions :)
Regarding companies with unavoidable overtime
hmm what I meant about 'unavoidable overtime' is that the kind of company, their business, and team structure all effect the chance a junior (or any level) developer will encounter overtime.
For example, consulting companies and agencies can have some very tight deadlines, managers stressed out on P&L targets, and angry clients. In addition, the work load tends to be cyclical (busy trying to get the client transitions to a nice work routine transitions into a mad rush trying to get the job done by the deadline).
Some projects have very strict SLAs, which might mean overtime work too. But it all depends on the individual company and a host of different factors.
As a lead, do you feel they perform well and have good quality code when they overwork?
I don't think all overtime hours are homogeneous. I generally don't see a drop in quality if a project requires a small amount of occasional overtime. But...
When overtime is excessive or frequent (even in small amounts) or deemed unjustified, I very quickly see a drop in morale (both individual and in the team). Developers as a whole write less tests, do less testing, and code reviews become rubber stamps - just so tasks can be marked done.
Senior devs can become very jaded, less open minded about listening to different ways to solve solutions, and often loose their eagerness to mentor junior developers. This has a impact on junior members on the team as they can loose their enthusiasm and willingness to improve - especially when they feel they can no longer ask questions or if their input is constantly discounted.
But each person and team have their own individual limits...which change over time.
Thank you for taking the time to answer, I really appreciate your input as a dev (or tech) lead. :)
It's a very fair point that a couple of extra hours here and there don't have a bad impact on the quality (with precautions taken), but crunch becomes a serious issue really quick.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Though I'm not a junior, I do lead teams with junior developers.
I feel *excessive overtime * in software development has been a huge problem for decades and I have been totally burnt out by it. My regret is letting myself be burnt out and not saying "no more".
I think there's a difference between overtime 'work' and self learning/improvement. Though that's a tricky subject...I feel your workplace should give you enough time to learn and grow. At the same time, there are limits, and I don't expect my employer to pay for my personal projects.
Regarding overtime work, I do think some overtime is unavoidable in development (especially in certain kinds of roles and companies), but junior developers should feel comfortable to stand up to managers and say no.
They should feel comfortable in setting certain boundaries and push back when they feel they are working excessive overtime. I do believe this takes experience and practice. It's hard to push back the first few times, but now, I don't think twice about it. My health is of primary concern. This doesn't mean I never do overtime, but I know my limits and will not cross it.
As a lead, I personally get concerned if I find a junior dev on my team is constantly working late hours to get their tasks done or always volunteering for overtime work. I feel it is part of the management and tech-leadership to step in and have a discussion about why a particular developer feels they have to work so much overtime.
The discussions are helpful because sometimes junior developers have fears that they are i) underperforming and ii) feel that simply putting in more hours to 'make up' for their slowness is the right thing to do. Those are just two of many examples I've come across.
Did it help my career? To be fully honest, I think there were some short term gains but in the long run I don't think it had a meaningful impact.
Thanks for answering! If that's fine, I have a couple of questions on some things you mention:
No problem, I'm happy to answer other questions :)
hmm what I meant about 'unavoidable overtime' is that the kind of company, their business, and team structure all effect the chance a junior (or any level) developer will encounter overtime.
For example, consulting companies and agencies can have some very tight deadlines, managers stressed out on P&L targets, and angry clients. In addition, the work load tends to be cyclical (busy trying to get the client transitions to a nice work routine transitions into a mad rush trying to get the job done by the deadline).
Some projects have very strict SLAs, which might mean overtime work too. But it all depends on the individual company and a host of different factors.
I don't think all overtime hours are homogeneous. I generally don't see a drop in quality if a project requires a small amount of occasional overtime. But...
When overtime is excessive or frequent (even in small amounts) or deemed unjustified, I very quickly see a drop in morale (both individual and in the team). Developers as a whole write less tests, do less testing, and code reviews become rubber stamps - just so tasks can be marked done.
Senior devs can become very jaded, less open minded about listening to different ways to solve solutions, and often loose their eagerness to mentor junior developers. This has a impact on junior members on the team as they can loose their enthusiasm and willingness to improve - especially when they feel they can no longer ask questions or if their input is constantly discounted.
But each person and team have their own individual limits...which change over time.
Thank you for taking the time to answer, I really appreciate your input as a dev (or tech) lead. :)
It's a very fair point that a couple of extra hours here and there don't have a bad impact on the quality (with precautions taken), but crunch becomes a serious issue really quick.