Mixing
How to get remote workers to properly engage while working on a task together?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
2
down vote
favorite
I believe pair programming creates MUCH cleaner code, much less bugs, better reusable architecture, and better team culture/bond. At my old job, I created dozens of pair programming setups in a traditionally "cubicled" culture. Those programmers ended out outperforming their peers on other projects by miles.
When I started my own company I started facing the following problem: offshore programmers are very shy. I've had a few programmers quit in the middle of an interview because they were too shy to let me see them code. However their GitHub profiles were great.
The second problem comes when pair programming online, it never seems to catch on as well as in a physical team room. Generally I've found the other programmer just sits around checking email or doing their own thing. There is very little conversation/interaction. This removes the benefits of working collaboratively.
Currently, I set up the programmers in a Google Hangouts session and give them one of 3 tasks
- Solve a bug
- Solve an architectural issue
- Train employee in architecture
How can I encourage or facilitate employees to better engage when working collaboratively but in an online/remote work environment?
software-industry telecommute teamwork
edited Jul 15 '14 at 20:14
Elysian Fields♦
96.9k46292449
asked Jul 15 '14 at 2:35
Toli Zaslavskiy
614169
suggest improvements |Â
up vote
2
down vote
favorite
I believe pair programming creates MUCH cleaner code, much less bugs, better reusable architecture, and better team culture/bond. At my old job, I created dozens of pair programming setups in a traditionally "cubicled" culture. Those programmers ended out outperforming their peers on other projects by miles.
When I started my own company I started facing the following problem: offshore programmers are very shy. I've had a few programmers quit in the middle of an interview because they were too shy to let me see them code. However their GitHub profiles were great.
The second problem comes when pair programming online, it never seems to catch on as well as in a physical team room. Generally I've found the other programmer just sits around checking email or doing their own thing. There is very little conversation/interaction. This removes the benefits of working collaboratively.
Currently, I set up the programmers in a Google Hangouts session and give them one of 3 tasks
- Solve a bug
- Solve an architectural issue
- Train employee in architecture
How can I encourage or facilitate employees to better engage when working collaboratively but in an online/remote work environment?
software-industry telecommute teamwork
edited Jul 15 '14 at 20:14
Elysian Fields♦
96.9k46292449
asked Jul 15 '14 at 2:35
Toli Zaslavskiy
614169
2
You have several related but distinct questions here...
– Elysian Fields♦
Jul 15 '14 at 2:59
1
As enderland pointed out above, you have three separate questions here which are related, but not the same. Some are on-topic, some aren't. Could you please make an edit that focuses on one specific problem, and what you are looking for in a solution? Thanks in advance.
– jmac
Jul 15 '14 at 3:01
good point. How's the revised question @jmac
– Toli Zaslavskiy
Jul 15 '14 at 3:08
how is this question different from How can I make sure my remote workers are not slacking off?
– gnat
Aug 1 '14 at 18:10
suggest improvements |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I believe pair programming creates MUCH cleaner code, much less bugs, better reusable architecture, and better team culture/bond. At my old job, I created dozens of pair programming setups in a traditionally "cubicled" culture. Those programmers ended out outperforming their peers on other projects by miles.
When I started my own company I started facing the following problem: offshore programmers are very shy. I've had a few programmers quit in the middle of an interview because they were too shy to let me see them code. However their GitHub profiles were great.
The second problem comes when pair programming online, it never seems to catch on as well as in a physical team room. Generally I've found the other programmer just sits around checking email or doing their own thing. There is very little conversation/interaction. This removes the benefits of working collaboratively.
Currently, I set up the programmers in a Google Hangouts session and give them one of 3 tasks
- Solve a bug
- Solve an architectural issue
- Train employee in architecture
How can I encourage or facilitate employees to better engage when working collaboratively but in an online/remote work environment?
software-industry telecommute teamwork
edited Jul 15 '14 at 20:14
Elysian Fields♦
96.9k46292449
asked Jul 15 '14 at 2:35
Toli Zaslavskiy
614169
I believe pair programming creates MUCH cleaner code, much less bugs, better reusable architecture, and better team culture/bond. At my old job, I created dozens of pair programming setups in a traditionally "cubicled" culture. Those programmers ended out outperforming their peers on other projects by miles.
When I started my own company I started facing the following problem: offshore programmers are very shy. I've had a few programmers quit in the middle of an interview because they were too shy to let me see them code. However their GitHub profiles were great.
The second problem comes when pair programming online, it never seems to catch on as well as in a physical team room. Generally I've found the other programmer just sits around checking email or doing their own thing. There is very little conversation/interaction. This removes the benefits of working collaboratively.
Currently, I set up the programmers in a Google Hangouts session and give them one of 3 tasks
- Solve a bug
- Solve an architectural issue
- Train employee in architecture
How can I encourage or facilitate employees to better engage when working collaboratively but in an online/remote work environment?
software-industry telecommute teamwork
edited Jul 15 '14 at 20:14
Elysian Fields♦
96.9k46292449
asked Jul 15 '14 at 2:35
Toli Zaslavskiy
614169
edited Jul 15 '14 at 20:14
Elysian Fields♦
96.9k46292449
edited Jul 15 '14 at 20:14
Elysian Fields♦
96.9k46292449
edited Jul 15 '14 at 20:14
Elysian Fields♦
96.9k46292449
96.9k46292449
asked Jul 15 '14 at 2:35
Toli Zaslavskiy
614169
asked Jul 15 '14 at 2:35
Toli Zaslavskiy
614169
asked Jul 15 '14 at 2:35
Toli Zaslavskiy
614169
614169
2
You have several related but distinct questions here...
– Elysian Fields♦
Jul 15 '14 at 2:59
1
As enderland pointed out above, you have three separate questions here which are related, but not the same. Some are on-topic, some aren't. Could you please make an edit that focuses on one specific problem, and what you are looking for in a solution? Thanks in advance.
– jmac
Jul 15 '14 at 3:01
good point. How's the revised question @jmac
– Toli Zaslavskiy
Jul 15 '14 at 3:08
how is this question different from How can I make sure my remote workers are not slacking off?
– gnat
Aug 1 '14 at 18:10
suggest improvements |Â
2
You have several related but distinct questions here...
– Elysian Fields♦
Jul 15 '14 at 2:59
1
As enderland pointed out above, you have three separate questions here which are related, but not the same. Some are on-topic, some aren't. Could you please make an edit that focuses on one specific problem, and what you are looking for in a solution? Thanks in advance.
– jmac
Jul 15 '14 at 3:01
good point. How's the revised question @jmac
– Toli Zaslavskiy
Jul 15 '14 at 3:08
how is this question different from How can I make sure my remote workers are not slacking off?
– gnat
Aug 1 '14 at 18:10
2
2
You have several related but distinct questions here...
– Elysian Fields♦
Jul 15 '14 at 2:59
You have several related but distinct questions here...
– Elysian Fields♦
Jul 15 '14 at 2:59
1
1
As enderland pointed out above, you have three separate questions here which are related, but not the same. Some are on-topic, some aren't. Could you please make an edit that focuses on one specific problem, and what you are looking for in a solution? Thanks in advance.
– jmac
Jul 15 '14 at 3:01
As enderland pointed out above, you have three separate questions here which are related, but not the same. Some are on-topic, some aren't. Could you please make an edit that focuses on one specific problem, and what you are looking for in a solution? Thanks in advance.
– jmac
Jul 15 '14 at 3:01
good point. How's the revised question @jmac
– Toli Zaslavskiy
Jul 15 '14 at 3:08
good point. How's the revised question @jmac
– Toli Zaslavskiy
Jul 15 '14 at 3:08
how is this question different from How can I make sure my remote workers are not slacking off?
– gnat
Aug 1 '14 at 18:10
how is this question different from How can I make sure my remote workers are not slacking off?
– gnat
Aug 1 '14 at 18:10
suggest improvements |Â
1 Answer
1
active
oldest
votes
up vote
3
down vote
As a software developer, if you asked me to collaborate over a hangout session I'd send you the text outlined below to explain why I'm not engaging, wait for the call to end, divide up the labor with my partner, each do half, and get paid to work part time until the next critical event. The solution to this is to present compelling objective argument for why they should work together and engage team-members in determining the most effective software development methodology for their work environment.
Last week Kent Beck made a claim that you don't really need bug
tracking databases when you're doing Extreme Programming, because the
combination of pair programming (with persistent code review) and test
driven development (guaranteeing 100% code coverage of the automated
tests) means you hardly ever have bugs. That didn't sound right to me.
I looked in our own bug tracking database here at Fog Creek to see
what kinds of bugs were keeping it busy.
Lo and behold, I discovered that very few of the bugs in there would
have been discovered with pair programming or test driven development.
Many of our "bugs" are really what XP calls stories -- basically, just
feature requests. We're using the bug tracking system as a way of
remembering, prioritizing, and managing all the little improvements
and big features we want to implement.
A lot of the other bugs were only discovered after much use in the
field. The Polish keyboard thing. There's no way pair programming was
going to find that. And logical mistakes that never occurred to us in
the way that different features work together. The larger and more
complex a program, the more interactions between the features that you
don't think about. A particular unlikely sequence of characters ({${?,
if you must know) that confuses the lexer. Some ftp servers produce an
error when you delete a file that doesn't exist (our ftp server does
not complain so this never occurred to us.)
I carefully studied every bug. Out of 106 bugs we fixed for the
service pack release of CityDesk, exactly 5 of them could have been
prevented through pair programming or test driven design. We actually
had more bugs that we knew about and thought weren't important (only
to be corrected by our customers!) than bugs that could have been
caught by XP methods.
http://www.joelonsoftware.com/articles/FiveWorlds.html
For example, pair programming (a typically YAGNI development type
process), in which each software task has a pair of developers
allocated to it, reduces the risks of staff turnover or absences.
However, there is an apparent reduction in productivity, as each task
now requires two people.
http://www.nasa.gov/pdf/418878main_FSWC_Final_Report.pdf
answered Aug 7 '14 at 21:19
Calvin
54823
You can't dismiss a colaboration session with an invalid argument. Pair programming isn't about creating bug-free software. Claiming that a third-party found that pair programming isn't effective for avoiding bugs isn't an answer to OP. And quoting NASA on "However, there is an apparent reduction in productivity, as each task now requires two people." is just naive.
– André Werlang
Nov 27 '16 at 19:33
suggest improvements |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
As a software developer, if you asked me to collaborate over a hangout session I'd send you the text outlined below to explain why I'm not engaging, wait for the call to end, divide up the labor with my partner, each do half, and get paid to work part time until the next critical event. The solution to this is to present compelling objective argument for why they should work together and engage team-members in determining the most effective software development methodology for their work environment.
Last week Kent Beck made a claim that you don't really need bug
tracking databases when you're doing Extreme Programming, because the
combination of pair programming (with persistent code review) and test
driven development (guaranteeing 100% code coverage of the automated
tests) means you hardly ever have bugs. That didn't sound right to me.
I looked in our own bug tracking database here at Fog Creek to see
what kinds of bugs were keeping it busy.
Lo and behold, I discovered that very few of the bugs in there would
have been discovered with pair programming or test driven development.
Many of our "bugs" are really what XP calls stories -- basically, just
feature requests. We're using the bug tracking system as a way of
remembering, prioritizing, and managing all the little improvements
and big features we want to implement.
A lot of the other bugs were only discovered after much use in the
field. The Polish keyboard thing. There's no way pair programming was
going to find that. And logical mistakes that never occurred to us in
the way that different features work together. The larger and more
complex a program, the more interactions between the features that you
don't think about. A particular unlikely sequence of characters ({${?,
if you must know) that confuses the lexer. Some ftp servers produce an
error when you delete a file that doesn't exist (our ftp server does
not complain so this never occurred to us.)
I carefully studied every bug. Out of 106 bugs we fixed for the
service pack release of CityDesk, exactly 5 of them could have been
prevented through pair programming or test driven design. We actually
had more bugs that we knew about and thought weren't important (only
to be corrected by our customers!) than bugs that could have been
caught by XP methods.
http://www.joelonsoftware.com/articles/FiveWorlds.html
For example, pair programming (a typically YAGNI development type
process), in which each software task has a pair of developers
allocated to it, reduces the risks of staff turnover or absences.
However, there is an apparent reduction in productivity, as each task
now requires two people.
http://www.nasa.gov/pdf/418878main_FSWC_Final_Report.pdf
answered Aug 7 '14 at 21:19
Calvin
54823
You can't dismiss a colaboration session with an invalid argument. Pair programming isn't about creating bug-free software. Claiming that a third-party found that pair programming isn't effective for avoiding bugs isn't an answer to OP. And quoting NASA on "However, there is an apparent reduction in productivity, as each task now requires two people." is just naive.
– André Werlang
Nov 27 '16 at 19:33
suggest improvements |Â
up vote
3
down vote
As a software developer, if you asked me to collaborate over a hangout session I'd send you the text outlined below to explain why I'm not engaging, wait for the call to end, divide up the labor with my partner, each do half, and get paid to work part time until the next critical event. The solution to this is to present compelling objective argument for why they should work together and engage team-members in determining the most effective software development methodology for their work environment.
Last week Kent Beck made a claim that you don't really need bug
tracking databases when you're doing Extreme Programming, because the
combination of pair programming (with persistent code review) and test
driven development (guaranteeing 100% code coverage of the automated
tests) means you hardly ever have bugs. That didn't sound right to me.
I looked in our own bug tracking database here at Fog Creek to see
what kinds of bugs were keeping it busy.
Lo and behold, I discovered that very few of the bugs in there would
have been discovered with pair programming or test driven development.
Many of our "bugs" are really what XP calls stories -- basically, just
feature requests. We're using the bug tracking system as a way of
remembering, prioritizing, and managing all the little improvements
and big features we want to implement.
A lot of the other bugs were only discovered after much use in the
field. The Polish keyboard thing. There's no way pair programming was
going to find that. And logical mistakes that never occurred to us in
the way that different features work together. The larger and more
complex a program, the more interactions between the features that you
don't think about. A particular unlikely sequence of characters ({${?,
if you must know) that confuses the lexer. Some ftp servers produce an
error when you delete a file that doesn't exist (our ftp server does
not complain so this never occurred to us.)
I carefully studied every bug. Out of 106 bugs we fixed for the
service pack release of CityDesk, exactly 5 of them could have been
prevented through pair programming or test driven design. We actually
had more bugs that we knew about and thought weren't important (only
to be corrected by our customers!) than bugs that could have been
caught by XP methods.
http://www.joelonsoftware.com/articles/FiveWorlds.html
For example, pair programming (a typically YAGNI development type
process), in which each software task has a pair of developers
allocated to it, reduces the risks of staff turnover or absences.
However, there is an apparent reduction in productivity, as each task
now requires two people.
http://www.nasa.gov/pdf/418878main_FSWC_Final_Report.pdf
answered Aug 7 '14 at 21:19
Calvin
54823
You can't dismiss a colaboration session with an invalid argument. Pair programming isn't about creating bug-free software. Claiming that a third-party found that pair programming isn't effective for avoiding bugs isn't an answer to OP. And quoting NASA on "However, there is an apparent reduction in productivity, as each task now requires two people." is just naive.
– André Werlang
Nov 27 '16 at 19:33
suggest improvements |Â
up vote
3
down vote
up vote
3
down vote
As a software developer, if you asked me to collaborate over a hangout session I'd send you the text outlined below to explain why I'm not engaging, wait for the call to end, divide up the labor with my partner, each do half, and get paid to work part time until the next critical event. The solution to this is to present compelling objective argument for why they should work together and engage team-members in determining the most effective software development methodology for their work environment.
Last week Kent Beck made a claim that you don't really need bug
tracking databases when you're doing Extreme Programming, because the
combination of pair programming (with persistent code review) and test
driven development (guaranteeing 100% code coverage of the automated
tests) means you hardly ever have bugs. That didn't sound right to me.
I looked in our own bug tracking database here at Fog Creek to see
what kinds of bugs were keeping it busy.
Lo and behold, I discovered that very few of the bugs in there would
have been discovered with pair programming or test driven development.
Many of our "bugs" are really what XP calls stories -- basically, just
feature requests. We're using the bug tracking system as a way of
remembering, prioritizing, and managing all the little improvements
and big features we want to implement.
A lot of the other bugs were only discovered after much use in the
field. The Polish keyboard thing. There's no way pair programming was
going to find that. And logical mistakes that never occurred to us in
the way that different features work together. The larger and more
complex a program, the more interactions between the features that you
don't think about. A particular unlikely sequence of characters ({${?,
if you must know) that confuses the lexer. Some ftp servers produce an
error when you delete a file that doesn't exist (our ftp server does
not complain so this never occurred to us.)
I carefully studied every bug. Out of 106 bugs we fixed for the
service pack release of CityDesk, exactly 5 of them could have been
prevented through pair programming or test driven design. We actually
had more bugs that we knew about and thought weren't important (only
to be corrected by our customers!) than bugs that could have been
caught by XP methods.
http://www.joelonsoftware.com/articles/FiveWorlds.html
For example, pair programming (a typically YAGNI development type
process), in which each software task has a pair of developers
allocated to it, reduces the risks of staff turnover or absences.
However, there is an apparent reduction in productivity, as each task
now requires two people.
http://www.nasa.gov/pdf/418878main_FSWC_Final_Report.pdf
answered Aug 7 '14 at 21:19
Calvin
54823
As a software developer, if you asked me to collaborate over a hangout session I'd send you the text outlined below to explain why I'm not engaging, wait for the call to end, divide up the labor with my partner, each do half, and get paid to work part time until the next critical event. The solution to this is to present compelling objective argument for why they should work together and engage team-members in determining the most effective software development methodology for their work environment.
Last week Kent Beck made a claim that you don't really need bug
tracking databases when you're doing Extreme Programming, because the
combination of pair programming (with persistent code review) and test
driven development (guaranteeing 100% code coverage of the automated
tests) means you hardly ever have bugs. That didn't sound right to me.
I looked in our own bug tracking database here at Fog Creek to see
what kinds of bugs were keeping it busy.
Lo and behold, I discovered that very few of the bugs in there would
have been discovered with pair programming or test driven development.
Many of our "bugs" are really what XP calls stories -- basically, just
feature requests. We're using the bug tracking system as a way of
remembering, prioritizing, and managing all the little improvements
and big features we want to implement.
A lot of the other bugs were only discovered after much use in the
field. The Polish keyboard thing. There's no way pair programming was
going to find that. And logical mistakes that never occurred to us in
the way that different features work together. The larger and more
complex a program, the more interactions between the features that you
don't think about. A particular unlikely sequence of characters ({${?,
if you must know) that confuses the lexer. Some ftp servers produce an
error when you delete a file that doesn't exist (our ftp server does
not complain so this never occurred to us.)
I carefully studied every bug. Out of 106 bugs we fixed for the
service pack release of CityDesk, exactly 5 of them could have been
prevented through pair programming or test driven design. We actually
had more bugs that we knew about and thought weren't important (only
to be corrected by our customers!) than bugs that could have been
caught by XP methods.
http://www.joelonsoftware.com/articles/FiveWorlds.html
For example, pair programming (a typically YAGNI development type
process), in which each software task has a pair of developers
allocated to it, reduces the risks of staff turnover or absences.
However, there is an apparent reduction in productivity, as each task
now requires two people.
http://www.nasa.gov/pdf/418878main_FSWC_Final_Report.pdf
answered Aug 7 '14 at 21:19
Calvin
54823
answered Aug 7 '14 at 21:19
Calvin
54823
answered Aug 7 '14 at 21:19
Calvin
54823
answered Aug 7 '14 at 21:19
Calvin
54823
54823
You can't dismiss a colaboration session with an invalid argument. Pair programming isn't about creating bug-free software. Claiming that a third-party found that pair programming isn't effective for avoiding bugs isn't an answer to OP. And quoting NASA on "However, there is an apparent reduction in productivity, as each task now requires two people." is just naive.
– André Werlang
Nov 27 '16 at 19:33
suggest improvements |Â
You can't dismiss a colaboration session with an invalid argument. Pair programming isn't about creating bug-free software. Claiming that a third-party found that pair programming isn't effective for avoiding bugs isn't an answer to OP. And quoting NASA on "However, there is an apparent reduction in productivity, as each task now requires two people." is just naive.
– André Werlang
Nov 27 '16 at 19:33
You can't dismiss a colaboration session with an invalid argument. Pair programming isn't about creating bug-free software. Claiming that a third-party found that pair programming isn't effective for avoiding bugs isn't an answer to OP. And quoting NASA on "However, there is an apparent reduction in productivity, as each task now requires two people." is just naive.
– André Werlang
Nov 27 '16 at 19:33
You can't dismiss a colaboration session with an invalid argument. Pair programming isn't about creating bug-free software. Claiming that a third-party found that pair programming isn't effective for avoiding bugs isn't an answer to OP. And quoting NASA on "However, there is an apparent reduction in productivity, as each task now requires two people." is just naive.
– André Werlang
Nov 27 '16 at 19:33
suggest improvements |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f30600%2fhow-to-get-remote-workers-to-properly-engage-while-working-on-a-task-together%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
2
You have several related but distinct questions here...
– Elysian Fields♦
Jul 15 '14 at 2:59
1
As enderland pointed out above, you have three separate questions here which are related, but not the same. Some are on-topic, some aren't. Could you please make an edit that focuses on one specific problem, and what you are looking for in a solution? Thanks in advance.
– jmac
Jul 15 '14 at 3:01
good point. How's the revised question @jmac
– Toli Zaslavskiy
Jul 15 '14 at 3:08
how is this question different from How can I make sure my remote workers are not slacking off?
– gnat
Aug 1 '14 at 18:10