In terms of the items that everyone mentioned, for yourself Riri, you know, variable naming and figuring out via the code review, it's very easily appliable. Anyone can apply that because you're just watching out for variable names. For the item that you raised Adrian around about lack of documentation, the solution being raising it in retrospectives and figuring out a solution from there, getting help from teammates to be able to catch those, that's also helpful.
I suppose state management on the other hand is a slightly harder problem to tackle, right, in terms of how exactly do you break from that bad habit. Hi, I'm Kara Yves Cadelina, HR Director of GoodFrontend 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 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 to the GoodFrontend podcast. My name is Kane and with me today is Riri, Renphil, and adrian. This is the first episode of a series we're doing on atomic habits.
It's a book by James Clear and it really talks about how important atomic habits are. It's something that we haven't done before but we're going to give it a go. The idea is that we will just talk about the book together, just have an informal discussion with our software engineers here in GFED, and hopefully we can impart some information that is useful to people.
For this first episode, we will be looking at the fundamentals, which is the first three chapters. We will try to really discuss some of the concepts that are found in the book, but also trying to apply that in terms of how exactly does atomic habit fit in software engineering practices. A lot of those already, of course, are processes that we already have, it's really nice to know that they're actually backed by information that is available, such as atomic habits.
Let's crack on. The ideas in the first three chapters, it's the idea of the power of atomic habits, how small habits compound. Then there's the identity-based habits, and then there's also the habit loop, the science behind how the habit is created.
Maybe we can start with the first concept in the book, which is the small habits, how small habits compound. Maybe one person here can take over and just give an overview in terms of how small habits compound and just the general idea, I guess, that the book is trying to convey. Any takers? Maybe I can share some ideas based on personal experience.
Before I started working on GFED, I had zero experience on React, actually. I tried teaching myself React by going on this website, it's called Frontend Mentor. They give out challenges, it's based on difficulty.
They have free challenges that you can make, you can do. The good thing about it is these challenges, they go up in difficulty. You can start small when you have no knowledge yet.
Then other developers can give you feedback, can give feedback to your solutions so that on the next challenge, you can incorporate those feedback to get better. I guess the idea is that when you're starting, you should start small and then just add on small improvements. Yeah, that makes sense.
Basically, what you're saying is when you were starting out in frontend development, you worked on challenges and you compounded it, and over time, with experience, you got better and better. Yeah, that makes sense. Now, the other one, I guess, that is related to that compounding one, I suppose that's an obvious idea to many people, but what got me curious, actually, when I was reading the book, when it was talking about small habits, was this idea of identity-based habits.
I'm curious, has anyone heard of this idea before the book as well, or were you familiar with it, or it was something that was unique to you that you noticed in the book? Yeah, as for me, it's the first time I read that concept, being identity-based, because initially, I'm thinking of, I want to do this thing, or I have this goal, but I'm not really thinking of how I should approach on doing this goal. So, based on the book, I think it suggests that before doing that goal, you should have an identity, how you should do that, so that instead of thinking of how the outcome, or the goal, you can start having a system, which we'll talk about later on, I guess, and that will also serve as your identity. Yeah, so it's the idea of thinking about what you want to become, rather than the thing that you want to achieve.
And you touched on the idea of the systems over goals, which I suppose is at the heart of what it means to create identity-based habits. Adrian, maybe you can take this one. Do you wanna, expand on this one, systems versus goals.
How would you interpret this idea, why is systems better than setting goals? For me, from my understanding, goals is something that everyone has in their life, everyone has their goal. However, not everyone spends time on planning on how they can achieve this goal, and that's where system goes in the picture. So, when you have a system on how you can achieve your goal, you are making it intentional, and as you are planning, you will encounter the challenges that may occur while you are trying to achieve the goal, and with this, you are having some plans, backup plans, on how to get past through these blockers, and eventually, since you already have a plan or system on how you can achieve the goal, it will become much easier to execute the goal, since you already have pre-planned it, and you know the hinders and what you can do to easily achieve the goal.
There's also one thing I can add on top of that. So, basically, sometimes if we reach the goal, we stop doing our system, or basically, we think that we achieved everything, and then we're back to zero, basically, and the system we built will be gone. But if our system is properly thorough, or we enjoy the system, basically, we can do it again and again, even if our goal is already done, and yeah, we don't have to stress on doing that system since we enjoyed it, basically.
Yeah, it's interesting, isn't it? Because it's kind of, I suppose, goals, you can think of them as projects. You know, a project has a beginning, and a project has an end, whereas a system, it's a process on how to achieve certain things, but it doesn't necessarily have an end. And in terms of software engineering, how would you, let's say, how would you describe, I guess, when would you apply a system? Do you always apply a system, for example? I'm just thinking in terms of projects, because most of our work are project-based, right? A client comes in, they want something done, they want something done at a specific time, but at the same time, the book is recommending in terms of building habits, it's talking about building systems rather than achieving goals.
So, how would you personally say you would marry those two ideas? I think with software development, even though we have kind of different projects, different goals, per se, the systems that we build, they should be flexible in terms of your system should not be tightly coupled with the goal. For example, in our projects, when we open a PR, we have guidelines for opening a PR. Sometimes we are very particular in the format as well of the PR.
Aside from PRs, we have systems in place to make sure we reduce human error. For example, we have ESLint, we have Prettier. I think these systems that we have in place, they're very decoupled from the goal, meaning you can take it anywhere.
Yeah. As for me, we can also increase the scope from software development into a project management base. So, in project management, we can have some agile systems built in that we use.
So, let's say we have a sprint where we have goals that we try to target or to achieve. And by the system we do during sprint planning, we identify the requirements or we talk about the requirements completely and thoroughly so that we don't have to, basically, we might miss some requirements on that goal so that we don't have to repeat doing the same target. And at the same time, when we try to go to the next sprint, we will avoid doing that same problem again since we have a proper system built in.
So, I mean, just listening to what you both were saying, things like ESLint, Prettier, they're systems really that improves quality, right? And project management tooling like Jira, agile practices, they're there to improve delivery and measurement and things like that. But yeah, as a software engineer, how do you balance the long-term view and the short-term view? So, Riri, you mentioned a little bit on this already, which is thinking about extendability and so on, but I just want to get more practical, I guess. So, if a client comes to you and they say they wanted for you to build an e-commerce website and they need to launch it in six months' time, what's the considerations that you would have in mind when you're thinking, okay, how do I build this in a way that is extendable, considering the long-term and short-term ideas? Maybe the long-term ideas might not even be in the client's mind at that moment, because the only thing they're thinking is, oh, we want something in six months to be able to sell stuff.
But at the same time, we know there are things that will come based on our experience. So, how do you tend to balance the tension, I guess? I think, since Renphil mentioned it earlier, we plan ahead. We are given the requirements ahead of time, and then we plan for the requirements.
But at the same time, we have to think about what else might the client want, or what else can this system, can this project have in the future? And then your solution should be built around having a flexible code, per se. Sounds good. Just to add on top of that.
So, sometimes when we do spring planning, our clients give their requirements, the deadline can be tough or tight. So, sometimes, even if we want to be flexible in our code, we don't have the capacity to do so, due to time constraints. For those cases, documentation would help, so that the next person can use the code that you did.
They will have an idea how they can improve it, if they have enough additional time to improve the codebase you did. Yeah, sounds good. Let's move on to the science, I guess, of habit formation, since we are talking about the fundamentals of atomic habits, which is the cue, craving, response, and reward.
So, we'll focus on this idea. So, we've just sort of briefly covered how small habits compound, we've briefly covered identity-based habits, and we heavily focused on systems over goals. But now, let's have a look at this habit loop, I guess.
Maybe, can someone expand on what the habit loop is, the CCRR, and just briefly give a quick description over it? Yeah, I have an idea for this one, habit loop. Basically, it's a cycle with four steps, cue, cravings, response, and reward. Cue is something that triggers you to do the habit.
Maybe it's something environmental in your setup, or something that you notice that makes you notice the habit itself. The next one is cravings. It's the desire to do the habit itself.
Maybe it's something that satisfies you, or something that rewards you after doing the habit. Well, the next step is response. It is how you respond to this cue and cravings, and how you can do the habit that you want.
Basically, it's how you respond on how you obtain the reward itself, while the reward, it is the one that satisfies you once you are able to do the habit. Basically, the cue is the first point that you notice, let's say, the reward. Since in this habit loop, reward is the most important one that makes us consider the habit very doable, while the cravings is the desire for you to have that reward itself.
Response, basically, it's just how you do or how you obtain that reward itself. Does someone want to perhaps apply that in software engineering? Give an example of that habit loop in either a system or process in software engineering. Yeah, I can go on that.
For me, I'm also basing on the book. There's a section there that sometimes the habit loop does not necessarily start. Habit loops can start because of previous misses or failures.
That's an example for me. Also, there's a concept on the book called feedback loop. If you can start, the habit loop can be started, just for an example.
From your previous feature that you did, a QA might notice some bugs due to a feature or browser API that you use, which is not supported in the target browsers that your project targets. Is that the Cue? When the QA notices that something is wrong, what would be the Cue? Basically, that's where the feedback loop starts. Since the QA noticed the issue, now you are conscious that this browser API is not supported in your target browsers.
By the next time you try to use the same feature, you will try to use the same browser API. That's where the Cue comes in. I should not use this one.
I should find another way to implement this feature. That will be the craving, so that the QA won't have an issue with the same problem that occurred previously. Is that the reward? The QA not being upset over your code? That's really interesting.
In the Cue and craving also, I got into something called the problems. As for the response and reward, that's what you call it. Problems and solution.
The Cue is that you notice that you use this browser API. The craving is to help the QA, maybe, so that the ticket or task won't be returned back to them. The response you will do is to find out the solution and how to implement it differently.
As for the craving, I'm sorry. As for the reward, it will be the experience or the new... Passing the requirement. Passing the requirement, yeah.
Also, the other alternative. You are able to find another alternative. Yeah, I think there's definitely an overlap, isn't it, between the craving and the reward.
You crave for the reward, and then when you get the fulfillment of that craving, that's the reward. It's really helpful to understand the science behind the habit loop for you then to be able to know how to build good habits, but also how to break bad ones. Now, speaking of breaking bad engineering habits, what would you say is your pet peeve when it comes to bad engineering habits? For myself, in particular, I think during code review, I notice a lot that I notice how the variables are named, because sometimes they're named inaccurately.
For example, if you have a variable that holds a Boolean value, sometimes you can't name it something like height, right? Height is not a yes or no. It's not a true or false. I think naming variables accurately helps a lot with readability of the code for other developers and for future developers on the project as well.
How about yourselves? What would you say is your pet peeve? What would you consider as a bad habit? One thing that I noticed also while onboarding in some projects, sometimes the tickets or the issues are not properly documented. Sometimes when I'm picking up a new ticket, that is out of my scope, trying to help others. I need to get some context.
Since there is no proper documentation, I have to disturb the other developers and ask for context or their help on how I could easily fix these tickets, because figuring it out by myself, it might take time, and it might hurt the development of projects. Instead of me being productive in my time, I have to gather evidence or some clues on these tickets so that I can properly fix and do the solution for it. As for me, this one pet peeve I have in mind is that multiple states in a component.
In React projects, which we are mostly working on, we encounter a lot of states in a single component. For those cases, I would want to break them down or group them and place them into custom hooks so that the related states can be grouped into these custom hooks. At the same time, the component will be linear, and it will be more readable since you were able to group those related states.
Wow. Yeah, that's a complex bad habit. So state management.
Basically, we've got variable naming, we've got lack of documentation, and how shall we say, bad state management. Okay. Those are common problems in software engineering.
Knowing what you know in terms of habit formation, which is the habit loop, the CCRR, key craving response reward, knowing what you know about identity-based habits, knowing what you know about small compounding habits, how would you suggest someone break those habits if they are falling into those traps? I think for myself, every time I open a PR, I think that's my cue. When I open a PR, I immediately review the change files and then sort of read my own code. I'm reviewing my own code.
And since I already know the solution, I already know what's happening, it's kind of hard to judge whether I've named this variable right, whether somebody else understands my code. So other people, other developers would help me a lot if they point out those mistakes. So that's another cue.
If they point out the mistake, then I would want to correct those mistakes and then hopefully get my PR merged. So that's the reward for me. I think code review is really important, isn't it? In almost every mature industry, there's this idea of auditing.
If you were a journalist, there's editors. If you were a software engineer, proper software engineering, there's always this process of code review. I guess it's a great blanket way of trying to catch as many bad habits as much as possible.
So code review is one of the ones that's a really helpful blanket way to catch as many bad habits as much as possible. Is there anything else that anyone can think of that would be helpful in terms of breaking bad habits? I think being aware of these bad habits is the hardest part of trying to break out of it. So I think as a team, maybe having a meeting and something like Retro is very important to us because in these sessions, we can open up the issues that we are encountering.
And as a team, we are trying to solve it so that everyone would be aware about it. And since we are tackling it as a group, everyone can share their thoughts on how we can solve these issues. And actually, just really being aware of the issues or the cues that makes us do these bad habits.
Since if we know the cues that causes us to do these bad habits, we can easily avoid doing this one. Yeah, actually being aware. Yeah.
As for me, we can break the bad habits by starting to, basically, when we try to develop right, we will create this big component or large component with so many lines. And when we try to basically try to review or as Riri mentioned earlier, look into your code again and see how you can improve it more. And maybe, yeah, that's where the time you can maybe make your components smaller, create a smaller component from this big component you just made.
And by using that, you will be able to create a more readable code also, which will help to break this bad habit. Yeah, thanks. I think in terms of the items that everyone mentioned, for yourself Riri, variable naming and figuring out via the code review, it's very easily applicable.
Anyone can apply that because you're just watching out for variable names. For the item that you raised, Adrian, around about lack of documentation, the solution being raising it in retrospectives and figuring out a solution from there, getting help from teammates to be able to catch those, that's also helpful.
Getting help from teammates to be able to catch those, that's also helpful. I suppose state management, on the other hand, is a slightly harder problem to tackle, right, in terms of how exactly do you break from that bad habit. Yeah, I think we did have that problem before in a previous project.
But we solved it by, we had weekly meetings, the front-end team had weekly meetings where we talk about best practices, right. And it was brought up that sometimes you have five states in a single component. So, in that meeting you can discuss, you can immediately discuss with the team the solution that you can come up with to kind of prevent that same problem in the future.
I mean, I think the common strand of thought that I get from the ideas of code reviews, retrospectives, you know, those team meetings, is this idea really of, for you to properly break out of bad habits, often you're unaware of them, is that you really need a sort of a collaborative environment. Yes, and I suppose with state management, it is an experience-based thing. If you don't know, you don't know, right.
And if nobody brings it up, you won't know. Yeah, it is something that's, yeah, it's only through mentorship, it's only through discussion, collaboration. Many people think that, I suppose, software engineers are quite geeky introverts, don't talk to people, but actually, we're probably the most effective ones, are usually the most, you know, are collaborative folks, because otherwise, you end up with a rickety mess of badly managed state, or code that is lacking documentation, or variables that are named with X, Y, Z, or whatever.
So, yeah, I know that is interesting. So, just looking at the key topics, we've covered the power of atomic habits, how small habits compound over time, and we've also covered systems over goals, which is how do you build identity-based habits, and we've covered the habit loop, cue craving response reward. I think that's all of it for the fundamentals, and thank you so much, Adrian, Renphil and Riri.
Thank you.
