4 ms·

The prevailing ideal of a commercial software team is a tight knit tribe. Members are selected for "culture fit", ability to do pleasant small talk around the l

by mbrock 11y ago

The prevailing ideal of a commercial software team is a tight knit tribe. Members are selected for "culture fit", ability to do pleasant small talk around the lunch table, personal hygiene, and so on. The team should huddle around every day for status updates, bonding, and small talk. Communication should be frequent and face-to-face collaboration is considered the ideal. You can adapt this ideal to remote work situations and there is lots of material about how to accommodate that. But many people who gravitate toward remote work are probably trying to move away from this ideal. For some it may be because they've experienced open source collaboration and don't see why commercial development can't be done in a similar way. Open source projects tend to use low-bandwidth, asynchronous communication, perhaps as a cultural heritage from the days of slow internet. That enables collaborators to schedule their work in whatever way suits them. Many programmers are psychologically introverted, which means that they function best when they're allowed to be by themselves, instead of being constantly communicated with. These programmers are often unhappy in the office environment, especially those with open plans. If you take a step back and look at contemporary software development offices from a kind of anthropological perspective, it's actually quite a bizarre and extraordinary way of life. When everyone is in the same house for 8 hours every weekday, the demand for social compatibility is, in some sense, even greater than with most families and friend groups... one way to get around that is for each worker to wear headphones all day, which is also quite a strange situation, socially... I'm personally yearning to be able to work remotely in a way that suits my introversion and my preference for asynchronous independence—or to be frank: I just don't want to be in the same house all day every day with 10 other dudes, and I really don't want to be on conference call with them all day either. Nor do I really want a strong "team spirit" in the sense of social bonding. I think work would be more sustainable and enjoyable if team relations were less tight, and if my lifestyle allowed me a wider spectrum of daily social interaction. I'm motivated by helping to do good software development. I'd rather do this in a way that's like the open source model, preserving my basic independence in terms of location, time, and communication.

joesmo 11y ago
This is exactly how we work at my job currently. We use pull requests and each programmer picks a task and goes on his way. When it's done, it's submitted to the other programmer for review (we have two full time). Most communication happens in chat and pull requests and we rarely have meetings other than the daily scrum-like sync up meeting (which is tolerable). Most tasks are half a day to a day (except larger tasks) so the turnaround is quick in case something was misunderstood. I think this process could easily scale to more developers as long as they are independent and able to work by themselves most of the time, unsupervised. That doesn't mean they have to be senior, only that they are disciplined and won't get stuck on easy problems.
- mbrock 11y ago
  As I see it, that's still far away from the kind of "open source" development model I'm thinking about. Most obviously, no open source project has mandatory daily status meetings! And usually, tasks are larger. They often have chat rooms, but they're not really used for synchronizing work, more for idle socializing and occasional discussions. Daily coordination in the "scrum" fashion, I think, is still under the threshold where work tends to become "tightly coupled" and synchronous. I have more thoughts about how I think this can discourage longer-term projects... but, another time... By the way, I think these are just two different models, with their own flaws and benefits, and it's interesting to think about whether they could be combined in some novel way.

by mbrock 11y ago

joesmo 11y ago

This is exactly how we work at my job currently. We use pull requests and each programmer picks a task and goes on his way. When it's done, it's submitted to the other programmer for review (we have two full time). Most communication happens in chat and pull requests and we rarely have meetings other than the daily scrum-like sync up meeting (which is tolerable). Most tasks are half a day to a day (except larger tasks) so the turnaround is quick in case something was misunderstood. I think this process could easily scale to more developers as long as they are independent and able to work by themselves most of the time, unsupervised. That doesn't mean they have to be senior, only that they are disciplined and won't get stuck on easy problems.

mbrock 11y ago
As I see it, that's still far away from the kind of "open source" development model I'm thinking about. Most obviously, no open source project has mandatory daily status meetings! And usually, tasks are larger. They often have chat rooms, but they're not really used for synchronizing work, more for idle socializing and occasional discussions. Daily coordination in the "scrum" fashion, I think, is still under the threshold where work tends to become "tightly coupled" and synchronous. I have more thoughts about how I think this can discourage longer-term projects... but, another time... By the way, I think these are just two different models, with their own flaws and benefits, and it's interesting to think about whether they could be combined in some novel way.