1. LESSONS FROM A CODING
VETERAN

2. TOM HUGHES-CROUCHER
@sh1mmer

4. Stuff to be “proud of ”
BSc 1st Class (Hons) Computer Scalable Server-Side Code with JavaScript
Science
Helped write two W3C standards
Written code for:
NASA
Tesco
Channel 4
Node Up and Running
Three Telecom
Tom Hughes-Croucher
Yahoo!

5. 3 RULES TO LIVE BY

6. RULE 1.
COMPLEXITY IS THE ENEMY

7. WHAT IS COMPLEXITY?

8. COMPLEXITY IS...

9. ...TOO MANY FEATURES

10. ...UNINTELLIGIBLE CODE

11. ...CODE THAT DOES THINGS
MORE THAN ONE WAY

12. ...TOOMUCHCODETHATJUSTGOE
SONANDONANDRUNSTOGETHER

13. COMPLEXITY IS...

14. ...ANYTHING THAT
REDUCES UNDERSTANDING

15. WHY IS UNDERSTANDING
SO IMPORTANT?

16. “BUILD TWITTER”

17. What is Twitter?
140 character micro-blogging service
AJAX web site
API
Scalability (sort of)
etc

18. “BUILD TWITTER” IS NOT
UNDERSTANDABLE

19. COMPUTERS REQUIRE
PERFECT INSTRUCTIONS

20. PERFECTION REQUIRES
UNDERSTANDING

21. RULE 1A.
HAVE A CLEAR GOAL

22. TANGIBLE OBJECTIVE

23. IT IS YOUR JOB AS DEVELOPER
TO ACCEPT THE REQUIREMENTS

24. CLEAR OUTCOME

25. SUCCESS = ??

26. A WAY TO MEASURE
SUCCESS

27. TDD

28. PUBLIC API

29. AGILE ALLOWS YOU TO FAIL
FAST

30. FAILING FAST ALLOWS
REDUCE COST OF DEFINITION

31. RULE 1B.
WRITE CODE YOU* CAN UNDERSTAND
* and your team

32. function(a,b,c){return{pub:function(d,e){for(c in a)if
(c.split("-")[0]==d)a[c](e)!==!1||delete a[c]},sub:function
(d,e){a[d+--b]=e}}}({},0)

33. function(
a, // the subscription object
b, // the current event number
c // (placeholder)
){
return { // return an object, with
pub: function( // a "pub" function that takes
d, // a channel name and
e // a message value,
){ // and
for( // for each
c // subscriber
in a // in the subscription object,
) if ( // if
c // its name, with the event number discarded
.split // by splitting it
("-") // with a hyphen and
[0] // taking only the first part,
== d // is equal to the published channel
) a[c](e) // call the subscriber. and if
!== !1 || // the value returned is false
delete a[c] // unsubscribe by removing the subscriber, and
},
sub: function( // a "sub" function that takes
d, // a channel name and
e // a subscriber function
){ // and,
a[ // on the subscriptions object,
d + // sets the name of the channel appended with
--b // a hyphen and the decremented event number, to
] = e // the function passed.
}
}
}( // auto-run with
{}, // the subscription object
0 // and event id.
)

34. LIKE “REAL” CODE

35. TERSE != BETTER

36. LANGUAGES ARE
EXPRESSIVE

37. //this is JavaScript
var isTrue
if (true) {
isTrue = true
}

38. //still JavaScript
var isTrue = true ? true : undefined

39. ANOTHER EXAMPLE

40. var c = Math.floor(b)

41. var c = ~~b

42. YOUR BRAIN HAS MORE TO
REMEMBER

43. FRENCH VS. ENGLISH

44. THERE ARE MANY REAL
PATTERNS TO REMEMBER

45. DON’T ADD SYNONYMOUS
PATTERNS

46. RULE 1C.
PICK SOME CONVENTIONS

47. BE OPINIONATED
AS LONG AS YOU STICK TO IT

48. PLACE { AFTER )

49. function buildObjectLiteral()
{
return // this returns!
{
"someProperty": "hello"
};
}

50. STUPID ERROR

51. STUPID CODE

52. IF YOU PICK A GOOD STYLE YOU
WON’T WRITE STUPID CODE

53. SEMI-COLON FIRST
JAVASCRIPT

54. // return whatever was printed
function showFields (data, version, fields) {
var o = {}
;[data,version].forEach(function (s) {
Object.keys(s).forEach(function (k) {
o[k] = s[k]
})
})
return search(o, fields.split("."), version._id, fields)
}

55. YOU CAN PICK ALL
KINDS OF STYLES

56. MOST IMPORTANT IS
CONSISTENCY

57. RULE 1D.
USE ABSTRACTION WISELY

58. SIMPLE VS COMPLEX

59. Browser Server

60. ABSTRACTION

61. GET
Browser Server
200 OK

62. TCP (Slow start)
Browser Server

63. ABSTRACTION AIDES
UNDERSTANDING

64. ABSTRACTION MAKES
THINGS SIMPLE

65. WHEN DOING COMPLEX THINGS
ABSTRACTION MAKE THINGS
MORE COMPLEX

66. //node.js style JavaScript
query = mysql.query('SELECT * FROM data');
query.on(‘result’, function(result) {
for(var i=0;i<length;i++) {
var row = result.rows[i];
//do something with the row
}
});

67. //threaded style JavaScript
result = mysql.query('SELECT * FROM data');
for(var i=0;i<length;i++) {
var row = result.rows[i];
//do something with the row
}

68. var x = "I am a string"
~1ns Running 1 instruction
2ns Data from l1 cpu cache
5ns Data from l2 cpu cache
80ns Data from ram

69. query
Server mySQL
result

70. result = mysql.query('SELECT * FROM data');
~100ms Time to run a query in database
50ms Time to roundtrip query over the network

71. LOCAL VARIABLE

73. REMOTE OPERATION

75. 100 Blue Whales
Cat

76. TOO MUCH ABSTRACTION

77. USE ABSTRACTION WELL

78. MODULARISATION

79. BLACK BOXES ARE EASY TO
UNDERSTAND

80. DRIVING A CAR ISN’T
ABOUT COMBUSTION

81. WELL DEFINED APIS
PROVIDE ABSTRACTION

82. RULE 2.
DON'T OPTIMISE TOO SOON

83. OPTIMISATION ISN’T JUST
ABOUT PERFORMANCE

84. RULE 2A.
1ST DRAFT, 2ND DRAFT

85. YOU AREN’T THE
KWISATZ HADERACH

86. YOU HAVE TO WRITE CODE
TO LEARN WHAT YOU NEED

87. THE FIRST VERSION ALWAYS
SUCKS

88. BACK TO AGILE
DESIGNED TO “FAIL”

89. BUILD IN TIME TO REWRITE
YOUR CODE

90. ESTIMATE
+ 1/3 + 1/4

91. RULE 2B.
WRITING COMPLEX CODE IS
OK WHEN YOU UNDERSTAND IT

92. RULE 2B.
WRITING COMPLEX CODE IS
OK WHEN YOU UNDERSTAND IT

93. RULE 2B.
REWRITING CODE TO BE MORE COMPLEX
IS OK WHEN YOU UNDERSTAND IT

94. SPEED

95. Math.floor(3.141) //3
~~3.141 //3 but faster

96. typeof foo === 'number' && !isNaN(foo) && foo !== Infinity
? foo > 0 ? Math.floor(foo) : Math.ceil(foo) : 0;
// ~~var in JavaScript explained by James Padosley
// side note (this is why I, personally, dislike ? )

97. ~~VAR IS LIKE MATH.FLOOR
FOR +INTEGER

98. RELIABILITY

99. RULE 2C.
DOCUMENT THE HECK OUT OF
OPTIMISATIONS

100. // Using ~~ to floor and generate a random #1-6
(~~(Math.random()*6))+1

101. RULE 2D.
OPTIMISE WITH TOOLS IF POSSIBLE

102. JSLINT

103. YUI/DOJO COMPRESSOR
CLOSURE COMPILER

104. CLANG

105. RULE 3.
ALL RULES ARE MADE TO BE BROKEN

106. WE ALL WORK FOR
BUSINESSES

107. REALITY BITES

108. DEAL WITH IT

109. RULE 3A.
IT’S OK TO WRITE SHITTY CODE
FOR A DEADLINE

110. YOU HAD A DEADLINE

111. YOU DRANK TOO MUCH
COFFEE

112. STAYED UP ALL NIGHT

113. YOU UPSET YOUR
[GIRL/BOY]FRIEND

114. THE CODE YOU WROTE
SUCKED

115. SUUUUUUUUUUCCCKKKEED!

116. BUT IT WORKED

117. SO. COOL.

118. RULE 3B.
BREAKING RULES INVOLVES CLEANUP

119. SOMEONE* WILL HAVE TO
MAINTAIN THAT CODE
* maybe you

120. SHORTLY AFTER YOU
WROTE BAD CODE

121. YOU WILL...

122. …

123. ...WHAT DOES THIS DO?

124. CLEAN UP CODE ASAP

125. SPRINT 1 : CODE THAT SUCKS
SPRINT 2 : CODE THAT DOESN’T

126. RULE 3C.
RULE BREAKING ISN’T SUSTAINABLE

127. IT’S CALLED
TECHNICAL DEBT

128. EVERY OPEN SOURCE
PROJECT YOU FORK

129. EVERY FUNCTION THAT
ISN’T DOCUMENTED

130. EVERY LINE THAT WAS ONLY
WRITTEN ONCE

131. TECHNICAL DEBT IS LIKE
OTHER DEBT

132. THE MORE OF IT YOU HAVE
THE HARDER IT IS TO FIX

133. RULE 3D.
IF YOU KEEP CHEATING GTFO

134. ENVIRONMENTS THAT DON’T
CARE ABOUT GOOD CODE

135. DON’T CARE ABOUT YOU!

136. STRESS IS NOT GOOD FOR
LIFE

137. CODING WITH RULE 1 AND RULE
2 IS CODING FOR THE FUTURE

138. CODING WITH RULE 3 IS
CODING FOR NOW

139. SHORT-TERM THINKING DOESN’T
YIELD LONG-TERM RESULTS

140. Summary
1. Complexity is the enemy 2. Don't optimise too soon
1a. Have a clear goal 2a. 1st draft, 2nd draft
1b. Write code you can 2b. rewriting code to be more
understand complex is ok when you
understand it
1c. Pick some conventions
2c. Document the heck out of
1d. Use abstraction wisely optimisations
2d. optimise with tools if
possible

141. QUESTIONS?
@sh1mmer