2 drums 2 codes
Sorry, again a music similitude I found...
Once, around 4 years ago I found a video in youtube of two drummers who were making a cover of Toxicity by System of a Down. The coordination, timing, tuning they both had was incredible, the song just sounded in tune and strong, like with a natural reverb (they were in an open space without any walls, so forget about any scenery reverb).
This jumped right into my mind as I was touching the subject of pair programming, as you can't blame one drummer for being out of time whether he was rushing or dragging, they were both following a song so it was a team's effort... saying this, you can't blame an observer or driver as they're both, at that moment, just one entity responsible for making a functioning code.
By attempting this collaborative technique you can attack efficiencies and less mistakes as something may pass by someone's thinking process, the other half of the team may find that mistake before having to go and fix it later in testing.
I consider pair programming a constant refactoring technique, in which you may be constantly improving the code and by changing roles (from driver to observer and viceversa) your scope may be magnified.
Once, around 4 years ago I found a video in youtube of two drummers who were making a cover of Toxicity by System of a Down. The coordination, timing, tuning they both had was incredible, the song just sounded in tune and strong, like with a natural reverb (they were in an open space without any walls, so forget about any scenery reverb).
This jumped right into my mind as I was touching the subject of pair programming, as you can't blame one drummer for being out of time whether he was rushing or dragging, they were both following a song so it was a team's effort... saying this, you can't blame an observer or driver as they're both, at that moment, just one entity responsible for making a functioning code.
By attempting this collaborative technique you can attack efficiencies and less mistakes as something may pass by someone's thinking process, the other half of the team may find that mistake before having to go and fix it later in testing.
I consider pair programming a constant refactoring technique, in which you may be constantly improving the code and by changing roles (from driver to observer and viceversa) your scope may be magnified.
Comentarios
Publicar un comentario