None of us would be very good developers if we never had arguments about The Best Way to Do Things. But I've had enough silly arguments about tabs-versus-spaces to last me the rest of my life. When should we stop arguing and start writing code? I'll share specific tactics for keeping code arguments evidence-based, respectful, and drama-free. Given at Refresh Austin on September 11, 2012.

1. How to argue
about Code

2. How to argue
about Code
(on the internet)

3. Why?

4. internet
+
open-source software
+
GitHub

5. Our arguments
should be purposeful.

6. ideal: scientific research

7. reality: political debate

8. “In science it often happens that scientists say, ‘You know that’s a
really good argument; my position is mistaken,’ and then they
actually change their minds and you never hear that old view
from them again. They really do it. It doesn’t happen as often as
it should, because scientists are human and change is sometimes
painful. But it happens every day. I cannot recall the last time
something like that happened in politics or religion.”
Carl Sagan (1987)

9. “Who the hell are you?”

10. No one of consequence.

11. “Where do you get off
censoring me, you fascist?”

12. I don’t.

13. Motives for having
a code argument:

14. to troll

15. to feel awesome
about yourself

16. to persuade others
to your way of thinking

17. to understand
the subject better

19. An argument has three goals.

20. Goal 1:
It should produce
a wise agreement, if possible.

21. Goal 2:
It should be efficient.

22. Goal 3:
It should not damage
the relationship between parties.

23. Our case study:

24. the original ticket:
https://github.com/twitter/bootstrap/issues/3057

25. Tactics for arguments:

26. Tactic 1:
Separate the people from the problem.

27. bad:
the objective nature of the problem
how humans feel about the problem

28. bad:
the objective nature of the problem
how humans feel about the problem

29. good:
the objective nature of the problem
how humans feel about the problem

30. the original ticket:

31. response from Jacob Thornton (@fat):

32. comments one and two:

33. comment three:

34. comment four:

35. (this is why you should be nice)

36. Tactic 2:
Focus on interests, not positions.

37. Tactic 3:
Invent options for mutual gain.

38. Tactic 4:
Insist on objective criteria.

39. (standards)

40. (benchmarks)

41. THE SELECTOR WARS

46. jsPerf
(jsperf.com)

47. “So what should I do?”

48. How to think:

49. Retain a willingness
to be convinced

50. Imagine where others
are coming from

51. Account for your own taste

52. Account for your own emotions

53. John Resig
“I learned some things about jQuery today…”

54. Recognize derails as they happen

55. Ahead:
An inventory of the discussions
taking place in a single closed ticket
on Twitter Bootstrap’s GitHub project

56. main question:
Should Bootstrap change a
syntactic shortcut that does not
minify properly in JSMin?

57. main question (broadened):
Should library authors care
about interoperability with JSMin?
Or should JSMin accommodate code
that Crockford finds distasteful?

58. derails and meta-discussions perpetuated
by at least two of the 143 ticket participants:

59. “People who don’t use
semicolons are
JavaScript hipsters.”
“No, people who are
fanatical about
semicolons are just
spreading FUD.”

60. “@fat is being a jackass
and a bad project
steward.”
“No, people like you are
bitching about a library
they got for free.”

61. “Semicolon or not, that line
should still be rewritten.”

62. “JSMin sucks anyway.
People should use
some other minifier.”

63. “Who cares about minification?
Everyone’s got a fast connection now.”

64. “We’ve now spent like a hundred comments
arguing about a single semicolon
that @fat is too stubborn to add.”

65. “We are bikeshedding
like hell up in here.”

66. “Stop posting on this ticket! GitHub sends me a
notification with each new comment.”

67. also: trolls

68. also: wisecracks

69. meanwhile:

70. Staying on topic
requires moderation.

71. How to speak:

72. Be nice.

73. Speak with surgical precision.

74. E-Prime

75. “Any proposition containing the word ‘is’ creates
a linguistic structural confusion which will
eventually give birth to serious fallacies.”
Alfred Korzybski,
Semanticist

76. “PHP is awful.”

77. “PHP is awful.”
“Whenever I use PHP, I end up longing
for the logical API and unsurprising
behavior of Ruby or JavaScript.”

78. “jQuery is easier to use
than MooTools.”

79. “jQuery is easier to use
than MooTools.”
“I find jQuery more intuitive
to use than MooTools.”

80. Be honest in your
characterizations.

81. “What if the other side
won’t play along?”

82. Don’t rise to the bait.

84. Emphasize the contrast between
your tactics and your opponents’.

85. Nicole Sullivan,
“Don’t feed the trolls”
http://bit.ly/JWksIU

86. In short: Postel’s Law

87. “Why do I have to
take the high road?”

88. (fin)