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

More Decks by Noah Gibbs

Other Decks in Programming


  1. Conscious Coding Practice The Three Concrete Steps There's a slide

    link later. You don't need to write frantically. @codefolio
  2. Who's This Guy? I wrote the book "Rebuilding Rails."

    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.
  3. You want to get better at coding. Faster.

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

  5. Coding is Practical

  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.)
  7. "Fingertip Feel"

  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
  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.
  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?
  11. Definitions: Tool, Task, Purpose

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

  13. Task: What You Build

  14. Purpose: Why You're Building

  15. Choosing Your Tool is Easy

  16. Two Ways to Choose Task

  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.
  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.)
  19. How to Choose Your Purpose
 (unless you have one already)

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

  21. Method 2: What Decision Scares You?

  22. M ethod 3: W hat's the W eirdest Thing that

    M ight Possibly W ork?
  23. An Example Coding Study: The Merry-Go-Round

  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)
  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), } }
  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
  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
  28. Different Purpose,
 Different Results (A partial example)

  29. Tool: simple Ruby Task: a tiny simulation of kids on

    a Merry-Go-Round Purpose: Object-Oriented Design
  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
  31. Seven Guidelines (But no rules!) Oh? And what if I

    break them?
  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.
  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.
  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.
  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.
  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.
  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.
  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!
  39. The Fun Way (Again)

  40. Pair Coding Studies

  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
  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.
  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.
  44. Questions? @codefolio Slides: https://bit.ly/rubyconf2019-gibbs Ask me in person for chalk

    teddy bear stickers!