Over the last few months, I’ve been helping students when they get stuck working on the Learn.co online full stack web developer course. While I’ve been doing this job, I’ve encountered a few students who have expressed dismay and frustration when considering their progress. In this post, I want to talk about what I say to those students, because it’s something I wish that I had heard earlier on in my journey.
The first thing I say is that it’s okay to get discouraged. Learning is hard. It stands to reason that learning to code would be hard also! The trick is to realize that getting stuck and getting frustrated are part of the process. And, as such, those negative emotions are not a prohibitive signal that “this just isn’t for you.” Like any other skill, if you’re not feeling any discomfort or difficulty while you’re practicing, then your practice isn’t doing you much good.
I highly recommend a book called Peak: Secrets from the New Science of Expertise. The book has a lot to say about the importance of deliberate practice. Deliberate practice is a specific kind of practice, usually guided by a coach, that aims at constantly focusing your attention just outside of your comfort zone. That way, the practice integrates enough of your current skills that you don’t feel completely in the dark. But, it also introduces you to new challenges that force you to learn and grow.
So, when you’re feeling discouraged, one of the first things you can do to get unstuck is to take a step back and look at what you’re trying to do. If you find yourself in a situation where you’re trying to tackle a problem that is well outside of your comfort zone, see if you can break it down. Instead of trying to solve the entire problem all at once, see if you can imagine a way to break the problem down into pieces. Start with the pieces that are most familiar, and gradually include the parts that are more difficult. Don’t give up, just try a different approach.
It Gets Better
I find that I still get discouraged and frustrated, but the problems that push me to that point get bigger. Gradually, as we push the limits of our comfort zones, our comfort zones expand. After a while, it takes really complicated problems to push us to our limits. The feelings are still there, but we’re now facing problems we wouldn’t even have approached before.
I find that one of the things that really distinguishes the progress of the students I’ve worked with is how deeply they’re able to drill down into the problems they’re working on. The farther along a student is in their journey, the more details and nuances they have in their insights about what their code is doing. The ability to zoom in and zoom out on a system and examine how the parts are working together really helps when it comes time to isolate where a problem is occurring.
Working in software requires that we continually develop and improve our skills at managing complexity. It requires an ability to be confident in our ability to solve problems, all the while acknowledging that every solution has the potential to create more problems in the future. One of the most important skills to develop, then, is to write code that is easy to understand and easy to change.
This is not a world where you can just read the book and study all the right answers and coast for the rest of your career. The book is constantly being rewritten by multiple authors who may or may not agree with one another. It’s also continually published and republished. And yes, you should still be reading it as much as you can. All of that said, it’s easy to see why getting discouraged is common while learning software development.
It’s Okay to be Wrong
Needless to say, expecting that you’re always going to get it right the first time is not reasonable. Instead, becoming a programmer requires that we make our peace with being wrong most of the time. That said, the more mistakes we make the more likely we are to start choosing solutions that are easy to change when we discover a better approach. When you get discouraged, don’t give up, try something new!
There is an inherent disconnect between the world that we are trying to model with our software and the software itself. The map is not the territory. Thus, software developers find ourselves the guardians of that disconnect. Gods of the digital realm, we are ultimately responsible, as a group, for the assumptions we make about what is or is not valuable. What we include in our digital world can be just as important as what we leave out.
In the end, software is a tool. We build it for a particular purpose. We build it to solve a particular kind of problem. Presumably, the problem we’re trying to solve actually exists in the real world. Our task, then, is to understand that problem as thoroughly and completely as we can. Then, we must isolate the parts of the problem that are most troublesome for us unaugmented humans to consistently solve. Those parts of the problem are the ones that our software should help us to solve.
We can expect to regularly get it wrong the first time. So, instead of trying to get it right the first time, we shift our focus to making as many mistakes as we can as quickly as we can and with as little risk as we can. It is through the process of making mistakes, trying new things, and playing around with edge cases that we come to solutions that are robust and easy to change. If we get in the habit of regularly changing our code while we build it, it’s easy to develop the habit of writing code that’s easy to change. (I find that writing smaller functions can really help with this)
Staying Focused and Maintaining Perspective
Thus, we are best served to make sure that when we get stuck & discouraged, we’re getting stuck on something that’s actually important. It is very easy to get tangled up in code that’s modeling part of a problem or situation that isn’t actually important. One of the easiest ways to get out of this trap is to follow the rubber ducky approach.
The way this generally works is you take a rubber ducky, put it on your desk, and explain your problem to the ducky when you get stuck. Often, the process of taking your problem and expressing it in natural language will reveal an error in the logic, a confusion about a variable name or function return, or some other helpful place to refocus attention. The main value of the approach is that it forces you to consider your code in the context of the problem you’re trying to solve.
The reason this works is that when we communicate our problem solving process to someone else, we know that they need the context of the problem to understand our thoughts. Thus, the act of explaining our problem to someone else forces us to recontextualize our solution. I’ve found that talking out my problems has been very helpful to me in getting unstuck. Communicating problems out loud is also a great way to identify parts of your code that are unclear.
Googling is Not Cheating
I know this sounds ridiculous. Still, I couldn’t help but include this at the end. Believe it or not, I have had some students working through our curriculum who consciously avoid going to Google. In the name of pedagogical responsibility, I must wholeheartedly encourage the quick and frequent use of Google. As a software gunslinger, your main focus should be working on your draw: “Be quick to the Google!”
The more often you Google, the better you’ll get at it. You’ll be forced again to frame your problem using language in the most accurate way you can. Over time, you’ll learn how to quickly distinguish the results that are appropriate for the problem you’re working on. Remember to keep iterating, if you don’t get results that look like what you want, think of another way of framing the question and try again quickly. You’ll get better at filtering out results that aren’t what you’re looking for as you get more practice.
Learn to be quick to the Google and quick to get back to your code to experiment. The goal is to shorten the feedback loop between having a question and having a testable approach to finding the answer.
Think about what your questions mean. If you wonder what
7/2 is in Ruby, drop into irb or repl.it/languages/ruby and check (it’s 3 by the way). Start thinking in terms of testable questions and assumptions. If I want to figure out how to get this math to work right in ruby, what could I try? What would
7/2.to_f return? What about
Whenever you find yourself unsure of the way something works, find a way to get feedback and go see for yourself. For beginners, I really like recommending repl.it, because it’s easy to setup a sandbox to work in multiple languages and get feedback on the way they behave very quickly with minimal local setup. You’ll find that if you take the time to articulate your problems using the rubber ducky approach and think of example cases that will test your assumptions, you’ll learn much more quickly. Ultimately, this approach will lead you to an increasing confidence in your abilities, and a consistent and effective way to respond when you get discouraged.
Also published on Medium.