Incrementally Refactoring Your Habits with Psychology

[Please note that this presentation contains strong language]

Transcript

My name is Tilde [Ann Thurium], my pronouns are they and them. And today I'm going to talk to you about incrementally refactoring your habits using psychology. I first became interested in this topic at my previous job where I was a software engineer at Pinterest. I worked there for a few years, like you do, and then I went up for promotion, which I didn't get, which I don't know, honestly, it was fair. I had some stuff to work on. So when I didn't get that promotion, my manager gave me some feedback, which was “You're not writing enough code and you need to double the amount of code that you're writing if you want to get that promotion”. And my reaction in real time was like “Oh shit”.

Now, just to give you a little context, at the time I was mentoring a pot of three early ID interns and a new grad. So there are some reasons why maybe my own output was lagging a bit. And so, some of that was just going to be shifting my focus away from mentoring. But some of that was going to be changing my habits. So before I got started trying to write more code, I wanted to do some research and really dig in to how to change my habits more efficiently. So what I'm going to talk to you today about are research-backed psychological tips for making new habits stick, what happened when I put these tips into practice in my own life and some ways you can use your text editor to write code more efficiently. I forgot to mention this, but please feel free to take photos, tweet, spread the joy however you want.

Social Accountability

Let's talk research. Tip number one, social accountability is key. Tell somebody, you can tell a friend, you can tell your manager or conference organizers hate this one weird trick, but conference-driven development is actually a method of social accountability. And part of the reason I want to talk about habits is because I knew at some point I was going to give a talk about it. So I found a study about social accountability. All the participants in this study had a goal that they were trying to achieve. The participants were divided into two groups. One group shared a weekly update with their friend about their progress. The other group kept their progress to themselves. Now I'm sure you're not going to be super surprised to learn that the group that shared their updates was more likely to complete their goal, but how much more likely do you think they were? They're twice as likely. That's a really big difference.

If/Then Plans

Tip number two, make a contingency plan. The literature refers to these as if/then plans, but I keep wanting to call them if/else plans. I can't imagine why that might be, but basically the thought is you need to think about what might go wrong when you're trying to achieve this goal so that you can plan around it. For example, let's say you had a goal of working out five days a week and normally you go to the gym, but what if your car breaks down? Well then, you could go running instead. A study I found with regards to if/then plans had to do with medication compliance, AKA actually taking your medication as prescribed, which sounds easier than it is. Participants who made a one-sentence plan about how they were going to take their medication, they took their medication correctly 79% of the time as opposed to folks who did not, who only took their medication correctly, 55% of the time.

Rewards

Tip number three, treat yourself. This is B.F. Skinner. B.F. Skinner was a founder of a school of psychological thought known as behaviorism. Behaviorism studies behavior because unlike feelings, behavior is easier to measure. So Mr. Skinner invented this device called the Skinner Box. And in it, you put a little rat or a little pigeon and with their little ratty paws and their little pigeony beaks, they press a lever inside the box. And sometimes a reward would come out in the form of food because what B.F. Skinner was studying was how rewards can be used to shape animal behavior. The unified theory that he came up with was called Operant Conditioning. Operant Conditioning is unfortunately a little too complex for me to cover in full depth today, but there are two main things I'd like to highlight. It is easier to change your habits with reinforcement than it is with punishment. So do something nice to yourself when you get it right rather than doing something mean to yourself when you get it wrong. It's more effective. It's science.

I like to think about reinforcement versus punishment when I'm framing goals too, so say what you do want to do rather than what you don't want to do. Like “I want to use keyboard shortcuts more” is better than “I want to stop using the mouse so much”. The other thing about rewards is that when you reward yourself, it really matters. So the closer you could do a reward to when you're actually trying to do the behavior that you're trying to change, the easier it is to make the connection in your brain between those two things. If any of you have ever changed the dog, you know that you can't just push down on the dog's butt and get it to sit and then give it a treat 10 minutes later. I mean, you can, but it's not really going to make the connection. And in our little hearts, we're a lot more like corgis than we maybe want to admit. Rewards don't have to be some huge thing. If you're trying to learn a new keyboard shortcut, you probably don't want to eat a donut every time you use it because that would be a lot. But small things you can do inside the moment or ask your coworker for high five, listen to your favorite tunes, stretch, take a selfie, or if you're working alone, or even if you're not, say good job out loud.

Repetition

Tip number four, repetition is key. How many of you have heard it takes 21 days to start a new habit or 30 days or n days for the value of n? Yes, a lot of us have heard that, but unfortunately research does not back that up at all. If the idea didn't come from science, where did it even come from? In the 50s, there was a surgeon named Maxwell Malts. Malts observed his patients and then anecdotally observed that “Hey, I gave this guy a new nose job” because he was a plastic surgeon “and it took 21 days for him to get used to his new face”. So he came up with this theory that it takes 21 days to form a new habit. And he wrote this book inexplicably titled, ''Psycho-Cybernetics'' about that theory. ''Psycho-Cybernetics'' was at the forefront of the like self-help book movement and it is super popular, like it's still in print today. And a bunch of other self help authors picked up the idea from there and just kind of spread out. But if science doesn't say it's 21 days or 30 days, what does science say?

Well, one study I found said it took between 18 and 254 days to start a new habit, which is hell of depressing. But one good thing or one quote I'd like to call out is that ''Missing one opportunity to perform the behavior did not materially affect the habit formation process.'' So you're going to screw it up. It's okay. And if you expect to screw up and just focus on getting back on the horse, it is much better for your habit-building than expecting to never fall off.

Reminders

Tip number five, reminders. Reminders can help us do the new thing that we're trying to do. I found a study about reminders that was also related to medication because for whatever reason, a lot of the studies about changing your habits have to do with drugs. One of the things the study was looking at are what are the most effective reminders for somebody who's trying to take any medication at nighttime? Is it a smartphone app or a note on your bedside table? A note on your bedside table is actually a lot more effective because reminders are more useful in the context where the behavior is already performed. And it makes common sense, because if you're already in the place where you're trying to do the thing, there's just less of a barrier to actually getting it done. So for your tweeting and photographing pleasure, here's all the tips on one handy dandy slide.

Identify Bottlenecks

What happened when I tried to put these tips into action in my own life? Well first, I needed to figure out what habits did I actually want to change. So is it a one-on-one with my manager talking about how I wanted to be more efficient and write more code. And she asked me "What do you think your roadblocks are?" And I was "Well, I feel like I'm fighting with my IDE and my editor, my dev environment all the time." And she was like "Really?" And she was a little skeptical because I couldn't come up with any concrete examples of that. So what she asked me to do was take a couple of days and just write down everything I was doing. And it makes a lot of sense, because if we're trying to performance profile our applications, we actually need data on where applications are slow. Like performance profiling our application, there is a cost to collecting this data and it's not like it's fun to write everything down for three days, but you don't have to do it forever and you can learn a lot in a small amount of time.

I also did this on paper because I didn't want it to get buried in a tab somewhere. So I thought that I was really struggling with my editor, but in reality, my bottlenecks were not being sure what to work on next after I finish a task, getting stuck while debugging, getting frustrated and then getting distracted by the internet, which is honestly a little embarrassing but I'm sure I'm not the only person in here who gets distracted from time to time. And you got to start from where you're actually at and you've got to start small. I knew if I tried to change everything about my workflow, I was going to fail. So I picked just one thing, which was my biggest bottleneck, just getting stuck while debugging.

Write about It

Then I made a written plan. So “Don't get stuck while debugging” is not very specific, measurable or actionable. And there's a lot about that that's not inside my control.

How could I make this into something that was actually achievable? Well, another thing I really struggle with is asking for help. I'm one of those people who will just beat my head against the wall when sometimes my teammates have contexts that could unstuck me pretty fast. So what I decided to do was set the timer, and if I'm stuck for more than 15 minutes, ask for help from a teammate. Now teammates have their own lives and problems. So I figured I would ask for help asynchronously, over slack, so that if they're doing something else, they have the option to ignore me. And that also factored into my, if/then plan about what might go wrong. So if nobody got back to me within 10 minutes, then I would write down my question for later and work on something else. This also required me to keep a list of more things to work on, like incremental refactorings and things that might not be my highest priority but would give me something to work on if I couldn't work on my top thing, and attacking the problem from multiple fronts.

Visual Cue

I'm pretty into bright colors as you could see and affirmations. So my reminder that went on my monitor in the context is some affirmations that I would figure it out and that people care about me and want to help me. My reward would be to sneak off to the quiet room and use a self-massage tool for two minutes. I told my manager about this plan and she was pretty supportive. And we also set a time to check in, in the future, in about a month just to see how things were going. Because like in my case, I would have a built-in check in next time it was time to go up for promotion, but I didn't want to wait that long in case this plan really didn't work.

Evaluate

So how did it go? Well, I really wish that Pinterest had been using GitHub because I wish I could have looked back on my contribution graph during that time. Pinterest is using a competing product that didn't have a contribution graph, but if they had been, I'm sure it would've looked something like this because, with these and some other changes that I made, I was able to meet my goal of doubling the amount of code that I was writing, which was awesome. But unfortunately, I still didn't get that promotion because I left Pinterest to join the Atom team at GitHub. It was a really tough decision because I loved my manager and my team, but the ability to, or the opportunity to work on an Open Source text editor with some really amazing people and work in JavaScript was really appealing to me and I couldn't turn it down.

When I joined the Atom team, my mind was blown because I learned about all these things that a text editor could do that I didn't know about before. What I'm working on now is combining my knowledge of how to change habits with the new editor features that I worked on so that I can write code even more efficiently.

Caveats

Now, I'm going to tell you about some editor tricks. So caveats. I'm telling you about Atom because it is the editor that I work on and use. However, what editor you choose to use it's a really personal choice and most editors have pretty similar feature sets. Even if you don't use Atom, you should still be able to get the benefit of a lot of these tips. It's just that the specific keyboard shortcuts, implementations entry points will probably be different.

Speaking of keyboard shortcuts, I'm going to tell you the keyboard shortcuts for Mac because that's the operating system that I use, but if you're a Windows or Linux user, it is Control instead of Command and Alt instead of Option and then things should still pretty much work as expected.

Command Palette

How many of you have used a command palette? I used to think the command palette was the thing that you just had to open to install packages in Atom, but then I learned that what the command palette is really useful for is shortcut discoverability. So let's say that you did what I did and you wrote down everything you're doing for three days. You probably have a list of things that you do a lot. Using a keyboard is a lot faster than using a mouse in most cases. But how do you know what keyboard shortcuts exist? With the Command palette, you can open it up with command+shift+P, start typing something that's like the thing you're trying to do and then you can see what shortcuts exists. That'll save you a few seconds that add up over time for the things that you do a lot. What if a shortcut doesn't exist? Atom allows you to BYO by which I mean bind your own, of course. So you can not only add shortcuts that don't exist, you can take existing shortcuts and change them.

In this example, I rebound the shortcut for delete entire line to be a two-finger shortcut instead of a three-finger shortcut. Binding your own shortcuts is slightly complicated because the shortcuts are different depending on where you are in the editor. So I don't have time to cover it in full depth, but there is a link to some documentation at bottom of the slide. So if you are interested, the documentation is thorough and would encourage you to check it out.

Multi Cursor

The killer use case for multi cursor is when you're doing the same thing to different elements within text. So in this example, I have a bunch of react components that take a prop named command that I'm changing to new prop name because this isn't a contrived example at all. But I swear I really, I do this kind of thing in real life all the time. So if you highlight the text you're trying to select or the first instance of it, and then hit command+D and to all the other instances are selected, then just start typing the new thing that you want.

Snippets

Snippets are ways of generating code from a shortcut which are very useful for anything boiler plat-y. However, if you're learning a new programming language or a framework, I would caution you against the use of snippets because I think that sometimes typing things out the hard way or the long way kind of helps get the syntax into your brain. So in these snippets, I have the name of the snippet, the prefix, which is the thing that you actually type, and then the body, which is the code that gets generated. And on the next slide, I'll show you how I use these to generate test boiler plate. So you start typing the snippet, hit Tab and then boom, I have the framework for some Mocha tests in much less time than it otherwise would have taken.

The other killer use case for snippets is live coding in talks because typing while someone else is watching is the hardest problem in computer science. And I guarantee you your audience is not riveted by watching you make typos and you don't even, you don't have to come up with all the snippets for yourself. Atom and most other editors have a pretty rich community package ecosystem so you can just search for snippets for whatever shortcut or whatever language that you're using and install them.

Code Folding

Code folding is useful for folks who might get distracted or overwhelmed by visual clutter on their screens or just have limited screen real estate. Folding allows you to collapse and expand the text that's inside of a block. You can fold it and unfold all in Atom with option+command+shift open bracket or close bracket.

Symbol Finding

Symbol finding allows you to jump straight to a function with a specific sub string in the name. So in this example, I had a long module that was doing a bunch of Git stuff and I knew I wanted to go right to the function named commit. I didn't just want to command+F, find commit because that would give me a bunch of variables and parameters and things I didn't want. So I hit command+Rd to bring up the symbol finder, typed commit and then jump straight to where I wanted to go.

Moving Lines

You can move entire blocks of text with command+control+up and command+control+down, which is faster than massing and it preserves indentation. And it's kind of fun in this weird way that I can't really explain.

Git/Github Integration

The part of Atom that I specifically work on is the Git and GitHub integration. So I'm really excited to talk to you about that. Switching contexts between the command line and your editor and switching context in your brain, it takes time. You can do most of the things that you want to do with Git right in your editor, like making a commit, making a branch, pushing, pulling, amending and publishing. I'll show you how. This is kind of a complicated UI, so let's break it down.

On the left, you have a diff view that's similar to what you'd get if you ran get diff on the command line. On the right, we have a staging area that shows the different files that have changes and whether or not they're staged. On the bottom, we have a commit box where you can type your commit message, actually make a commit and then see a list of recent commits. And on the bottom, we have all the branchy things like pushing, pulling and creating a new branch.

One thing that's much easier with this UI than on the command line is partial staging. So partial staging is making a commit when you have some other changes that you don't want to be in this commit just kind of hanging out. It's really useful for if you have a team or a workflow where you want to tell a very precise, beautiful story with the changes that come in each commit, which can be easier for people, for your teammates to code over your code. However, some teams don't care about commit level granularity and only care about poll request level granularity and maybe they use a squash workflow. So if you're in the latter camp, partial staging will not be quite as useful to you. I really love that you can stage and un-stage changes or lines of code or hunks of code from the diff view because it has saved me the time and embarrassment of checking in numerous console log statements.

And you can even resolve merge conflicts right in your editor because show of hands, who loves merge conflicts? So one thing we've been putting a lot more time and love into recently is the GitHub functionality. So if you're using Atom and you're working in a repository that has remotes hosted on github.com, you can see a list of open pull requests. Let's say you get curious about one and you click on it, then you can see the description, comments people have left, build status and a list of all the commits. But the real, the killer feature of this is that checkout button because reviewing code is so hard. When I'm reviewing teammates code, I'm trying to put together an abstract picture in my head of what it's doing it. It's so much easier if I can check it out myself and run it and drop in logging and statements and just see what the heck is going on, because I'm a kinesthetic learner. And I know that Git allows you to pull down remote changes on the command line, but I'm busy, I don't want to remember that magic incantation. The checkout button saved me time and made me a much better code reviewer.

Markdown Preview

Shifting gears away from getting Git and GitHub stuff, Markdown Preview. Markdown is a formatting language that a lot of folks use for documentation and read me's and things like that. But I think, if you don't write it every day, it can be hard to remember what the different formatting syntax is. So by using control+shift+M you can see what the markdown will look like in its final form and write documentation more easily.

Teletype

The last Atom feature I'm going to tell you about his teletype. Teletype is a feature that allows two people to type in the same text buffer. So it makes it easier to pair program or collaborate with your colleagues. Because I got such a productivity boost out of collaboration, it would feel remiss not to include collaboration tools in my productivity tips. I'm just going to show you this video because it explains teletype way better than I ever could.

It's pretty cool. We use it all the time. Anyway, in order to keep making Atom more awesome, we need your help. We're kicking off a user research program, so if you're interested in participating in a user interview, I'd love for you to sign up at this link. And even or especially if you don't use Atom, your perspective as a new person or someone who's not familiar with the UI is incredibly valuable to us.

Conclusions

In summary, here are the most important things that I learned from this process of trying to change my habits. So refactoring your habits is an iterative, incremental process and you can't change everything at once, nor should you. But allowing myself to pick one or two things that I'm focusing on, allows me to not be anxious about everything that I'm not focusing on right now and just trust myself that whatever small changes I make will add up over time and I'll get to everything eventually.

So you're lying to yourself about how you're spending your time. Just like how I thought that I was spending all this time fighting with my editor, but really I was fighting distraction. It's okay, we're all lying to ourselves, but you have the option to record how you're actually spending your time so you can get truthful data about what you need to change. My quest to improve my code output, let me question everything in a good way. Why did I want to write more code? Well, I wanted that promotion. Why did I want that promotion? As somebody who does not have a traditional CS background, I'm insecure about my skills and I was working under the assumption that getting a promotion would help me feel more secure. But that's ultimately a faulty assumption. Sure, it would provide a temporary boost to my self-esteem. But to really fix insecurity, you need to attack it at the root and not just rely on the tech industrial complex of validation because there's so much about the promotions process that's outside of your control.

Engineering productivity is so much more than how many lines of code you've written because if you write a million lines of code and it's on a product that no one needs, you're solving the wrong problem, that's not actually very productive at all. I'm not trying to knock my old manager because she's amazing, but I think that it's so easy as leaders and engineers and managers to over-focus on how much code am I writing because it's easier to measure than how much value I'm bringing. Of course, I still care about writing code and how productive I am in that regard, but I'm shifting my focus back to try to do other things that are adding a lot of value to the team, like kicking off this research program, like mentoring. So at the end of the day, go forth, try to change your habits and become a better person. But don't forget to be kind to yourself along the way.

Questions and Answers

Man 1: Is there a limit to what you think you could change with some of this methodology?

Thurium: So since its methodology, it's something you could use to change many different kinds of habits - . Can you say more? Can you tell me more about what you're asking? You want to make sure I'm answering the right question.

Man 1: So things like can I change the way I drive to work or is this something completely applicable outside of just learning a new skill?

Thurium: Yes, I think you could absolutely change. What do you want to change about your driving?

Man 1: Less frustration along the way.

Thurium: Yes, I think you'd need some data about what actually is frustrating you and then you need to make it specific, measurable and actionable.

Man 1: Am I maybe lying to myself that it's the route?

Thurium: Yes. Something like that.

Man 1: Could be.

Woman 1: You mentioned the GitHub [inaudible 00:31:07] particularly pull requests for Atom. Is that available for GitHub enterprise as well or is it just public GitHub for right now?

Thurium: It's not available for GitHub enterprise. We'd like to do that. It's on our list of features we'd like to support in the future.

Man 2: You talked about not lying to yourself and sometimes the reason why we lie to ourselves, it's not just a simple habit, but there's actually a psychological reason why we're lying to ourselves. So how do you tackle that?

Thurium: Therapy.

Man 2: It's not usually that bad.

Thurium: Well, I don't think that therapy is just for “Oh my life's gone horribly off the rails!” I think that, even if you're doing well or doing okay, just having someone else who's a professional to reflect ideas off of can really just be helpful for everybody. So I basically recommend it, no matter who you are.

Woman 2: So you mentioned at the beginning that you were mentoring and helping new grads. Was that not taken into account at all by your manager in your appraisal?

Thurium: Somewhat it was, but I think that I had agreed to take on too much, I think this is the root of that problem. I shouldn't have been mentoring new grads and interns at the same time. That was a bad choice on my part. So yes.

Woman 2: You're blaming yourself again there, though aren't you? I mean, nor should they have given you more than you could do.

Thurium: Well, my relationship with my manager – and I imagine most people once you're software engineer – it’s not just “Do this”. It's a collaborative back and forth conversation about how much you're taking on. So I think that's a shared fault.

Woman 3: Sometimes the process to become more efficient or make progress iteratively, as you have mentioned, becomes more of a team effort; a multi-person possibility instead of it just being “I rely on a friend for something I want to improve”, but it's more of multiple people might want to make changes at once. Do you have any suggestions on how to do that more from a team perspective?

Thurium: So your question is how do you change your goals as a group?

Woman 3: Yes, exactly.

Thurium: There's one other person who's not on my team, but is on a sibling team that also is very goals-focused, and even though we're not working on the same stuff, we have a meeting every two weeks, because at GitHub, we use repositories and issues for everything. We have goals repositories that we share with one another and issues that have weekly goals so that we're just continuing to regularly check in with one another. And that would be one kind of a structure for how you could have a social accountability or change goals with someone other than your manager. Does that answer your question?

Woman 3: Kind of. It was also from a team perspective, in the sense of me being able to accomplish my portion of the goals doesn't always get the team fully there and that there is an accountability across multiple people to also keep up. So are there any points around like encouragement? Because you say it's better to treat yourself instead of do punishments and stuff like that. How do you try to encourage others to also make that same progress towards a team effort?

Thurium: I don't know. That's a really good question because I think all I can do is try to model the behavior that I want to see. I think a lot of it is on the manager to encourage and reward behaviors that are collaborative rather than rock stars. But I think, yes, as an individual contributor, other than giving people honest feedback about how their behavior is impacting me and trying to be the change I want to see, I don't know what else to do.

Man 3: You talked about logging your time to get data on where your time's going. What's the right level of granularity of time granularity to log?

Thurium: I logged every time I did something new and roughly how long it was taking. I think that, even if you did 15 minute increments, I would probably still get you pretty granular data, but you can adjust up or down depending on how much of a pain in the ass it is.

See more presentations with transcripts