Finding Developer Flow (with new insights on TDD)

Sometimes everything just clicks, solutions just come to you and as you quietly tap away you feel almost at one with the computer, you're in the zone. At other times, nothing seems to make sense, you've been struggling with this one issue for hours and not even StackOverflow seems to know what the problem is. You feel like your brain is about to explode. Why even do this?! You're in the chasm.

Join Richie (@richiekhoo) & Dan (@danieldraper) as we explore what is "Developer Flow" and how it affects your productivity as a programmer.

This workshop focussed on the art of effective Test Driven Development and bought some new clarity delving into and unpacking Uncle Bob's awkwardly named technique of the Transformation Priority Premise.

Using multiple principals gleaned from many of the greats (and a few of our own ideas too) we explored an approach to writing code whereby you can really attempt to stay in the zone and work with greater easy and productivity.

Further resources related to this workshop can be found here:
https://gist.github.com/evolve2k/5f8ef8bb7a231a57e94b

Transcript

1. Finding Developer Flow Richie Khoo and Dan Draper
2. What is Developer Flow?
3. A state where you are continuously clear on the next thing you want to achieve and the next step you will take towards achieving it. Devoid of confusion and frustration. Developer Flow
4. Uncle Bob’s Rules of TDD 1. You are not allowed to write any production code unless it is to make a failing unit test pass. 2. You are not allowed to write any more of a unit test than is sufficient to fail. 3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test. Source: http://www.butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
5. • Write a program that replicates the children's game "Fizz Buzz". • Your program should take an integer number and apply the following rules: • If the number is a multiple of 3 then return a string "fizz" • If the number is a multiple of 5 then return a string "buzz". • Numbers that are both multiples of 3 and 5 (e.g. 15) should return the string “fizzbuzz”. Exercise 1 TDD FizzBuzz 1. You are not allowed to write any production code unless it is to make a failing unit test pass. 2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. 3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test. Rules of TDD
6. Common criticisms of TDD 1. Time consuming. 2. Overkill when used to test framework driven code. 3. Good in theory but hard to really apply in practice. 4. Takes a lot of time to master and know ‘what to test’ and how to test in the TDD way. 5. Often you write a test and then it really doesn’t inform you of what to do next and you end up doing what you started off doing anyway.
7. Transforming Code
8. So, about Refactoring “Refactoring is the process of restructuring existing computer code (changing the factoring) without changing its external behaviour. Refactoring improves nonfunctional attributes of the software.” Technically refactoring is very specific, specs should stay green as you refactor. If your tests turn red at anytime this is a smell that you are likely not factoring in clean chunks.
9. Transformations Refactoring have counterparts called Transformations. Refactoring are simple operations that change the structure of code without changing it’s behaviour. Transformations are simple operations that change the behaviour of code. Transformations can be used as the sole means for passing the currently failing test in the red/green/refactor cycle. — Uncle Bob Martin
10. ‘Transformation Priority’ Premise (TPP) “Transformations have a priority, or a preferred ordering, which if maintained, by the ordering of tests, will prevent impasses, or long outages in the red/green refactor cycle.” - Uncle Bob Martin
12. Tip #1 Use Guard Clauses Corey Haines likes to use a Guard clause to help him reset his code to the return a nil state as a nice easy way to get back to the bottom of the Transformation Priority staircase. A guard clause is just an explicit return statement at the top of a method. It is so called as it is said to guard the rest of the contents of the method.
14. Tip #2 Start with the nil case Handling the nil input or empty input cases is often a good place to start and also ensures you cover an important edge case by design.
15. • Write a program that replicates the children's game "Fizz Buzz". • Your program should take an integer number and apply the following rules: • If the number is a multiple of 3 then return a string "fizz" • If the number is a multiple of 5 then return a string "buzz". • Numbers that are both multiples of 3 and 5 (e.g. 15) should return the string “fizzbuzz”. Exercise 2 Fizz Buzz Revisited 1. You are not allowed to write any production code unless it is to make a failing unit test pass. 2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. 3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test. Rules of TDD
16. 4 Rules of Simple Design 1. Passes the tests 2. Expresses every idea we need to express 3. Says everything once and only once (no duplication) 4. Has no superfluous parts Kent Beck’s Simply Designed Code:
17. Source: http://xkcd.com/974
18. • Given an integer number between 0 and 9999 return a string representing the number in words. • For example: 1274 should return "one thousand two hundred and seventy four” Exercise 2 Number to Words 1. You are not allowed to write any production code unless it is to make a failing unit test pass. 2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. 3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test. Rules of TDD
19. Coding Workflow How can you find focus and efficiency by eliminating waste?
20. A few things worth mentioning • Guard or Spring - Auto run your tests when you save. • betterspecs.org - A library of nice spec examples • Love your editor • Customise your bash/terminal settings • Learn to love your autocomplete • Dash App • Getting fast at reading documentation • ruby-toolbox.com • Gems (better-errors, pry, rollbar, x-ray) • Git-flow
21. What can you do to maintain developer flow?
22. A few things worth mentioning • Finding your zone • Staying productive - Pomodoro Time (eg. 25 min time boxes or 50/10), trello etc. • Audio • Eliminating distraction (Airport mode) • Workspace • Coffee/sugar/alcohol intake • Fitness • The Sleep Paradox • Mental Health (stress, emotion, you poor poor thing,) • Time away from electronic devices
23. Quality Code vs Perfectionism vs Pragmatism
25. Sandi Metz Rules of Practical Object Oriented Design 1. Classes can be no longer than one hundred lines of code. 2. Methods can be no longer than five lines of code. 3. Pass no more than four parameters into a method. Hash options are parameters. 4. Controllers can instantiate only one object. Therefore, views can only know about one instance variable and views should only send messages to that object (@object.collaborator.value is not allowed).
26. Rule Zero or ‘When you are allowed to break the rules’ You can break a rule when you can convincingly argue for why it should be broken such that another programmer agrees that your argument is convincing and that the rule should be broken at that time.
27. • Clone starter code from http://github.com/coderdan/flow-api • Create an API method which responds to a GET request to / users and returns a JSON formatted array of User objects. • Each user object should have at least a name attribute but can optionally include other attributes such as email or ID. • The API should require authorization by way of a simple key and order the users by name ascending. • For example: Exercise 3 JSON API 1. Classes can be no longer than one hundred lines of code. 2. Methods can be no longer than five lines of code. 3. Pass no more than four parameters into a method. Hash options are parameters. 4. Controllers can instantiate only one object. Therefore, views can only know about one instance variable and views should only send messages to that object (@object.collaborator.value is not allowed). Practical Design Rules 1. Runs all the tests 2. Expresses every idea we need to express 3. Says everything once and only once (no duplication) 4. Has no superfluous parts Simple Design Rules
28. • Apply pagination rules to the API method in the previous exercise. Your API should paginate if there are more than 10 records. Exercise 3A PAGINATION 1. Classes can be no longer than one hundred lines of code. 2. Methods can be no longer than five lines of code. 3. Pass no more than four parameters into a method. Hash options are parameters. 4. Controllers can instantiate only one object. Therefore, views can only know about one instance variable and views should only send messages to that object (@object.collaborator.value is not allowed). Practical Design Rules 1. Runs all the tests 2. Expresses every idea we need to express 3. Says everything once and only once (no duplication) 4. Has no superfluous parts Simple Design Rules
29. Retrospective for the day
30. Resources • Resources Gist for this workshop including Dan live coding todays examples. • https://gist.github.com/evolve2k/5f8ef8bb7a231a57e94b/edit • Videos & articles by Corey Haines, Sandi Metz, Katrina Owen. • Practical Object-Orientated Design in Ruby by Sandi Metz • The Ruby Rogues Podcast (https://devchat.tv/ruby-rogues) • Kent Beck (http://www.c2.com/cgi/wiki?KentBeck) • Uncle Bob (http://www.c2.com/cgi/wiki?UncleBob) • Code Kata’s (http://codekata.com, web search for more) • Reach out to us, we’d love to hear how you go! • Richie Khoo (@richiekhoo) • Dan Draper (@danieldraper) Where to next?