EP2: Make It Obvious

Join Kane, Jp, Francis, and Jonathan as they discuss these critical concepts. They will take a closer look at the aspects like:

3:00 Make it Obvious: To begin building a habit, it's essential to make it visible and clear in your environment. The host highlights the first rule of habit formation: by making habits more obvious, you're more likely to engage with them.

3:50-6:05 What's a Cue?: Cues are triggers that prompt a behavior. Understanding cues is key, as they serve as the foundation for recognizing when and how habits form in our lives.

6:21-9:03 Implementation Intention: Setting up clear, intentional statements about when and where you’ll carry out a habit dramatically improves the likelihood of success. This technique helps take vague intentions and make them concrete actions.

9:04-10:25 Habit Stacking: Habit stacking is a technique where new habits are linked to established ones. This helps habits feel more natural and seamlessly incorporated into daily life.

10:34-15:40 Habit Stacking for Junior Software Engineers: The host provides examples tailored to junior software engineers, illustrating how small, productive habits can be layered into existing workflows, leading to skill-building and improved productivity over time.

15:50-18:02 Motivation vs. Environment: The host explains why motivation alone is unreliable. Instead, creating an environment that encourages positive habits is a more sustainable approach for long-term success.

18:03-23:55 The "IDE of Choice" Concept: Environment extends to the tools you choose. For software engineers, this means setting up their Integrated Development Environment (IDE) in a way that reduces friction and encourages productive coding habits.

24:05 Advice to Younger Self: In closing, the host reflects on what they’d tell their younger self about the importance of cultivating these habits early on and focusing on systems that support consistent progress.

This episode is right for software engineers in wanting to develop good habits and systems for continuous improvement. Tune in to get actionable strategies for improving your engineering practices.

I guess it always refers to that original idea of atomic habits, so to speak. Starting small and you keep stacking it, you know. You start small, you stack on top of it, and then there's like this snowball effect that by the time you know, by the time you realize it, that atomic thing that you started off with has now become really huge.

And yeah, it's something that I suppose I would encourage many software engineers who are starting out to consider. Sometimes they think it's too difficult, but actually it's just starting small and then building on top of that. That's the way forward.

Yeah, that's why this section of making it obvious is like, so if you start big then it's not really obvious, right? There's a lot of things that are uncertain, unknowns and so on. That's why starting small and just it's easy to make it obvious to us. So we have this existing habit and then you put another habit, so and then as time goes by you put another thing that you want to do.

Yeah, so the idea is you stack habits and you make the previous habit the cue for the next habit. Yeah, exactly. We should also consider our working devices.

What I mean is our laptops. I think working on a Mac is far better than working on a Windows machine. So do you agree with that? I agree, 100%.

Yeah, I think the last time I used Windows was at least 15 years ago. So it's been a while, it's been a while. I do agree, yeah.

I mean a Unix-based system is just, yeah, it's not comparable for development environments. 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 back to the GoodFrontEnd podcast. My name is Kane and I'll be hosting our podcast series for this six-episode series on atomic habits. With me is Jonathan, JP, and Francis from our GFED software engineering team.

And today we will be discussing the first law in the Atomic Habits book, which is to make it obvious. It's chapters four, five, six, and seven. And really the big idea is to, when you create a habit, you need to make the trigger of that behavior obvious.

So you make the cue obvious. Just a quick summary, as part of this episode, we'll be covering cue awareness, how exactly do you make it obvious, some tactics such as implementation, implementation intentions, habit stacking, and environment design. Let's jump straight to it.

Maybe to start with, what's a cue? Maybe I can start with that. So I can give an example of a cue. So for example, I use an application called Homodoro app, or it's basically using the concept of Pomodoro, where you have four sessions of 25 minutes of work or focus work and five minutes of break, right? So you do that four times.

And basically how I start my work is when I click the start button, I hear a click, right? And that basically cues me to focus in my current task. And after 25 minutes of time, the break timer will start. It rings a bell.

And that's basically my cue for taking a break and getting out of that focus work, right? And that auditory, those sounds that it makes, basically cues me to those two kind of flow. And it kind of helps, or actually does help me a lot. And yeah, I think that's one example that I can think of.

Thanks. Yeah. I guess that's the most common way people create cues when you wake up in the morning, you set up an alarm, it makes a sound.

So it's a kind of similar thing. So yeah, no, it's interesting. I don't use Pomodoro myself.

But for you, you start, is it four blocks that you do four blocks of 25 minutes? Yeah, actually, I adjusted it. So I now kind of have two sessions of 15 minutes of work and then 10 minutes of break twice. So you do a cue to start work, you do 15 minutes of work, and then you get a notification to say stop working, start resting.

You stop for 10 minutes, and then you get another ring to start working again. And then you do 15 minutes and then 10 minutes. Oh, nice, nice.

Nice. Okay, wonderful. Wonderful.

So the main point, I guess, in chapter four of the book is, yeah, you need to make the trigger very obvious. In this case, it's an alarm. For starting new habits, James Clear talks about implementation intention to make it obvious, so to speak, making your cue obvious.

I don't think I've ever heard the term implementation intention, in fairness, outside of atomic habits. So I think it might be helpful just to give an explanation of what it is. Does any of you guys still remember what implementation intention is? Well, I guess from my understanding, implementation intention is basically having the natural, not natural, but maybe the desire or, I guess, intent to do the work.

I guess I can give an example to make this clear. So in my case, unlike Francis, I don't use a Pomodoro. So what I do is I set up my environment in a work environment so that I put my peripherals in a specific position so that I know like, oh, if I see my desk, my setup like this, like, oh, it's time to work.

It's time to do my task. And I think by just preparing my setup and just having a flow, setting myself up for a flow, I think that's one way of having the intent like, oh, it's time to work. It's time to get in the zone, I guess.

Yeah. So it's like you schedule it, right? So you have a specific place and the time and the intent of what you're going to do, right? Yeah. So it's kind of like very deliberate.

So after setting up, then that cues you to work. It's like forcing yourself. I can even say that sometimes the environment, like, let's say if there's too much noise, usually I can't get in that flow.

So whenever I sense that, oh, everything's more peaceful and it's like, you know, when you're in a library, like you go to a library because you want to study in silence. So I guess the same, it's kind of the same for my case on my home setup. So yeah, like you have the intent to just be focused on what you're doing.

Yeah. No, sounds good. So basically it's about being specific in terms of I'm going to do this at a certain time, at a certain location, you know, and just working on it.

Nice, nice, nice. I mean, the other one, I suppose, that James Clear was talking about, apart from implementation intention, when you're starting to build a new habit is this concept called habit stacking. So does someone want to expand on that? How would you describe habit stacking in your own words? Yeah, I think you can.

So habit stacking is when you have an existing or existing habit that is, let's assume it's a good habit, I guess. And then you have to stack a connected or related habit on that one. So that if you saw that, if you do that habit, the existing one, then you know that the cue is there.

It's already there. Yeah. So I'm done with this.

So I have to do this other one, the new habit. So I think that's the essence of that habit stacking technique. So we have this existing habit, and then you put another habit.

And then as time goes by, you put another thing that you want to do. So the idea is you stack habits and you make the previous habit the cue for the next habit. Yeah, exactly.

Yeah. Yeah. Sounds good.

Just to, I guess, dig deeper on this idea of habit stacking, because I do like the idea of habit stacking. How would you propose for, let's say a new software engineer, someone who is more junior, how would you use habit stacking to encourage them, let's say, to improve their code quality or maybe learn a new technology? How would you propose the use of habit stacking for that purpose? Yeah, I think we can always start small first. So as a beginner, so for myself, I am a self-taught for development in web development.

So I started on learning the foundation like CSS, HTML, and JavaScript. And from there, since most of these technologies have documentation, you can go there and then check the examples there and then play around with it. And then from there, you will be able to, I guess, fork or copy it on your local machine.

And then start from there, start from the one that's already existing, because you don't have to stress yourself since you're still new and you don't have to pressure yourself by studying all of this stuff or new technologies that's being used in our industry, right? So you have to start working on your foundation first, and then from there, build the other one. So for example, in our case, we have a React, right? But most of the articles that we see when we say that, how do you learn React? Something like that. They say that you have to learn first the JavaScript and then move up to React.

Yeah, so it's a process of mastery, I suppose. You start by creating a habit of the foundations, and then building on top of that foundation. Once you make a habit out of those foundations, you build on top of it.

And then you build on top of that, and then whether that's a new framework or a new technology and so on. I guess another example of that is, let's say, I'm writing some code, and then afterwards, I will try to review it. So that's kind of one of my habits, to review the code that I wrote, make sure that it's consistent with the layout or the style of code that is used throughout the code base.

And then after that, I kind of stack another habit on top of it, which is to journal or reflect on, basically, what I've done and what the problems I've encountered and what I did to solve those problems. It's a good thing you mentioned styling and the review, because I think this especially applies for frontend, because I think most of us started development, like just learning about code. But I think that as we go on with our projects, for this personal or for work, we usually tend to encounter problems that sometimes are outside the code base.

Example like designs, and then like criterias. And then usually, for me personally, I find myself learning these design systems and other stuff that's, there's not really any technical stuff of them at most. So yeah, I think it's more of like stacking in terms of learning, like you're learning code, but at the same time, you're learning things that are outside of the code.

So yeah, I think that's one way of considering how habitual stacking works. Yeah. So it is, it's, I mean, I guess it's always refers to that original idea of atomic habits, so to speak, starting small, and you keep stacking it, you know, you start small, you stack on top of it.

And then there's like this snowball effect that by the time you know, by the time you realize it, that atomic thing that you started off with has now become really huge. And yeah, I, it's something that I suppose I would encourage many software engineers who are starting out to consider. Sometimes they think it's too difficult, but actually, it's just starting small and then building on top of that.

Yeah, that's the way forward. Yeah, that's why this section of making it obvious is like, so if you start big, then it's not really obvious, right? That's a lot of things that are uncertain, unknowns and so on. That's why starting small and just it's easy to make it obvious to us.

All right. So in terms of cues and habit formation, chapter six of the book, I thought the title was quite attention grabbing. James Clear titled it, motivation is overrated, environment often matters more.

So it's this idea that environment design is much more effective than motivation. Would you do you agree with that statement? Or would you disagree with that statement? I agree with that 100%. I think I related that a lot.

So I like to set up environments. I think I can even say that I romanticize my work environment at most. I like to make the stereotype like when you're a programmer, you have multiple screens and all that.

So I think when you see something like that, let's say you went into an office, you see a desk, it has like two or three monitors and then you have this very, I guess, cool peripherals like mechanical keyboard. I think mechanical keyboards are something that's very popular nowadays, whether you're playing games or not. I think for developers, they're quite the trend nowadays.

So I think when you see those devices, you just want to work, like you feel the intention to work. Yeah. I think it's kind of a spoiler, right? So making your environment very pretty, I would say, is that it just makes you feel good, then you just do better.

And yeah, I also think that optimizing your environment definitely helps a lot. I myself optimize my environment, not only physically, but also my own dev environment. I use some applications.

I use a text editor that fits me and so on. And those kind of environments, just physically or emotionally, psychologically or whatever, just making yourself feel good at what you have is very important. So what's your IDE of choice? Oh, that's a good question.

I don't use VS Code, actually. So I started with NeoVim. So it's a text editor.

It's basically an enhanced version of Vi, an old text editor that contains plugins in order to achieve that IDE-like features of other, like VS Code, so on. And also that kind of environment where I only use the terminal, right? So NeoVim is embedded in the terminal. I work just in the terminal, and that feels great, right? I don't need to change my kind of setup.

I don't need to, say, change to another application to do something. Let's say when I try to, for example, some people use Obsidian to take notes, but that's another application to go to. But I only work in the terminal.

I just use a text file type, like Markdown, and just edit that in the terminal itself. So I don't really need to switch to something else. I just need to do it in one environment, and that just feels better to me.

How about you guys? Do you guys agree NeoVim is the way to the future? For me personally, no. I use NeoVim before. I mean, I use it from time to time, but I think the simpler setup just works for me.

I just have my own VS Code IDE, and then just the built-in terminal from my laptop. I think I work much more effective, because sometimes I use different IDEs for personal projects. I use sometimes the Visual Studio one, the one with the full-fledged IDE.

There's another one called ZED. I don't know if you've heard of that. It's a new IDE for Mac OS only, I think for now, and sometimes even Unity when I do my hobbies on game day.

But when I open VS Code, and then just my stack terminal, then I just know that I have to focus on my current tasks, my day-to-day. Yeah, personally, I do things completely opposite to you. I like things separate.

So I use VS Code normally only for coding. I don't use the terminal features. I use iTerm for that, and then I have to do things in tabs, virtual windows.

Everything has to be completely separate from one another. For the most part, if I'm just opening, let's say, a new code base or whatnot, I prefer to use Sublime because it's faster. But for my main project, I would use VS Code.

How about yourself, Jonathan? How would you describe your digital environment workspace? Yeah, so I think I've customized my setup in Mac OS as well. So I use this code raycast app. So basically, some people call it Spotlight on steroids, I guess, because you can customize each app for a key combination.

So Spotlight is the search functionality? Is it the command space? Yep, that's the default, right? So what I did in my setup is to launch the raycast app to Caps Lock space, since Caps Lock is easier for Pinky, right? So I use it to launch some apps like browser, VS Code, and other work-related messaging apps, right? So basically, I use single monitor. So that's why I decided to look for that kind of key bindings, where you can easily navigate through all your apps on a single screen, right? Because some people may like it to compartment their screen, right? For example, the half of the screen is the browser, and the other half of the screen is the editor, right? So I'm not that kind of guy. So yeah, so I use that raycast, and yeah, I feel comfortable on that one.

Yeah, actually, everyone has a lot of their own environments, preferences, and so on. And basically, I also have a single monitor and use spaces in Mac to just switch different places. Like my space one is for my editor, the second space for my browser, third space, Slack, and so on.

And yeah, it's nice to see that everyone is there. And I think no one has mentioned this before, but I think we should also consider our working devices. What I mean is our laptops.

I think working on a Mac is far better than working on a Windows machine. So do you agree with that? I agree. Yeah, I think the last time I used Windows was at least 15 years ago.

It's been a while. It's been a while. I do agree.

Yeah, I mean, a Unix-based system is just, yeah, it's not comparable at all for development environments. So here's one question for you. And perhaps we will end with this question.

If you were to advise your younger self when you were starting out, what environment design advice do you think you would give to your younger self? That could be a digital environment or physical environment. What would be your environment design to your younger self so that you can be more productive and that you can create good habits? A lot of things, actually. As long as I have cash, that is.

I'll buy three monitors. But no, I personally think that my current environment is my kind of end game kind of thing. And I would say that sticking, as for my younger self, just sticking to what you can work with at that time, what you can just use, whatever is in your own disposal, just use it.

Because at the end of the day, all you want to do is just to do things. That's all. I think I agree with what you just said.

I did mention a while ago that I like to romanticize my setup. But I guess my advice to my younger self is use what works for you and don't I guess romanticizing it has a limit. So in my case, I thought that I need three monitors to be a developer or multiple screens to be a developer.

But you don't really need that. Sometimes you just need your laptop on your lap. It doesn't even need to be on a desk as long as it works for you and the environment gives you this zone feeling, this heavily focused on it.

I think that's the way to go. I think you can also plan. For me, I think it would be helpful to plan your learnings.

You can have a roadmap. Actually, I think it's good to have a mentor since an experienced developer can help you guide. For example, he can guide you on what you have to learn.

For example, you're an absolute beginner. You don't know anything on any programming languages. Then he or she can give you a template, I guess, that you can follow and then follow that.

And since your mentor has the experience and you don't have one, you can stick to that roadmap first and then explore, I guess. Actually, that's a good point. I personally join tech communities and just feel myself in that kind of space of just helping other people.

Just having a community helps a lot. I agree with everyone. I think what works, works.

Adrian from a previous series just has a simple setup, but he's the best out there. Well, the funny part on your responses, we started off with motivation is overrated. Environment often matters more.

Now, we ended up with people telling me that environment doesn't matter. Just work with what you have. Just have people around you who can teach you and mentor you.

For an absolute beginner, you don't have money, right? So, you don't have anything. Yeah, I get it. I think that's the difference between trying to understand something in theory and in practice when you have experience.

Because in theory, certain kids would be advantaged because they would be in the best environment. Let's say they are in the best schools. They have the best equipment.

They have all the rooms that they have. But not everybody starts like that. You just have to work with what you have.

You focus with what you can do at the time. You surround yourself with a community of people that can help you out. Then, over time, you then build an environment that works for you.

That's wonderful. We don't have to agree with everything that's in the book. Experience always trumps theory.

Thank you so much. Thanks, Jonathan. Thank you, JP.

Thank you, Francis.