Not living to work. Is there something wrong with me?

[mjr]

I'm a software engineer

Me, too.

and I can tell you that sometimes working 50-60 hours a week and some late nights/weekends comes with the job when you're approaching a deadline.

The problem with this, in my opinion, is that it's a problem with planning by management. Management (in general) has a bad habit of setting unrealistic goals for projects, and never being "wrong". Just work people more. The problem is, studies have shown that working beyond 40 hours per week is actually detrimental to performance. In Software Engineering, you start cutting corners, getting sloppy, neglecting testing, and making poor coding decisions. So it takes you LONGER than it would otherwise. Robert C. Martin has written a couple of books and articles on that very subject.

[TheHuckster]

The problem with this, in my opinion, is that it's a problem with planning by management. Management (in general) has a bad habit of setting unrealistic goals for projects, and never being "wrong". Just work people more. The problem is, studies have shown that working beyond 40 hours per week is actually detrimental to performance. In Software Engineering, you start cutting corners, getting sloppy, neglecting testing, and making poor coding decisions. So it takes you LONGER than it would otherwise. Robert C. Martin has written a couple of books and articles on that very subject.

That's very true, but in short stints (I'm talking about a week, not any longer) it can mean the difference between making a deadline and having to extend it. The stakeholders have likely set aside times to demonstrate the software, or have things lined up for deployment that, if extended even a few days, could threaten the success of the project. If they're counting on this complete for a trade show, or something, and you miss that deadline, you've just missed a critical opportunity.

The problem is the 80/20 rule. You might have a project 95% done, and it looks like it's on the way to success until the testing/final phase where anything can go wrong, and Murphy's Law takes hold. Something takes a little longer than you might think, and you might have missed your estimate by something as little as 2% but it still means you need weekend work to make up for it.

And anything, and I mean anything can threaten the schedule that is beyond even the managers' control. Sick days, snow days, unexpected problems (third party software having poor documentation), R&D delays (giving an ETA on research into a new technology is basically impossible)... and if you're off on your ETA by only 10 hours everything looks good until you are a week or two out.

I've been on projects that went perfectly, except for this one last tiny step that was discovered in a final phase and took longer than expected, and we had to work a few extra hours for it. No biggie.

And believe me, I've been on projects that were managed horribly where not only was it over the deadline by MONTHS, but everyone was working 80-hour weeks for all of those months just to get it out the door, and the resulting product is exactly what you think they are. After having been in those projects and not seeing any improvement because the management is too thick-headed to fix the problem, it's the reason they're in my "past employment" section on my resume.

[gremcint]

I used to live to school but I just don't have that in me anymore and I'm trying to find it so I can finish my thesis.

[MadMike]

Management (in general) has a bad habit of setting unrealistic goals for projects, and never being "wrong". Just work people more.

Yep, we went through this with a major project at my job awhile back. They set a deadline, and the project was going live on that date, come hell or high water. Of course, the smaller bits and pieces kept falling behind schedule, and they had to move dates out, but they still kept the original deadline date. They just took time away from the remaining pieces, threw more people at it, mandated overtime, etc. And like you said, corners started being cut, and mistakes started being made. One exact quote from one of our wonderful managers was, "We don't have time to do it right! We'll fix it later!"

And of course, that bit us in the ass for many years to come. It seemed like we were fixing things forever.

[Andara Bledin]

Well, you can either do it right, or do it over. Your bosses opted for the latter.

[Rapscallion]

I came to my current place of work from a very underpaid origin (hint: don't work for family). I grasped onto the overtime with both hands. Came in very useful in the first few years of my mortgage.

These days, I've cut down the overtime and am even starting to plan holidays, rather than 'guess I'd better use some up'. Could be far worse, but I took a conscious step to get as much overtime and me as far in front as possible by working my derriere off, and then easing off later. Physically, my knees hate me, and thus my options for manual overtime are limited. However, I'm avoiding the course taken by some I know of living to work. I knew I wanted to get ahead, and I'm there now, and I'm intent on staying there.

That being said, I'm easing off the charge and enjoying life more. Trying to get more of a life, and I'm even reckoning on a holiday in a few weeks to visit as many historic sites (mostly castles) in the south-west shortly. I don't begrudge the many long hours I put in when younger and more able to do it; whilst I'm not rich by any means, I'm reasonably comfortable since I did that work in the past.

Rapscallion

[Racket_Man]

The problem with this, in my opinion, is that it's a problem with planning by management. Management (in general) has a bad habit of setting unrealistic goals for projects, and never being "wrong". Just work people more. The problem is, studies have shown that working beyond 40 hours per week is actually detrimental to performance. In Software Engineering, you start cutting corners, getting sloppy, neglecting testing, and making poor coding decisions. So it takes you LONGER than it would otherwise. Robert C. Martin has written a couple of books and articles on that very subject.

I learned about this book The Mythical Man-Month waaaayyyyy back in my early college days (IT/software design/systems design/programming/etc. in the late 1970's/early 1980's 1st degree and again in the late 1980's 2d degree). one of the system design prof's swore by it and assigned this article/work as a REQUIRED reading assignment .

The full article is here as a PDF https://www.cs.virginia.edu/~evans/g...s/mythical.pdf