• Today was a good day - paper review

  • 3.2: Factors that impact workdays
    • Vast research body available.
    • human aspects are left out generally - liike job satisfaction (which is general fulfilment - influenced by good and bad workdays)
    • affective states impact the assessment of a good and bad workday
      • Positive affective state => Positive effect on problem solving skills and productivity
    • Previous work -> +ve emotion = good workday. Hope is a mediator. Positive emotions at work increase openness to new experiences, dedication, work engagement.

    • Sheldon et al have further shown that on good days, students feel they have higher levels of autonomy and competence which reulsts in better outcomes.

      • What does "students" mean in this case?
    • Others found that variety of tasks and nonrepetitive tasks are good for developer morale.

  • 4. Study design

    • Microsoft (30K devs across >12 dev centers with their own processes)
    • 4.1
      • Data saturation point (diminishing returns) (7 interviews but conducted 10 anyways)
      • Sorted the activities using card sorting approach
    • 4.2
      • 4 sections in survey:
        • Demographics (position, team, experience)
        • Activities (??), allowed to add more
        • If previous work is a typical workday or not
        • asked more questions.
      • Minimize fatigue of survey by giving a smaller questionnaire

      • Devs selected with replacement

        > Did they check for congruence?  
        

        • Only 6.6% responded twice.
    • 4.3 Validity of self-reported data.
      • Time use data canbe achieved through various ways but the authors chose self-reports because they scale better, have a holistic approach (than automated tracking), and show perceptions of the devs actually.
      • Self-reporting is influenced easily so it was run with 10 people before.
      • asked about the previous day because it's more fresh than a general case.

  • 5. Conceptual Frameworks

    • Answers RQ1
      • What factors influence good and typical developer workdays and how do they interrelate?
    • 5.1 Good workdays
      • "Would you consider yesterday a good day? Why or why not?
      • 5.1.1 Data Analysis
        • ...
        • Binary rating of either good or not good by applying various methods.
      • 5.1.2 Conceptual Framework
        • 11 Factors identified - value creation, efficient use of time, and sentiment
        • Initially thought that quality is important factor, since some respondents described good workdays as days they improved the quality of the software or did not break something.
        • Good workday
          • Value creation 68%
          • Efficient use of time 54%
          • Perception 9%
    • 5.2 Developers' Typical Workdays
      • "Was Yesterday typical?"
      • If "No" answered, then asked more question
      • Applied the same coding strategy from before.
      • 5.2.2 Conceptual Framework
        • Thought that a key component is whether the dev has control over the factor - but turns out it is the contrast between expectation and reality.
        • 7 high level factorrs
          • When the work was not dev-related, devs rated the day as atypical. They think these days are slower.
            • On-call phase is atypical
          • Type of workday - when allocated for coding, bug-fixing, etc then they do not pursue activities perceived as distracting.
          • External - meetings (no control over these) cause atypical day, lack of knowledge, fixing stuff,
          • Location - Non office work (WFH gives agency)
          • Main work tasks - Unplanned tasks
          • Personal - health related only
    • 5.3 Interrelationship between good and typical days
      • In our analysis of related work, we found an interconnection between job satisfaction, goodness, routine, typicality and
        productivity.
      • Agency is very important - meetings disrupt agency

  • 6. Quantitative analysis

    • Use of same binary rating system

    • 6.1 Correlation between Typical and Good workdays

      • This means that although typical and atypical workdays are both more likely
        to be considered good than bad, the percentage of typical
        workdays that were considered good (62.9%, good typical
        days over all typical days) is higher than the percentage
        of atypical workdays that were considered good (56.7%,
        good atypical days over all atypical days) to a statistically
        significant degree.
    • 6.2 Time spent on activities at work
      • ^^Authors bash old research here^^
      • Time spent is > 8 hours
      • Devs are working overtime - this is seen previously in German and Finnish workers who had autonomy over their working time.
      • activities are grouped into "Dev heavy" and "collab heavy" and "other"
      • Most time is spent on dev-heavy things, then collaborating.
      • Both, on good and typical workdays, developers spend considerably more time with development related activities.
      • And on good workdays, they spend about half an hour less in collaborative activities, than on bad workdays.
    • 6.3 Workday Types
      • Separate workdays into different types - coding, bugfix, collaboration, meeting, various
      • devs like working alone and become happy when they're writing code.
      • dev-heavy workdays are considered more typical than other days.
    • 6.4 Collaboration
      • ^^Authors bash old research here^^
      • Old research shows interruptions as one of the biggest impediments to productive work.
      • 15 mins resume period, 4 interruptions (1 hour wasted)
      • Meetings are inefficient but useful
      • about 2 impromptu meetings, rarely unplanned meetings - unplanned meetings - longer on bad workdays
      • 20% in and preparing for meetings in a total workday.

  • 7. Making good days typical

    • 7.1 Optimizing dev workdays

      • Generally, it is advisable to minimize administrative tasks and infrastructure issues, and reduce
        interruptions and meetings.

        > However, they cannot work for long on meetings either way?  
        

      • Uninterrupted work might be easier to achieve in smaller offices shared with only a few colleagues rather than the currently omnipresent open-plan offices.

      • Collaboration is helped by open-plan offices.

        > Major point here.  
        

      • WFH helps in less context-switching and interruptions
      • seniority means more atypical days
    • 7.2. Agency: Manage competition over attention and time
      • Tradeoff
      • veto power, free will to change their work schedule.
      • During non-dev work, meetings are perceived as productive and not the same during other times.
      • Seniors value collaboration more than juniors do.
    • 7.3 Evaluation of contributions at work
      • Devs who reflect about this value coding over collaboration.
      • Good output = good volume of work produced, not collaboration.
      • Teams are considering other factors during performance reviews.
      • Learning something new is rarely considered as a successful day?!

  • 8. Threats to validity

    • 8.1 External validity
      • Single organization!
        • However, acquired, diversity, regions, culture are varied.
    • Construct validity
      • ...
    • Internal validity
      • Anonymous - so the data might be corrupt between days when the devs were not the same!
      • Wellbeing could've affected survey answers.
      • Stereotype threat - ?