Transcript
Thank you so much. Thank you for having me here. This has been the talks that I've watched that have been awake, and they've been fantastic. I hope you've enjoyed them. My name is Steve. I say it as Steve and write it as Steven. On the screen, you can see my contact info on Twitter. That's probably the best place to reach me, and my Gmail. All the slides we are looking at today are available on the internet at that URL.
As Nathaniel mentioned, I'm an engineer at Artsy, a company based in New York where we are building a platform for collecting and discovering art, and I am based in Milwaukee, in the United States, kind of the Midwest part, a couple of hours north of Chicago by car. So I'm going to ask a couple of survey questions to kick us off real quick. We will come back to this real quick. The two things I want to know from you are, if you're able to answer these questions: what is your experience in your career, beginner, intermediate, advanced, and then the second question, have you gotten stuck on a problem recently? Yes or no. We will circle back to this in a little bit.
Maybe helpful is to define what I mean by the word "stuck", it's kind of nebulous, it's unclear. To add a little bit of clarity to this, what I mean when I say "stuck" when you've been looking at code for minutes, hours, or days, and you swear should be working, and you've gone over it a bunch of times and can't figure out why it is not doing what you think it should be doing, looking at it, and it is doing something it should not be doing, and you're starting to get frustrated.
I do a loft different things at Artsy. I work with JavaScript, React, Ruby work, I Rails, SQL, Elasticsearch. I specialise as a generalist but one thing thing I love to do is help people get unstuck. I've got a lot of really great team-mates who are great at getting people unstuck too. I've taken notes on how we help each other get unstuck. That's what I want to share with you today.
The first thing I have is maybe a little bit of less of a strategy, and more of a mindset shift. Right? So we are going to embrace stuck. Jumping back to that survey question, those survey questions that I asked, what is your experience level in your career, and have you gotten stuck on a problem recently? And I am not seeing any responses to this anywhere. I wonder if I have to look somewhere else? But, basically, we tend to find here is that it is not just beginners that get stuck here, it's everybody that gets stuck, especially you beginners, and now I'm seeing the responses. What do we got? Intermediate yes, and what we generally find is that everybody answers this problem yes - even the advanced engineers, the people who have been doing this for a long time.
Beginners, take note: if you're new to this job and you think eventually I'm going to be so good at engineering and developing that I'm never going to get stuck, that's not the case. That day is never coming. You keep getting stuck, the problems just become different.
I have a former co-worker and a friend named Will who wrote an article he calls to start meditating, stop trying to empty your mind, and he talks about how many newcomers to meditation think they're bad at it because their mind is not empty, and their mind wanders and think they about different things. Having an empty mind isn't what meditation is about, it is about mindfulness and noticing that it is wandering, and that's really it. In his article, he says it may freely frustrating like you're doing it wrong, but that is the practice. Similarly, when it comes to getting stuck as a developer, it is not a reflection of your skill level, it's not a reflection of your experience level, it's not an impediment that is preventing you from doing your job, in fact, getting stuck is the job.
It is what we are getting paid to do. We get paid to get stuck and then get unstuck. It's our unique skill and why we get to do this instead of someone else. It's okay to be stuck because that is you doing your job which is not just to write lines of code but also to solve problems. And honestly, it takes time to solve problems. It takes time if it takes you a while to get through something. With that mindset shift, let's look at more actionable strategies for you.
The first set of strategies I have is in regards to explaining the problem. You get stuck on something, find a way to try to explain the problem to someone, or something, and let's talk about some of those strategies. You can write about it. Lots of different places to write about your problem, why you're stuck. Maybe you're old school and you want to write an email to somebody you used to work with, or Slack message to a team-mate, or maybe you like to ask questions on Stack Overflow or a blog that you write on.
I keep a work journal, a nice thing because I write about the problems I'm running into, and then I can go back in time, and, when I run into that problem three months later, I remember what I was stuck on, and I do a quick search, and I can find how I got through it three months earlier. Maybe you've got a dependency that you think there is an issue with it, go ahead and start writing up a GitHub issue.
The last one on this list, something that has been tremendously helpful for us, in our Slack we have a channel named Dev Help where developers go when stuck on something. They post a question, and people come in and help answer they're question, and, when they figure it out, the problem they move beyond it, make sure it is captured there in the thread and mark it with a check mark that it's been solved. The cool thing about these right strategies that you don't need to send the message, just writing it up can be enough to help you figure out what your problem is.
Maybe you're more of a verbal person, in this case, talking to the duck is a thing you can do. It is an expression that comes from the pragmatic programmer, where basically you have this little rubber duck that you keep at your desk, and, when you get stuck on something, you try to explain to the duck what is going on. It does not have to be a duck. It doesn't have to be a real thing.
It can be real, or it can be imaginary, but the strategy is most effective when you are talking out loud. You have to explain the problem to the duck out loud. Say the words out loud. Tell the duck what this line of code is doing, tell it where it goes next, what is supposed to be happening that is not happening. If you feel weird to talk the to inanimate objects, you can talk to a person. The same thing as talking to a duck, except that it is your co-workers aren't the duck, basically. If you're lucky enough to be in person in co-workers, ask them to look over your shoulder. We are working virtually most of us, and it's not too far away to reach out over Slack or Teams or whatever you're using and ask to have a look at this with me and run some ideas off you and figure out why this is not work ing. T
he distinction I have here in my head is pairing versus talking to a person is more like we're both going to get our hands on the code together. We do pair a good amount at Artsy - not all the time because that can be overwhelming for people, but I like a couple of hours a day, and especially when I'm stuck on a problem reaching out to somebody saying I'm going to start up this live share session, or let's go ahead and pair on this, and see if we can figure out and trace down why it's not doing what it is supposed to be doing.
So all of these things that have to do with explaining can be explained by something had in psychology called the protÈgÈ effect. The protÈgÈ effect is something that you've probably experienced if you ever taught someone something through your one-on-one, or a lunch-and-learn, a workshop, or just teaching newer employees, or even if you've written a blog post about a topic, and you find yourself researching it deeply so that you understand it enough to write the blog post. If you've done any of those things, you've probably experienced the protÈgÈ effect which is when you teach something, you tend to learn it more deeply.
Now we're not teaching someone a skill when we are explaining why we are stuck, but we are teaching them our mental model of the problem space. So if this can give you a better understanding of your model of the problem space.
A couple of things happen when you are teaching something to someone. You're inspired to think about and learn the topic thoroughly, because you're going to have to explain it, and you don't want to look like a fool. You have to learn better learning strategies, which is really cool. And it also inspires you to think about how you would learn the topic. You do a little bit of meta thinking here. While learning, you think how you would learn it if you went back to do it again or how you might teach it to someone else, how they might best learn it.
There are a few studies that have been done about the protÈgÈ effect, and I will highlight one here from 2016. The name of the study is there at the bottom in blue. In this experiment, the control group was told here are some things you're going to learn them. The experiment group was told, here are some things you're going to learn them, and, when you're done, you're going to go and teach them to someone else. And what the researchers found was that the students in the learning by preparing to teach intervention developed a more detailed and better organised concept map of the problem. They learned it better, basically.
I'm going to Zoom in. These words "learning by preparing to teach". That is an interesting name to give this experiment group. What it is pointing out is that this group that was told they were going to teach something to someone else after they learned never actually went to teach, it was just the act of thinking that they were going to learn it, or they were going to teach it. It prompted them to start using those deeper learning strategies to understand this problem better.
The other thing that happens when we explain something to someone is that it forces us to challenge our assumptions and prove that the code that we think is running is actually running. I think this is really critical and important for all these strings, this challenging of assumptions, and kind of reminds me of some other things that I've read or experienced.
There is a book by a psychologist named ... and if you're familiar with flow, it is from this book. I want to pick out this one quote, because I think it's really interesting and related to challenging assumptions. He says experience is one thing for what it is, not what you think it is. ... when I was in grade school, taught at grade school, and in college, I also see my kids learning this about their art too, I don't know how many times teachers told me, draw what you see, not what you think you see.
You often think you see something that isn't there, or you are simplifying it. This is about symbols, right? When we see this drawing here, we recognise it instantly as an eye. But it's not an eye. It's three simple shapes. That's not really what an eye looks like. It's the symbol of an eye and our brain is able to use this as a short cut to say oh, we are talking about eyes now. In reality, an eye looks more like this, incredible detail and subtlety, a lot of colours in the iris, those are blue eyes, for sure, but green, and brown there, and you can see the reflection there, the blood y pulpy thing in the corner that I'm sure has a name back up I don't know what it is.
When we are focused on a problem with our code, we use symbols like this and make assumptions. We build up a model in our head of the pieces working together, and treat them as black boxes and abstractions, so maybe there are four different things interacting in our code here. We think of them more abstractly, and how they interact that way. They are symbols and you assume they're working as you think that they work, when in reality, every one of those abstractions has incredible complexity and detail. So much complexity that we have to treat them as these abstractions, because if we didn't, if we tried to understand every single line of the entire system, they would just be overwhelming. There is way too much going on. Too many details. When you get stuck, it often means that our symbols don't reflect the reality of what is going on in the code.
So those abstractions are a little bit different. Those black boxes are differently shaped than what they really are in the code, and explaining the problem forces you to evaluate every assumption, and every one of those shapes and explore the details of each of them, and that is often when you uncover the issue.
Next we are going to figure out how to isolate our problem when we get stuck. I've got a few strategies here, and it starts with some risk analysis. We are going to ask ourselves a few questions. What is the thing I have introduced to my code that I know the least about? What is the thing most likely for me to improperly use? These could be dependencies, new code, existing code.
Finally, what is the thing I'm making the most assumptions about? This is really getting more directly to the point here. If you can give us an answer to any one of these questions, there's a good chance that's where you're stuck and you should head in that direction next. Even if you can't, a good strategy to start with for isolation is removing code. Then we can do this by deleting code a little bit at a time.
So maybe I have several blocks of code that I know overall they don't do what they are supposed to do and I'm not sure which one is failing me here, so just remove some of it. Stick in a hard-coded line that returns something that you are expecting that function to return. And now we are - now we have a smaller problem here. Maybe we can go in further and remove more code, and just keep removing these little bits, a little bit at a time so that eventually we are dealing with ten lines of code instead of 50, 100, 200 lines of code, and maybe this will help us isolate with this smaller block of focus.
We can apply this to our recent changes too if we're using something like Git to track our source, and instead of deleting code, now we are backing changes out one at a time, so back out an economy the, the next commit, and the next, until we get to the point where the code works again.
I will point out there is a command built into Git that does this or something similar to this. If we think of our system as this super sweet Lego camper here and something in it is not working right, the strings of code removal are like this, we are dissembling it, and taking it apart, and trying to figure out this is a raft component working with the sleep component over here.
Sometimes we are not even sure we have the right pieces to build the camper, though, and we're not sure if that raft will play nicely with the wheel or the windshield, and the reason we are stuck is because the dependencies are incompatible with each other, and those cases it's not useful to isolate the problem by building a proof of concept that these things can play nicely together.
Demonstrate the problem or the subsystem in a very isolated context with no dependencies or nothing that is not needed to prove these things can work together. And sometimes we get stuck because we don't even know where to start, get stuck in a state of analysis paralysis.
We know we need to build this thing, but there is all this complexity, and when we try to build it we get lost in thought. A proof of concept can help in there too but not necessarily if we don't know what concepts to prove.
We're at that point where we don't know where to start, we don't know what to prove out, my strategy that I recommend is to eat the frog. That is a phrase that the internet tells me comes from Mark Twain - I have no reason not to believe it, but it's the internet. Mark Twain may have said eat a live frog first thing in the morning and nothing worse will happen to you rest in the day.
The morbid twist on that is nothing worse will happen to either of you in the day! Which of these four things to start with, we know we have to build this app and we don't really know which ones are important for our proof of concept, choose the most risky one, the one you have uncertainty about, and start there. It may be that the other three things, like rails on the top left, and your UI on the top right, your database on the bottom right, maybe it's just like the React that you have a problem with, start with just React as the part that you need to isolate.
You can throw away the code after you do this little proof of concept, but it will get you moving, and it will teach you things about your system and how things are eventually going to come together. If that hardest problem still seems to big, think about it as multiple problems and try to separate them and approach them once at a time, starting again with the most scary and the one with the most uncertainty.
Writing tests is another neat way to isolate the source of your stuck in your code. It's an extremely useful skill for solving problems as a developer, allows you to tighten your development feedback loop of making changes and then observing their effects and repeating that cycle.
The basic idea here with writing tests is whether it is a unit test of a tree of function calls, or integration tests of a tree of components, or end-to-end tests, if we write a failing test at the highest level that we can, we know it's going to fail because the code's not doing what we expect it to do, and then we iteratively climb down the tree to a more isolated and granular level.
If it fails there, we dig one level deeper and eventually we get to a point where we are down to one or two blocks there. I know that everything else is fine. It's this specific piece that is causing the issue, and we can figure out why our Lego camper - when you break something down from something large or small, it gets a smaller surface area and gets easier to figure out.
My favourite strategy, or set of strategies, is about escaping the problem. It starts with relaxing, taking a shower, taking a nap. When you relax and walk away from a problem, your brain kind of shuts off about it, and you let it wander. Other parts of your brain activate, and then they can find solutions without you trying.
I read an article today that suggested this exact strategy for when you're stuck on your Wordle. You also become more open-minded to the problem, and less likely to dismiss ideas that don't seem obviously related, so relaxation is just a good way to be creative. This is why things, we have all these ideas in the shower because we shut off the problem and let our brain do other things.
Physical exercise is another great way to escape a problem and let your brain process it. This will increase blood flow to your brain, improve your executive functions and improve your mood which often can give you the push you need to get back at solving the problem, and, if you find something that is rhythmic and repetitive, your mind can shut off and wander - it's great. Maybe you have other hobbies that you use to do this kind of thing, playing guitar, or drawing, any of these things are great, great solutions for when you're stuck.
And if all of that kind of feels like it's unproductive, you can choose a more productive escape strategy like move on to another problem. If you're working on something big and heavy and deep, and you've got some things in the back there like copy changes, tackle a couple of those. You'll get away from the problem you were working on, and also accomplish a couple of things. Why does escape help us solve problems? Your mood improving from getting away from this problem that is just bothering you, and you can't let go of. I do this in rock climbing a little bit. If I lose confidence working on a hard route in rock climbing, I'm ready to give up, I will look around the gym for something really easy is and do a couple of those and feel better about myself. I'm not awful at this. I can do this. I just need to try again.
When we come back to the original problem after escaping, we have to relearn it a little bit, and this can help you challenge your assumptions, it's like talking to the duck, and it is also kind of a nice way to rebuild your mental model of the problem. If the last time we rebuilt it we got some of those symbols and abstractions wrong, rebuilding it might give us a chance to get them right this time.
Finally, your brain can come up with the answer while you're thinking about other things, which is magical. There are a couple of psychological principles involved here. For starters, there is something called analogical problem-solving using information from one domain to solve a problem in another.
You notice parallels between two different activities, and you notice more and more parallels between them and you start reframing the original problem in the context of this second area and it can help you overcome that source of whatever you were stuck with. There is another thing in psychology called incubation. It comes from again Mihaly's creativity and flow.
Created the five stages of creativity based on previously proposed stages by a political scientist named Graham Wallace. They are described as preparation when you investigate a problem consciously in many different directions, and then incubation, you put the problem away. You do nothing, and you do a different problem, and your brain processes it subconsciously. Ill aluminium nation is when the preparation and incubation come together and we have this sudden insight.
Evaluation, we kind of vet the idea, look at it critically, and then in elaboration, we expand on those new ideas and test and refine them and figure out how best to apply the ideas. He was very clear about the fact that these don't, there is no sequence to this. They play together in all sorts of different orders.
He describes incubation as when ideas turn around below the threshold of consciousness, during this time that unusual connections are likely to be made. When we intend to solve a problem consciously, we process information in a linear, logical fashion. ... unexpected combinations may come into being. The emphasis here on words like "unusual" and "unexpected" is mine. He goes on to compare, when we're thinking about a problem, we push it in a linear direction, straightforward, we are going to solve this thing A to B. But when we set it aside and let it incubate, it extends to parallel processing allowing our brain to freedom to problem-solving.
We can combine things in ways that our conscious mind would have rejected. When we are faced with a difficult problem, we think that we need to really focus on it, and, if we are not focusing on it, we are procrastinating. The truth is for these complicated problems where we are really, really stuck, your brain and creativity need to expand in many directions to find a solution. So staying actively focused is kind of a detriment. But if you give your brain this room to explore the space on its own time, that can help you explore these ideas that your focused rational mind would reject, so go for a walk, out, set the problem aside, take a shower, a nap, do some wood working then and for a bike ride. Let your brain handle this one on its own while you do something else.
Final set of strategies is about hardening yourself for the next time. Keep in mind our mindset shift from earlier. It's what we are here to do. Learn new ways to solve problems so that that you have different tools for the next time you run into this. You can pair even when you're not stuck. Especially in my experience, people tend to think of pairing as something you do when you get suck but there's so much to learn from someone else when you're writing a new feature from scratch when you see how they approach a problem and how they solve it. It's a great way to learn all these new tools. GitHub is great. You can find other projects to read code, and explore new technologies, learn for the sake of learning.
I keep a Trello board that I fill with messages of appreciation and thanks, and I call it my Wall of Motivation. There is a talk in the You Got This library by Gargi Sharma making your work visible, mentioning the Bragg Talk. This is an example of it here. The nice things that happen, I track them here, but more important than tracking them is going back to look at them now and then, because if you're like me, when you get stuck on something, your self-talk changes for the worse, and you start saying awful things, imposter syndrome kicks in, but this call of motivation replenishes my ego and helps me remember that you're, in fact, doing a great job, especially when you are getting stuck.
You're doing great. You're doing fantastic. It doesn't feel like it, but this work is hard and it takes time. Keep a list of things you do every day in a journal. I try to get deeper about the problems I'm solving. Even tracking the accomplishments you have, whether it is something big like shipping a feature or something small like you learned, or you discovered or a mistake you made, small steps forward, you can look back at the journal and see that you're doing this job of solving problems.
Not the first time we've talked about exercise, or not the first time you've heard it today. It reduces anxiety, depression. I mentioned rock climbing earlier. If that is within your physical means, that's a fantastic form of exercise for developers because it's all focused on solving individual problems, but whatever is visible for you here, whatever form of exercise, whether it is just going for a walk, anything that gets the blood flowing through your body is super helpful. Meditation can also be useful.
There are mental and physical benefits to meditation, especially for me, levelling your emotions which factor into me getting stuck like I said. That's really helpful and increases your ability to persist through these challenges. Get outside of your head if you can. If you can do more active one-on-ones with your leaders, or if not your leader, someone you can be vulnerable with, and you can talk about the times that you have felt stuck, and they can talk about the times that they've felt stuck, and you can share in these struggles together.
The common thread for these hardening strategies is about getting into, really. Eps, strengthening yourselves, we're not professional athletes, maybe some are - but they condition themselves every day for the physical challenges they face. We are facing incredible mental challenges every day. We should condition ourselves for those too. All right, summary of the things that we talked about.
Strategy groups: embrace getting stuck. Getting stuck and unstuck is the job. Explain things to someone else. It will help you challenge assumptions and rebuild the model in your head and figure out why you may be stuck on something. Try to break the problem down, isolate it. Give yourself a smaller surface area to focus on. Set it aside. Walk away. Go for a run, take a shower, take a nap. Let your brain process this thing on its own.
And finally, condition yourself for the next time that you're going to run into this, because you're going to get stuck again, and that's okay, and that is you doing your job. I just want to thank you all for your time. And I'm happy to answer any questions or have any discussion here.