Time Out: Part 1

In my spare time, one of my very favorite activities is long distance running — not only because I love the activity itself, but because it so often confers wisdom that is highly applicable in so many other areas of life, including, as I have come to find, programming.

In fact, what I identify as the single biggest key to success is as a runner, I would also say is one the greatest assets you can have as a developer as well. What is this wondrous asset? Is it strict adherence to goals? A particular training regimen? The perfect diet?

You might be surprised at my answer (and of course I only speak for myself, as a casual/non-competitive runner…though I have been at it for over 20 years). In my opinion, the single biggest key to success is the ability to differentiate the moments when you need to keep pushing from the moments when you need to stop — even if you have not yet met your goal — and to act accordingly. This might sound like something that would be obvious, but it’s often not. For me, at least, every time I run, there are two competing voices in my head: one saying “Don’t stop until you’ve reached your goal! You can do it!” and the other saying “I’m tired; my knee hurts; I’ve already run plenty far; it’s just ONE run, stopping won’t be a big deal; if you turn around now you’ll have more time to do XYZ when you get home…”

Now it’s easy to assume the solution is to just ignore the second voice, figure out how to tune it out, and always keep pushing. And all of that sounds relatively consistent with conventional wisdom. But the problem is, sometimes you really do have knee pain, you really didn’t get enough sleep, and you really should stop. If you do have a real injury, or are ill-prepared, not only is continuing not going to help, it can actually be extremely detrimental. Running on an injury will undoubtedly worsen the injury, and maybe even cause a secondary compensation injury, and is sure take you out of the game for however long it takes to rehab. And pushing when you’re legitimately tired can lead to injuries, or slow you down so much that the run wasn’t even worth it — you’d have been better off calling it, and trying again the next day.

But on the other hand, that little voice telling you to stop, giving you plenty of reasons to do so, is always there. It’s not grounded in facts or reason — it’s just always droning on. You can’t trust it — if you listen every time you feel a twinge of discomfort, you’ll never finish a single run, ever.

Listening uncritically to either of these competing voices can result in disaster, so if you are going to be a successful runner, they key is to listen even more deeply, to your body. To start being able to honestly assess when your body is sending up red flags versus when you’re just feeling lazy. For me, it took years of trial and error — cutting myself short on runs I probably could have finished and regretting it, continuing on a run when I really shouldn’t have, only to spend weeks rehabbing instead. Honestly, it can be just as hard and upsetting to make myself stop when I’m hurt, and had my heart set on making a goal, as it is to push on when I don’t really want to. But finding the right balance, and learning to distinguish the times when stopping really is a necessity — and when it’s not — has lead to much more successful training than when I wasn’t as self-aware and often made the wrong choice.

But how does that relate to programming? It’s not like you can sprain your brain — isn’t it always the right choice to keep pushing? That was what I thought when I first began Launch School. Pick a goal and stick to it. If I budgeted 6 straight hours of study or coding time, that means 6 straight hours of study or coding time— anything else is a failure. But boy was I wrong.

Learning new, challenging, technical material and problem solving with that new material is hard. Objectively hard. And it takes time. Your brain may not be a muscle, but the fatigue you experience can be very real. For me, when I’m taking in new material or working through a challenging problem, there is definitely a tipping point at which my brain is “full”, “maxxed out”, “done”. But what’s the harm in pushing on, once you’ve reached the “full” point? It’s not like a leg injury that will actually cause harm after the fact, right? Except that it kind of is.

In my experience, when I really have hit my limit of new information or problem-solving, my ability to process and comprehend even more information is severely diminished. I almost always critically misunderstand the excess information, which leads to flawed mental models going forward. It is much, much harder to correct a poor mental model than it is to simply build it correctly in the first place. (Think of a song for which you’ve mis-learned the lyrics — every single time you sing along, if you aren’t being very deliberate, you’re likely to sing the misunderstood verse rather than the correct one.)

When I’ve reached my “max” point with a coding problem that I just can’t manage to solve, I often find I have thoroughly convoluted the problem in my head, and wind up farther from the solution instead of closer. Of course PEDAC is essential at mitigating this — but even with PEDAC if my brain is truly fried, I can still manage to confuse myself pretty deeply. Fortunately, if you’re pushing to Github with some regularity, you might not lose all of the progress you made on the problem…but you’ve still got to contend with the new misunderstanding you created for yourself by forcing yourself to keep working on it when you shouldn’t have, and that winds up being counterproductive.

When I keep pushing through mental overload, not only do I rarely get anything out of that time, I almost always set myself back. But like with running, of course I’m human — not working is always easier than working, and as I’m making my way through the new dense material, there’s a little omnipresent voice saying “this is hard; I’ve done enough already; hey look here’s something more fun and easy I could be doing instead!” And if I listen to that voice, I will never, ever accomplish anything. And that is a very real concern for those of us in this self-paced program. With no external timetables forcing us to buckle down, the fear of never finishing, wasting too much time, or going too slow, is very valid. In fact, I think it’s one of the most common concerns for students in Core — especially when we first begin. We watch other students who seem to be progressing faster, or set arbitrary deadlines for ourselves — without even understanding what we’re committing to, since we don’t know what material is ahead or how challenging it will be — then beat ourselves up if we don’t meet them. Even for those savvy enough to recognize that using pace through as-yet-unknown material isn’t a great metric, and settle on logging study hours instead, we are often disappointed with our results — in spite of honestly doing our best and working as hard as we can, our study hour count can be wildly underwhelming, which leads to the fear “if I’m burned out after half a day of study, how am I ever going to manage to work a full 40+ hour week in this career?” So it’s easy to think that forcing extra study hours is good, even if it doesn’t feel that way, and to feel defeated, like a failure, if you genuinely can’t do it.

But if you’re not a runner and you decide you want to run a marathon, you don’t start out running 18 miles at a time. You don’t even start out running 5 miles at a time. It takes time to build that muscle, to develop that endurance. And similarly, if you’re new to web development, you need time to condition your brain to think programmatically. You need time to genuinely understand the meta-concepts that dictate how computer languages work. Without that foundation, you are unlikely to be able to pull off that “long run” right away, without hurting yourself in the end. And the proof really is in the pudding. RB101 to the 109 written exam took me 6 months. JS210–211 — which covers the same expanse of material, but in JavaScript, in my opinion, a significantly more challenging language to learn — took less than half that time, because I wasn’t starting from scratch; I already had plenty of “muscle” built up. Building on a solid foundation gets easier and faster the more you know — but that foundation comes from time and practice, it’s not something you just start out with.

Moreover, while there is always more to know — from my understanding, a career in web development requires a perpetual commitment to learning— conquering entirely new material is certainly not all you’ll be doing day in and day out, as you do in Launch School. And once you’ve got a bit of learning under your belt, it’s pretty common to recognize that you can spend a lot more hours coding than you can learning brand new material because writing code in a language you understand is exercising muscles you already have, vs. growing new ones. Even if you’re up against a tricky bug, you’re not tackling something as conceptually challenging as pass by reference/pass by value all day every day. So it stands to reason that the amount of hours you’d put in while learning very challenging material here in Core isn’t a reflection of the number of hours you are able to log when you’re actually doing the work. When I was preparing for the 229 project, I heard many students say they spent 10–14 hours working on it, and I’ll admit, I was a little concerned as to whether I had that kind of stamina. But sure enough, I wound up on the long end of that spectrum, and the hours flew by! Learning really is just a very distinct process from utilizing skills you already have, and takes a very different amount of mental energy.

So hopefully I’ve established why I think it’s important to have a clear sense of when you’re at a valid stopping point, and why acting on that is a good thing. But how can you tell when you’ve reached it? Honestly, I don’t think there’s an easy or universal answer. I think it’s a very personal awareness that is honed over time through trial and error. I make an effort to notice what is going on in my subjective experience at times when I’m starting to feel “done,” especially when I realize later that I over-studied. I pay attention to how I feel if I step away — did I regret it, or did it feel like the right choice? It’s easy to get into a lot of mental gymnastics trying to second-guess yourself, but I do think with time, intention, and honesty, you can really refine your ability to determine when you need a break and when you don’t. Core is an excellent time to experiment and develop this self-awareness, in my opinion, precisely because you aren’t up against real deadlines, you aren’t reporting to any boss, mistakes in judgment while you’re learning your limits aren’t likely to have wildly detrimental consequences.

So now you know how important is to be aware of your own breaking point. What’s the best way to benefit from that information? See Part 2 of my article here.