Conscious Coding Practice: the Three Concrete Steps

You feel guilty about not knowing enough "Computer Science." But that isn't what you're still missing in your coding. If you could just pick up any problem and solve it, you wouldn't care if you used a formal-sounding algorithm to do it.

There's a way to get that "fingertip feel" for coding. And it comes from mindful, conscious practice.

Sounds abstract, doesn't it? Instead, it's very simple, specific and concrete. We'll go over the basic steps, the pitfalls, and how to do it. It works whether you're a beginner or an expert. You'll be able to create coding studies for yourself, not just find other people's exercises that are already worked out for you.

This talk is in Ruby. But the technique works with any language, library or paradigm. It's also good for pairing.

Transcript

1. Conscious Coding Practice
   The Three Concrete Steps
   There's a slide link later. You don't need to write frantically. @codefolio
   

   View Slide

2. Who's This Guy?
   I wrote the book "Rebuilding Rails."

   Also a lot about Ruby performance for
   engineering.appfolio.com.
   I've been a pro coder for over 20 years.
   But if you have to care about me
   to understand this, I did it
   wrong.
   And I give out chalk-bear stickers! Ask me after the talk.
   

   View Slide

3. You want to get
   better at coding.
   Faster.
   

   View Slide

4. The Dragon in the Room:
   "The Computer Science Stuff"
   

   View Slide

5. Coding is Practical
   

   View Slide

6. Good Practice

   is Better
   than

   Bad Practice
   (There's a whole "mindful practice" thing
   you can find in books. Practicing well is a
   whole field of study.)
   

   View Slide

7. "Fingertip Feel"
   

   View Slide

8. Coding Exercises
   are... Okay.
   • Somebody experienced has to
   write them
   • Don't usually exercise your
   judgement about what to build
   • Hard to learn things you don't
   know
   • Have to find new ones constantly
   

   View Slide

9. A Better Choice:
   The Coding Study
   I'll tell you where I stole this technique later. It's really good.
   You pick three things: a Tool, a Task and a Purpose.
   You do it for yourself (or pairing.)
   And it's useful for beginners through twenty-year veterans.
   

   View Slide

10. The Coding Study,
    In Simple Steps
    1. Choose and write your Tool, Task and Purpose
    2. Choose how long to work on it
    3. Do the work until done, or until time runs out
    4. Look back: what went well or poorly?
    

    View Slide

11. Definitions: Tool, Task,
    Purpose
    

    View Slide

12. Tool: Your Language,
    Libraries, and So On
    

    View Slide

13. Task: What You Build
    

    View Slide

14. Purpose: Why You're
    Building
    

    View Slide

15. Choosing Your Tool is Easy
    

    View Slide

16. Two Ways to Choose Task
    

    View Slide

17. Choose a Task: Easy Way
    Pick something simple. Pick something you've
    done before, or a simple exercise from online.
    Mostly, this method is... fine.
    

    View Slide

18. Choose a Task: Fun Way
    Observe the world. Pick something, anything.
    Turn it into a system of behaviour.
    (Yes, there will be an example.)
    

    View Slide

19. How to Choose Your Purpose

    (unless you have one already)
    

    View Slide

20. Method 1: What Superpower
    Do You Wish You Had?
    

    View Slide

21. Method 2: What Decision
    Scares You?
    

    View Slide

22. M
    ethod
    3: W
    hat's
    the
    W
    eirdest Thing
    that
    M
    ight Possibly
    W
    ork?
    

    View Slide

23. An Example Coding Study:
    The Merry-Go-Round
    

    View Slide

24. Tool: simple Ruby
    Task: a tiny simulation of kids on a Merry-Go-Round
    Purpose: play with that behaviour (age, strength and pushing)
    to understand it better
    Timebox: 1 hour (for me, then)
    

    View Slide

25. # First half
    kids = [15, 12, 11, 5, 4, 3]
    kids = kids.map { |age|
    {
    age: age,
    push: 3 * (age - 3),
    weight: 5 * Math.sqrt(age),
    cling: 4 * (age - 2),
    }
    }
    

    View Slide

26. # Second half
    speed = 0
    loop do
    oomph = kids.map { |k| k[:push] }.sum
    weight = kids.map { |k| k[:weight] }.sum
    speed += oomph.to_f / weight
    puts "o: #{oomph}, w: #{weight}, s: #{speed}"
    if speed > kids[-1][:cling]
    kids.pop
    if kids.size == 0
    break
    end
    end
    end
    

    View Slide

27. # Second half (expanded a bit)
    speed = 0
    loop do
    oomph = kids.map { |k| k[:push] }.sum
    weight = kids.map { |k| k[:weight] }.sum
    speed += oomph.to_f / weight
    if speed > kids[-1][:cling]
    puts "#{kids.size} little monkeys," +
    " on the merry-go-round..."
    puts "#{kids[-1][:age]} fell off and bumped his head"
    kids.pop
    if kids.size == 0
    puts "No more monkeys on the merry-go-round!"
    break
    end
    end
    end
    

    View Slide

28. Different Purpose,

    Different Results
    (A partial example)
    

    View Slide

29. Tool: simple Ruby
    Task: a tiny simulation of kids on a Merry-Go-Round
    Purpose: Object-Oriented Design
    

    View Slide

30. class Kid
    attr_reader :push, :weight, :cling
    def initialize(age)
    @age = age
    @weight = 5 * Math.sqrt(age)
    @push = 3 * (age - 3)
    @cling = 4 * (age - 2)
    end
    end
    class MerryGoRound
    def initialize(kids)
    # ...and so on
    

    View Slide

31. Seven Guidelines
    (But no rules!)
    Oh? And what if I break them?
    

    View Slide

32. 1: Choose First and Write
    That is:
    Choose your Tool, Task and Purpose first, before you begin
    coding.
    Write them out, in words.
    If broken: feature creep.
    

    View Slide

33. 2: Time Limit
    Choose a time limit. If you're not done by then, stop.
    If broken: long failures where you don't learn
    much and long 'successes' where you keep
    building but stop learning.
    

    View Slide

34. 3: Throw It Away
    When you've finished the exercise, don't use it for anything
    else. You're not producing a finished product.
    If broken: over-engineered prototypes that
    teach you less and take longer to produce; you
    start building to use, not to learn.
    

    View Slide

35. 4: One Idea at Once
    Your Purpose is the idea you're studying. You want it to be one
    idea big, no more.
    If broken: your studies take much longer to
    get started; feature creep; hard to finish.
    

    View Slide

36. 5: Simple, with Layers
    Start your code very simply and build up in layers. Debug
    statements help, too. Since you're doing development from
    scratch on each study, get the benefits of starting from scratch.
    If broken: long startup for each study; dread
    of starting; less writing, more debugging.
    

    View Slide

37. 6: Work from Life
    Look at a real system in the real world. Staring at real
    complexity and letting it surprise you is the hidden purpose
    here.
    If broken: you only refine what you already
    know instead of learning something nobody
    (yet) knows; you lose your best cheat.
    

    View Slide

38. 7: Break Rules
    Nothing is set in stone here. Break all these rules when it makes
    sense. Or just to see what happens!
    (Or un-break!)
    This is play, not work. Break every rule that
    gets in the way of learning. Or playing!
    

    View Slide

39. The Fun Way (Again)
    

    View Slide

40. Pair Coding Studies
    

    View Slide

41. Pair on defining the task and purpose, not just writing the code
    Start "flat-footed," don't bring in a fully-developed idea
    Brainstorm together before typing
    One person on the keyboard at once
    Do something small; then swap roles and continue or restart
    

    View Slide

42. Where I Stole This
    Who else has too many tools, and must learn by practice? Artists.
    They call this a "life study." They choose their tasks from life --
    drawing people, landscapes, fruit, etc. They have many purposes
    -- colour studies, composition studies, shading studies...
    I explain differently for the coding crowd, but only a little.
    

    View Slide

43. Where Next?
    @codefolio
    Slides: https://bit.ly/rubyconf2019-gibbs
    Ask me in person
    for chalk teddy
    bear stickers!
    You can find more blog posts about this
    at https://codefol.io and an in-process
    book at software-technique.com.
    

    View Slide

44. Questions?
    @codefolio
    Slides: https://bit.ly/rubyconf2019-gibbs
    Ask me in person
    for chalk teddy
    bear stickers!
    

    View Slide