7 ms·

Focus and Flow: trade-offs in programmer productivity (2021)

78 points by danboarder 3y ago

wscourge 3y ago
TLDR: remove distractions & use pomodoro.
cracrecry 3y ago
I do not recommend doing pair programming as a way to handle long periods of isolated work. If you can not work alone without supervision you have to deal with those psychological issues first or just change your job. Your boss is not going to pay two salaries for doing the work of one. If you do pair programming, it will be because you can be more productive that way that working alone, and that is not the case most of the time (although most people want to believe that). As entrepreneur and engineer and programmer for a long time when I hear "pair programming", a big light bulb appears in my head screaming and blinking SCAM!. It can be done sometimes with specific people at specific times for specific reasons but I do not believe that it works for most people.
- deleted 3y ago
  [deleted]
- tarcon 3y ago
  There are more reasons to do pair programming: It also transfers knowledge of all kind (domain, tools, techniques), saves the time for code review, strengthens relationships and improves team culture
  - apwell23 3y ago
    100%. It lowers support load, increases bus factor , improves sense of collective ownership, makes you humble. Unfortunately a whole lot of people are totally against that idea so i make do with chatgpt/copilot as my pair programmer these days.
- rileymat2 3y ago
  It has always been strange to me that for an industry that claims to be engineering and data focused stops when it comes to our own processes. One Lazy google search searching for a paper, and not a blog: https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.... In 1999, a controlled experiment run by the second author at the University of Utah investigated the economics of pair programming. Advanced undergraduates in a Software Engineering course participated in the experiment. One third of the class coded class projects as they had for years – by themselves. The rest of the class completed their projects with a collaborative partner. The results of how much time the students spent on the assignments are shown below in Figure 1. After the initial adjustment period in the first program (the “jelling” assignment), together the pairs only spent about 15% more time on the program than the individuals [4]. Development costs certainly do not double with pair programming! Significantly, the resulting code has about 15% fewer defects [4]. (These results are statistically significant.) Figure 2 shows the postdevelopment test cases the students passed for each program – essentially the percentage of the instructor’s test cases passed. The initial 15% increase in code development expense is recovered in the reduction in defects, as the following example illustrates... So the from this paper is the initial work is more costly, anyone that tells you it is not is probably wrong, but not double. But they are producing different work at a different quality level, at a different speed. Sure there could be problems with the methodology, it might apply to students and not professionals (a classic psyche 101 bias). But it is something, certainly not a scam.
  - kosolam 3y ago
    Students can’t be compared to industry workers. In my 20+ years of professional career in a multitude of companies of various sizes and domains, I have never seen pair programming implemented as a regular working method. Nothing that even gets close to this.
    - rileymat2 3y ago
      I agree, students and industry workers are not directly comparable. But one of the issues that I would wager is somewhat comparable is the human factors which, in the study above showed large inefficiencies in the first assignments before the "jelling" of the pair. This makes most one shot studies problematic, it also makes starting to pair problematic if you are experimenting. I have never worked in a full time pairing place, it was experimental, here there, sometimes. But the initial inefficiencies rung true to me, along with this jelling. But, I have visited a place that did implement full time all the time pairing. (https://menloinnovations.com/our-way/our-process https://menloinnovations.com/our-way/our-process) With all the money spent on software development, I am a bit surprised there are not numerous double blind experiments and studies where two different consultancies are assigned the exact same very complex project with staffed professionals using different processes. It would be extremely costly, but could pay the industry back many-fold.
- ZephyrBlu 3y ago
  Personal productivity is second to team productivity. Pair programming facilitates discussion, context sharing and alignment. The biggest problems are almost always misalignment and lack of context/shared understanding, not productivity of individual team members.
- hmeh 3y ago
  Pair programming is, first and foremost, a technique for implementing continuous review. The old adage: If code reviews are good, do them constantly and continuously. We pair/mob when appropriate, and we don't do pull requests. If you pair AND do pull requests, it may be worth examining that. The secondary order effects cannot be ignored either. On our team, pairing is used to: - Coach more junior developers into being more proficient at their work - Share knowledge so that norms, standards, and other knowledge can propagate through the team in a more natural (and effective) way than documentation - Share techniques at the more tactical level - Further explore the solution space and do better planning and execution (go slow to go fast) And others.
  - ParetoOptimal 3y ago
    The biggest downside to pair programming is that unless you are a strong communicator and feel like investing the energy, great ideas get averaged down to well.. Average. It doesn't have to be the case, but because of averages it typically is.
    - hmeh 3y ago
      If I understand what you are saying correctly, you are saying that if two people are pairing and the one with the better idea does not successfully communicate their idea, either from lack of trying or lack of effectiveness, then the person with the lesser idea might "win" and that is what would be implemented? If so, I would say that the appropriate response to that is to, as a team, work to improve communication and collaboration consistently -- every day, in every work item. Leadership should reinforce the import, exemplify it, and observe and coach. In general, what it sounds like you are saying is that people who are bad at things do things poorly. Yes, that's true, but that's why we have all the tools we have available to us to help them do things better. We don't have to like in squalor, we can choose to help each other rise above it.
- sbellware 3y ago
  As an entrepreneur and engineer and programmer having spent 30 years in software without washing out and still accelerating, I'm shocked every time I encounter the well-conditioned presumption that work cells in knowledge work should be decomposed to the single point of absolute irreducibility, which is inevitably the 1-person/1-work-item presumption. It implies the assertion that parallelization _should_ be maximized to the ultimate, which implies that the nature of the work is largely just implementation details and typing out code on a keyboard. But that's not where delays and inefficiencies are in software. And decomposing work cells to the point of total parallelization only exacerbates the factors that do indeed worsen the delays and inefficiencies. Software development has been so underperforming for so long that we presume that the natural, unavoidable state of software development is what the average team experiences today. That's only true of average teams with average productivity and average per-person yield. It's true in the middle of the productivity/performance bell curve, but not to the right of it. The 1-person/1-work-item division of labor sub-optimizes the momentum transfer that high-performance teams harness to get the high-performance results that they're after. Doing so is predicated on a number of factors, but principally it requires a vigorous attention to structural design fundamentals, rigorous norms, the ease of provability of changes and additions made to the design and implementation, and a solid grasp of organizational mechanics and process mechanics with a fluency in the effects of batching and queueing in systems-of-work in knowledge work and product development. In my work, and in the work in our organization, the 1-person/1-work-item system is the exception and collective work is the norm. That's because of breakthrough levels of productivity that can be unlocked at the upper echelons of quality. In fact, at that level, the terms "productivity" and "quality" don't have any meaningful difference. In the middle of the software development curve, there is already such middling productivity/quality that any particular strategy is unlikely to have much observable effect at all on outcomes. It's not until quality is increased to a point well over the present average that the effects of the numerous individual virtuous systems amplifying each other in the overall production system that the sub-optimization of the 1-person/1-work-item division of labor is obvious. At that level, management of software development operates like an accounting system that only records gains and disregards losses from the final bottom line. Every iota of spent effort is counted as a gain without regard for whether the result of the work creates loss-free assets or not. The field of software development has largely lost track of structural design fundamentals, both in the software itself and the design of the processes and procedures wherein the software is built. The vast majority of software developers operating today don't know what a mistake is in software development. They don't even recognize the design mistakes inherent in the tools they choose, and they tend to live in software ghettos where productivity poverty is the norm. They've got good slum survival street smarts, but have never been outside of the slum, so they couldn't orient themselves toward a healthier approach and healthier work life if they wanted to. They don't recognize the mistakes that are painfully obvious when seen through the lens of design fundamentals, so they don't know what to avoid. Software developers at large don't know where the "true north" heading is. To me, it's this current state of ghettoized software development that's the scam. It's the productivity balance sheet that fails to recognize losses and setbacks and that books "technical debt" as an asset that is the real scam in software work and software work management. But again, the vast majority of software workers and managers have never known any better. So, yeah... putting advanced, interconnected systems of work in the hands of teams that labor under the conditions that can't benefit of those systems of work is obviously ill-advised. But that doesn't mean that those teams can't induce productivity breakthroughs and realizations by practicing the techniques, even if in an uncoordinated and indefinite way. Though it will look like inefficiency to a manager who also has never had the opportunity to work outside the limits of software poverty. For a team to be able to go beyond single-person work cell division of labor and parallelization, it'd have an enormous amount of historically-cumulative deficits to overcome. And a team that's operating like this is operating with such relatively-low throughput that they're likely already to behind on their deliverables even before they get started on work that it would be impractical to suggest taking a more deliberate approach. In short, this kind of team is always operating under what are effectively emergency measures. That team's principal management system is Crisis Management. And when every work item is managed as a matter of crisis management, there's no point in hoping for much more than mere survival and coping mechanisms. I wouldn't say that it's necessarily a "scam" to fail to manage the endless emergencies and crisis intentionally, but it should raise some eyebrows for a team to be so far behind the eight ball to be experimenting with systems of work that aren't supported by the counter-balancing systems of work that interact to create emergent productivity. But then again, if they don't start some time, they'll never really get ahead of the software poverty line. The real scam in software development is "technical debt". The normalized predatory lending and borrowing that the term "technical debt" is a proxy for is the real racket in software development. Being a "post technical debt" team is something that few developers who started their careers since the term was coined can even imagine. It's like a mythical Lost City of Atlantis to developers who've never known any difference. The technical debt that keeps software works and software workers in technical poverty is the issue that should be hauled out into the cold light of day and exercised like a malevolent demon. But that can't happen until software developers, designers, managers, and operators invest the time to come to an understanding of what structural design decisions makes software work harder and increases the level of poverty that developers live in, and keeps increasing it until the developers themselves are utterly desensitized to their own unfortunate circumstances. But if they can make it out of the slum, getting past the grasping at 1-person/1-work-item management is part of it. That person will inevitably realize that it's an entirely arbitrary structure born out of the desperation of a project that embraced its own decline in the very first moments of its life. It's a work system that is an effect of the same conditions that make software work harder to do than necessary. At that point, every developer and every manager will have an intimate grasp of the difference between efficiency and productivity, and will know not to forsake long-term productivity for mere short-term efficiencies, and managers will know better than to manage for utilization rather than continuity. But it can't be readily done in a team that's already implemented itself into a technical deficit for not having known what to avoid in the first place. The scam is the low-yield spend of most software efforts. "Cooking the books" is today's software development's stock and trade. In a very real sense, software development is largely operated as negligence at best, and fraud at worst. And a good deal of the negligence is the failing to recognize that the sub-optimizations that we submit ourselves to every day are self-inflicted. The most heartbreaking thing about the whole sordid software affair is that to solutions to the problems have been well-known for decades in industries that have more maturity than software, but software's industrial immaturity is the very thing that keeps it from seeing the need to make a study of industry and production systems. Taylorism is the sickness that doomed so many industries that came before software, and it remains the mindset that continues to suppress software work today. And nothing will change until developers start to really, really make an effort to understand the subtle reasons why things are the way they are, and to start working for a life beyond the self-inflicted poverty of the ghetto and the slum. But generational poverty is a much more pernicious and endemic issue in software work than the appearance of the petty crimes and scams that impoverished people give into just to make their lives a little more survivable.
- Cthulhu_ 3y ago
  Scam? How so? I believe that thinking your solo work is good enough is hubris. I'm not a fan of pair programming either, but I don't trust my own work enough to not have someone else review it first.
zubairq 3y ago
Interesting read about programmer flow!
kosolam 3y ago
I guess different stuff works for different people. The pomodoro thing is inhuman in my opinion, too mechanical and the process itself is distracting the mind from the actual work that it should work on. I found the combination of flow+off keyboard thinking time to be my preferred natural flow of work. Usually I dive in and work in a flow for as long as I can, which usually is around an hour and up to a few hours in some cases. Then I naturally take a break. Then get back again. But in cases when I stop because I need to think rather than think-and-type, the break becomes longer, as necessary.
- halfcat 3y ago
  I use mini-pomodoro to build momentum when I can’t get started. Start with 2-3 minutes “work”, 1 minute break. Keep bumping those up toward 25/5. Usually by the time I’ve done a few rounds, I don’t want a break and I’ve got my momentum, and I ditch the cycles and just work. This works surprisingly well for me even at a micro level, like exercise 10 seconds, break for 5 seconds, repeat. Before I know it I’m just exercising uninterrupted for 20 minutes. I left out one part: clap for yourself The process is more like: * Pick something * Do it * Clap for yourself * Repeat And the key is to make “do it” as small as necessary to keep the cycle going, then expand it once the human reward system takes over.
  - datameta 3y ago
    Absolutely this. When I was building up a soldering habit (have a backlog of analog synth modules to make) I made a point of soldering 1 component. But then by the time the iron heated up, I've decided what goes into the board next, and soldered that one component, I might as well do 5 or 10.
- rynoV 3y ago
  [dead]
ttiurani 3y ago
> By definition, a flow state is non-collaborative; [...] you’re certainly not going to be in that mindset while you’re in a pair programming session. This is not true. Group flow is a well documented phenomenom[0]. While it's easiest to recognize for example in an orchestra, group flow can happen with pair programming as well. [0] https://www.aalto.fi/en/oasis-of-radical-wellbeing/group-flow-what-is-it-and-how-to-achieve-it https://www.aalto.fi/en/oasis-of-radical-wellbeing/group-flo...
- halfcat 3y ago
  I do wonder if group flow and individual flow have more to do with different skill sets, and which path best suits the people you have, as opposed to the idea that group or individual flow is more effective. Like, I like to whiteboard and mock up a problem in Python to wrap my brain around it. My coworker likes to mock things up in Excel. Usually when we work together, I find myself just waiting to get off the call so I can do my own whiteboarding. What makes sense to him in his Excel file doesn’t hit as much for me. Whereas it seems like group flow uses some kind of higher level coordination process, whether it’s whatever orchestra “best practices” have been established over centuries, or people chanting together in temples, or whatever. The question being, while group flow exists, is it simply that it requires people who like engaging in the “group flow activities”? Like we can probably find people who coincidentally like chanting, and those people might make good monks. But will my coworker and I ever work well in a pair programming environment?
  - serialNumber 3y ago
    Excel? How does that work - first time I'm hearing of it being used in that way
    - deleted 3y ago
      [deleted]
- bradknowles 3y ago
  I've played in a large band, with over fifty members. I did that for several years. The thing that kept us together was the conductor, not some sort of "group flow". This is not to say that "group flow" doesn't exist, but I'd want more extraordinary evidence for this claim.
seadan83 3y ago
I think the title suggests larger questions. What is Flow? How many different kinds of flow states are there? To what extent are they equal? I recently listened to "Your Brain: Who's in Control?" [1], a PBS documentary that looked at a musician in an MRI rapping a memorized piece vs an ad-hoc rap. They found the musician's prefrontal cortex was inhibited when doing the ad-hoc exercise. The prefrontal cortex is used as a "filter" center, to predict and evaluate the potential outcome of actions and basically to tell you when something is a bad idea. When developers are in flow, and they are creating brand new code - do their prefrontal cortex'es also become inhibited? Is that the same kind of flow state? I believe there are multiple types of flow state: - gardening/choirs, time drops away and you lose yourself in the trimming, edging and mundane gardening tasks - gaming, when I was younger and after an approx 16 hour binge of Civilization, my mind was still in the game. I was asleep and was still thinking in-game, solving problems, and wondering "where is the end turn button." Being in that level of flow state, the thoughts of 'end turn', 'move unit' - just occurred, my mind's connection to the game through my body was erased, the motor movements to click, hotkeys, all gone from conscious thought and just automatic. - music: Type (A) - playing a well known piece, it just happens. Type (B) Improv, jazz musicians do this all the time for hours on end. - biking/exercise: after a few hours, a sense of time can stop and everything becomes automatic. - driving: actions to signal, brake, accelerate require no thought; your mind says "speed up" and the body's reaction is automatic and requires virtually no thought. The interface between you and the car disappears, you no longer think "press my foot down" - you only think "accelerate" - reading: a best example of this I recall was being younger and reading Lords of the Rings. Hours melted away, I experienced complete immersion in the story. - math homework: I recall calculus homework sessions that took 3-4 hours, and did not feel nearly as long. After a while would just get lost in the problems and lose time. I think all of these are flow states. I don't think they are all exactly the same. Which is all to say, I suspect there is a lot more to 'flow' state than we think, there are likely multiple facets which are different on their own. Further, individual variation could have a significant impact. Would someone who is ADHD experience the same flow states in the same ways? Another aspect, common & routine actions get "burned into" our neural circuitry. A persons morning routine is an example, the actions for 'burned-in' things no longer require much if any thought at all to do. You stop thinking "what's next" and just instead follow a routine and pattern that needs no decision making. It takes time and repetition to achieve this. This burn-in I feel is likely super related to 'flow'. For neural burn-in, I wonder if it's like a thru-hiker. EG: Routine aspects like foot placement and moving the trekking poles become burned in - leaving more space in the conscious for other activities. Yet, I know that things like "watching out for Bears" is not in the conscious space, but very active! I recall some times of seeing Bears almost immediately without realizing I was scanning for them so much. Very much like a high importance CPU interrupt firing, but one that I would have thought would have been a more active process rather than a background process. All in all, a super interesting area ripe for a lot more research. Our current understanding of flow feels like we now just past the "peak of 'mount stupid' (AKA Child's Hill)" [2] in the dunning-kruger effect, and just realized that we know very little about flow at all. [1] https://www.youtube.com/watch?v=yQ6VOOd73MA https://www.youtube.com/watch?v=yQ6VOOd73MA [2] https://www.theoptimumdrive.com/f1-blog-entries/2020/6/8/explaining-the-dunning-kruger-effect https://www.theoptimumdrive.com/f1-blog-entries/2020/6/8/exp...
BasilPH 3y ago
I have a lightweight way to use the pomodoro technique: I just start a pomodoro at x:00 or x:30 on the clock, and take a break at x:25 or x:55. This lets me work through a pomodoro when I'm super concentrated and doesn't introduce a distracting app or alarm. It's based on this blog post[^0], which I can highly recommend in general. [^0]: https://guzey.com/productivity/#how-i-work-and-rest-how-my-system-is-different-from-all-the-others-and-why-i-like-it-so-much https://guzey.com/productivity/#how-i-work-and-rest-how-my-s...

78 points by danboarder 3y ago

TLDR: remove distractions & use pomodoro.

I do not recommend doing pair programming as a way to handle long periods of isolated work. If you can not work alone without supervision you have to deal with those psychological issues first or just change your job. Your boss is not going to pay two salaries for doing the work of one. If you do pair programming, it will be because you can be more productive that way that working alone, and that is not the case most of the time (although most people want to believe that). As entrepreneur and engineer and programmer for a long time when I hear "pair programming", a big light bulb appears in my head screaming and blinking SCAM!. It can be done sometimes with specific people at specific times for specific reasons but I do not believe that it works for most people.

deleted 3y ago
[deleted]
tarcon 3y ago
There are more reasons to do pair programming: It also transfers knowledge of all kind (domain, tools, techniques), saves the time for code review, strengthens relationships and improves team culture
- apwell23 3y ago
  100%. It lowers support load, increases bus factor , improves sense of collective ownership, makes you humble. Unfortunately a whole lot of people are totally against that idea so i make do with chatgpt/copilot as my pair programmer these days.
rileymat2 3y ago
It has always been strange to me that for an industry that claims to be engineering and data focused stops when it comes to our own processes. One Lazy google search searching for a paper, and not a blog: https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.... In 1999, a controlled experiment run by the second author at the University of Utah investigated the economics of pair programming. Advanced undergraduates in a Software Engineering course participated in the experiment. One third of the class coded class projects as they had for years – by themselves. The rest of the class completed their projects with a collaborative partner. The results of how much time the students spent on the assignments are shown below in Figure 1. After the initial adjustment period in the first program (the “jelling” assignment), together the pairs only spent about 15% more time on the program than the individuals [4]. Development costs certainly do not double with pair programming! Significantly, the resulting code has about 15% fewer defects [4]. (These results are statistically significant.) Figure 2 shows the postdevelopment test cases the students passed for each program – essentially the percentage of the instructor’s test cases passed. The initial 15% increase in code development expense is recovered in the reduction in defects, as the following example illustrates... So the from this paper is the initial work is more costly, anyone that tells you it is not is probably wrong, but not double. But they are producing different work at a different quality level, at a different speed. Sure there could be problems with the methodology, it might apply to students and not professionals (a classic psyche 101 bias). But it is something, certainly not a scam.
- kosolam 3y ago
  Students can’t be compared to industry workers. In my 20+ years of professional career in a multitude of companies of various sizes and domains, I have never seen pair programming implemented as a regular working method. Nothing that even gets close to this.
  - rileymat2 3y ago
    I agree, students and industry workers are not directly comparable. But one of the issues that I would wager is somewhat comparable is the human factors which, in the study above showed large inefficiencies in the first assignments before the "jelling" of the pair. This makes most one shot studies problematic, it also makes starting to pair problematic if you are experimenting. I have never worked in a full time pairing place, it was experimental, here there, sometimes. But the initial inefficiencies rung true to me, along with this jelling. But, I have visited a place that did implement full time all the time pairing. (https://menloinnovations.com/our-way/our-process https://menloinnovations.com/our-way/our-process) With all the money spent on software development, I am a bit surprised there are not numerous double blind experiments and studies where two different consultancies are assigned the exact same very complex project with staffed professionals using different processes. It would be extremely costly, but could pay the industry back many-fold.
ZephyrBlu 3y ago
Personal productivity is second to team productivity. Pair programming facilitates discussion, context sharing and alignment. The biggest problems are almost always misalignment and lack of context/shared understanding, not productivity of individual team members.
hmeh 3y ago
Pair programming is, first and foremost, a technique for implementing continuous review. The old adage: If code reviews are good, do them constantly and continuously. We pair/mob when appropriate, and we don't do pull requests. If you pair AND do pull requests, it may be worth examining that. The secondary order effects cannot be ignored either. On our team, pairing is used to: - Coach more junior developers into being more proficient at their work - Share knowledge so that norms, standards, and other knowledge can propagate through the team in a more natural (and effective) way than documentation - Share techniques at the more tactical level - Further explore the solution space and do better planning and execution (go slow to go fast) And others.
- ParetoOptimal 3y ago
  The biggest downside to pair programming is that unless you are a strong communicator and feel like investing the energy, great ideas get averaged down to well.. Average. It doesn't have to be the case, but because of averages it typically is.
  - hmeh 3y ago
    If I understand what you are saying correctly, you are saying that if two people are pairing and the one with the better idea does not successfully communicate their idea, either from lack of trying or lack of effectiveness, then the person with the lesser idea might "win" and that is what would be implemented? If so, I would say that the appropriate response to that is to, as a team, work to improve communication and collaboration consistently -- every day, in every work item. Leadership should reinforce the import, exemplify it, and observe and coach. In general, what it sounds like you are saying is that people who are bad at things do things poorly. Yes, that's true, but that's why we have all the tools we have available to us to help them do things better. We don't have to like in squalor, we can choose to help each other rise above it.
sbellware 3y ago
As an entrepreneur and engineer and programmer having spent 30 years in software without washing out and still accelerating, I'm shocked every time I encounter the well-conditioned presumption that work cells in knowledge work should be decomposed to the single point of absolute irreducibility, which is inevitably the 1-person/1-work-item presumption. It implies the assertion that parallelization _should_ be maximized to the ultimate, which implies that the nature of the work is largely just implementation details and typing out code on a keyboard. But that's not where delays and inefficiencies are in software. And decomposing work cells to the point of total parallelization only exacerbates the factors that do indeed worsen the delays and inefficiencies. Software development has been so underperforming for so long that we presume that the natural, unavoidable state of software development is what the average team experiences today. That's only true of average teams with average productivity and average per-person yield. It's true in the middle of the productivity/performance bell curve, but not to the right of it. The 1-person/1-work-item division of labor sub-optimizes the momentum transfer that high-performance teams harness to get the high-performance results that they're after. Doing so is predicated on a number of factors, but principally it requires a vigorous attention to structural design fundamentals, rigorous norms, the ease of provability of changes and additions made to the design and implementation, and a solid grasp of organizational mechanics and process mechanics with a fluency in the effects of batching and queueing in systems-of-work in knowledge work and product development. In my work, and in the work in our organization, the 1-person/1-work-item system is the exception and collective work is the norm. That's because of breakthrough levels of productivity that can be unlocked at the upper echelons of quality. In fact, at that level, the terms "productivity" and "quality" don't have any meaningful difference. In the middle of the software development curve, there is already such middling productivity/quality that any particular strategy is unlikely to have much observable effect at all on outcomes. It's not until quality is increased to a point well over the present average that the effects of the numerous individual virtuous systems amplifying each other in the overall production system that the sub-optimization of the 1-person/1-work-item division of labor is obvious. At that level, management of software development operates like an accounting system that only records gains and disregards losses from the final bottom line. Every iota of spent effort is counted as a gain without regard for whether the result of the work creates loss-free assets or not. The field of software development has largely lost track of structural design fundamentals, both in the software itself and the design of the processes and procedures wherein the software is built. The vast majority of software developers operating today don't know what a mistake is in software development. They don't even recognize the design mistakes inherent in the tools they choose, and they tend to live in software ghettos where productivity poverty is the norm. They've got good slum survival street smarts, but have never been outside of the slum, so they couldn't orient themselves toward a healthier approach and healthier work life if they wanted to. They don't recognize the mistakes that are painfully obvious when seen through the lens of design fundamentals, so they don't know what to avoid. Software developers at large don't know where the "true north" heading is. To me, it's this current state of ghettoized software development that's the scam. It's the productivity balance sheet that fails to recognize losses and setbacks and that books "technical debt" as an asset that is the real scam in software work and software work management. But again, the vast majority of software workers and managers have never known any better. So, yeah... putting advanced, interconnected systems of work in the hands of teams that labor under the conditions that can't benefit of those systems of work is obviously ill-advised. But that doesn't mean that those teams can't induce productivity breakthroughs and realizations by practicing the techniques, even if in an uncoordinated and indefinite way. Though it will look like inefficiency to a manager who also has never had the opportunity to work outside the limits of software poverty. For a team to be able to go beyond single-person work cell division of labor and parallelization, it'd have an enormous amount of historically-cumulative deficits to overcome. And a team that's operating like this is operating with such relatively-low throughput that they're likely already to behind on their deliverables even before they get started on work that it would be impractical to suggest taking a more deliberate approach. In short, this kind of team is always operating under what are effectively emergency measures. That team's principal management system is Crisis Management. And when every work item is managed as a matter of crisis management, there's no point in hoping for much more than mere survival and coping mechanisms. I wouldn't say that it's necessarily a "scam" to fail to manage the endless emergencies and crisis intentionally, but it should raise some eyebrows for a team to be so far behind the eight ball to be experimenting with systems of work that aren't supported by the counter-balancing systems of work that interact to create emergent productivity. But then again, if they don't start some time, they'll never really get ahead of the software poverty line. The real scam in software development is "technical debt". The normalized predatory lending and borrowing that the term "technical debt" is a proxy for is the real racket in software development. Being a "post technical debt" team is something that few developers who started their careers since the term was coined can even imagine. It's like a mythical Lost City of Atlantis to developers who've never known any difference. The technical debt that keeps software works and software workers in technical poverty is the issue that should be hauled out into the cold light of day and exercised like a malevolent demon. But that can't happen until software developers, designers, managers, and operators invest the time to come to an understanding of what structural design decisions makes software work harder and increases the level of poverty that developers live in, and keeps increasing it until the developers themselves are utterly desensitized to their own unfortunate circumstances. But if they can make it out of the slum, getting past the grasping at 1-person/1-work-item management is part of it. That person will inevitably realize that it's an entirely arbitrary structure born out of the desperation of a project that embraced its own decline in the very first moments of its life. It's a work system that is an effect of the same conditions that make software work harder to do than necessary. At that point, every developer and every manager will have an intimate grasp of the difference between efficiency and productivity, and will know not to forsake long-term productivity for mere short-term efficiencies, and managers will know better than to manage for utilization rather than continuity. But it can't be readily done in a team that's already implemented itself into a technical deficit for not having known what to avoid in the first place. The scam is the low-yield spend of most software efforts. "Cooking the books" is today's software development's stock and trade. In a very real sense, software development is largely operated as negligence at best, and fraud at worst. And a good deal of the negligence is the failing to recognize that the sub-optimizations that we submit ourselves to every day are self-inflicted. The most heartbreaking thing about the whole sordid software affair is that to solutions to the problems have been well-known for decades in industries that have more maturity than software, but software's industrial immaturity is the very thing that keeps it from seeing the need to make a study of industry and production systems. Taylorism is the sickness that doomed so many industries that came before software, and it remains the mindset that continues to suppress software work today. And nothing will change until developers start to really, really make an effort to understand the subtle reasons why things are the way they are, and to start working for a life beyond the self-inflicted poverty of the ghetto and the slum. But generational poverty is a much more pernicious and endemic issue in software work than the appearance of the petty crimes and scams that impoverished people give into just to make their lives a little more survivable.
Cthulhu_ 3y ago
Scam? How so? I believe that thinking your solo work is good enough is hubris. I'm not a fan of pair programming either, but I don't trust my own work enough to not have someone else review it first.

zubairq 3y ago

Interesting read about programmer flow!

kosolam 3y ago

I guess different stuff works for different people. The pomodoro thing is inhuman in my opinion, too mechanical and the process itself is distracting the mind from the actual work that it should work on. I found the combination of flow+off keyboard thinking time to be my preferred natural flow of work. Usually I dive in and work in a flow for as long as I can, which usually is around an hour and up to a few hours in some cases. Then I naturally take a break. Then get back again. But in cases when I stop because I need to think rather than think-and-type, the break becomes longer, as necessary.

halfcat 3y ago
I use mini-pomodoro to build momentum when I can’t get started. Start with 2-3 minutes “work”, 1 minute break. Keep bumping those up toward 25/5. Usually by the time I’ve done a few rounds, I don’t want a break and I’ve got my momentum, and I ditch the cycles and just work. This works surprisingly well for me even at a micro level, like exercise 10 seconds, break for 5 seconds, repeat. Before I know it I’m just exercising uninterrupted for 20 minutes. I left out one part: clap for yourself The process is more like: * Pick something * Do it * Clap for yourself * Repeat And the key is to make “do it” as small as necessary to keep the cycle going, then expand it once the human reward system takes over.
- datameta 3y ago
  Absolutely this. When I was building up a soldering habit (have a backlog of analog synth modules to make) I made a point of soldering 1 component. But then by the time the iron heated up, I've decided what goes into the board next, and soldered that one component, I might as well do 5 or 10.
rynoV 3y ago
[dead]

ttiurani 3y ago

> By definition, a flow state is non-collaborative; [...] you’re certainly not going to be in that mindset while you’re in a pair programming session. This is not true. Group flow is a well documented phenomenom[0]. While it's easiest to recognize for example in an orchestra, group flow can happen with pair programming as well. [0] https://www.aalto.fi/en/oasis-of-radical-wellbeing/group-flow-what-is-it-and-how-to-achieve-it https://www.aalto.fi/en/oasis-of-radical-wellbeing/group-flo...

halfcat 3y ago
I do wonder if group flow and individual flow have more to do with different skill sets, and which path best suits the people you have, as opposed to the idea that group or individual flow is more effective. Like, I like to whiteboard and mock up a problem in Python to wrap my brain around it. My coworker likes to mock things up in Excel. Usually when we work together, I find myself just waiting to get off the call so I can do my own whiteboarding. What makes sense to him in his Excel file doesn’t hit as much for me. Whereas it seems like group flow uses some kind of higher level coordination process, whether it’s whatever orchestra “best practices” have been established over centuries, or people chanting together in temples, or whatever. The question being, while group flow exists, is it simply that it requires people who like engaging in the “group flow activities”? Like we can probably find people who coincidentally like chanting, and those people might make good monks. But will my coworker and I ever work well in a pair programming environment?
- serialNumber 3y ago
  Excel? How does that work - first time I'm hearing of it being used in that way
  - deleted 3y ago
    [deleted]
bradknowles 3y ago
I've played in a large band, with over fifty members. I did that for several years. The thing that kept us together was the conductor, not some sort of "group flow". This is not to say that "group flow" doesn't exist, but I'd want more extraordinary evidence for this claim.

seadan83 3y ago

I think the title suggests larger questions. What is Flow? How many different kinds of flow states are there? To what extent are they equal? I recently listened to "Your Brain: Who's in Control?" [1], a PBS documentary that looked at a musician in an MRI rapping a memorized piece vs an ad-hoc rap. They found the musician's prefrontal cortex was inhibited when doing the ad-hoc exercise. The prefrontal cortex is used as a "filter" center, to predict and evaluate the potential outcome of actions and basically to tell you when something is a bad idea. When developers are in flow, and they are creating brand new code - do their prefrontal cortex'es also become inhibited? Is that the same kind of flow state? I believe there are multiple types of flow state: - gardening/choirs, time drops away and you lose yourself in the trimming, edging and mundane gardening tasks - gaming, when I was younger and after an approx 16 hour binge of Civilization, my mind was still in the game. I was asleep and was still thinking in-game, solving problems, and wondering "where is the end turn button." Being in that level of flow state, the thoughts of 'end turn', 'move unit' - just occurred, my mind's connection to the game through my body was erased, the motor movements to click, hotkeys, all gone from conscious thought and just automatic. - music: Type (A) - playing a well known piece, it just happens. Type (B) Improv, jazz musicians do this all the time for hours on end. - biking/exercise: after a few hours, a sense of time can stop and everything becomes automatic. - driving: actions to signal, brake, accelerate require no thought; your mind says "speed up" and the body's reaction is automatic and requires virtually no thought. The interface between you and the car disappears, you no longer think "press my foot down" - you only think "accelerate" - reading: a best example of this I recall was being younger and reading Lords of the Rings. Hours melted away, I experienced complete immersion in the story. - math homework: I recall calculus homework sessions that took 3-4 hours, and did not feel nearly as long. After a while would just get lost in the problems and lose time. I think all of these are flow states. I don't think they are all exactly the same. Which is all to say, I suspect there is a lot more to 'flow' state than we think, there are likely multiple facets which are different on their own. Further, individual variation could have a significant impact. Would someone who is ADHD experience the same flow states in the same ways? Another aspect, common & routine actions get "burned into" our neural circuitry. A persons morning routine is an example, the actions for 'burned-in' things no longer require much if any thought at all to do. You stop thinking "what's next" and just instead follow a routine and pattern that needs no decision making. It takes time and repetition to achieve this. This burn-in I feel is likely super related to 'flow'. For neural burn-in, I wonder if it's like a thru-hiker. EG: Routine aspects like foot placement and moving the trekking poles become burned in - leaving more space in the conscious for other activities. Yet, I know that things like "watching out for Bears" is not in the conscious space, but very active! I recall some times of seeing Bears almost immediately without realizing I was scanning for them so much. Very much like a high importance CPU interrupt firing, but one that I would have thought would have been a more active process rather than a background process. All in all, a super interesting area ripe for a lot more research. Our current understanding of flow feels like we now just past the "peak of 'mount stupid' (AKA Child's Hill)" [2] in the dunning-kruger effect, and just realized that we know very little about flow at all. [1] https://www.youtube.com/watch?v=yQ6VOOd73MA https://www.youtube.com/watch?v=yQ6VOOd73MA [2] https://www.theoptimumdrive.com/f1-blog-entries/2020/6/8/explaining-the-dunning-kruger-effect https://www.theoptimumdrive.com/f1-blog-entries/2020/6/8/exp...

BasilPH 3y ago

I have a lightweight way to use the pomodoro technique: I just start a pomodoro at x:00 or x:30 on the clock, and take a break at x:25 or x:55. This lets me work through a pomodoro when I'm super concentrated and doesn't introduce a distracting app or alarm. It's based on this blog post[^0], which I can highly recommend in general. [^0]: https://guzey.com/productivity/#how-i-work-and-rest-how-my-system-is-different-from-all-the-others-and-why-i-like-it-so-much https://guzey.com/productivity/#how-i-work-and-rest-how-my-s...