Coding with an Organized Mind

Transcript

1. Coding with an Organized Mind Jason Swett

2. Overview • The consequences of coding with a disorganized mind,

   benefits of coding with an organized mind • Defining your work: how to break a project into small, discrete tasks • Setting up your work: using a to-do list • Carrying out your work: working tidily

3. About Me

4. None

5. Organized vs. disorganized • Chaos, failure, stress, psychic entropy •

   Order, success, enjoyment, flow

6. Defining the work: how to break a project into small,

   discrete tasks • Breaking a project into user stories • Breaking user stories into tasks

7. Breaking a project into user stories

8. Designs must make sense before work or estimation can start

9. Common project problem: the designs are incomplete and/or logically impossible

10. Usability testing • Leaves design defects no place to hide,

    leaving behind only logically consistent designs • Removes fuel for bikeshedding

11. Example usability testing scenarios • “Winston Yapplezapple calls to schedule

    an appointment for 2:00pm on Monday. Add the appointment to the calendar.” • “Winston Yapplezapple calls back later to reschedule the appointment for 3:00pm. Reschedule the appointment.”

12. Each usability test scenario can become a user story

13. Attributes of a good story • Clear, descriptive title (“Ability

    to schedule appointment”) • It’s obvious what it means for the story to be complete • Not more than a few days’ work

14. Setting up the work: using a to-do list

15. Purpose of the to-do list: to always know, with zero

    ambiguity, the answer to 
 “What EXACTLY am I trying to accomplish right now?”

16. Where to-do list items come from

17. • Lifetime • Year • Month • Week • Day

    • Moment

18. Coarse grain
 —> fine grain

19. Goal example, coarsest grain to finest, least tractable to most

    tractable • Get appointment system working • Add ability to schedule an appointment • Add ability to add a patient to an appointment • Get a patient field to show up in the appointment form

20. Start your day with a “draft” to-do list

21. Example draft to-do list Personal
 - Work on RailsConf talk


    - Van oil change
 - Order spatulas on Amazon Work
 - Ability to save appointment
 - Ability to cancel existing appointment

22. Maintain your list throughout the day

23. Modified to-do list (“expansion” technique) Personal
 - Work on RailsConf

    talk
 - Van oil change
 - Order spatulas on Amazon Work
 - Ability to save appointment
 - - Test for saving appointment (valid case)
 - - Test for saving appointment (invalid case)
 - - Test for saving appointment (schedule conflict)
 - Ability to cancel existing appointment

24. Carrying out the work: working tidily • Focused work sessions

    • Atomic commits • Small, short-lived branches • Small, frequent deployments

25. Focused work sessions • Close email • Close Slack •

    Don’t allow Twitter/FB/etc. notifications on your phone or computer (and preferably just delete the apps from your phone) • Clearly state your current goal and related tasks, using nested levels of granularity

26. Atomic commits • Each commit should be just one unit

    of work • I tend to commit every 5-15 minutes • Commits allow you to periodically clear your mind • Atomic commits make rollback/troubleshooting easier

27. Small, short-lived branches • Branches that live longer than a

    few days are risky (divergence) • The more branches you have, the longer they live, and the bigger they are, the more overhead and confusion they cost • When working on large features, favor feature flags over long-living branches • git-flow is horrible

28. Small, frequent deployments • Same benefits as frequent commits (less

    divergence) • Dev/prod parity

29. Takeaways • Iron out project design flaws using usability testing,

    and make sure every story is crisply defined • Write down everything you’re going to do, and always be able to answer “What am I trying to accomplish right now?” • Work in small units, using atomic commits, frequent integrations and frequent deployments

30. Keep in touch • codewithjason.com • jason@codewithjason.com • I help

    Rails teams implement these and other practices