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.
