So basically, what you guys are saying is for yourself, Riri, in terms of work, you're doing tasks, but you still have the obligation, so to speak, to the code your view. And so how you made that easy is to create a separate, you created a clone of the codebase, one is dedicated to code your view, and then one is dedicated to doing your tasks. And then for your case, Jonathan, how you solve this matter in terms of how to make it easiest, you spend your quiet hours on focus work.
And then a certain part of your day, you dedicate to code your views, meetings, collaboration, and so on. That sounds good. I think those are really good, if you like, applications of how to make, have it easy.
So yeah because especially for us, we've discussed in other episodes, code review is really important, you know, so it's kind of the thing that you, I guess, you do for others, and you also appreciate when other people do it for you. And so yeah, definitely thinking of ways on how to make it easy, how to make it easier for you to contribute to other people's work is a good thing. Hi, I'm Kara Yves Cadelina, HR Director of Good Frontend OPC.
We're here at Camp John Hay, Baguio City for a week of personal development. Together with a web developer, we feature our Goodfrontend podcast, inspired by James Clears's Atomic Habits. We'll dive into practical strategies for building effective habits, breaking bad ones, and transforming your life one tiny step at a time.
Let's get started on this journey of growth and transformation. Hey, guys, welcome back to the Good FrontEnd podcast. And today we are on episode four of the Atomic Habits series.
The topic for today is the third law, which is to make it easy. I guess the big idea is, it's about reducing friction and complexity when you are trying to perform a habit, so that it's easier for you to do that habit. I guess the things that we will cover, there's the two-minute rule, there's the environment optimization, there's the motion versus action, and things like that.
Maybe we can start with the first concept, which is in chapter 11. I'll just read a quick summary. And it's called Walk Slowly, But Never Backward.
James Clear introduces the concept of motion versus action. He says, many people get stuck in motion, which involves planning, strategizing, and thinking, rather than actually taking action. Clear argues that to build a habit, you need to focus on doing the action itself, even if imperfectly.
He emphasizes the importance of repetition over quality in the early stages of habit formation. The key is to start, no matter how small or imperfect, because the frequency of action matters more than how well you perform the habit at first. Do you agree or disagree? Actually, yes, I agree with that.
At least in my opinion, I have some kind of work flow. So, instead of planning things, I actually just prototype. I just prototype it quickly, I just write the things, and just create a working environment, working script, just something that works.
Because planning, if you just try to plan without actually trying to build the thing, sometimes it fails, sometimes it succeeds. But for me personally, I just try to prototype quickly. This to me sounds like the argument around waterfall versus agile, which is basically like the waterfall methodology is all about making sure you plan everything.
It's as in, it works like a waterfall, whereas agile starts from the ground, you build up. Do you all agree with that statement, or does anyone disagree? Would there be a case where you would say, maybe it's good to plan, strategize, and think before you actually take action? For my case, I think I would have, there were cases before where I would take tickets that I have no idea about. For example, one example would be payment, payment related tickets.
Usually, we have a third party for that, and sometimes I would have zero knowledge of this third party. So, I think there's some merit in researching before actually taking action. But at the end of the day, you have to actually implement something in order to know whether you did it right, if it's working.
And if it doesn't, then you learn by failing, through failing. Yeah, there's this term we use, it's called analysis paralysis, which is when you spend so much time analyzing the problem that you're just paralyzed because you're stuck to trying to find a perfect solution. Actually, this is very common in a lot of places.
For example, in learning, there's a lot of resources out there in the internet, and then someone starts to learn, let's say, programming, web development. And because of so many resources out there, they're stuck into thinking what's the best resource out there, instead of just doing the work. And they're just stacking all the resources.
Yeah, collecting them in bookmarks. So, I think it's better to just do it and find out. Yeah, and I guess it's, I mean, it's not even a bad thing.
I mean, even with a payment, for example, it's not like you can't iterate and refactor, right? So, I think it is a nice practice to just get on with it. Just get started, even though it's imperfect. Implement something, create a draft PR, let people comment on it, and then you just improve over time.
Yeah, sounds good. So, let's go to chapter 12. Rather than me summarizing, maybe does someone want to be a volunteer and summarize this chapter, the law of least effort? Maybe I can summarize.
Basically, the law of least effort says that when a person is presented with two options, we usually, almost always, go with the more convenient and the easier option. Okay, nice. So, people will always choose what's easiest.
Yeah. I think it was mentioned in some previous episodes that motivation is overrated. So, however much you're motivated to do something, however much you want it, sometimes motivation is not enough.
So, no matter how motivated you are, at the end of the day, we tend to choose whatever is easiest to do. So, if you're motivated to do something so difficult, it does not, your motivation does not matter. Yeah, sounds good.
I guess, in terms of work practices, what I can think of is breaking down a big task into smaller tasks, mainly because it's just, yeah, there's just so much information overload to take if you're trying to handle something that breaking it down into smaller tasks is a helpful way to try to tackle the problem one bit at a time. Yeah, actually, I try to just create a bunch of to-do lists of what I'm going to do. Let's say I'm taking a ticket that I'm working with and I just created this branch, small branches of, let's say, from a big problem and then chunk it into smaller problems, and if those smaller problems are still kind of difficult to do, then I'll try to create more branches of those smaller subsets.
Sounds good. How do you think changing your environment can help with making things easy, I guess? What would you, if you can think of, let's say, an example at a work setting, how can you make something difficult? Because, I mean, software engineering is inherently complex, you know, it's something that is inherently complex, otherwise everybody would be doing it, right? It's an item that is inherently complex, but what would you say is your ways of trying to make things easy for you and how do you, I guess, rearrange your environment to do that? Maybe I can give my personal kind of environment. So, I like to use startups, right, where I just, when I open my desktop or my Mac, it just starts things up, right? Let's say my terminal and my browser, Slack, and other work-related things, right? And also, my terminal itself also has some kind of startup.
It creates three tabs automatically, opens the project directory I'm working with automatically and so on, and that kind of automation helps with reducing that friction of just getting started, right? Because it's already in there, you can start immediately. And yeah, I think that kind of reducing friction is essential, at least for me. Yeah, so you're basically sort of automating the startup of these things as much as possible.
Sounds good. Anything else from anyone? How do you think, how else does this concept apply in software engineering work? Well, previously, I did encounter some friction. When I work, I tend to dislike switching context, basically.
So, when I develop a ticket, I tend to finish all of it before reviewing somebody else's work. But sometimes, a ticket can take so long that you're no longer reviewing somebody else's code. So, what I did was, to reduce the friction of context switching and switching from one branch to another, stashing your changes, I basically made two copies of the same codebase.
One is for, solely for development, and then the other one is for code review. So, I think, in my mind, even though I am context switching, there's still some attachment. So, if I see this window with this branch name, this is the context it is working on.
And when I see this window with this branch name, this is somebody else's code that I'm reviewing. So, I think that helps. Yeah, I think I can add something on that.
Since, based on my experience, I tend to work on early hours, since we're working differently, right? So, we're working with teams from other countries, right? So, I'm working around 1 to 10 or 2 to 11 p.m. And most of the time, I work mainly focusing on coding on the 1 to 4 or 5 window range. Since after that, there's so much meeting, you can't focus on coding. So, I tend to do as much as possible in that time range.
And then after, on the meeting window range, then, yeah, you can do code reviews or something easier to handle while having the meeting, yeah. Yeah, okay. Sounds good.
So, basically, what you guys are saying is, for yourself, Riri, in terms of work, you're doing tasks, but you still have the obligation, so to speak, to the code your view. And so, how you made that easy is to create a separate, you created a clone of the code base. One is dedicated to code review, and then one is dedicated to doing your tasks.
And then, for your case, Jonathan, how you solve this matter in terms of how to make it easy is, you spend your quiet hours on focused work, and then a certain part of your day, you dedicate to code reviews, meetings, collaboration, and so on. Yeah, that sounds good. I think those are really good, if you like, applications of how to make a habit easy.
So, yeah, because especially for us, we've discussed in other episodes, code review is really important. So, it's kind of the thing that you, I guess, you do for others, and you also appreciate when other people do it for you. And so, yeah, definitely thinking of ways on how to make it easy, how to make it easier for you to contribute to other people's work is a good thing.
Yeah. Okay. So, next one, the final chapter, I guess, on this one is chapter 13, and the title is how to stop procrastinating by using the two-minute rule.
Now, I've heard of the one-minute rule, which is if you drop something on the floor, it's not yet a minute, so you can still eat it. But I've not heard of the two-minute rule until I've read this book. So, maybe someone, does someone care to explain what the two-minute rule is and how that relates to habit formation? The two-minute rule basically says that when you start a new habit, a new behavior, it should take two minutes or less to make it easy to do.
Right. Sounds good. So, basically, any habit you try to start, you try to do it two minutes or less.
Now, I'm struggling to try to connect that into software engineering. Let's say you're trying to learn a new language. How would you put that into application using the two-minute rule? I mean, I guess you could block out the two-minute time block to learn a language.
But I think the point of the two-minute rule is to get over, to just start something, right? And once you've started, it's easier to continue doing something rather than stop it. So, if you've learned something for two minutes, the most likely scenario is you're going to keep learning. Yeah, yeah, yeah.
I guess it's about starting something. I actually do know someone who wanted to learn Hebrew. So, how he did it was, yeah, he started with a two-minute rule.
He just read, tried to read a little bit of Hebrew every single time, even if it's like a sentence a day, and then two sentences, and then three sentences. Yeah, I guess something is better than nothing. No, sounds good.
Can you think of maybe an example where you managed to overcome procrastination using the two-minute rule? At least for me, I wouldn't say that I personally use the two-minute rule, but in my case of procrastination is just to be in a community, right, filled with people. And basically, how I procrastinate is just seeing problems asked by other people and just try to solve them and then help them. And actually, that's what I do in my free time.
And if I'm not ready to do something, then I would just try to help someone. But for the two-minute rule, I guess I can link it to physical development. So, let's say you're trying to do push-ups, right? It's quite hard to do, so you're kind of procrastinating it.
But if you just start doing this push-up, then automatically you will just continue longer as long as you just started. Yeah, no, sounds good. I think, yeah, I agree.
It's not so much the minutes, right? It's the idea is getting the smallest number that you can think of and just starting just a little bit. Yeah, exactly. Starting a little bit.
Yeah, I guess in summary, it's about making habits easy, making something difficult easy, which is kind of weird thing talking about making something easy when, yeah, software engineering is something inherently complex, right? But at the end of the day, there are different ways to make something more simple. So, thank you so much, Riri. Thank you, Jonathan, and thank you, Francis.
