• LinkedIn
  • YouTube
  • Spotify

EP5: Make It Satisfying

In this episode, we explore the fourth law of Atomic Habits: Make It Satisfying. Learn how rewards, habit tracking, and the "never miss twice" rule can help you stay on track and build lasting habits. 🎧 Listen now

Hosts

Guests

0:00 - Introduction: Overview of the Atomic Habits framework and introduction to Law #4.

2:10 - Why Satisfaction Matters in Habit Formation: How positive feelings contribute to long-term success.

3:30 - The Power of Immediate Rewards: Using quick rewards to reinforce good habits and boost motivation.

5:45 - Habit Tracking: How using calendars or apps to track progress can increase satisfaction and keep you on track.

7:25 - Instant vs. Delayed Gratification: Finding the right balance between short-term rewards and long-term goals for sustainable habits.

9:50 - External Rewards and Motivation: How external rewards like recognition or bonuses can fuel your efforts at work.

11:15 - Designing Rewarding Systems: Tips for creating systems that offer ongoing satisfaction and progress.

13:40 - The Role of Accountability: How having someone to hold you accountable can enhance the habit-building process.

15:30 - Accountability in Professional Environments: Setting up systems at work to promote positive habits and increase productivity.

17:00 - Consistency Over Perfection: Why maintaining consistency is more important than perfection, even when you slip up.

19:00 - Making Habits Stick: Practical strategies to ensure continued progress, even on difficult days.

Which we can cover, yeah, I guess there's the idea of, you know, immediate gratification. How do you think you sort of balance those? Do you tend towards delayed gratification or do you prefer to have that kind of immediate gratification? What do you think motivates you more to kind of keep doing a certain behavior? Yeah, I think personally I prefer delayed gratification. So for example, I have this wants that for example a gadget and I want to have it but it's not really practical.

So what I do is, for example, I was able to do the habit consistently. Then I will think of it as a success, a habit formation and then buy the item that I want. Okay, you're saying you prefer delayed gratification, you know, just a hypothetical situation.

Let's say you were working on a project, you work really hard, right? So the bigger the task, the bigger the reward. Well, but you do an all-nighter, you know, you do all of these things and then then you get told that, you know, yeah, you did a great job. We'll give you a bonus two years from now.

How do you feel about that? Hi, I'm Cara Yves Cadelina, HR Director of Good Front End OPC. We're here at Camp John Hay, Baguio City for a week of personal development. Together with a web developers, we feature our Good Front End podcast.

Inspired by James Clear'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. Welcome back to the Goodfrontend podcast.

My name is Kane and I'll be hosting our podcast series on Atomic Habits by James Clear. Now we're on episode five. So it's, well, we've gone through four, two more to go.

So episode five is on the fourth law, which is make it satisfying. So we will be covering chapters 14, 15, and 16, which is focused on the reward of the habit loop. So just a quick summary.

We've got the CCRR, which is cue, craving, response, and then rewards. So we're on the fourth one, which is the rewards, and we'll be focusing on this. I'll give a quick summary and then maybe I'll ask a few questions.

Hopefully we can bounce some ideas to each other. So just a quick summary on this one. James Clear says that the more rewarding a habit is, the more likely you are to repeat it.

So he explains that to ensure a habit sticks, it needs to be satisfying in the short term. So immediate reward plays a crucial role in reinforcing behavior. Then he introduces the concept of habit tracking, which we can cover.

This is the habit tracking is where you have a visual evidence of your progress, and it helps maintain motivation. And also, there is the idea of avoiding to falling off track by using the rule of never missing twice. So we'll cover those concepts as well.

So let's go for the first one. Habit tracking. Does someone want to maybe give a quick brief explanation on what habit tracking is? And I'm curious also whether that's something that you guys apply day to day, whether for work or for personal reasons.

Yeah. So I think personally, I use a to-do list for my habit. So I have a template using a tool called Obsidian.

So every day, it automatically creates a template for that day. For example, this template consists for your exercise or your things to do every day, then I have to check it every time I finish those tasks. So Obsidian is a to-do list, is it? It's a note-taking app, I guess.

Oh, okay. Note-taking app. So I use it as well for templating and to-do list things, something like that.

Okay, cool. Cool. Nice.

Nice. Anyone else? Do you guys do any form of habit tracking at all? Yes. For me, I use Obsidian as well.

So for me, I use the Obsidian for tracking my habits. Let's say in software engineering, if I learn something new, I add it to my journaling and it will turn into habits and for personal life as well. I'll connect it into software engineering.

If I can improve that, it's like vice versa for it. Cool.

So habit tracking, in a way, I guess, is sort of straightforward because you just try to take note of the various habits that you have as something that is visual.

For the other item that James Clear is talking about, the role of immediate reward. So he says that in chapter 14, he says, Clear discusses the importance of immediate rewards in maintaining habits. He explains that humans are wired to seek instant gratification, so to form lasting habits.

We need to find ways to make them immediately satisfying. I'm just curious with this, I guess, instant gratification. Is it something that you guys, I don't know, whether, is it like a conscious thing? Do you ever consciously attach gratification to the things that you do in terms of work? Or how do you think this can help with just work practices? Yeah.

We can incorporate instant gratification, let's say, after you work or after you finish a task by taking a break or getting a coffee, something like that. Nice. Yeah.

So basically, the reward is the break. Yeah. Or maybe the coffee, that caffeine intake.

Yeah. I think it's really important to add this instant gratification, especially when you're starting a habit, since it was also discussed previously that motivated is overrated, right? So you have to reward yourself by... So instead of when you don't have motivation, you can create a system that rewards yourself, something like that. So yeah.

One thing I want to add to that is that not all habits is very interesting for us in the first place. So especially when developing a habit that would be helpful for us, but not much rewarding for us, I think instant gratification will help us incorporate the habit to the satisfying feeling that we are receiving after doing that habit. So in the long run, we were able to develop a much tighter association of the habit to the rewards that it is giving to us.

Yeah. I mean, in terms of behavioral change, there's this term we use, positive reinforcement and negative reinforcement. I suppose the idea is if something rewards you of a good thing, you keep doing it.

But at the same time, if let's say, I don't know, what example is there for a negative reinforcement? Yeah, I can give an example. Let's say on opening a PR or code reviews, the negative reinforcement that I could think of would be the failed build. Yeah.

It's the opposite of the positive reinforcement, which is the green check that we see on the PRs. Yeah. Yeah.

No, I think that is really helpful when you get that feedback straight away when you are developing, having that CICD pipeline set up correctly. Yeah. It's a way to train engineers how to write good code without having to tell them, because the machine itself will tell you.

So in terms of practices, do you think a bit like the CICD pipeline where it gives you a green tick when your PRs are good or it gives you that X mark when you create a PR with some issues? Are there any other techniques that you think gives this whole idea of a reward system that you've seen in other projects? I guess it is normal in a work environment that the high-performing developers are given a reward or at least the whole team if they have produced a very efficient and significant product. So sometimes at the end of the project, they are being noticed and they are given a reward. And contrary to that, other underperforming workers were given punishments or sometimes they lost the privileges that they have already.

Yeah. Yeah. Okay.

So basically in terms of like engineers getting, I don't know, maybe like a bonus for doing a good work. Yeah. Delayed gratification.

Which we can cover. Yeah. I guess there's the idea of immediate gratification and there's the idea also of delayed gratification.

Yeah. For you guys, how do you think you sort of balance those? Do you tend to eartn towards delayed gratification or do you prefer to have that kind of immediate gratification? What do you think motivates you more to kind of keep doing a certain behavior? Yeah. I think personally I prefer delayed gratification.

So for example, I have this wants that, for example, a gadget and I want to have it, but it's not really practical. Yeah. So what I do is, for example, I was able to do the habit consistently.

Then I will think of it and I will think of it as a success, a habit formation and then buy the item that I want. Okay. You're saying you prefer delayed gratification.

Just a hypothetical situation. Let's say you were working on a project, you work really hard, right? So the bigger the task, the bigger the reward. Well, but you do an all-nighter, you do all of these things and then you get told that, you know, yeah.

You did a great job. We'll give you a bonus two years from now. How do you feel about that? Yeah.

I guess what James Clare tries to argue is the more immediate the gratification is, the more effective the habit formation is. I do wonder whether you can give a reward too early as well. So obviously, there are instances where rewards are just given too late, you know.

I think if you give the reward too late, whether you give it to another person or to yourself, that delay becomes like a kind of a negative punishment because it's a delay. So it has to be immediate enough. But at the same time, if you give it too soon, I don't know.

I don't know also whether that's a good thing. So let's jump to Chapter 15. So one of the things I thought was really helpful with Chapter 15 on behavior change because he's talking about, you know, how do you actually change behavior, right, that will last.

And he was talking about accountability partners and financial penalties, right. So if you think of, I guess, let's say, just work in general, you know, when you're creating code, what do you see as, I guess, the systems in place that helps you to be more accountable? Especially for you guys, because you work remotely and you work from home, what do you guys have in place to sort of help you to be accountable in terms of making sure that you're constantly performing well? Or maybe what should be in place so that you have an accountability system in place? I think being able to view your KPR or your performance is a great way to be aware of how you've been working in your current field. Yeah, so more metrics.

So for you, having sorts of metrics is helpful for you. I don't know, something like maybe being told of where you fair in relation to others. Like, I don't know.

We don't really do this, but maybe how much points you delivered personally compared to the others? For me, we can have the story points as the contract. Okay. Yeah.

So since it's already estimated, right? When tech analysis is our estimation, we have to vote for that point, right? So technically you have to finish that task in that given period of time. So once you've finished that earlier, then you'll be satisfied.

But once you exceed the time, it's like you will stress yourself out, right? Yeah, yeah, yeah. So basically it's like that kind of system. Yeah, I get what you mean.

So basically what you're saying is using the estimation point and taking it more seriously as a form of contract to say, okay, that's the target, that's the goal. And let's say you measured it for three points. Let's just assume it equates to three days, you know? And so if you're on the second day and you're only 50%, then you know to work hard for the third day to push yourself because at the end, you're the person who estimated the task, right? So yeah, if you're mis-estimated, then yeah, it kind of makes sense.

So yeah, no, I think that's good. So making use of estimations as your accountability system to make sure you're constantly delivering the work that needs to be done is helpful. How about on the side of... I suppose the point system is good from a speed perspective.

How about code quality? What would you say is like the accountability systems that you find helpful to ensure that you're delivering code quality at a certain standard? Yeah, I think I can answer that. So for the code quality standard for accountability, I think code review would be helpful. Let's say we all have each perspective, I guess, since when doing code review, we have, let's say, a nitpicking and the others would be helpful as well.

Yeah, I think whoever invented or whoever introduced code reviews in software engineering is a genius because yeah, it's a system of accountability that is built into, that forces people to write good quality software. I mean, it doesn't guarantee it, but it increases the chances at least. Yeah, no, no, I completely agree.

Is there any specific, let's say, or let me put it this way. When you guys are reviewing other people's code, how would you do it so that you sort of... because there's a way where when you're reviewing, you might get a negative reaction, right? And the whole point of us when we are reviewing each other's code is that we want to create a system that is better than what it might be had you not reviewed it. So what do you do as the accountability partner to make sure that you don't get a negative reaction or you sort of create a culture where excellence is a priority? For me, I try to give appreciation or recognition to the good parts that they have done before I give my criticism.

Yeah, yeah, sounds good. And I also try to ask why they do this and why they write it like that because maybe I am lacking the context. Maybe I am lacking context on what are they thinking while they are working for that ticket.

Yeah, sounds good. So basically, when you're commenting on other people's work, it's more that you're asking them questions. Why certain things are done in a certain way, so to speak.

So it's more like a conversation. Sometimes I add a little emoji that could make the mood lighter. Yeah, yeah.

No, I agree because I think sometimes when you're writing something, you might have meant something. You might have meant it in a neutral tone, but it could be that the person is in a bad mood and then they read it in a negative tone. And so, yeah, emojis are really helpful in terms of conveying whether you're serious about something or you're more lighthearted about the matter.

Anything else would you say is like as the accountability partner would be a good code reviewer best practice to encourage people to change behavior when you see something wrong in their code, to encourage other people's behavior to change when you see something wrong in their code? Yeah, I think for me would be documentation. Since when doing a code review, we have a set of, let's say, documents that corresponds to to code reviewing. We have a system that shows, let's say, the best practices that we follow on the code base and how we do things there.

Yeah, I think adding notes as well in the PR or pull requests. So basically, most of the devs have limited time for review, right? So it would be helpful to have additional notes, especially if it's complex or they have to do a component in their CMS or in their scammers tools, something like that. Then it would be helpful to prepare the data that they needed.

And yeah. Oh, that's interesting. So yeah, you're taking it more from the perspective of how do you make sure you get the best feedback possible for your code review is to, yeah, going back to that other point, making it easy as much as possible for the code reviewer to do their job.

Yeah. And equally, it becomes like a satisfying activity for the people who are reviewing your code because they think, you know, oh, it's nice to read this because everything is already well prepared. It's already written in your PR.

Yeah. No, no, no. Sounds good.

So no, I agree. I think, yeah, using PR templates or good documentation, preparing the data beforehand, providing replication steps and so on are wonderful ways to make sure that it's a satisfying activity to review someone's code. OK, awesome.

All right. Final one. Let's cover the final chapter on this section, which is Chapter 16.

It's titled How to Stick to Good Habits Even When Life Gets Busy. So in this final chapter, Clear addresses the challenge of maintaining habits during busy or stressful times. He suggests using never miss twice as a rule, allowing occasional slip ups without letting them spiral into habit breaking failures.

The focus is on consistency over perfection. Clear also highlights the importance of having simple and flexible habits that can adapt to different situations, making them easier to stick to. Even when life gets unpredictable, then it's easy to stick to them.

So this whole idea of never miss twice as a rule. I'm curious, is this something that any of you guys have any experience of or can think of a good example on how best to illustrate it? Yeah, I think for me personally, so I exercise daily, but Sunday would be rest day. Right.

Yeah. So it's a one day rest. Then Monday you will have to exercise again.

So you will you don't you will not have to miss twice. Right. So I think that's a that's my system that I am comfortable with.

Something that you think it would be tiring for doing it multiple times a day. Yeah. Then you have a rest day for one day and then do it again for following week.

Yeah. It's I guess it's something like cutting yourself some slack sort of thing. Or, you know, I don't know if anyone's a big gym fan, but yeah, people have cheat days and so on.

So they have like super strict days of having, you know, healthy meals, but they reserve one day for what they want to eat, whatever they want. Yeah, that sounds good. What's what strategies do you use to prevent missing important work related habits twice in a row? Do you do anything specific to make sure that you consistently attend signups or is any one here misses stand up regularly? What do you do to do you keep any specific strategies at all or, you know, just to make sure that you're always on standups, you know, the regular meeting cadences, attending demos, retrospectives, or do you think that all these habitual rituals are a waste of time? What's your general view about about those? I think for software engineering or the agile process we have currently, so we have this daily stand up, right? And for example, on a project, we do a two week sprint.

Yeah. And we do the retro estimation and other stuff once every two weeks. So I think this is helpful since for the daily stand up, you will be aware on what the team is doing.

Or like, for example, someone in the B is doing something and your ticket also needs that thing. So you will be aware then you don't have to, you don't have to contact him or her when you miss the stand up, right? So I think it's important to attend those rituals. Basically, it will prepare you as well for working on your tickets or tasks.

Now, I mean, personally, do you guys find it helpful? Yeah, I think the stand up rituals, retrospective rituals, demo rituals, do you think those are good habits or do you think they're a waste of time? Yeah, I think I agree. I agree with all of them. Let's say, for example, the demos, let's say you finish your ticket and the QA team or the business team demoed your works.

And when you see it, like there's no bugs on the demo and the client is happy. And for the development parts or the dev, it is satisfying to see that your task is good. Demos are good because it's a form of reward system, isn't it? I think everyone wants to be sort of appreciated for the work that they are doing.

And so when you have demos in place and you see people satisfied with your work, you tend to be motivated and you're satisfied because you appreciate it. But equally, I mean, if you didn't do a good job and the work is demoed and then the client is not happy about it, then it pushes you to do better because there is a disapproval from the client side. So I completely agree.

I think many people think demos is a waste of time and so on. But actually, no, it's helpful. I think it's only a waste of time if you do the demo, but there is no feedback, whether positive or negative.

So it's important to make sure that when there is a demo, that you have to push for feedback. There has to be a feedback of a negative or a positive feedback at least. So it sounds good.

I think that that pretty much covers all of those chapters. Thank you so much, Jonathan. Thank you.

Thank you, Ericson. And thank you, Adrian.

Related Episodes
Thumbnail image for podcast episode

EP1: The Fundamentals

In this episode of the Goodfrontend podcast, the team dived pretty deep on James Clear's "Atomic Habits," trying to determine how its content is relevant to software engineering practices. They explore core concepts found in the book: compounding effect of small habits, identity-based habits, and the habit loop (cue, craving, response, reward). It reminds engineers how these principles help them develop better habits, creating systems that encourage continuous improvement on the professional level.

Thumbnail image for podcast episode

EP2: Make It Obvious

This podcast episode explores the powerful strategies for building better habits and productivity, inspired by James Clear's "Atomic Habits." Explore the art of building lasting habits in this episode! Learn why cues, habit stacking, and environment design can make more impact than motivation alone. Especially for junior software engineers, these principles can transform daily workflows and accelerate learning. Tune in to discover actionable advice to streamline your journey to success!

Thumbnail image for podcast episode

EP3: Make It Attractive

Making Coding Fun: The "Make It Attractive" Principle Imagine you're a software engineer, staring at a mountain of code. It's late, you're tired, and the thrill of coding has faded. This is where James Clear's "Make It Attractive" principle from Atomic Habits can be a game-changer. Why "Make It Attractive" Matters: * Motivation is Key: Let's face it, coding isn't always fun. Sometimes, it's downright tedious. But if you can find ways to make it enjoyable, you'll be more likely to stick with it. * Small Wins, Big Impact: Break down complex tasks into smaller, more manageable chunks. Celebrate each small victory, no matter how insignificant it may seem. * Reward Yourself: Condition your brain to associate coding with positive experiences. Treat yourself to a short break, a favorite snack, or a fun activity after completing a task. * Find Your Flow State: Discover what helps you get into the zone. Is it a specific type of music, a quiet workspace, or a particular coding challenge? * Learn with Others: Join coding communities, participate in hackathons, or pair-program with colleagues. Sharing knowledge and collaborating with others can make Remember, the goal isn't to become a coding machine. It's to build sustainable habits that lead to long-term growth and enjoyment. By making coding attractive, you'll not only improve your skills but also rediscover the passion that first drew you to software engineering.

Thumbnail image for podcast episode

EP4: Make It Easy

🎙️ Want habits that stick? In our latest episode, we dive into the third law of Atomic Habits: Make It Easy. Learn how to reduce friction, start small, and optimize your environment for lasting change!