About the talk
RailsConf 2019 - Getting Unstuck: Strategies For Solving Difficult Problems by Steven Hicks
Even with the simplest of problems, we can get stuck on code. It happens to engineers of all experience levels. This session will show you many strategies for getting unstuck.
We'll start by reframing the act of getting stuck as a positive. Then we'll talk about many strategies for identifying the problem and moving on. We'll discuss the psychology behind these strategies, and answer questions like "Why do my best ideas come to me in the shower?" Finally, we'll look at ways to harden yourself for the next time you get stuck.
Getting unstuck is a skill. This session will help you sharpen that skill, and prepare you for the next time you want to throw your keyboard out a window.
All right, welcome to day 3 of realcomp. I meant to say thank you to Bear. If you're up front for inviting me to be part of the self care track. I'm super excited. Thanks to all the organizers. I helped organize an event down in Milwaukee, and it's a lot of work. So if you get a chance to thank anyone in a green shirt, please do. My name is Steve. I ready to Steven people call me Steve. It causes confusion. On Twitter. I'm at people with that's p e p o p o w i t z. There's a story. It's not that interesting. How do you know if you want to get in touch
with me is Steven. J. Hicks at gmail.com if anyone is curious all the slides that will go through are available online at Steven Hicks. Me / getting - unstuck. I am an engineer at a company named artsy-fartsy is based in New York and I am not based in New York. I am based in Milwaukee and I work from my basement. Or as I call out the spider hole, but our mission is to expand the Art Market and we're really trying to do this by we're providing a platform to collectors for discovering and buying art.
I don't know. How do you all do that without getting into the argument about styling and what I've come to realize that when you do have discussions about style you automatically win the argument if you just say idiomatic like that idiomatic Ruby, I'm not sure. My research is Buddy there. Like I think there's like a clause in the Treaty of Ghent or something that says anytime to parties are at conflict about Ruby code. If one of them says idiomatic everybody has to drop it and walk away. I don't know much about Ruby or rails, but I know stuff about
getting unstuck and One thing I want to start with is to clarify what I mean with the word stuck because it's really nebulous in this kind of unclear stuck is when you have been working on code and even looking at the same code for an hour or for a day or days and you're frustrated because you can't figure out why it doesn't work. Why doesn't it do the thing that I should be doing or why is it doing this thing that it shouldn't be doing? Are you getting frustrated? You're not sure where to go. This is my favorite
thing and development this active getting unstuck when someone in a stand-up says I feel like I'm stuck on this problem and I can't move forward. I get an adrenaline rush and I think this is great. I love to sit in there with you and try to get you unstuck. It's over the past few months. I have been just taking notes on the things that I do to help myself get unstuck in the things that my co-workers you to get themselves and me unstuck and I just wanted to kind of share those notes with you today. The first thing I have to offer you is not so much a strategy as it is a mindset shift.
Let's embrace the act of getting stuck. Quick survey in the room. Let's do a show of hands for anyone in here who considers himself a beginner to development. Maybe you call yourself Junior. Maybe you don't. Okay, we've got its maybe like a quarter of the people in the room. How about hands for people who consider consider themselves more mid-level? More of those and then how about senior-level? You've been doing this for a while and you feel like you're you're pretty good at it. Okay. Pretty even break down there probably slightly fewer juniors in the rest for beginners.
Question to raise your hand if you feel like you've gotten stuck on code in the last month or so look around this room and noticed that everyone got their hand up right now so you can put them down. So while you feel like as a junior engineer, you're going to spend the day and not get stuck on code. I'm really sorry to tell you that that is not the case. It's just going to be different problems that you get stuck on. My coworker will read an article that he called to
start meditating. Stop trying to empty your mind and he writes about in the practice of medical meditation how beginners especially think that they're bad at meditation because they don't have an empty mind their mind is constantly racing and it constantly filling up with socks. Wills Point in this article is that that's not what medication is about. It's not about having an empty mind meditation is about recognizing your thoughts acknowledging on letting them go and returning to focus on your breath. He says it may feel frustrating
and like you're doing it wrong. But that is the practice. Similarly when it comes to getting stuck in your code. It is not a reflection of your skill level or your experience level as we stop by that tremendous show of hands. It is not an impediment that is preventing you from doing your job. If I could getting stuck is the job. That is what we're getting paid to do. As Engineers, it's our unique skill. That's why we can pay to do this instead of somebody else because we can get stuck on a problem. Pound our heads against it and then get
unstuck. It's okay to be stuck. Because that's just you doing your job, which it turns out is to solve problems. Not necessarily write code writing code is a tool that you can use to solve problems, but that's not what the job is. It's okay if it takes you awhile because tell him problems is difficult and it takes time. Wish that I would like to show you some more actionable strategies and I've broken the rest of the strategies into several groups. The first one is a group that I
call explain the problem explain it to someone else. this starts Maybe by writing about the problem. Write down all the things that you can say about your code and the problem that you're having with it even do this many places. You can write an email to someone people still do that. You can write a message in slack. Everyone. Does that Lots of other ways to do it. My favorite on this list is to write a message in slack to slackbot because it's the truth is for all of those. Most of the time before you even finish writing the message
and send it you figure it out on your own. Maybe you are more of a verbal person. And then you can talk to the duck. If you've not heard of talking to the doc, you might also have heard it as rubber ducking the idea for this is you keep at your desk or small rubber duck. And when you get stuck on your phone you pick up that talk and you start talking to it. And you say look over here. This is a problem that I'm having here's where I think I'm passing this into here. Now it doesn't have to be a duck. It can be an action figure.
It doesn't even really have to be real quick and you can just pretend it's there the thing that's probably most important though is that you are actually verbalizing your thoughts trying to do it in your head is definitely not as effective put it into words helps you out. Maybe instead of a duck you want to actually talk to a person this is super scary. But when you get stuck, you can invite a co-worker to come look over your shoulder and just say okay. I'm at explain disco to you as if they were the duck. Here's all the things that are happening that I think
shouldn't be happening in here is all all of his stuff and this is really helpful. To get you unstuck. And maybe you want to take it even to the next level and pair with them have them sit down next to you and start show him the code, but then have them start poking around and it had them to keyboard. Let them play around with stuff Break Stuff and see what they can make happen. Take turns repair a good amount at RC not all of the time, but I'd say a good day for me is 3 hours a day. Christina Perri and we'll talk about this more lately is that
it's really good for getting on stuff, but it's even better when you're not stuck. All of these explains strategies work for several reasons and I think we can start by by talking about something called the Protege effect. If you've ever taught something to someone whether that was one-on-one or that was you know, since the new team members or you taught a workshop and see something to someone suddenly you understand it better than before you taught it.
And there's a couple reasons it happens. For starters you are inspired to learn the topics early because you don't want to look like a fool when you're explaining it to these other people. There's also a met effect to it where you start thinking about how you would best learn it and how someone else might best learn it as I start to reframe it and think about it that way and that really helps you understand whatever it is that you're explaining. There have been several studies that have been done related to the Protege
of fact. I'm quoting one here. This is a study from 2016 and in this experiment. The control group was told you're going to learn something that you don't know. And the experiment group was told you're going to learn something that you don't know and then you're going to go teach these other people. And what's the researchers found? Was that the students in the learning by preparing to teach intervention developed a more detailed and better organized concept map of the problem. I'm going to zoom in a little bit on
that quote and focus on these words learning by preparing to teach the really neat thing about this study. And about the Protege fact is that those students in the experiment group that were told you're going to learn this and then you're going to teach someone else. I never actually thought I knew anyone else. They were just told that they had to do afterwards and that expectation force them to choose better learning strategies as they looked at their code, or as they look at this thing that they were learning. Another thing that happens when we're explaining is that it forces us to
challenge our assumptions about the code. This makes me think of some ideas that I have read from a psychologist in me high chick sent me high. If you're not familiar with him, you're likely familiar with his work in his book in 1997 about creativity. He popular popularized the concept of Flow State so that that states that you get into a really good day where you start your day and all the sudden it's the end of the day because you are working on problems
that were the exact right level of difficulty for you. But he also is talking generally about creativity and he said he says this experience this one thing for what it is. Not what you think it is. This is all about challenging assumptions. It is similar to what I remember being taught when I was a kid in our class. I had several teachers tell me what you see not what you think you see. Oh my goodness this make sense. as There's a. In an artist life where they they go from understanding things and drawing things in terms of symbols. Drawing things and thinking of them in terms of
reality. When you see the try and you instantly recognize it as an eye, it's got that I shape and it's got a blue iris and it's got a black people. But that's not what an eye looks like. That's just a shortcut. It's a heuristic. It's a symbol of an eye in reality and I looked more like this. It's got a ton of detail. It's got The little red bloody poppy sing in a corner that I'm sure has a name, but I don't know what it is. You can see the reflection of the eyelashes in the eye and those are definitely blue eyes, but that Iris has shades of blue shades of green Shades of Black gray
and brown. Similarly when we are focused on a problem in our code. And we think about how are code is really just we're trying to get these four different things to work together. Maybe one of them is some you I've one of them is some business logic. One of them is a database. One of them is user settings. If you think about this as you're working through this and you build up this model in your head of how this code works together. Each one of those different components turns into symbols in your head.
And we just assume that they're working as intended and as we wrote them we think we wrote them in reality through start to dig in a little bit deeper. What you find is incredible detail about each one of those components in your code. Unfortunately, we we absolutely have to treat them as black boxes or we be completely overwhelmed with the complexity in our system. We just wouldn't be able to figure out what it does. So we go back maybe we focus and you tell on one piece of code that were looking at but the rest of it it just becomes a
black box. Explaining your code to someone else forces you to look at it more like this. You have to look at all the details in your system. Your challenges your assumptions you no longer can explain the code in terms of what this is just the UI. It works fine. Don't worry about it. You have to dig into the UI and figure out what it's doing. And that's often when you uncover the issue. Strategy group number to buy call isolate the problem in this is all about isolation this starts with some risk analysis. Ask yourself a few questions about the cold you're looking at.
What is the thing I've introduced that I know the least about. What is the thing that is most likely for me to improperly use? And what is the thing on making the most assumptions about? and if you find that you can Confidently answer any one of these questions. There's a good chance that that's where you're getting stuck. Now whether or not you can answer those questions we can move on and we can start removing code from our system. This will help us isolate the source of the problem and there's
a couple different ways we can do this. We can delete our code iteratively. Maybe we've got several blocks of code here and in overall, we know that it's not working, but we don't know where we can go ahead and just wipe out half of it replace it with a single line that does what it should be doing. And this will help you determine if the issue is in the code review removed or the code that remains and if it's in the code that remains and you still really can't narrow it down. Go ahead and remove more code delete more of it and replace it with a single line.
This really helps you turn your problem from something like 50 lines of code that you have to look at 2:10 lines. We can do something similar if we're using to get or similar Source control if you think of your photos really it's just a series of commits overtime and we're not sure when we introduced this problem. We can start it back up those changes one at a time and then just go re-evaluate look and see if it still happens after we remove that most recent commits. If it still happens remove the the next most recent commit until we get to a point where we have identified. This is where we
introduced the problem. And again that helps you. Make your problems smaller, you're looking at less codes to figure out what you did wrong. This is such a great strategy that I recently found out from my coworker John right there that is built into get there's a vice X command. I heard it mentioned at least once at this conference. But if you're unfamiliar with the advice, that's what it does is you tell it the the last known good commits and the first known bad commit and it will go ahead and check out for you somewhere in the middle. And then you run a test and say is it
still a problem or does it work and based on your response still go check out another one in the middle and it's basically using a binary search to help you identify the single commit that broke your code. If you think of your system of code as this super sweet Lego camper. And something isn't working right in it via code removal strategies. We just talked about our kind of like this or like this assembly in this finished product breaking off big chunks to see which one of these chunks doesn't work, right.
Sometimes though. We aren't even sure we can build the camper because we aren't sure if the wheel plays nicely with the windshield and if the windshield plays nicely with the raft. And in these cases it's useful to isolate your problem by building a proof-of-concept. Demonstrate the the problem or the subsystem with just the pieces that you think might not be playing nicely together. So you can identify if it is indeed an issue that the wheel can't play nicely with the windshield. There is a subcategory of being
stuck. Where you can't get started on something you're stuck in a state of analysis paralysis and you just aren't sure where to go. And in this situation. My recommendation is to eat the frog eating. The frog is an expression that comes from Mark Twain or so, the internet tells me so it might be a lie if she said eat a live frog first thing in the morning and nothing worse will happen to you the rest of the day. I can't confirm that dance. But we took that to mean now basically do the hardest thing up front. And so if we look back at our system of code where we've got these different
pieces that were trying to get us to work together and we we aren't sure where to start. We just we know we need to end up with this thing. Somehow that has all these pieces in it, but we don't know what to do. You can take a little bit deeper dive into those components and maybe what turns out is that three of the components that are in there. You totally understand it and they're not that complex and you're not really worried about them if that one in the bottom left, maybe he's never worked as a mongo database before and you don't know how you're going to do this thing. in
that situation, that's the best place to start start with that one that you know the least about that scares you the most If it seems like that piece in the bottom left is too big and you still don't know where to get started. Just repeat the process dig deeper into that that section and maybe you realize there's a couple things that I'm not worried about it all with Mongo. It's just this one particular thing that I really don't know how to do. Starting with that scariest will answer your questions for you about how your system is going to fit together. And that is the best place
to begin. Writing tasks is another way that we can isolate the problem and tests are in my opinion. Probably the most useful skill as a developer. Because they help you tighten that feedback loop so that you can make your changes and observe the results and repeat that. There are a few ways that I have seen automated test used to help isolate an issue. The first is to write unit tests on existing functions. If you think of your code as it's free of function calls, you
can go through them and write unit tests on each one of them and what you might find. It is 5 of those six different. There are blocks up there. You can make the unit test pass pretty easily but that 6 to 1 and you're having a hard time getting you to test the pass on that one. There's a good chance that that function or that piece of code isn't doing what you think. It's doing. maybe you've got a function that's a little bit larger and scarier to write unit tests for in this case what you might find is there are sections in that function that
look like they're not that scary and maybe we can extract them into a separate function and ready unit test of that code. And what does houses do was identify again is the problem in that function that we extracted or is it in the original function? And integration tests are I need strategy for for finding the source of a problem. What I recommend doing there is start with your entire subtree with whatever the future is writing writing integration tests against that feature in what you find is that in the aggregation test fails because
something's going wrong in your code. But once you've done that just arbitrarily choose a branch below it and say, okay. Well the whole thing doesn't work, but let's dig one level deeper and let's write an integration test at that level and see if we can get things to pass there. If we can't get things to pass in that branch in the right Branch, so let's dig another level deeper arbitrarily choose another another Branch down and we can get integration tests to pass on that. So we understand what it's doing but one of those branches is still red and this
will help us Target and isolate the issue. the common thread for these isolation strategies is break down your problems from large problems too small problems. When a problem has a smaller surface area. It is a lot easier to figure out. Strategy group number three is about escape and this is my favorite strategy to talk about. When you're stuck on a problem walk away from it. relax Go take a nap or take a shower. John tells me that gnats and showers are really remote person piece of advice to give people.
So maybe you can't do that. But maybe what you can do is just book a conference room and just go turn the lights off and relax for half an hour. When you relax and you shut your brain off from the problem it wanders and even though you're not thinking about the problem the full-time. It's still processing it in the background and it can come to the conclusion on its own. We'll talk about the details of that in a little bit. Get some physical exercise. There's so many benefits of physical exercise. It increases the blood flow to your brain. It improves your executive functions.
It appears your mood, which is a factor when you're stuck. I know when I've been stuck in a problem. My mood definitely goes south. And if you find a form of exercise that's rhythmic and repetitive your brain can shut off again and wander and explore it on its own. Find other Hobbies exercise is a natural one for me because that is my hobby. But maybe you like to play guitar. Or do you like to draw? Maybe he likes net. And if all those feel like they're just procrastination. Move on to a different problem
set this one aside. Go grab a different story from the backlog. That's smaller and looks like you can just knock that one out of the park immediately. We don't always get that right and sometimes we end up now stuck on a different problem. But when we do get it, right, it's really helpful because it boosts start ego it builds and builds up that courage that we need to get back to the original problem. I do this when all the time when I'm rock climbing and I got stuck on a route rock climbing where I just done it six times and there's one spot. I can't get past. I'll look around the gym for
two of the simplest route second finds. And just go to the house and when I return to that original problem, I feel like I've got this boots that I needed. There's a few things that are happening when we escaped the problem. It boost your confidence just like I I talked about with the rock climbing if you work on that smaller story. And you're able to get it done really quickly. It's going to remind you that you're doing a great job. Also, when you come back to the original problem, you have to relearn it. You've forgotten that mental model that you had you've let it fall apart
and now you're rebuilding that mental model and maybe you'll just do it slightly differently and this time you'll understand it better. and your brain when you're not actively thinking about a problem can come up with the answer. On its own and there is a few things that happened here. The first is a principle called analogical problem solving. This is when you apply things that you've learned in 1 Activity 2 things in another activity. So maybe I'm going for a run and suddenly I realize running code actually is
just like the thing that I did while I was running. And then you start to notice more things more similarities with yours is another similarity between running and and the code that I'm working on and eventually you compared to each other and you realize there are a lot like each other and suddenly go back to the original problem the code that you were working on and you start to think about it in that context of running or whatever that other activity is and it helps you reframe it shifted a little bit. There's something called incubation. That's also happening.
When you set a problem aside. Incubation is an idea that was introduced in the 20s 1920's by a political scientist named Graham Wallace who wrote about four stages of creativity. He said the four stages are number one preparation. You're actively thinking about a problem. Number to incubation you set that problem aside and you just let it sit and you do nothing or you do something unrelated to the act of solving that problem. While you're doing that your brain is still processing it. And then stage 3 elimination the incubation in the preparation come together and you have
those moments you have this realization. Oh, this is what's going on. This is how I solve that problem. Insect stage for his verification problem and exploring it a little bit further. No, Graham Wallace was very clear that these aren't sequential these things don't happen in order they happen together. And at any one point you can be in all four of them. More recently. Mihai csikszentmihalyi who we mentioned earlier. He introduced the idea of flow. He also expanded Grandma's is
stages of creativity. The first three he says are the same and then he expanded number for into two things evaluation is when you've met the problem and decide if it's a good idea and an elaboration is when you try to extend it push it to its limits. Tell me how does a really great job in his book of describing incubation for us. He says in an incubation ideas turn around below the threshold of Consciousness. It is during this time that unusual connections are likely to be made. When we have time to solve a problem consciously, we process information
in a linear logical fashion, but when ideas call to each other on their own without our leading them down on straight and narrow path unexpected combinations may come into being emphasis is mine on unusual and unexpected. And we had a really takes a thing straight into the Wheelhouse of engineer's he Compares it to parallel processing and he says when you're actually thinking about a problem you got Tunnel Vision on that problem and you're pushing it in your direction. You're like, you're like a problem that can only be processed linearly. When
you set it aside. It allows your brain of freedom to pursue this problem in more of a parallel manner. And now your brain can make these interesting Connections in ways that you weren't letting it before your conscious mind. Wish you would just have rejected all of these interesting things that it's doing. So often when we are faced with a difficult problem, we think that we really need to focus on it and if we're not actively focus on this problem, we're procrastinating. But the truth is when you got a really complicated problem. Your brain in your creativity might need that space to
pursue it on their own. Seen actively focused is actually a detriment to those kinds of problems. So give you a room space to explore it on its own set the problem aside go for a walk. Get a workout in. Take a shower or a nap or book that conference room for half an hour. Read a book about something related or unrelated. Getting your basement do some woodworking. Go for a trail run. Just gives your brain the time to expand on this problem and exploring on its own time. All right
group number for is all about hardening ourselves for the next time we get stuck. Keep in mind our mindset shift from earlier getting stuck is the job. This is what we're paid to do. And go ahead and learn new ways to solve problems. Pair with someone even when you're not stuck on something start a new story together and what you'll see. What are you experienced? Is a whole bunch of new ways to solve problems that you never would have thought of on your own. Go ahead and read code and other projects see how they are solving
problems in their code. Explore new technologies and and learn just for the sake of learning. These are all things are going to help us the next time we get stuff because it's going to give us some different strategies. I keep a Trello board that I fill with messages of appreciation and thanks and I call it my wall of motivation and it has all these things on it. Then that people have told me I've done a good job at are ways that I've helped them. And I return to it when I'm feeling stuck or when I'm feeling down. And it's really really helpful.
it helps me bring my ego back up because When I'm stuck and I'm guessing a lot of your the same. I really start to get down on myself and I myself socks changes for the worse. I start saying awful things about myself. Like why am I still doing that? So I should have quit program in years ago. This is why motivation. When I look back on it really helps me remember and it'll help you remember that you're doing a really really great job and sometimes you need to just remind yourself of that. Another of my co-workers
recommended when I started at RC that I start keeping a journal. About all the things that I accomplished every day. And this is really helpful because it reminds you. These aren't necessarily big things that I'm checking off a list like it's maybe not I submitted a PR or I've moved this ticket to done. It's little things like I prepared for an hour with John on something. And it reminds me when I look back at that. Journal. These are all the things I did today. And yeah, I did a good job of getting stuck and getting unstuck.
Exercise is super important. It'll help reduce anxiety and depression. Amongst other things and if you're looking for a new form of exercise, I strongly recommend rock climbing. I think it is in the best activity for developers because it is all about Small tiny feedback loops. It's all about trying to do one climb that last not even a minute and you failing you failing you failing you learn from it every time and within five minutes, you've failed seven times in and on the 8th time. You got it.
Meditation can be helpful. There's a variety of mental and physical benefits to meditation. Especially in regards to getting stuck. It'll help you level your emotions which factor in In those moments where where you are stuck your emotions sometimes run amok and if you can train your body to be a little more in control in those situations that can be really helpful. Get us out of your head and talk to somebody about the struggles that you have when you're stuck. You more one-on-ones with your leader. And if that's not somebody you feel comfortable
talking to as much find a co-worker that you feel really comfortable talking about all of your struggles with and maybe it'll tell you all about their struggles and you'll find out that we all kind of have the same struggles. The Common Thread Freddy's Harding strategies is to condition yourself get in the Reps. We think about a professional athlete they are faced daily with Incredible physical challenges and they spend a lot of time training your body physically. Professional developers face mental challenges credibly difficult
mental challenges every single day. So we should do everything that we can to train ourselves to face those problems again. Here is your cheat sheets. Reframe the after getting stuck getting stuck and then on suck is the job. Let's embrace it. Explain the problem to someone else. This will help you challenge assumptions in a rebuild your mental model. Isolates Problems by breaking them down from large into small. What problems incubate what your brain process them on its own escape the problem and set it aside? And then condition yourself. The next time that you get stuck.
Buy this talk
Access to all the recordings of the event
Buy this video
With ConferenceCast.tv, you get access to our library of the world's best conference talks.