pith. sign in

arxiv: 1907.05931 · v1 · pith:V6EAFOFUnew · submitted 2019-07-12 · 💻 cs.SE · cs.HC

An Exploratory Study of Live-Streamed Programming

Abdulaziz Alaboudi , Thomas D. LaToza This is my paper

Pith reviewed 2026-05-24 22:07 UTC · model grok-4.3

classification 💻 cs.SE cs.HC
keywords live-streamed programmingpair programmingdeveloper collaborationknowledge sharingstreamer motivationstool limitationsonline identity
0
0 comments X

The pith

Live-streamed programming shares some pair-programming benefits but features a distinct public streamer-watcher relationship with unique motivations and challenges.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper investigates live-streamed programming in which developers broadcast their open-source work and interact with watchers via chat. Analysis of video sessions and streamer surveys shows this practice mirrors certain pair-programming traits yet operates through a one-to-many public dynamic rather than a close pair. Streamers pursue knowledge sharing, social connection, and online identity building, while contending with tool shortcomings and the need to sustain watcher interest. These observations point toward ways to improve support for this collaborative coding approach.

Core claim

Live-streamed programming shares some of the characteristics and benefits of pair programming, but differs in the nature of the relationship between the streamer and watchers. Streamers are motivated by knowledge sharing, socializing, and building an online identity, but face challenges with tool limitations and maintaining engagement with watchers.

What carries the argument

Exploratory analysis of 20 hours of live-streamed programming videos and surveys of 7 streamers that compares the practice to pair programming while cataloging motivations and challenges.

If this is right

  • Live-streamed programming can function as a public form of knowledge sharing for open-source projects.
  • Existing streaming platforms impose tool limitations that reduce effectiveness.
  • Design recommendations for new tools can address watcher engagement and interaction needs.
  • Streamers gain opportunities to build online identities through their development sessions.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The public format might encourage higher code quality through visible accountability.
  • Educational use could arise if watchers treat sessions as live tutorials.
  • Integration with code repositories might allow direct contributions from watchers during streams.

Load-bearing premise

The 20 hours of analyzed videos and the responses from 7 surveyed streamers provide a sufficient and unbiased basis for identifying general characteristics, motivations, and challenges of live-streamed programming.

What would settle it

A follow-up study that examines a much larger set of streams or surveys many more streamers and finds no meaningful similarity to pair programming or entirely different primary motivations would undermine the reported patterns.

Figures

Figures reproduced from arXiv: 1907.05931 by Abdulaziz Alaboudi, Thomas D. LaToza.

Figure 1
Figure 1. Figure 1: In live-streamed programming, a developer working on a programming activity shares a live video of their work with other developers, who may interact through chat to ask questions, suggest alternatives, and help find defects. Abstract—In live-streamed programming, developers broad￾cast their development work on open source projects using streaming media such as YouTube or Twitch. Sessions are first announc… view at source ↗
Figure 2
Figure 2. Figure 2: A streamer (D7) thanked a watcher for finding a defect. reporting three defects and helping debug another four. D1 stated during session 2 that he would not have discovered a defect a watcher reported, as it was related to an edge case that he was not aware of: “Thank you! I would not have thought about the accented character”. Another streamer (D5) tested multiple incorrect hypotheses about the cause of a… view at source ↗
Figure 3
Figure 3. Figure 3: Excerpts from session 3 which offer examples of the interactions between the streamer (left) and watchers (right). These excerpts illustrate knowledge sharing between the streamer and the watchers, watchers helping in debugging, and watchers joining and leaving throughout the session. driver between them. We did not observe any instances of a streamer and watchers rotating their roles. C. What motivates de… view at source ↗
Figure 4
Figure 4. Figure 4: A tool mockup illustrating our design recommendations to the session or answers to key questions posed in the chat. Besides video segment linking, watchers who have questions about the codebase should have the ability to link their questions with a code location, helping offer both the streamer and other watchers more context. D. Tool Workflow To illustrate how our design recommendations might be embodied … view at source ↗
read the original abstract

In live-streamed programming, developers broadcast their development work on open source projects using streaming media such as YouTube or Twitch. Sessions are first announced by a developer acting as the streamer, inviting other developers to join and interact as watchers using chat. To better understand the characteristics, motivations, and challenges in live-streamed programming, we analyzed 20 hours of live-streamed programming videos and surveyed 7 streamers about their experiences. The results reveal that live-streamed programming shares some of the characteristics and benefits of pair programming, but differs in the nature of the relationship between the streamer and watchers. We also found that streamers are motivated by knowledge sharing, socializing, and building an online identity, but face challenges with tool limitations and maintaining engagement with watchers. We discuss the implications of these findings, identify limitations with current tools, and propose design recommendations for new forms of tools to better supporting live-streamed programming.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The paper reports an exploratory qualitative study of live-streamed programming on platforms such as Twitch and YouTube. It analyzes 20 hours of video sessions plus survey responses from 7 streamers to characterize the practice, compare it to pair programming, identify streamer motivations (knowledge sharing, socializing, identity building), and document challenges (tool limitations, maintaining watcher engagement). The central claims are descriptive and rest on thematic extraction from this dataset.

Significance. If the reported themes prove robust, the work supplies an early empirical baseline for an emerging form of open-source collaboration and could usefully inform requirements for streaming-aware development tools.

major comments (2)
  1. [Methods] Methods (or equivalent section describing data collection and analysis): the study draws conclusions about general motivations and challenges from only 7 survey respondents and 20 hours of video, yet provides no sampling frame, response rate, selection criteria for the video corpus, saturation assessment, or details of the qualitative coding procedure (e.g., codebook development, inter-rater reliability). These omissions make the load-bearing claims about prevalence of themes difficult to evaluate.
  2. [Results] Results/Discussion: the assertion that streamers are motivated by knowledge sharing, socializing, and identity building (and face the listed challenges) is presented as a finding of the study, but the small self-selected sample of public streamers who opted into research introduces plausible selection bias; no evidence or triangulation is offered to show that the themes generalize beyond this subset.
minor comments (1)
  1. [Abstract] The abstract states the sample sizes but the main text should explicitly report how many distinct streamers and sessions were observed in the 20 hours.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback on our exploratory study. We address each major comment below and will make revisions to improve methodological transparency and to better frame the scope of the findings.

read point-by-point responses

  1. Referee: [Methods] Methods (or equivalent section describing data collection and analysis): the study draws conclusions about general motivations and challenges from only 7 survey respondents and 20 hours of video, yet provides no sampling frame, response rate, selection criteria for the video corpus, saturation assessment, or details of the qualitative coding procedure (e.g., codebook development, inter-rater reliability). These omissions make the load-bearing claims about prevalence of themes difficult to evaluate.

    Authors: We agree that more detail on data collection and analysis is needed. The study used convenience sampling of publicly announced streams on Twitch and YouTube involving open-source programming; we will add explicit selection criteria for the 20-hour video corpus, describe survey recruitment (via Twitter, Discord, and streaming communities), and expand the analysis description to cover the inductive thematic process (codes developed iteratively by the first author with team review). No formal saturation assessment or inter-rater reliability statistic was performed, as is typical for small-scale exploratory work with a single primary coder. We will revise the Methods section accordingly (revision_made = yes). revision: yes

  2. Referee: [Results] Results/Discussion: the assertion that streamers are motivated by knowledge sharing, socializing, and identity building (and face the listed challenges) is presented as a finding of the study, but the small self-selected sample of public streamers who opted into research introduces plausible selection bias; no evidence or triangulation is offered to show that the themes generalize beyond this subset.

    Authors: We accept that the self-selected survey respondents introduce selection bias and that the themes cannot be claimed to generalize. The study is exploratory and descriptive; the 20 hours of video analysis from additional streamers offers limited triangulation. We will revise the Results/Discussion to explicitly state the exploratory scope, add a limitations paragraph addressing sample characteristics and non-generalizability, and remove any phrasing that could imply prevalence beyond the observed data (revision_made = yes). revision: yes

Circularity Check

0 steps flagged

No circularity: purely descriptive empirical study

full rationale

The paper is an exploratory qualitative study that analyzes 20 hours of video and surveys 7 streamers to identify characteristics, motivations, and challenges. It contains no equations, fitted parameters, predictions, derivations, or mathematical claims. All findings are presented as direct observations from the collected data without any reduction to prior inputs or self-citations that bear the central load. This matches the default expectation of no circularity for non-derivational empirical work.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

Central claims rest on the representativeness of a small convenience sample of videos and streamers plus the validity of qualitative coding; no free parameters or invented entities appear.

axioms (1)
  • domain assumption The selected 20 hours of videos and 7 streamers are representative of live-streamed programming practices overall.
    Generalization from this sample to broader characteristics and motivations depends on this premise.

pith-pipeline@v0.9.0 · 5683 in / 1271 out tokens · 55210 ms · 2026-05-24T22:07:37.681113+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

47 extracted references · 47 canonical work pages

  1. [1]

    How open source soft- ware works:“free

    K. R. Lakhani and E. V on Hippel, “How open source soft- ware works:“free” user-to-user assistance,” in Produktentwicklung mit virtuellen Communities. Springer, 2004, pp. 303–339

    work page 2004

  2. [2]

    Design lessons from the fastest q&a site in the west,

    L. Mamykina, B. Manoim, M. Mittal, G. Hripcsak, and B. Hartmann, “Design lessons from the fastest q&a site in the west,” in Conference on Human Factors in Computing Systems , 2011, pp. 2857–2866

    work page 2011

  3. [3]

    Software engineering at the speed of light: how developers stay current using twitter,

    L. Singer, F. Figueira Filho, and M.-A. Storey, “Software engineering at the speed of light: how developers stay current using twitter,” in International Conference on Software Engineering , 2014, pp. 211–221

    work page 2014

  4. [4]

    Social coding in github: Transparency and collaboration in an open software repository,

    L. Dabbish, C. Stuart, J. Tsay, and J. Herbsleb, “Social coding in github: Transparency and collaboration in an open software repository,” in Conference on Computer Supported Cooperative Work , 2012, pp. 1277–1286

    work page 2012

  5. [5]

    Stackoverflow and github: Associations between software development and crowdsourced knowl- edge,

    B. Vasilescu, V . Filkov, and A. Serebrenik, “Stackoverflow and github: Associations between software development and crowdsourced knowl- edge,” in International Conference on Social Computing, 2013, pp. 188– 195

    work page 2013

  6. [6]

    Building reputation in stackoverflow: An empirical investiga- tion,

    A. Bosu, C. S. Corley, D. Heaton, D. Chatterji, J. C. Carver, and N. A. Kraft, “Building reputation in stackoverflow: An empirical investiga- tion,” in International Conference on Mining Software Repositories , 2013, pp. 89–92

    work page 2013

  7. [7]

    Let’s talk about it: Evaluating contributions through discussion in github,

    J. Tsay, L. Dabbish, and J. Herbsleb, “Let’s talk about it: Evaluating contributions through discussion in github,” in International Symposium on Foundations of Software Engineering , 2014, pp. 144–154

    work page 2014

  8. [8]

    Code reviewing in the trenches: Challenges and best practices,

    L. MacLeod, M. Greiler, M. Storey, C. Bird, and J. Czerwonka, “Code reviewing in the trenches: Challenges and best practices,” IEEE Software, vol. 35, pp. 34–42, jul 2018

    work page 2018

  9. [9]

    Thousands of people are watching this guy code a search engine,

    J. Koebler, “Thousands of people are watching this guy code a search engine,” 2015, accessed: 2019-01-16. [Online]. Available: https://motherboard.vice.com/en_us/article/pgax4n/ thousands-of-people-are-watching-this-guy-code-a-search-engine

    work page 2015

  10. [10]

    Live programming on twitch is growing fast,

    C. Bernasconi, “Live programming on twitch is growing fast,” 2019, ac- cessed: 2019-06-25. [Online]. Available: https://www.claudiobernasconi. ch/2019/05/29/live-programming-on-twitch-is-growing-fast/

    work page 2019

  11. [11]

    Lessons from my first year of live coding on twitch,

    S. Hinton, “Lessons from my first year of live coding on twitch,” 2017, accessed: 2019- 01-16. [Online]. Available: https://medium.freecodecamp.org/ lessons-from-my-first-year-of-live-coding-on-twitch-41a32e2f41c1

    work page 2017

  12. [12]

    Rethinking databases and noria with jon gjengset,

    A. G. Bell, “Rethinking databases and noria with jon gjengset,” 2019, accessed: 2019-06-25. [Online]. Available: https://corecursive. com/030-rethinking-databases-with-jon-gjengset/

    work page 2019

  13. [13]

    Live coding open source on twitch,

    S. H. Adam Stacoviak, Jerod Santo, “Live coding open source on twitch,” 2018, accessed: 2019-06-25. [Online]. Available: https: //changelog.com/podcast/288

    work page 2018

  14. [14]

    Social media for software engineering,

    A. Begel, R. DeLine, and T. Zimmermann, “Social media for software engineering,” in Workshop on Future of software engineering research , 2010, pp. 33–38

    work page 2010

  15. [15]

    Survey: Open source programs are a best practice among large companies,

    L. Hecht and L. Clark, “Survey: Open source programs are a best practice among large companies,” 2018, accessed: 2019-03-02. [Online]. Available: https://thenewstack.io/ survey-open-source-programs-are-a-best-practice-among-large-companies/

    work page 2018

  16. [16]

    Who really contributes to open source,

    M. Asay, “Who really contributes to open source,” 2018, accessed: 2019-03-02. [Online]. Available: https://www.infoworld.com/article/ 3253948/who-really-contributes-to-open-source.html

    work page 2018

  17. [17]

    Code, camera, action: how software developers document and share program knowledge using youtube,

    L. MacLeod, M.-A. Storey, and A. Bergen, “Code, camera, action: how software developers document and share program knowledge using youtube,” in International Conference on Program Comprehension , 2015, pp. 104–114

    work page 2015

  18. [18]

    Williams and R

    L. Williams and R. Kessler, Pair programming illuminated. Addison- Wesley Longman Publishing Co., Inc., 2002

    work page 2002

  19. [19]

    A multiple case study on the impact of pair programming on product quality,

    H. Hulkko and P. Abrahamsson, “A multiple case study on the impact of pair programming on product quality,” in International Conference on Software Engineering , May 2005, pp. 495–504

    work page 2005

  20. [20]

    The effects of pair-programming on performance in an introductory programming course,

    C. McDowell, L. Werner, H. Bullock, and J. Fernald, “The effects of pair-programming on performance in an introductory programming course,” in Technical Symposium on Computer Science Education, 2002, pp. 38–42

    work page 2002

  21. [21]

    Improving the cs1 experience with pair pro- gramming,

    N. Nagappan, L. Williams, L. Williams, M. Ferzli, E. Wiebe, K. Yang, C. Miller, and S. Balik, “Improving the cs1 experience with pair pro- gramming,” in Technical Symposium on Computer Science Education , 2003, pp. 359–362

    work page 2003

  22. [22]

    Strength- ening the case for pair programming,

    W. Cunningham, L. Williams, R. R. Kessler, and R. Jeffries, “Strength- ening the case for pair programming,” IEEE Software, vol. 17, pp. 19–25, 07 2000

    work page 2000

  23. [23]

    The costs and benefits of pair program- ming,

    A. Cockburn and L. Williams, “The costs and benefits of pair program- ming,” in EXtreme Programming and Flexible Processes in Software Engineering. Addison-Wesley, 2000, pp. 223–247

    work page 2000

  24. [24]

    Dalton, Mob Programming

    J. Dalton, Mob Programming. Apress, 2019

    work page 2019

  25. [25]

    Mob programming: A whole team ap- proach,

    W. Zuill and K. Meadows, “Mob programming: A whole team ap- proach,” in Agile 2014 Conference, Orlando, Florida , 2016

    work page 2014

  26. [26]

    Exploring the efficacy of distributed pair programming,

    P. Baheti, E. Gehringer, and D. Stotts, “Exploring the efficacy of distributed pair programming,” in Conference on Extreme Programming and Agile Methods , 2002, pp. 208–220

    work page 2002

  27. [27]

    Globally distributed software development and pair pro- gramming,

    N. V . Flor, “Globally distributed software development and pair pro- gramming,” Commun. ACM, vol. 49, pp. 57–58, Oct. 2006

    work page 2006

  28. [28]

    How distribution affects the success of pair programming

    G. Canfora, A. Cimitile, G. Di Lucca, and C. A. Visaggio, “How distribution affects the success of pair programming.” International Journal of Software Engineering and Knowledge Engineering , vol. 16, pp. 293–313, 04 2006

    work page 2006

  29. [29]

    Distributed pair pro- gramming: A systematic literature review,

    B. J. da Silva Estácio and R. Prikladnicki, “Distributed pair pro- gramming: A systematic literature review,” Information and Software Technology, vol. 63, pp. 1–10, 2015

    work page 2015

  30. [30]

    Saros: An eclipse plug-in for distributed party programming,

    S. Salinger, C. Oezbek, K. Beecher, and J. Schenk, “Saros: An eclipse plug-in for distributed party programming,” in Workshop on Cooperative and Human Aspects of Software Engineering , 2010, pp. 48–55

    work page 2010

  31. [31]

    Exploring the effects of collaboration scripts embedded in a distributed pair program- ming system,

    D. Tsompanoudi, M. Satratzemi, and S. Xinogalos, “Exploring the effects of collaboration scripts embedded in a distributed pair program- ming system,” in conference on Innovation and technology in computer science education, 2013, pp. 225–230

    work page 2013

  32. [32]

    Collaboration and learning through live coding (Dagstuhl Seminar 13382),

    A. Blackwell, A. McLean, J. Noble, and J. Rohrhuber, “Collaboration and learning through live coding (Dagstuhl Seminar 13382),” Dagstuhl Reports, vol. 3, pp. 130–168, 2014

    work page 2014

  33. [33]

    Live coding practice,

    C. Nilson, “Live coding practice,” in Conference on New interfaces for musical expression, 2007, pp. 112–117

    work page 2007

  34. [34]

    Live coding in laptop performance,

    N. Collins, A. McLean, J. Rohrhuber, and A. Ward, “Live coding in laptop performance,” Organised sound, pp. 321–330, 2003

    work page 2003

  35. [35]

    Algorithms as scores: Coding live music,

    T. Magnusson, “Algorithms as scores: Coding live music,” Leonardo Music Journal, pp. 19–23, 2011

    work page 2011

  36. [36]

    What can computer science learn from a fine arts approach to teaching?

    L. J. Barker, K. Garvin-Doxas, and E. Roberts, “What can computer science learn from a fine arts approach to teaching?” in Technical Symposium on Computer Science Education , 2005, pp. 421–425

    work page 2005

  37. [37]

    Improv: Teaching programming at scale via live coding,

    C. Chen and P. J. Guo, “Improv: Teaching programming at scale via live coding,” in Conference on Learning at Scale , 2019

    work page 2019

  38. [38]

    Programming as a performance: Live-streaming and its implications for computer science education,

    L. Haaranen, “Programming as a performance: Live-streaming and its implications for computer science education,” in Conference on Innovation and Technology in Computer Science Education , 2017, pp. 353–358

    work page 2017

  39. [39]

    Watch me code: Programming mentorship communities on twitch.tv,

    T. Faas, L. Dombrowski, A. Young, and A. D. Miller, “Watch me code: Programming mentorship communities on twitch.tv,” Human-Computer Interaction, vol. 2, pp. 50:1–50:18, Nov. 2018

    work page 2018

  40. [40]

    Looking for group: Live streaming programming for small audiences,

    T. Faas, L. Dombrowski, E. Brady, and A. Miller, “Looking for group: Live streaming programming for small audiences,” in Information in Contemporary Society, 2019, pp. 117–123

    work page 2019

  41. [41]

    What it feels like to be an open-source maintainer,

    N. Lawson, “What it feels like to be an open-source maintainer,” 2017, accessed: 2019-02-08. [Online]. Available: https://nolanlawson. com/2017/03/05/what-it-feels-like-to-be-an-open-source-maintainer/

    work page 2017

  42. [42]

    How effective develop- ers investigate source code: An exploratory study,

    M. P. Robillard, W. Coelho, and G. C. Murphy, “How effective develop- ers investigate source code: An exploratory study,” IEEE Transactions on Software Engineering. , vol. 30, pp. 889–903, Dec. 2004

    work page 2004

  43. [43]

    Questions about object structure during coding activities,

    M. Abi-Antoun, N. Ammar, and T. LaToza, “Questions about object structure during coding activities,” in Workshop on Cooperative and Human Aspects of Software Engineering , 2010, pp. 64–71

    work page 2010

  44. [44]

    Asking and answering questions during a programming change task,

    J. Sillito, G. C. Murphy, and K. De V older, “Asking and answering questions during a programming change task,” IEEE Transactions on Software Engineering., vol. 34, pp. 434–451, Jul. 2008

    work page 2008

  45. [45]

    Searching and skimming: An ex- ploratory study,

    J. Starke, C. Luce, and J. Sillito, “Searching and skimming: An ex- ploratory study,” in International Conference on Software Maintenance , 2009, pp. 157–166

    work page 2009

  46. [46]

    Introducing visual studio live share,

    A. Silver, “Introducing visual studio live share,” 2017, accessed: 2019-06-25. [Online]. Available: https://code.visualstudio.com/blogs/ 2017/11/15/live-share

    work page 2017

  47. [47]

    Creating guided code explanations with chat.codes,

    S. Oney, C. Brooks, and P. Resnick, “Creating guided code explanations with chat.codes,” Human-Computer Interaction. , vol. 2, pp. 131:1– 131:20, Nov. 2018

    work page 2018