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

Conscious Coding Practice: the Three Concrete S...

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
  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.
  3. 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.)
  4. 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
  5. 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.
  6. 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?
  7. 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.
  8. Choose a Task: Fun Way Observe the world. Pick something,

    anything. Turn it into a system of behaviour. (Yes, there will be an example.)
  9. 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)
  10. # 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), } }
  11. # 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
  12. # 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
  13. Tool: simple Ruby Task: a tiny simulation of kids on

    a Merry-Go-Round Purpose: Object-Oriented Design
  14. 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
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. 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!
  22. 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
  23. 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.
  24. 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.