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

Conscious Coding Practice: the Three Concrete Steps

Noah Gibbs
November 18, 2019

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.

Noah Gibbs

November 18, 2019
Tweet

More Decks by Noah Gibbs

Other Decks in Programming

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