Two programmers work at the same computer, taking turns driving and navigating. They constantly communicate with each other as they switch roles fluidly. Pair programming has been shown to reduce defect rates significantly and results in better designed, simpler and more maintainable code. It can turn seemingly impossible problems into easy or quick solutions. Pair programming is also more fun than expected.

1. Hello

3. PAIRING,
FAST and SLOW

4. i18n
蘇泰安 f taiansu
README.md
aboutćmef taiansu
log
do Ŷćyear 電腦雜誌技術編輯 end
gem install rails
validates čhaveY scjp Ṡẞ true
mvim jćrbĉ jćjs
workY at OptimisDevr
fronY end j ẄćỶ Ś backY end j ẄćŶ

5. What is pair programming

6. Two programmers at one computer
One drivesċ the other navigates
Switching roles fluidly
They constantly communicate

7. Why Pairing

8. Ỳć reduction in defect rates of ỲẎỜto ẎẄỜ
Ýć better designĉ simplerĉ moreQmaintainable code
Ŷć impossible problems become easy or even quick

9. Way more fun then it sounds

10. productivity && fun

11. Ninja
( feel like )

12. Herbert Simon:
I 情境提供了線索ĉ
線索讓專家得以提取記憶中的訊息ĉ
而訊息提供了答案。
專家直覺就是辨識，
不多也不少，就是它。 J

16. Two system

18. System 1automaticlly
quickly
little or no effort
no sense of voluntart control

19. 17 * 24

20. CPU bound

21. Pay attention

22. System 2conscious and resoning
allocates attention
slow
have boundry
lazyĉ lazyĉ lazy

23. Cache things to System 1

24. system_1 += system_2
take 10,000 hours

26. Müller Lyer illusion

29. Think pair programming
this way

30. The driver
focuses on tactics:
writing clean code that runs and pass the testć

31. The navigator
focuses on strategy:
how the code fits into the overall design
which tests will drive the code forward
which refactorings will improve the entire codebase

32. Our Case

33. Goal

34. Discuss

35. & Code

37. What we found

38. Set up a goal everytime

39. TDD is great for pairing

40. Stay talking

41. shared knowledge
both technique
and your application

42. You'll know your partner more

43. improve communication
ability

44. rest frequently

45. Result

46. 3 days
30 LOC
plus test

47. U no pair?

48. Office setting
Boss
Culture

49. Tools
ScreenHero with Skype
tmux

50. It's an insurance

51. 名為'信賴'的模型
martz ­­松本行弘的程式世界, 2009
I 但是，從前面的的討論也能發現，
會發生這些問題的「大規模開發」，
顯然也不是什麼幸福的狀況。
是不是應該先改善專案內的信賴關係，
直到足以採用Ruby的程度為止。
就算最後決定不使用Ruby也一樣 J

52. Fear

53. How to do
OEREILLYč The Art of Agileĉ Chć ẎćỲ
How they do
PeepCodeč play by play series
bitćlyfWbAÝbH

54. Thank you
any questions?