Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Coding with an Organized Mind

Coding with an Organized Mind

4fa58c43c72a15d2d560ffd931fbe9bb?s=128

Jason Swett

May 01, 2019
Tweet

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