Re: Overtime: the "Bad News" Warning Sign (Process and Quality References)

[eyepopslikeamosquito]

A few quotes from Peopleware on the subject of overtime:

Overtime for salaried workers is a figment of the naive manager's imagination. Oh, there might be some benefit in a few extra hours worked on Saturday to meet a Monday deadline, but that's almost always followed by an equal period of compensatory "undertime" while the workers catch up with their lives. Overtime is like sprinting: It makes some sense for the last hundred yards of the marathon for those with any energy left, but if you start sprinting in the first mile, you're just wasting time.

It has been our experience that the positive potential of working extra hours is far exaggerated, and that its negative impact is almost never considered. That negative impact can be substantial: error, burnout, accelerated turnover, and compensatory "undertime" ... When you take into account the way that the team members' differing abilities to work overtime tends to destroy teams, the case against it becomes persuasive.

They further note that Jerry Weinberg proposed an interesting psychological explanation for why so many folks propose overtime even though they know it's not going to help: "we don't work overtime so much to get the work done on time as to shield ourselves from blame when the work inevitably doesn't get done on time".

Process References

• Five Whys
• Common Software Development Mistakes
• Working Solo and in a Team and Psychological Safety
• Conflict in Teams

• Nobody Expects the Agile Imposition (Part I): Meta Process
• Nobody Expects the Agile Imposition (Part II): The Office
• Nobody Expects the Agile Imposition (Part III): People
• Nobody Expects the Agile Imposition (Part IV): Teamwork
• Nobody Expects the Agile Imposition (Part V): Meetings
• Nobody Expects the Agile Imposition (Part VI): Architecture
• Nobody Expects the Agile Imposition (Part VII): Metrics
• Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship
• Nobody Expects the Agile Imposition (Part IX): Culture

• Organizational Culture (Part I): Introduction
• Organizational Culture (Part II): Meta Process
• Organizational Culture (Part III): Spaceflight and Aviation
• Organizational Culture (Part IV): Perl Culture
• Organizational Culture (Part V): Behavior
• Organizational Culture (Part VI): Sociology
• Organizational Culture (Part VII): Science

• Building the Right Thing (Part I): Pretotyping
• Building the Right Thing (Part II): Lean Startup
• Building the Right Thing (Part III): Customers

• On Interviewing and Interview Questions
• On Finding, Hiring, Inspiring and Keeping

Quality References

• Quality, Developers and Testers: Organisational Issues
• Re: Strategies for maintenance of horrible code? (Legacy Code References)
• Re: eval to replace die? (Exceptions and Error Handling References)

• Effective Automated Testing (Testing References)
• Perl CPAN test metadata
• Re: Winning people over to better development practises (TDD)
• PM discussion of Dependency Injection in Perl and C++
• What is the best way to add tests to existing code?
• Organising Large Test Suites
• Testing failures: How to override print to make it fail?
• Quality, Developers and Testers: Organisational Issues
• Re: How can I use Perl knowledge in my Software Testing career
• Re: Philosophical question about testing
• Re: Test Case Generator
• why Test::More? (see especially response from Your Mother)
• A brief question about testing/best practices
• Re^3: How to test for empty hash?

• Formal verification
• Capability Maturity Model

• What goes in a test suite? by Marza (2002)
• Perl Testing and Quality Assurance by anonymonk (2003) - see response by adrianh
• On Quality by Tanktalus (2005)
• Strategies for maintenance of horrible code? by converter (2006)
• What is quality? by jimt (2006)
• A Guide to Hiring Programmers - The High Cost of Low Quality by clinton (2006)
• Improving the quality of my modules by SBECK (2015)
• Re: Choosing the right module (Judging the Quality of a CPAN module) by me (2022)

Extra References

• Beyond Agile: Subsidiarity as a Team and Software Design Principle by einhverfr (2015) - SunnyD thought it was an extra episode from me :)
• [OT] Reflecting on SQL. Meditating on Perl. Do languages meet requirements of Agile? by betmatt (2020: do Perl and SQL support agile programming?)

• Swallowing an elephant in 10 easy steps by ELISHEVA (2009)
• Interview method feedback? by DetachedDutyScout (2015)
• (OT) Employee Retention - Why do you stay, why do you go? by tachyon (2003)

• Do you prefer to work remotely? by pollsters (2022)

• Re: About 'Show me your Code' by Your Mother (2010)
• Re: Perlmonks SmartPhone App (pretotyping) by me (2011)

• OpEd: Programming is not Team Sports by SunnyD (2012)

• Perl Certification by cosmicperl (2008)
• On the scaleability of Perl Development Practices by jdrago_999 (2008)
• An interesting rebuttal of "agile" by anonymonk (2008)

See Also

• Re: I need perl coding standards (Coding Standards References)

Updated: using this node for "Process References" nowadays.

[Anonymous Monk]

Peopleware is one of my must-reads, and it flags many warning signs. It has interesting opinions about open plan offices, having too many things to do, and it's amazing how little seems to have changed for the better in the past couple of decades.