I think what you'd want to optimize what you have, whilst you have it. When you're young, what you have is energy. Well, as you get older, you have less energy, but you have more wisdom.
So when you're young, you definitely want to be as competitive as you can, because there will be a time when your physical body is not able to really respond to the demand of what you want in your head. You just become slower and weaker. So definitely, if you're in your 20s, be as competitive as much as possible.
I think that actually applies a lot for us front-end devs, because I think in the front-end space, frameworks and all these stuff, they just keep on coming and coming. Updates are just getting faster and faster, sometimes from months to weeks to days. I think we're kind of used to that environment of just constantly learning new stuff and then just catching on, especially if you want leading-edge technology.
Yeah, I completely agree. I think front-end is probably the most competitive space in software engineering in terms of churn of change. It changes so much.
Just because, I guess, it's that part of software engineering that serves the customer, closes to the customer. And yeah, people change. I mean, they change much more frequently than we think, and you always have younger generation coming older, and they're the ones who are spending the money now.
So you have to cater the software to basically meet their needs. So yeah, keeping up with that change is really important. Hi, I'm Cara 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 developers, 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. Hello, welcome back to the GoodFrontEnd podcast. My name is Kane, and I am hosting this Atomic Habits series, and we're on the final episode, which is the advanced tactics.
It will cover chapters 17 to 20 of the Atomic Habits book by James Clair, and with me back here is Riri, Francis, and JP. So our goal for this podcast, I guess, is to try to unearth as much as possible this section, advanced tactics. The big idea of this section is that it's about optimizing and mastering habits to reach higher levels of achievements and maintain long-term progress.
I suppose when you build habits, over time they become less effective, and somehow you need to kind of fight habit formation, so to speak, you kind of need to modify it slightly so that you're continuously progressing. We'll focus on probably three key topics, which is genetics and habits. We'll cover that.
Then we'll look at the Goldilocks rule, and then finally, what do you think is the best way to avoid stagnation, to make sure that you're constantly achieving higher heights with habit formation. All right. So let's start with the first item, genetics and habits.
So my question is, how much do you think genetics matter? Does genetics matter? Yes or no? Yes. Yes. Okay.
Genetics matter? Okay. When does genetics not matter? Well, genetics can dictate, well, it can narrow the possibilities of what your career path would be, something like that. But at some point, you have to help yourself also in order to achieve.
For example, if you have a specific goal, there's a point where genetics does not help you anymore, and you have to work for this goal. Yes. I think I heard something like Africans tend to be quite fast in running because they have the muscle twitch or something like that.
They have a faster muscle twitch, which allows them to build muscle mass and so on quicker. So yes, I guess in that sense, genetics matter. And that just doesn't apply with physical stuff, but also IQ, so to speak, IQ, EQ, and so on.
So that part, you can't do much with genetics. The other item that you mentioned is genetics. I suppose that the code that I remember from the book is that genes do not determine your destiny.
They determine your areas of opportunity. So for example, I suppose if you're good at maths, then there's lots of opportunity for you for maths-related work. If you're quite artsy and creative, then you might become an artist and so on.
Okay, so genetics matter. So in terms of genetics and habits, one of the key points that James Clear makes, I guess, is that when you align your genetics with your habits, then you're more likely to succeed or make the most out of certain habits. So let's try to sort of apply that in software engineering.
I guess so everyone has their own tendencies, right? Someone might be naturally inclined to problem solving. Someone might also be inclined to communications and so on. So it might not be technical.
It might not be also social-related. But yeah, it definitely helps with improving the habit formation of what you're naturally inclined to, right? And that kind of tendencies that you have, just doing that kind of thing instead of doing other things that you're not naturally inclined of helps a lot. But you also need to have that kind of small kind of, what do you call this? That capacity that you need to have in order to basically go out of your comfort zone, right? So things that you're not naturally inclined to.
So for example, you might not be good at communication, but you're good at problem solving. Then you need to put a little bit of time on that particular thing of communicating or anything social. But also you want to lean into the problem solving, your capability of problem solving.
Yeah, no, I like that. So basically what you're saying is if you are genetically good at problem solving, forming those habits are much, much easier. But for example, for any job that you do, communication is a necessity.
And so even if you're not genetically good at communicating certain things, that is still something that you can still improve. So in that sense, genetics doesn't matter for that side because there is still ways for you to be able to improve your communication skills. No, it sounds really good.
Is there any other things, would you say, that are skill sets whereby really genetics don't matter? I think any area, honestly, in terms of software engineering, whether it's your ability to write code or communication like we said before. Because the thing about things that are, let's say, we don't have the genes to do this certain thing. As long as we can change them, we can still improve on them.
So we have to consider, especially things like problem solving, like math. I mean, some people, yes, sure, they're talented or genetically gifted to solve problems. But even if you aren't talented, that doesn't mean you can't solve them.
You can consider yourself as a malleable type of person where you can hone your skills. Sure, it might take some time to get used to it, but surely you can reach the point where those talented people are. It's just that they just do it faster, maybe they do it a bit more efficiently.
But yeah, I think you can always improve on any area as long as it doesn't involve things that you cannot change with yourself. Yeah, okay. So your point is basically, you can still improve on things even if you're not genetically inclined to that specific skill set.
It just means that it might take you longer to get there. Yes, yes, yes. I completely agree.
So certain people, they learn things very quickly, they can do things in six months and then all of a sudden, they're experts in speaking Chinese or something like that. But another person who might not be genetically inclined to learn it, they might study it for three years and then after, they'd be speaking Chinese three years later. But it's still possible, providing that it's actually something that you can change.
But I suppose an example of something you can't change is something like your height, right? Unless you do those extreme surgeries of breaking your bones to make you taller. Don't do that. It's probably not worth it, right? Okay, awesome, awesome.
Okay, cool. So the second thing that is covered in the final section is the idea called the Goldilocks Rule. Yeah, I must admit, I don't think I've come across this term before until I've read the book.
So does someone want to attempt to explain what it is from your recollection on what the Goldilocks Rule is? So the Goldilocks Rule basically states that in order for a habit to stick, you have to be challenged but at the same time, it's not too difficult for you to do. So there's a point where it's satisfying to do because it's not super easy to the point you're bored but it's also not super hard to the point you don't want to do it anymore. Yeah, yeah.
And I suppose they call it the Goldilocks Rule because the whole Goldilocks story whereby Goldilocks goes into the bear's house and then one's too hot, the other one's too cold, and the baby bear's porridge is just right. The idea is really trying to, when you're doing habits or you're doing tasks in software engineering, you just take the right task at the right level so that it's not too easy but not too hard at the same time. In terms of, I guess, thinking about the Goldilocks Rule from software engineering practice, what do you think is a helpful way to, like an indication that maybe a task is too hard or what would you say is an indication that now you think, oh, this is too easy for me, I need to pick something harder? I guess in terms of like tickets where we estimate them so they will have story points that we can know if it's, how complex it is.
And I guess that's the indicator of that kind of complexity. And of course, it's a team estimate. So it might not be your estimate but the whole team.
And that's where I have a question. So basically, if you do not have an estimate of something or you just don't know how to estimate something, how would you know what's the baseline or the middle ground of what's between easy and hard? Yes. If you don't have any indications and you're bad at estimating, then how could you know, right? Yeah, I guess, at least in agile practices, there is a thing we call spikes.
So often if we have certain tasks, I don't know, that's rather new to everyone. Let's say you're integrating a new payment provider. Let's say, I mean, you're integrating Alipay from China, right? So they release a bunch of APIs.
No one's ever tried this API before. So no one really knows how complex it is, whether it's too easy or too hard. The best way to do it would be to say, yeah, we can't estimate this work.
The best thing is probably for us to create like a spike, which is like a sort of investigation effort. And the idea would be the task is to figure out how complex it is to implement this certain solution. And you would want to give that to someone who is a little bit more senior in the team, who is perhaps good with technical analysis.
Yeah, I see. It all makes sense. Well, personally, when I was starting out as a developer with estimations, it helped a lot putting notes on the ticket or maybe even just discussing the ticket beforehand.
It helps to discuss it with someone more senior so that the senior developer can maybe lay out the solution. Because sometimes a ticket can have a description of what the expectations, the outcome of this ticket. But as a junior developer, you might not know the specific steps to get there.
So it helps to talk with a more senior developer so maybe they can lay out the solution, the steps for you. Yeah, yeah, yeah, yeah. No, that sounds good.
Yeah, I suppose having senior engineers in a team is a must-have. So ideally, you'd want your senior engineers to be the ones who are helping you to understand, okay, this task might be a bit much for you or helping you to pick the tasks that is just right at the optimum of your level. Just because it's easier for someone external to assess your capability compared to you assessing your own capability.
However, in certain cases, that's not always the case for everyone. Not everyone has the luxury of having a mentor or having a senior next to them. And so people have to fend for themselves, so to speak.
And I wonder whether you've ever found yourself in that context and what would you advise to someone like that? What would you advise to someone who doesn't have a mentor or a senior engineer to help them out? How would you try to get that Goldilocks rule in place to make sure that they are constantly improving in software engineering? So I've been in this situation many times. But my solution is, I think, just understand the resource more. Because to me, how I identify if something is very complex and challenging is when I can't explain it in very simple terms.
Like sometimes I know how to do a certain task, but I can't explain it to, let's say, a more junior developer in a much simpler way so that they can understand it better. So I think we've been doing this a lot since, like, in school, or teachers do this a lot so that they can understand the resource better. So I think having the ability to explain things to someone who doesn't even know technology, if you can explain it to that level of simplicity, I think that's when you can tell, oh, I'm pretty good at this, I can do this easily.
Yeah, no, no, that sounds really good. Anything else? Any advice from... Yeah, actually, that's what I want to know as well. So back to what I said earlier, and it's probably answered already through this discussion, but I want to list out, like, so like I said earlier, estimating a ticket is a team effort.
So let's say one person estimated as three, and the other people estimated as one. So how would you help that person who estimated three in order to understand how to work that ticket? So let's say what's your... How would you list your process of taking this ticket on? That's a really good question. So just to paraphrase, if I understand correctly, what you're saying is, in a team estimation, you've got a task and someone, most of the team estimates as one. Yep.
And then maybe because to them it's easy. And then one or two people in the team estimates the task as three. And your question is, how do you help the people who are estimating three? Yeah, for example, they took that ticket, right? Yeah.
And so how would you help that person? What's your kind of process into working the ticket out? Is that a question for me or for everybody? Well, I think for me, we've encountered that situation a lot. But to me, I think the best solution is to meet in the middle. Let's say maybe one in a three will get to a two as the final decision.
But I think another thing to consider is talk about it beforehand or maybe have a discussion on how complex is it really? Because sometimes those people that estimated at a higher score, maybe they just think that, oh, this might take a bit longer. But in reality, it's just a lot easier than they think. Yeah, I think that's how I see it.
Yeah, that's actually a good answer. But when you're now working on that ticket, what will be your process? I think the first thing that I would say is when you're estimating, you're not estimating the problem. What you're estimating is the solution to the problem.
So there's multiple solutions to a problem. There could be a one-pointer solution to a problem, a three-pointer solution to the problem. What JP is saying is correct is, firstly, when you have discrepancies in the numbers, it's worth discussing, okay, why did you say one and you say what your solution is? Someone who said three, okay, why did you choose three and what is your solution? Because maybe the person who chose three has a better solution and he thought of certain use cases that need to be considered but the others haven't thought of.
Or it could be that he is just over-engineering the process, right? And it could also be that he just chose three because he's done it based or she's done it based on, I don't know, just a finger in the air estimate, you know? So it's really important to know what the solution is behind those numbers for you to be able to determine, okay, why is there a discrepancy? And sometimes as well, for example, if I were the developer who estimated three and then the rest of my team estimated one, I think sometimes, in some cases, it's because I feel intimidated by this ticket. I don't feel confident about my own solution to this ticket. So I think the approach would be, I would ask for help.
If I were to work on this ticket, I should try my best to ask for help from more senior developers. Well, your question was, how would you help this person? But I think the answer is, this person should also help themselves by asking others. Instead of the more senior developers helping this person, this person should ask help from more senior developers.
Yeah, I guess that, yeah, I like the answers, yeah. So kind of like, you let them get context from other people and then apply this kind of rule in order to make a somehow challenging task for them into somewhat manageable due to senior people knowing more context of it and then can give advice. Yeah, the tricky part about that one is, like you mentioned, asking questions.
Sometimes a much more junior dev doesn't know when to ask a question. So I think it's a good skill for devs to ask good questions because that's what makes things more clear. Yeah, no, agreed.
Yeah, it's tricky, isn't it? Because in the ideal world, yeah, you always have your senior developer behind your back, helping you along the way, holding your hand. But in reality, there's a scarcity of senior developers, not just in the teams that you're working in, but in the industry as a whole. And even when you have senior developers that are capable, it's always the case that they want to help you out.
Well, they care about other things apart from helping you out. So yeah, I understand. There's definitely that tension.
How do you know or how do you keep the correct level of challenge so that it's not too easy or it's not too hard? In a way, it's a kind of criticism on the book, because it kind of simplifies the Goldilocks rule as if it's that simple. Because in the original story, Goldilocks had to try all the porridge before she learned what is the middle part. Yeah, yeah, no, no, completely agree.
Yes, yes. You have to try, I guess. Yes.
And also, I mean, one of the disadvantages, I think, with having a senior developer holding your hand is that you don't develop that skill of trying and understanding what's too easy and what's too hard, because it's just being given to you. The environment is designed for you, and you think you're just super awesome because you can do all the tasks. You know? But yeah, in reality, there's like a pro and con to everything.
And so sometimes, yeah, having that skill by just trying, maybe that's the solution, you know? Just getting on with it, try first. If it's really too hard, then ask a question. But the idea is to try to take the task as far as you can take it.
And then when you're stuck, then asking a very specific question on the thing that you're stuck with, getting an answer, getting a feedback, trying again to try to push it until you reach that point again where you're stuck. And then you keep doing that. So it's more like a habit of being proactive and having that can-do attitude.
Awesome. Yeah, I guess when you have that challenging task that's kind of above your skill level, you want to make sure that you are making it manageable or at least making it smaller, or the hard task to be smaller than what it is in order to basically apply this rule. Yeah, yeah.
No, no, I agree. So yeah, I completely agree with that. It's sometimes when people pick up a task, actually they can do 80% of that task.
The only thing that they can't do is that 20%. So it makes sense to break down the task in smaller chunks, focusing on the things you can do and then isolating the things that you can't do. And when you manage to isolate that area, then that's the bit that you ask help on.
And sometimes the thing that you can't do is only the beginning part. Maybe you only need help with the overall solution and you can do everything else. Okay, great.
That's awesome. Thank you, Francis. That's a great question.
The final item on the advanced tactics is avoiding stagnation. So I guess during habit formation, when you're as a software engineer, we always want to be better. We always want to be able to handle harder tasks and so on.
And I'm curious for you guys, what do you do to make sure that you're constantly improving in your craft? Personally, I'm always trying to look for feedback. I think it's better if I get some sort of feedback rather than none at all. So for example, for us, we have the yearly review.
Sometimes I don't know what skills am I lacking on. And it's helpful to get feedback on those things because throughout the year, I try to do my best. But sometimes there are parts that I am satisfied with that might not actually be the case.
So for example, it might be that I think I'm communicating well, but then maybe it turns out I'm not at all communicating well. So yeah, so feedback helps a lot. Okay, nice.
Yeah, feedback. Feedback is helpful. What do you guys think? Is that helpful to you as well, 360 feedbacks? Yeah, for sure.
Do you think once a year is good? Or do you think it's not too frequent? What's too frequent? And what's frequent enough, would you say? I think, well, our projects last maybe eight months to 10 months. Maybe even a year. I think that's a good amount.
Yeah, so maybe end-of-project feedback. End-of-project feedback, yeah. Yeah, no, sounds good.
How about the others? What do you kind of do to avoid stagnation? Do you do anything in particular to try to, I don't know, constantly upscale? I guess curiosity is important in order to not settle on anything. Because if you're satisfied with something and you're not finding ways to do more, then it's a no-brainer that you will just plateau. And finding something that makes you curious helps with just removing that kind of mental block of being satisfied of one thing.
And having that curiosity helps you in improving in any field, really. I think I'd like to add to what Francis just said about curiosity, because I think we also have to fine-tune the skills that we are constantly improving, especially in software engineering. Because consistency is good.
But if you don't fine-tune your consistency on your daily habits, then you won't really get anywhere. So what I'm trying to say is you can do the same thing, like let's say you practice a certain stack, then you do it over and over and over again. But if you don't really branch out on certain situations, certain technologies or related stuff, I guess a good example is when you're starting out as a developer, I think we've all heard of having interviews using LeetCode and those solving problems.
I mean, sure, they help and they might get you a job. But those people who are more, let's say, do more project-based learning, they're the ones who end up being much more effective because they know how to encounter a solution that's much more realistic in a sense. I think that's how I approach it.
Also applying all the kind of tips and tricks that we've already discussed from previous series helps with just making things manageable and just not procrastinate at whatever you want to do. Yeah, there's this term we like to use. Some people have like one year experience five times and there are people who has five years experience.
So what I mean by that is you can be in the industry for five years. Two engineers can be in the industry, work in the industry for that same amount of time. But one person, they've basically just repeated their experience five times.
Let's say they've just been doing email templates and for the whole five years, they've just been working on email templates. But there are people who have five-year experience and that's something that we're often quite, you might notice, we're quite conscious about. So when I have like engineers in the team who, let's say, worked on a previous project and this person, I put them on content management system implementations, I'm quite conscious that on the next one, I try to canal them into maybe doing something else like a search.
And if they've done search already, I'm quite conscious to make sure that I push them in a different area which is more technical, let's say, the checkout. So the idea is to try to, yeah, again, it's like the Goldilocks rule, trying to put something new. And yeah, it's exposing yourself or exposing your junior engineers into areas that they are not familiar with so that they can be curious, as you say.
And I think, yeah, for those who don't have the benefit of having senior engineers, I completely agree with what you're saying, Francis, which is curiosity is the key for you to keep improving because if you don't look at what's out there, then how will you know? So if you're just okay sitting down in your comfort zone, then how do you know? And maybe the last one thing that I would say is that sometimes, some of might not agree with me on this, but sometimes the fear of missing out can be something positive, right? Because the reality is we work in technology that is very fast-paced. So if you don't keep up, then when you fall behind, you fall behind. And so having a healthy dose of fear keeps you motivated to be at the top of your game.
Yeah, actually, I still have one thing to say about it. It might not be for everyone, because it's just one way, right? At least for me personally, throughout my childhood, I've been very competitive at a lot of things, sports, video games, and so on, maybe studies as well. Maybe studies as well.
Not much on that, but yeah, that kind of competitiveness helps me basically build this mindset of I want to be good at this particular thing. And I want to be good if I'm, or basically anything, right? I want to be good at this thing. I want to be good at that thing.
