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
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. 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!