00:00:12.190
All right, conscious coding practice: the three concrete steps. For any of you that think I'm Abdi Grimm, I have bad news; he's in the next room over.
00:00:25.580
Who am I? Some of you know I wrote the book "Rebuilding Rails." For those of you who didn’t know that, congratulations, now you do! I also write a bunch of blog posts on Ruby performance. I've been doing this for a very long time and teaching people about this for a long time as well.
00:00:32.300
However, if you have to care about how awesome I am, then I didn’t do this right. So with luck, this should be mostly self-explanatory. The bits that aren't self-explanatory are the kind of things where you'll eventually try it both ways and decide whether I'm more or less right. I also have bear stickers, so feel free to come up after the talk or grab me at any point during RubyConf and ask for a bear sticker—I have a bunch.
00:00:48.649
Oh, also, I love questions! There’s a pretty good chance that any question you have, somebody else does too. Feel free to yell them out! I also talk really fast; I’m sure this is a shock to those of you who've been listening for the last 30 seconds. If I'm talking too fast, it would be wonderful if you say, 'Slow down!' because you're not the only one thinking it—others may just be too polite to say it. I appreciate it if you would.
00:01:08.990
Alright, so I've talked about me, and that's never the interesting part of the talk. Let's talk about you for a second. Instead of coding, which is what I'm talking about, you could say software development or software engineering, or whatever it is you personally call that thing you do where you write code.
00:01:37.250
But now, that thing you do when writing code – I don’t mean algorithm design or reading books about it. I mean the bit where you actually write the code down. I assume you want to get better at that, and I assume that's why you're sitting in this room today. If, for some reason, you're here by accident, I hope you decide to do that! A lot of the time, you can't cover this topic without hitting this first: so many engineers have as their personal Bugaboo—something that prevents them from being great at coding—the computer science stuff.
00:02:58.150
They mean different things by it, but that's the phrase many people use. This isn’t just something that bootcamp participants say; even those who graduated from college many years ago use the same phrase. Usually, you mean something kind of academic by that, and you may have met good programmers who are not good academics. For them, that wasn’t the obstacle, so I'd like you to, for today, consider suspending disbelief for a little while and assume that if they can do it, you probably can too. If it didn't stop them, it probably won't stop you either.
00:03:39.940
If you're afraid of the computer science stuff, keep in mind there's a lot of other stuff besides that. Coding is practical; you get better at it by doing it, not really by just reading about it. You can know all the algorithms and read extensively about all this and still sit down at your IDE and stare for an hour at a for loop that just isn’t working. If it can fail in that regard, it can also succeed in that regard.
00:04:13.480
When I say you get better at it by practicing, good practice is better than bad practice. There are a whole set of books about the kind of practice you should do for all sorts of skills. I don't know many books focusing specifically on programming, but there are a bunch of them about practice in general. The good practice is crucial, and how you practice is important. That’s part of the reason you get into these disputes at work where everyone wants to use their favorite library or what they prefer to do because there’s the code you write for the business and the business wants you to write boring, profitable code.
00:04:52.760
Of course, you’d like to write code that helps you get better at programming the fastest. Part of this struggle, and the wonderful thing about it, is that it happens because the people around you—just like all the other programmers you work with—really hunger to get better. Business code only gets you so far. Now I say it's not the academics; it’s not that.
00:05:41.950
What is it then? It's that you want to approach a problem, pick up the problem, make progress on it, and get it solved. What you want isn’t knowledge of the algorithm; it's the ability to approach a new problem, structure it in your head, and write it. You want that to feel straightforward. The way you get to that point is through practice, specifically mindful, careful, repeated practice. A lot of practice, but the core of it is still practice!
00:06:21.270
Some of you may be thinking, 'Ah, he's here to point me at one of the code exercise sites.' Coding exercises as they exist today are fine; they're not bad, and I'm not going to tell you not to do that, but there are specific things they do poorly. One is that you need someone experienced to write them, usually someone more experienced than you, and you need a good teacher to write them. You need to be reasonably certain you have a good teacher for the exercises, as seen in Sandy Matz's book "99 Bottles of Object-Oriented Programming".
00:07:09.710
Many of you have read it, and many more have heard of it. It’s amazing partly because an extremely experienced developer who's also a good teacher created it and put a lot of effort into it! The vast majority of coding exercises are not from that caliber. Generally speaking, these exercises do not challenge your judgment. They don’t ask you to choose what to build, and that’s a huge part of our job.
00:08:04.130
They also don’t really help you learn things you don’t already know. The standard coding exercises lack variety, and once you repeat the same one, it only provides limited value. So when I say coding exercises are okay, that's what I mean.
00:08:39.290
In contrast, there’s a discipline that has most of the same teaching problems we do and has a very standard exercise that we can borrow completely. I’ll tell you how to do this, and we’ll go over examples and guidelines. To do this, pick three things: you'll choose a tool, a task, and a purpose. As we discuss this, you can do it for yourself or in pairs.
00:09:30.920
You don’t need a teacher to administer this as an exercise; you don’t need someone to carefully evaluate where you’re at. This is something you can do independently or with a partner. This method is useful from the point you can put a few loops together, and it scales well for up to twenty years of professional practice. I’ve met people with more experience than me who use almost exactly this technique, so I’m pretty sure it lasts beyond that.
00:10:20.130
In simple steps, you choose your tool, task, and purpose, write them down, pick a time box for the specific exercise, note how long you’re going to work on it, do it until you’re done or until time runs out, and finally you look back on it. There’s a caveat; some of these steps are tricky. I don't expect that by the end of this slide, you’ll all be able to do it, but...
00:11:07.870
If you're taking photographs or anything else... don’t worry about not seeing everything! So let’s define terms: tools are fairly straightforward. You probably have a go-to language or library that you tend to pick for new projects, and I’m not going to try to convince you otherwise. When using a new tool, you likely want a familiar task and purpose; when you’re choosing a new task and purpose, you probably want a familiar tool.
00:12:21.420
It’s not hard to pick tools; you can do something you’ve already done in a new language—great! That’s a way to learn a new language myself, or choose a language you already know well. Tools are the easier part. The task is what you’re building, which is provided by normal coding exercises. Things like “coding challenge of the week” are examples.
00:12:54.460
We can talk about ways to choose a task for this, but the purpose—probably less familiar—is the reason why you’re doing the exercise. It’s what you hope to learn, and it defines the point of the exercise. Even if you already know your tool and your task, your purpose should affect the way you build it. We’ll talk about how to choose that, but keep in mind: the purpose gives meaning to the rest of it!
00:13:45.940
So we talked about how choosing a tool is easy. You either pick a tool specifically to familiarize yourself with a new one or use a common one. Let's discuss choosing a task: the easy way is to pick something simple or something you've done before. I don’t literally recommend Fibonacci, even though that’s on the slide, but you know, if you build something like a music organizer that reads through your files, organizes them into playlists, or something, there are many small tasks that are good...
00:14:33.660
I find small tasks like the music file one more appealing than coding challenges centered around algorithms, which are hard to get excited about. I assume it’s no better for other folks in this room, but it’s fine—you can pick a task you don’t care about, and that’s okay! Now, let's discuss the fun way to choose a task.
00:15:29.340
The world is a giant mountain of ludicrous complexity. Literally anywhere you look, you could describe it in detail, but you’d die before finishing. Everything in the world is a fountain of limitless complexity, so if you’re searching for complexity, there’s no shortage. Finding something in the world and coding it means you have to simplify a complex system into a smaller set of rules.
00:16:34.810
As a coder, that’s your job! If you’re a professional coder, this should be quite familiar to you. We're going to go through examples shortly because I think that's an interesting way to approach learning as well. So how do you choose your purpose? Well, you may already know what you want to learn, and that's fabulous! Don’t let me talk you out of it.
00:17:37.060
But just in case you don't know what you want to do, or if your goal is simpler—like wanting to get better at programming, which is a great goal—let's talk about some purposes that will help you. Here’s one: what superpower do you wish you had? Is there someone whose abilities you wish you could replicate? If you want to get better at a specific skill, you can choose that as your purpose.
00:18:27.740
For example, if you're impressed by colleagues who can design NoSQL architectures, you can make your purpose get better at using Redis! Sorry, using Reddit would be a different exercise! However, you can choose something someone else can do—that's not a bad way to improve. Many of my improvements came from looking at others and asking myself, 'How do they do that?'
00:19:23.230
Another way to choose a purpose is to consider what decision scares you in your projects, whether personal or professional. There is probably something you look at and think, 'Maybe I’ll use that library?' If you're unsure about something, you kind of avoid it. So, why not build a little prototype? You don’t have to create a full solution immediately. Instead, work towards solving your problem incrementally.
00:20:17.520
For instance, if you're curious whether a specific API method will work well, build one that's similar but outside of your complex project, and then play with it for a while. You might end up with a solution, or you could continue doing trials to gather more insights.
00:21:01.400
Lastly, consider the weirdest thing that might possibly work. If you try to mimic someone else, you'll get better in that context. If you solve a problem, you’ll become better at that too. If you choose something random and do it, you may uncover insights nobody knows. Many fine best practices exist, and you can break those best practices a lot for preference, discovering what happens when you mess it up. It’s a great experience!
00:21:55.850
One of the things that makes me happiest about Ruby on Rails is how it used the principle of 'Don't Repeat Yourself' (DRY) in what seemed to be ridiculous ways. At first, it seemed ludicrous to relate class names to their database table names! You can often find valuable insights if you stretch these principles to their limits.
00:22:54.150
Now, I've been waxing poetic about abstract concepts, which is fine, but you may get tired of that. Let's use some examples! So, I was out with my kids at a park watching a group of children play on a merry-go-round, my kids included. You can always learn by observing, especially with people, and I found it interesting how smaller kids wanted to be pushed on the merry-go-round but couldn’t push themselves as hard as they wanted.
00:23:53.570
The older kids were willing to push the younger ones, sometimes in ways that were playful, but sometimes they ended up flinging the younger ones off! As you watch these interactions, you begin to grasp various systems at play and how complex interactions can be—just when you think you’ve figured out the rules, the kids change their behaviors on a whim. The world is utterly fascinating!
00:24:58.470
Let's turn this into a coding study! Here's what I mean by the fun way to choose a task. I previously mentioned how you'd write things down in advance, so let's do that. Tool: simple Ruby program; Task: a tiny simulation of kids on a merry-go-round; Purpose: to play with the behaviors of kids, such as pushing and hanging on.
00:25:45.170
I set myself a time box of about an hour; the times you'll hear me talk about are quite short. This is partly because I’m an old coder with a lot of experience, but it’s also due to the fact that if you get stuck for too long on any one task, you’re not truly learning. So, it can be beneficial to limit the time you spend on each part.
00:26:19.640
So, I started by thinking about what I’d like to observe based on the kids I saw that day in the park, comprising kids of similar ages: twelve, eleven, five, four, and three. I created a basic structure for each one: how old they are, how hard they can push, their weights, and how tightly they are clinging onto the merry-go-round!
00:27:12.730
With this foundation, I wanted to calculate how fast the merry-go-round would spin, starting from rest. I summed the kids' pushing forces and weights to determine their acceleration. Throughout this exercise, I was engaged in playful experimentation; I changed values to see different results. You can print out results and track variables as you play with numbers to discover what works and what doesn’t.
00:28:17.500
Now, regarding how hard each kid hangs on, I decided to experiment and see if the youngest child would get flung off first, watching that play out. At some point, you run out of kids and you realize that you can only account for some behaviors, so I had to keep things moving and wrap it all up. I thought, 'What if I turn this into a fun little song?'
00:29:09.760
Inspired by what I learned from '99 Bottles of Beer,' I imagined a scenario where I’d keep a running tally of who was left on the merry-go-round: ‘How many kids are on the merry-go-round? Oh no, which kid is about to fall off?’ Eventually, we reach, 'No more kids on the merry-go-round!' Instead of defaulting to printed variables through the code, I made it entertaining. Even without aiming for a nugget of wisdom, serendipity emerges so beautifully through creativity.
00:30:05.050
If I wanted to continue this project, I would want to bring in another behavior kids do on the merry-go-round, augmenting and expanding upon the foundational tasks. The same tools, tasks, and different objectives can lead to drastically different results. For example, if my goal was exploring object-oriented design instead of writing a whimsical song, I would first think about structuring the objects that represent each child and their behaviors.
00:30:56.380
This shift in purpose would completely alter the approach I took. The exercise illustrates how you can adapt and grow, incorporating different aspects based on what you're trying to learn!
00:31:42.780
Let’s shift a bit and talk about guidelines. Even if you don’t do exactly what I’ve described, these guidelines are useful for almost any kind of practice, really. They serve as best practices. You should instead listen to them and evaluate them. I’ll share what I believe can go wrong if you overlook these things, and you can decide whether or not you want to follow them.
00:32:37.990
Firstly, choose your tool, task, and purpose before starting. Write them down! This helps clarify your learning goals. If you write your plan down, you can refer back to it later. If you finish adding a bunch of features, you can look back and say, ‘Oh, I guess I already did that.’ Ask yourself if you’re seeking new knowledge or if you’ve satisfied your learning objectives. If you know what you’re doing, you’ll be more productive, while being aimless leads to random and unhelpful results.
00:33:38.820
The time box works on a similar principle. If you set a specific time frame, like two hours, it creates a natural sense of urgency and promotes deeper focus. You’ll get better at gauging how much time remains, encouraging you to dive deeper and delve into the task. After that, though, you may find yourself losing interest or focus, running the risk of long failures that contribute little to your learning.
00:34:29.040
I suggest you throw away what you make after completing the exercise! You can keep a copy; however, don’t treat it like a finished product. If you know you will keep it, you become inclined to treat it as production code, deterring you from trying creative or risky choices. If you're only trying to learn, then everything you produce—even if it's messy or imperfect—is a success!
00:35:21.050
Select a purpose that is manageable. You could come up with several potential purposes, but want to prioritize your objectives. This helps you navigate decision-making regarding what to work on first and whether it aligns with your learning goals. You want guidance about which direction to go, so having those clear priorities can simplify it.
00:36:10.220
Dare to work in layers. You want to be unembarrassed about building toward what you are doing and nothing more. You don’t want to create a massive ambitious task you won’t complete, as longer startup times burn precious hours working on something that may end up not functioning as intended. Start small; choose simpler tasks or objectives—that’s more beneficial to your learning experience.
00:37:02.000
Work from the real world! Picking real systems affords you a significant edge. I don’t mean striving for perfection; rather, you should address standards or techniques reflective of societal norms you want to meet. This can be truly beneficial for your growth.
00:37:50.130
Finally, break the norm! I don’t just mean difficult rules, though you could. It's okay to break best practices! The crucial aspect is that learning should be fun and engaging. You want to elevate your skills, so if any conventions get in the way of your learning—blow right past them.
00:38:43.900
Now, let’s revisit choosing a task. The odd thing I’m suggesting may be the most valuable aspect of this talk. There’s no shortage of complex systems around! You have to decide which of them spark your interest, as that’s the first step to picking something that adds value. For me, I enjoy systems related to human behavior and dynamics.
00:39:38.010
Selecting systems associated with people effectively pushes you to ensure your work is compelling and relatable. It's easier to measure success. You can also choose natural systems or anything else that captivates your curiosity! Authentically engaging with what you’re inclined to work on will yield more intriguing personal coding.
00:40:08.570
Thank you all!
