Why would he stop though? If there are no repercussions and he gets what he wants, why would he feel compelled to change? Even if a co-worker said anything, he might shrug it off and do it again next time. Then came the most important question, where was the manager/owner in all of this? I connected the dots pretty quickly and, while it sounds obvious now, I realized they created a vicious cycle.

A terrible behavior was allowed, not once, but multiple times. That had become the norm since leadership never corrected it. That became how they did work, how he was allowed to behave. I realized then that it was a leadership issue, sure the behavior was unacceptable, but it was allowed and legitimized it. That's when I promised myself that if I was in a position like this, I would not allow it.

Lowering the bar is the easy way out. Avoiding friction is a very weak way to lead a team. Today more than ever before, we need to hold the bar to the correct standard. What I'm afraid to see is the industry slowly accepting Agents PRs in the name of higher productivity. It is no surprise that things like these will continue to happen. I'm looking forward to seeing where the industry will focus to make sure AI raises the bar rather than increasing output sacrificing quality and rigor.

So please, remember that your inaction sends as strong of a message as your actions.

So there I was, surrounded by the leading minds of this AI wave. Everyone seemingly nodded and clapped at every answer. Gergely has done his research and was a great host. Even though we are used to his ability to interview, I still found it impressive. The first chat was with people from OpenAI, everyone was quietly listening. The room agreed on where this AI trend is leading us. The OpenAI Codex team supposedly writes 90% of their code with agents. If you have adopted AI at your company or on a shared project, the question is immediate: who is reviewing all of this code?

Writing code was never the bottleneck. Now that it has become quicker to accomplish (for the sake of discourse, assume the code produced is comparable to a human) it has helped highlight where the obstacles are. While I want to dig into this in another post, what surfaces here is the fact that, if we buy into this future of software development, things will change dramatically. I see some merit in what one of the guests said "Everyone will be a manager" but that should have been clarified. As someone who walked the management path, I find myself reviewing code more often than I write it. That's the only overlap I see with his statement. Delegating to a human IS NOT the same as delegating to an agent. Reviewing human-generated code vs agent-generated code is comparable (don't forget about the assumption we made earlier) and this is as far as I would push it. Also, not everyone will share the excitement since not everyone wants to be a manager anyway.

That statement was already a yellow flag which then evolved into a vision of a flatter hierarchy. Fewer managers (since I assume that when everyone is a manager, no one really is a manager). Now, I am all for regularly reviewing how your organization is structured and removing unnecessary roles. I don't buy into his example of having 30+ direct reports. I thought about this a while and could not figure out a realistic plan to properly and actively manage the growth of more than 30 people.

I thought about doing some math here.

• Let's say you have 15m 1:1s with everyone. That would be 7.5h of weekly meetings, and if you grow that to 30m slots it puts you at 15h a week of 1:1s. I will stick to the 7.5h since the math would still work if you decide to meet with your direct reports every 2 weeks instead of every week. Every single day you spend 1.5 hours in 1:1 meetings. This seems doable, not optimal, but doable.
• If you average 3 people per project, that means you have 10 projects in progress at all times. You, the manager, will be directly responsible for overseeing them (which is also doable). You are also responsible for each individual's growth opportunities. You can't afford any distraction. With these many people and these many projects things could spiral quickly.
• You can't skip performance reviews! Every 6 months I would assume that any decent manager will spend at least an hour per direct report in crafting a development plan and reviewing their work. That puts you at 30h of work (I'm starting to become very optimistic here!).
• Won't you have to discuss this with each individual? That would be at least another 30m per person, which adds up to 15h of meetings (adding the 15m from 1:1 puts you at 45m per person, minimum acceptable level).
• [...]

This is starting to sound quite exhausting and not something a good manager will be able to sustain long-term, unless you want to do a poor job. Or, unless you delegate EVERYTHING to an agent. At that point, no manager is needed to begin with (I really hope I am not predicting the future).

Between the "Everyone will be a manager" and "Flatter hierarchies means you can have 30+ direct reports" I was immediately skeptical about anything else after that. It seemed like this is the future they want to sell you and I'm having a hard time accepting that it's a good one.

Where I am now (MongoDB) everyone is tech-savvy so the back-and-forth is minimal. The discussion becomes more about how pressing the next feature is for the customer, understanding that I'm negotiating time allocation now to eventually "get it back" later. No empty promises though, which would otherwise damage trust. This is true for my immediate team but what about my boss's boss, and their boss, and their boss? How can I justify engineering investment up the management ladder so it doesn't look like I'm wasting time on projects that don't translate into profits?

Here's what I learned along the way since I became a manager that I would recommend to you as a starting point. The work starts before planning for the quarter. Having a vague idea of how a developer productivity project can benefit the product will not play in your favor (or anyone's favor). There are two ways this can and should be framed to stakeholders.

The first one can be measured. You can estimate (for example) time wasted waiting for your CI/CD pipeline to tell you your changes are safe. You can also expose all the downstream effects of it (TimeToResolution in case of a critical bug). These numbers are your bridge to faster customer delivery. The second one is a hidden cost that helps as supporting evidence. Bad developer experience can drive talent away. You risk to lose not only good teammates but also their domain knowledge. On top of that, you'll have to hire and go through the aches and pains of that too. I label this as hidden because it's not evident to other stakeholders and it's more challenging to justify with numbers or metrics. Add this as an "addendum", but not necessarily the driving force behind a project as it will make it harder to sell.

Here's how to execute:

• Draft a proposal where you identify and quantify the measurable costs. Collect evidence for hidden costs to strengthen your case.
• Loop in your manager if you haven't already. Their buy-in is crucial.
• If you're the manager, support and help your team ensure measurable costs demonstrate faster customer delivery. Hidden costs should stay as an addendum.
• If, even after framing it correctly, it doesn't make a strong case, archive and move on.
• If it makes for a good case, put it on the plan and negotiate for it.
• Once the project is completed, follow up 30-60-90 days later. Show how the measurable costs validate your initial thesis. This will help build trust.
• Rinse and repeat.

Rather than investing in full page journals, I wanted to be able to quickly revisit the past. I found these five-year memory books that were perfect. The commitment is one line per day. You jot down how you feel at the end of the day, what was going on, or a single highlight that made that day memorable. I was also tracking other habits or energy levels but, given the limited space, I would end up forgetting what my acronyms or symbols stood for and eventually gave up. The "one line per day" philosophy stayed though.

I stuck with it for a whole year and I'm really glad I did! Just a few weeks ago I hit this milestone and every day I get the chance to revisit where I was at this time a year prior. Revisiting memories, important facts, moods, and milestones leaves a smile on my face every time.

It hasn't always been easy. There was a period during this summer when I wasn't doing well mentally and I had a hard time focusing. I barely noticed that I suddenly stopped journaling. I refused to leave an empty entry so, after a few days of falling behind, I quickly caught up and used my phone to write down what happened in the past 5 days. The key part here was not needing a full minute-by-minute recollection, even if a day wasn't captured to perfection, that's fine!

I'm no Marcus Aurelius writing Meditations. I needed something that didn't require eloquence or insight. A year in, I can see what made this sustainable for me:

• The journal is very portable.
• It's quick and easy to do.
• The effort required is minimal.
• If you miss once you can catch-up later.
• You can chain it to other night-time or morning routines.

I'm proud of having an entry for all 365 days, and impressed by my consistency. Next goal is to complete all 5 years! I find this approach to be the easiest way to pick up journaling. Keep it simple.

I'm not going to lie, that was a disappointing comment. We really can't let "AI can do this" take over the desire to cultivate your craft (either in your work or as a hobby). Most importantly, if we start giving in to AI taking over and giving up on learning how to do it ourselves, we won't develop any understanding for the craft.

I believe an AI in the hands of a Senior Engineer will yield better results than in the hands of a Junior Engineer. That's because Seniors spent a considerably larger amount of time on the craft. We can't expect Juniors to deliver at a Senior's level just because they can now use AI.

This is a reason why we should continue to invest in Junior Engineers. AI should empower them to learn in a way that fits their needs but should not replace their work or thinking. If we stop nurturing the craft, we will end up with unskilled contributors who cannot distinguish between good and bad. Being able to delegate small changes or bug fixes to an agent, doesn't mean we should deprive a Junior engineer from the opportunity to learn more about the project they're in. Those are what's helpful for onboarding.

If you've been in your industry for a while, find out how to adapt onboarding in the age of AI. How can we use it to increase quality and not just quantity? How can we reduce the timeline to grow tomorrow's Senior engineers? When I look around, it seems like I'm not alone thinking this way. In a recent article from the Pragmatic Engineer, this quote stood out:

Personally, the lack of impact by AI coding tools to date upon the speed of development and quality of software, is amusing to me. If I take the apps I use, websites I visit, and services I access via software, I don’t see signs of faster iteration, higher quality, and fewer bugs since AI started shaking up the tech industry.

Don't let AI fool you into thinking you can now save costs, increase quality, and deliver faster. You need people who can solve problems that are not there yet, you need the Seniors of tomorrow who can harness the tools. Bet on Juniors now so that you can sustain your project/company/org tomorrow and not find yourself submerged under a sea of inexplicable AI work.

Note: I decided to remove the "Thoughts" section moving forward. It felt unnecessarily repetitive and overkill for short-form posts.

I lost that habit pretty quickly once I started my career in the tech industry. There are just so many things you won't know, especially at the beginning of your career. Realistically, you won't have the answers all the time. You're well-equipped to find them, but to have a useful and constructive conversation or technical discussion, asking questions is fundamental. I went through a phase early in my career where I just wanted to demonstrate that I knew much more than I actually did, so I danced around things I wasn't sure of until I could go back home and get the answers myself. When I think about it now, this is counter-intuitive based on how my career and habits have evolved.

Nowadays, I feel incredibly comfortable asking questions, no matter how advanced or basic I think they are. I do not hold back. I find this to be counter-intuitive because you would expect that early in your career you should be encouraged to ask more questions because you know less, and later in your career you might ask fewer questions because you've been around long enough that you might have an answer or good intuition for it. Even writing this down sounds silly, that a lot of people are afraid to ask questions.

At MongoDB, we have a really good internship program. The first piece of advice that I always give is to ask questions constantly. There's a fine line between asking a question lazily and asking a question out of lack of knowledge. I always recommend making an effort initially, but not being afraid to ask questions and also inquiring how you could get those answers on your own. That's part of the growth, especially for interns or junior hires. The expectation is that they don't know much, but they have the will to find out and discover. It's normal and expected that they should ask questions. The main concern should not be to look like you already know a lot but rather your work ethic, your ability to collaborate, and your ability to adapt to a work environment.

Early in your career, the need to ask questions is mostly based on learning and knowledge at a basic level. In order to be able to contribute meaningfully, you have to have a better understanding. While you can pursue that on your own, you're encouraged to ask questions. Later in your career, this is something that I found especially true for leaders and even veterans at a company: the nonchalant way of asking questions, no matter how basic they may sound. The goal is to ensure that when in a conversation or discussion with others, there's no misalignment on understanding of what is being discussed. The main goal is clarity. If something is not clear or unknown, the question will be asked. If there's a fear that someone else in the room might not have the knowledge, good leaders will ask the question to make sure that everybody knows, to level the playing field and make sure that everybody has the same amount of knowledge so that we can have a constructive conversation.

Thoughts

Never fear asking questions no matter where you are in your career. Sure, there might be some questions that could feel too basic, but I cannot remember in my career anyone asking a question that was so basic that my assessment of their expertise or professionalism changed. To this day, if you were to ask me, "Do you remember anyone asking a stupid question?" my answer would be no.

Don't overthink it. People won't remember anyway that you asked that question even if you're worried about it. People won't make a big deal out of it, and you probably won't either. If somebody asks you, "How do I define a pointer in Go?" you give the answer and then move on with your life and never think about it again. Your worries are misplaced.

It's important to use questions. No matter where you are in your career, early on you have to build up knowledge and fill the gaps. Later on, that is still true, but in addition to that, as you evolve into a tech lead or any leadership figure, it's important that you make sure clarity is king. In order to do so, asking a question is one of the many tools you have at your disposal to reach the highest level of clarity for the room. Ask away, don't overthink it.

In the interview, he discusses the importance of sustaining what you enjoy most in life while giving back to society—like his contribution to Redis. Rather than morphing into something he's not by moving to the US, he decided to stay in his hometown and continue living the life he enjoys most, surrounded by the people he loves: family, friends, and food. His reflection is about being able to enjoy things that mean a lot in life and bring real happiness.

The other day, inspired by his words, I stopped for a second before eating my meal—probably for the first time in forever. It was a combination of things I miss most about Italy. I enjoy baking bread, and I made a special focaccia with olives and rosemary that turned out absolutely perfect. When I sat down with my wife and made a sandwich out of it, I paused for a few seconds to just enjoy the moment.

We continue to be in a never-ending rush: to buy the next house, move to the next city, get the new job, get the next promotion, get the project done. We make progress in every aspect of our lives at such a pace that we don't celebrate enough what we have or enjoy moments at a slower pace. I think in Italy we do that very well—maybe sometimes to a fault. We like to take our time with moments that should be enjoyed longer.

To honor that, and inspired by Antirez's words which reminded me of my roots (I've only been here in the US for 10 years), I paused and expressed gratitude for the type of food I grew up with that brings me the highest level of happiness.

Thought

So here's my invite, just like yesterday: find things that really bring you joy and try to slow down when you're facing those moments. Really soak them in and let them be a spark in your life to ground you and help you appreciate what you have.

And another reminder to find a better balance—there's no rush to the grave, especially in an age where AI seems to accelerate everything. Do not feel bad about slowing down.

One idea the author communicates throughout the book is the ability to question everything (he doesn't do this directly, but hints at it in several locations), even wisdom that's been around for decades. Yes, these guidelines can be helpful to keep in mind, but realistically, there's rarely a perfect storm that allows for all the good things to manifest: being able to move fast, delivering impactful features, unblocking others, writing perfect code with simple interfaces, perfect test coverage, ...

Anyone who has been in the industry long enough knows that the answer to many questions in the technical field is "it depends". When you study system architecture—as you might have noticed from some of my previous posts on reviewing system architecture—you'll see that many decisions are not absolute truths in every situation. They vary based on the needs of your application and your circumstances. I find this to be applicable to many things in life.

It's fun to rethink "best practices" that have been passed from generation to generation of developers. I've realized that the clashing of these ideas often comes from strongly opinionated individuals. But the best engineers I've had the pleasure to work with understand better than anyone else which compromises should be taken and what the consequences are. They're very good at communicating the balance they're trying to strike.

Thought

My general thought for today is an invite: when you're reading anything technical—or about personal growth, leadership, or anything teaching you something—feel free to second-guess and truly understand whether the opinion, as authoritative as it may be, applies to yourself, to your circumstances, and to every situation you've personally witnessed.

Distill the content into primitive principles that you can follow and adapt to your life. This is also true for software development. There are certain principles that should stay true no matter which pattern you follow. The classic example is small functions vs big functions. They all come with pros and cons, and it's more about understanding what your goal is rather than strictly following "all functions should be short" dogmatically.

I led the discussion for the last chapter, which summarized system design for AI Engineering. It covered the evolution of AI systems, recommended components, and extensive material on user feedback and system improvement. Unfortunately, as I read through the book, I became increasingly skeptical about the quality of applications built on multiple AI agents.

I optimistically assume that as years pass, we'll have more effective and efficient models to use as individual blocks within AI application systems. For example, routers can be implemented using smaller models. Since many LLMs are probabilistic models (oversimplifying here), connecting all these components together reveals a problem: your data flow starts from a user query expressed in natural language (already an approximation of what the user wants). It then proceeds through several components like routers and gateways, which are also often models of different sizes. All of them are probabilistic, so not exactly accurate. As you put all the pieces together, you realize it's a very non-deterministic system, beyond what we've seen in regular system design.

Just last year I reviewed a software architectural book, and it's impressive how different a mature set of guidelines is compared to what I've seen in this book. What made it worse was the section on user feedback. That's where I lost most hope. There are countless ways to collect feedback, but again, it's based on unreliable and sometimes biased communication that you still have to sift through to extrapolate something your model or application can use to improve.

This still feels like a complex combination of components glued together with trial and error. I'm not sure if this impression is only because of how far we'd gotten when the book was written, or if things are now in a better place. And don't get me started on the ability to reproduce bugs or poor flows, that's already hard in established systems, I can't imagine in AI applications!

Thoughts

Building applications in the AI space seems complex at scale to be built reliably. I'm aware that simpler ones fundamentally based on educated prompts can work fairly well, but their level of complexity is much lower than the more involved systems we're used to seeing in largely successful products.

It was incredibly beneficial to read this book in a group setting. It was eye-opening to see how most people came to the same conclusions and had the same (perhaps too harsh) opinion about the book's delivery.

There still seem to be many unsolved problems to make AI applications predictable and reliable. While we're definitely in the early stages, it will be fascinating to see how the industry evolves in the next 5 to 10 years. I'd recommend exploring these issues before buying this book.

Whenever I get excited about a new endeavor or a new habit, I tend to go all-in and try to maintain a perfect streak. I either maintain the same level of intensity or I eventually burn out and need to reset. It took me some time, but I'm happy I learned that about myself.

Other times though, life happens! You get sick, you have to travel, or you have to take care of loved ones and that can put you off balance from your day-to-day routine. Part of the challenge in the past has been lack of forgiving myself for not maintaining a perfect streak and also not finding the right routine to reset.

I've recently stumbled upon this video and thought I would take the chance to outline a framework for resetting that could help me in moments when life has other plans. I can give myself up to a week to restart, focusing on very few things every day. That will build up to restoring a healthy routine. Sadly, in the past, I would even let months go by. Blasphemy!

Something else that can contribute to burnout is the inability to see progress. Especially when you are cultivating new interests or learning something new. If you don't see yourself making progress or getting better, it can be demotivating to the point that you might as well stop. Knowing that, I decided to find ways to really enjoy these new learning paths and still find a way to notice the progress.

So similarly to what I've learned from Ultralearning is that you should spend 10% of your time figuring out a plan. Depending on what you're trying to learn, there are very different ways to go about it. Measuring progress in something like writing is very different from measuring progress in something like learning a new language. It's important that you find ways to look back and see the improvements you've made compared to where you were six months prior or a year prior.

The time commitment also plays a role in your expectations. Personally, I started off with trying to write a full blog post every six weeks and realized that the amount of time I could dedicate to it was not going to make this a sustainable habit. I ended up pulling back a lot and that's ok! Use these experiences to learn something about yourself. Adapt and iterate.

The few factors that generally play a role are in setting yourself up for success when you want to learn something and you have a busy life:

1. Have a plan
2. Understand how much time you can dedicate to your activity
3. Set reasonable expectations based on the above
4. Write down specific goals

Thoughts

Don't fall into the trap of having a perfect streak. Forgive yourself when you fail, and most importantly, make yourself resilient. Define and iterate on a reset routine or framework that can help you get back on track when you are out of balance. Don't let obsession over progress or stats burn you out, and follow the few steps above to have reasonable progress with reasonable expectations.

Keeping momentum is more important than having large improvements in short amounts of time that require you to overextend yourself. Find something that can compound daily or that you can keep up with comfortably, and that you also enjoy. Set yourself up for success, the sky is the limit!

What hit me first was how differently everyone at the table approached AI. I was surrounded by smart people who've been in tech for years, and they were all over the map. Some were using AI for everything from code reviews to meeting notes. Others were still figuring out if it was worth the hassle. The fascinating part wasn't the variety of approaches, though. It was seeing how the people who'd really made AI work for them operated at a very different level of intensity. To a point, it almost sounded like they really wanted to make AI work and, possibly, achieved that. They were the right combination of stubborn and curious. They were obsessive about refinement. I appreciated the very methodical approach to figuring out what worked. They developed their own systems for prompting, their own ways of breaking down problems, their own methods for getting consistent results. That's no easy task!

Meanwhile, I kept thinking about my own experience and how much it mirrored what I was hearing from the more skeptical people at the table. I've definitely fallen into what I now realize is the "one-shot" trap. You have a task, you throw it at ChatGPT or Claude with a pretty basic prompt, get back something that's close but not quite right, and then feel like you're spending more time fixing it than you would have just doing it yourself. The cycle of frustration is quite exhausting and you soon give up, writing off AI almost completely.

The thing that really got to me was realizing how much my own experience and assumptions were working against me. When I ask AI to add a feature, refactor some code, or add a button I'm unconsciously assuming (or at least I used to) it knows all the context I know. The testing patterns we use, how we like our commits structured, the particular quirks of our codebase. In that moment of disappointment when the output isn't what I expected, I blamed the AI instead of recognizing that I gave it incomplete information.

Listening to these conversations made me think about how many times I've written off AI tools after those first interactions. There's this gap between what you expect based on all the hype and what you actually get when you try to use it for real work. That gap is discouraging, especially when you're hearing stories about other people becoming dramatically more productive. Given all the misinformation nowadays, I don't even know who to believe anymore. Some productivity claims are a little too wild for my taste.

But sitting around that table, I started to see that people who'd pushed through that initial bumps had discovered some useful tidbits. They almost deconstrcuted AI to make the "magic" disappear. Instead of expecting it to read your mind, you start getting better at communicating what you actually need. And so all the structured prompts start to make more sense.

The diversity of approaches was probably the most encouraging part of the whole conversation. Some people were using AI for highly technical automation. Others had found their sweet spot in document work or handling repetitive tasks that used to eat up hours of their week. A few spent a significant amount of time refining their prompts taking inspiration from some general recommendation you find out in the wild (like how to get rid of the em dash).

Thoughts

What struck me during this event, was that none of them had found their happy compromise immediately. They all went through that same frustrating period, but they stuck with it long enough to develop their own methods/evaluations. They'd treated it like learning any other complex skill, with the expectation that it would take time and deliberate practice to get good at it.

I left that lunch with a different perspective on my own AI experiments. Instead of expecting immediate productivity gains, I'm trying to think of it as building a new capability that will pay off over time. The key seems to be pushing through those early failures and treating them as data points rather than reasons to quit. On one of my most recent attempts I approached it like I would when learning a new library or framework. I try something, it doesn't quite work the way I want it, I refine, check the result and repeat the cycle until happiness has been reached. Now the focus is on the prompt instead (whether you like it or not) instead of your test suite or iterative coding approach. I still find joy in coding by hand but I also find joy delegating incredibly rote work to an agent.

When I started my journey as a Manager, I promised myself I would try my hardest to avoid confusion in my performance reviews. It gets incredibly easy to understand how it affects people when you put yourself in their shoes. And, most importantly, I care deeply about other's growth and do not want to disappoint. When you say (quoting the article directly):

"Oh you’re doing well, communication could improve a bit but overall you’re doing well."

It's bad for a few reasons. First, it's not clear what "communication" is referring to. Is it the way you communicate with the team, with me, with other teams? Second, it's not clear what "improve a bit" means. Is it a 10% improvement, a 50% improvement? Third, it's not clear what "overall you’re doing well" means. Is it a 90% doing well, a 50% doing well? To make things worse, some people might accept this feedback and, even though they have some reservations, nod pretending to agree. Not everyone is comfortable with confrontation, which can often play against them. Being in a position of power, it's your job to make sure that doesn't happen.

Being able to read social cues can help. I remember once catching a glimpse of discomfort during a review that someone disagreed with. By trying ot be nice, they avoided the confrontation and that's when I pressed to understand what they disagreed with. As a result, our relationship grew stronger and we both learned a few more things about how to communicate with one another.

When you discuss anything, be as direct as you can. Avoid communication "fillers" that end up diluting your message. Provide clear directions and messages, don't dance around it for 20 minutes.

Thoughts

It's challenging to change to way you communicate, my anecdotal suggestion is to slow down. Don't let your instinct and reflex take over, give yourself some time to think about what you're going to say next. Be comfortable with silence in between words or sentences, the "uhms" often make it worse.

Work on your communication and gather feedback any chance you get. Be intentional in the way you share an idea and you can get started practicing by reviewing your writing first. One step at a time.

Jumping to today, AI is everywhere (for better or worse). It feels like it's still very early in this new era. A lot of tools trying to get ahead or assert dominance in the market early on. It's honestly confusing and tiring. I do see a lot of value in how the industry (any industry really) is changing. At any given time you could find me argue in favor and against it. Looking at the glass half-full, AI brings a level of "democracy" we've never seen before. Everyone (or at least everyone with access to a computer) has access to so much knowledge and the barrier of entry has never been this low. If you understand how, and this is not a given, you can learn anything you want and be at least mediocre at it in a much shorter amount of time than ever before. You can write better, draw better, plan better, code better (let's just assume this is universally true for a moment).

The glass is also definitely half-empty. We are reinforcing models that gobble everything we produce and massage it, repackage it, and spit it out. My biggest worry is that we end up creating something that feeds itself in an endless loop. Grabbing this quote from the article:

Although of course, as Cory Doctorow points out, the temptation is to not even try to spot the bugs, and instead just let your eyes glaze over and let the machine do the thinking for you – the full dream of vibe coding.

This is what terrifies me. We let the machine do the thinking and we just get better (possibly) at giving it instructions. We don't write that post anymore we just provide a generic prompt and fix it up a bit. We don't draw as much, we provide a prompt and iterate. We don't code as much, we provide a prompt and iterate. And what we produce ends up in the machine again, and again, and again. There's no prediction yet of where this is going to lead us (probably someone much smarter than me already has some valid prediction).

The reality is that AI can give you an edge if you understand how to use it and avoid letting it do all the thinking for you. As I try to adapt to this new world, I worry about Agentic Developer Experience (I'm not sure if the ADX term has been used anywhere so take it with a grain of salt). How can we think about how developers can become more productive without being too detached from what Agents supporting their work are doing? How can we make it feel like magic while still providing the tools for curious exploration? I occasionally orchestrate Agents in a way that empowers me without crippling me. I haven't found a good balance yet but I feel like I'm getting closer every day.

Thoughts

Just some scattered thoughts as I think about how I envision users to interact with Atlas Stream Processing (that's what I work on nowadays!). I have to consider where we are headed with AI and it's both exciting and daunting. We can be the ones that pave the way or completely miss the mark and doomed to catch-up forever. I am hopeful though, really!

Don't get me wrong, the title of this post is simply provocative. Marshall Goldsmith collects a good amount of bad habits and explores them in depth. There are decent call outs that are exaggerated to get the point across (although some examples are from real people and experiences). I was a bit put off by some blank statements and assumptions about successful people. Some of the habits listed are simply...toxic office behavior. I feel lucky that I never worked in teams where this attitude was accepted (with a few individual instances being an exception), even if it seemingly carried successful outcomes.

A good example was the one leader looking over everyone's shoulder, making up arbitrary deadlines, and questioning everything everyone was doing. He was able to squeeze a project within a tight made-up deadline. In the end, a successful outcome. Too bad he built no trust, no following, and definitely no commitment. It only worked once and people caught up quickly. That was an incredible opportunity for me to learn the type of leader I didn't want to be. I want my team to work hard against a deadline not because I am being annoying, but because of a shared understanding of urgency. Not only have I seen that play out positively, but camaraderie came into play when others jumped in to help make the deadline. With no prompting on my end but with my full approval and support.

I recommended every current and aspiring leader to work hard on creating a safe and supportive environment and the sky will be the limit. When I read through some of the bad habits in the book, I could confidently say that if anyone on my team were to do some of those it would not affect the relationship we have with one another. We understand where everyone is coming from and that we come with good intentions. No one withholds information intentionally and, when we feel it's something we should know, we say it out loud and give the other the chance to fix the mistake. We are regular people and don't expect each other to be perfectly executing on every interaction we have. Another example is the "negatrons" (people who will often find the negative aspect of whatever you're discussing). We need some of that! If we keep staying unrealistically positive we just pave the way for failure. Negativity can and should be harnessed to reinforce an idea.

Thoughts

I believe that you need to build awareness of some of the bad habits listed in the book. You might find some of your behaviors might actually fall under one of the 20 categories mentioned by Marshall. Don't fret though and think about your relationship with the rest of the team. Some of these behavior won't have the catastrophic effect depicted in the book IF you have a strong relationship with your peers. That doesn't mean you should pay no attention to your own behaviors and how you communicate, but you know (hopefully) that your team will call you out if you step out of the right path. As a leader, I would focus on that first and continue on your journey of growth following some (or all) the recommendations from the book.

I will leave with this quote that I enjoyed, although I don't seek power but good leadership instead. If you switch "have power" with "be a great leader" this will be just as effective.

In order to have power, you need to inspire loyalty rather than fear and suspicion

Expedition 33 is a video game celebrating what worked well a few decades ago in the RPG scene. A true labor of love. I don't play games that much anymore but a few gameplay videos and the hype brought me to it. Since the start, I couldn't put it down. For some context, I grew up with FFVII and FFVIII (although for some reason I played the VIII before the VII). Ever since, I missed the turn-based combat system and a story to get attached to. My hopes went up with Baldur's Gate 3 and went full blossom with Clair Obscure.

I've been doing an exercise during my playthrough to really understand WHY I found this game a great work of art. I recommend everyone to make an effort in distilling the reason why you truly enjoy something (e.g. a book, a movie). Little by little you'll be able to identify the underlying elements of what you greatness looks like to you. In my case, I also discovered things this game was NOT doing that I really appreciated.

The combat system is fun, but why? Turn-based systems allow you to take your time to strategize and not rely purely on reflexes and muscle memory. Knowing the order in which characters and monsters play, gives you the chance to think through your next actions. They also really nailed the dodge/parrying system. They found a way to combine active combat with turn-based exchanges. You are engaged in every fight, for every single turn, including the opponent's one. The parrying/dodging mechanism is not too harsh and you can get by even if you're not great at it (at least I did!).

The story is a true journey. As it unfolds, you start to understand that some things don't add up as smoothly as you thought (by design). You are made to believe so and so are the bad guys and you end up not being so sure who is on the wrong side of the story half-way through. It is not overly complex, you can follow along easily and it is up to you to expand further by exploring the world. To top it off, there's a strong moral choice you need to make. This opens up the conversation with other players on which decision they made and why. It forces you to stop and think not only about the game but also about human nature. I enjoy a story that puts you in a position of dilemma without giving you a straight answer (because a straight answer does not exist).

I completed the game obtaining all the achievements. To my surprise, there was no real grinding. What I mean is, I never felt the need to do the same thing over and over just to get the achievement. There's enough unique fights that you can end up at max level never really getting bored. Even the hardest challenges didn't take more than 20 minutes of attempts to pass.

Thoughts

I wish everyone the opportunity to experience pure awe for something. I still remember admiring Leonardo Da Vinci's paintings at a museum when I was a kid. And stood there wishing one day I could create something that's a clear labor of love like the one I was witnessing. Nowadays you can often tell the difference between a work done out of passion vs one done out of greed (to be fair, the distinction is not always that clear cut).

Can you think about something you were very passionate about when you were a kid? Have you found a way to bring that feeling back? Is there a chance for you to go back to it?

I decided to commit to this effort and work on my long-term memory. Part of it is the fact that I want to stay sharp as I age. I believe that building a habit now for long-term results will pay off. The commitment is to focus on all the non-fiction books I read since the beginning of the year. I would like to remember confidently not only the general content, but also some interesting facts.

To do so I will use Anki! For every book I will create flash cards that I'll review daily for 5 to 10 minutes at a time. I'm hoping to see some results next quarter so that by the end of the year I'm able to re-collect and converse about any of the books I've read.

I already reaped the benefits of spaced repetition for the US Citizenship interview. There you can be asked a maximum of 10 questions from the 100 Civics ones. Flash cards made it incredibly simple to learn and memorize, to the point that I went to the interview incredibly confident about it.

Thoughts

I will conclude by saying that everyone should commit to do this exercise and being more intentional on information that we want to retain. That could range from some fun facts to specific philosophic principles.

Another reason why I think flash cards are a good idea is to better balance the "waiting" times in your life. Rather than instinctively grab the phone for some good 'ol scrolling, you can alternate between pure quiet and focus times and quick reviews. I will test myself roughly at the end of next quarter to see if it had the impact I expect.

This was one of the many experiences I witnessed in my life. Looking back, I’ve come to recognize that these attacks were never personal. The perpetrators would commonly fall into three categories, each demanding a different response.

The Three Faces of Negativity

While this categorization might appear reductive, I’ve witnessed these patterns with such consistency that they deserve a better look.

1. The Backhanded Comments: Veiled Daggers

I’m always surprised by people's lack of awareness of how their words can affect others. Regardless of intention, they can either build someone up or tear them down. I’ve often seen these remarks as a defense mechanism or a way to dismiss someone’s work.

Neither is good. They reveal broken team dynamics. After all, who would dismiss a colleague’s work so easily, unless it threatened their work or sense of self-worth?

How do you react?

As someone who’s not a fan of gratuitous criticism, I immediately go deeper. I want to learn more about the comments made.

• What’s the basis for it?
• Where is this coming from?
• Do they have a better idea in mind?
• If it’s a concern, how can we mitigate it?

This comes from a genuine curiosity: Why do they feel like their comment should be made in passing? How do I transform a backhanded comment into productive criticism?

How do you avoid making this mistake?

Give yourself a chance to think before expressing a quick judgment. Avoid making wild predictions without information to back them up. This has the chance to damage a relationship you care about.

2. The Uninformed Critic: Speaking Without Knowledge

This can be an honest misjudgment, but not one we should overlook. I’ve noticed these comments from people who don’t want to be left out of the conversation. They sometimes believe a zinger can draw more attention and make them sound more intelligent. That’s a risky way to do it, not one I’d recommend. How do you react?

Lead with Kindness and curiosity. Assume the best and follow-up with questions to quickly dismantle the misinformation.

• What makes you think so?
• How can we work around that?
• Have you considered X (where X covers the context they might be missing)?

How do you avoid making this mistake?

Ask clarifying questions! I have found that some of the most competent and effective leaders leave nothing to be guessed. They ask questions that other people in the room might consider obvious. Doing so, they help everyone fill knowledge gaps, ensuring the whole crowd has the same level of understanding.

3. The Poor Communicator: Right Message, Wrong Delivery

This has been close to my heart for a long time. I have learned to give these individuals the benefit of the doubt, which often leads down divergent paths.

Sometimes, they’re genuinely too abrasive. No matter how you twist it, their actions reflect the way they communicate. That’s when I prefer to part ways.

Other times, they have good intentions but can’t express them correctly. In the latter case, I have built powerful relationships by simply taking time to understand their communication style.

How do you react?

Similarly to my previous article, separate information from delivery.

• Is it an objectively fair assessment?
• If it were someone else you trust saying it, would you consider that insight differently?
• Do their actions contradict their words? (i.e. are they generally good individuals to work with compared to how they deliver information?)

How do you avoid making this mistake?

Learn how to read the room and people’s reactions. That can be the first sign of you expressing a comment poorly. If you care about the relationship, don’t be afraid to ask follow-up questions and acknowledge that you have clumsily expressed your opinion.

I’m aware that reading social cues does not come naturally to everyone. If you’re unsure, find the courage to ask other participants for feedback. Reflect on it so you can improve your communication further.

What Research Reveals About Our Reactions

I wasn’t surprised to see evidence of what causes your reaction to naysayers and nemeses. Edward L. Deci and Richard M. Ryan's self-determination theory provides a straightforward and compelling explanation.

We all commonly need to feel competent and effective in our field. This is a driver for our motivation and growth. When faced with naysayers' and nemeses’ criticism, our sense of competence becomes threatened. If we feed into that knee-jerk reaction, we fall into the trap of exacerbating the relationship by taking a strong stance or response just to oppose the other party.

This is unhealthy and can lead to a lose-lose scenario. The rapport is now prickly, and that interaction can lead to the poorest outcome. It is now based on emotion, not fairness. I find myself circling back to Shane Parrish’s “Clear Thinking” book. In multiple instances, he calls out how emotional reactions (“defaults”) hinder clear thinking and better results.

These experiences can be discouraging, training the impostor syndrome to grow stronger. But it doesn’t have to end there.

From Negativity to Vigorous Motivation

I’ve found that skepticism of my abilities often affects me the same way. The default reaction is an emotional one, trying to protect my sense of self-worth from the opposing view. Once I overcome the initial self-doubt, I’m able to rationalize the rival’s challenge (or at least that’s what it looks like to me).

Seeing the naysayer as a nemesis is superpowered by the will to prove them wrong. Beware though! This is both good and bad. If it leads you down an unrealistic path that swerves you away from more significant outcomes, then you should stop and rationalize the cause-and-effect chain. On the other hand, you can drive that emotion to stay motivated in pursuing an important personal goal. Always asses what’s at the other end.

If you’re being challenged to jump over a Lion’s den because someone is second-guessing your courage, you should let that go. In this case, winning over the naysayer gives you nothing (but provides a nice meal for the Lion). Opposite to that, if you’re facing doubts in realizing your ambitious plan of becoming a pro athlete, you might just need to roll up your sleeves and prove them wrong.

Conclusion

When facing naysayers, harnessing disruptive emotions can propel you forward. Rivalry, properly framed, can be a motivator to help you focus on your goal. It’s not all dandy, though. It takes mental strength and willpower to re-frame any of the three interactions as a test rather than a final assessment of your worth.

What matters most isn't eliminating criticism but developing a harder shell. Learn to pause and discern underlying value from gut reaction. The strongest leaders aren't those who avoid criticism but those who've learned to mine it for the precious insights.

Does any of this resonate with your experience? What other strategies have you used to soar above the rivalry?

Every time I stumble upon any of these books, I come out with a potential framework. An example is Thiago Forte's PARA method. As I navigate these type of books, I come across different flavors of similar systems. Sometimes they solve the same problem in a peculiar way, sometimes they are just a way to organize your thoughts.

I wish I was more diligent in following any of them. Some stuck with me as a habit, others come and go. Today, I had a realization. What if I used a framework for "everything"? What if the way I lead a team, the way I navigate a crucial conversation, the way I make financial decisions, were all based on my own framework? In a way they already are, we follow our internal compass navigating these circumstances based on our life experience.

This can make it hard to measure the success of any of those systems. Sometimes you experience setbacks and adjust your compass, sometimes you forget about it. But do we ever stop and adjust our frameworks at any wrong turn? Would it be too challenging to start defining thinking systems for everything in our life?

Thoughts

On today's episode of scattered thoughts: everything can be a framework!

I like to nurture these passing thoughts and give them space to develop. I often come across different ways to approach a circumstance by reading books, taking a class, during a coaching session, and so on. While I consider how helpful these approaches could be, I rarely think about how I can effectively apply them to real life. I believe that this ability to closely observe behaviors around you (including your own) and how your decisions affect your life is a not-so-secret secret of highly successful people.

I'm starting to think (and writing it down makes it obvious) that "hoping" a lesson from a book sticks with me is wishful thinking. Note taking can only carry you so far; an almanac of frameworks could be something I use consistently and adjust based on its successes and failures. But how do I make it easy and simple to follow them at any given moment? That's more thinking for another day.

Building Trust As an IC

My impostor syndrome held me back, brushing away any chance to be part of a community. I felt the constant struggle of having to do it all by myself. Then, with a glimpse of mental clarity, I drove back down memory lane. I remembered that I had been the one building communities before, but not in a professional setting. It all came back. Building this environment requires deliberate work; it doesn't just "happen" over time.

I went through ups and downs when I worked at startups or smaller companies. Poor leadership often caused a lack of trust between peers. You would try to outshine your teammates and hoard knowledge to sound brighter. Not only did this make me feel lonelier than before, it eventually fostered unhealthy competition.

Collaboration was a second-class citizen. It created uncomfortable dynamics because you wanted to take credit for the work done. It was hard to make good, lasting decisions; everyone wanted to push for their idea even when it was not the best. Only one could win and get the trophy! (Spoiler alert: there was no trophy.) I didn't know how to change this, and I didn't feel empowered to try.

Looking back, I should have taken the initiative and talked to my manager. I was blown away by how people could run a company or manage a team at such a young age. I was sure they had it all figured out. How come they couldn't fix it? There was no way someone like me could help, right? It turns out they were also figuring it out. They didn't intend to create this environment and could have used someone to call it out.

At this point in my career, I thought I could gain trust only by delivering excellent work. I was uncertain about many things but was confident in my creative problem-solving. I doubled down on that and was eventually offered to be a leader at the company. Since I found myself trusting people who were either delivering or were trying hard to do so, I figured that’s how I should behave to gain the team’s trust.

My tips for building trust as an IC:

• Deliver excellent work.
• Go out of your way to help others.
• Communicate openly and frequently with your manager.

Building Trust As a Manager or Senior IC

As I advanced to managerial and director roles, I've been committed to creating a safe space. If I didn't feel empowered to lead those changes before, others likely felt the same. I knew it was a leadership problem then, so I wanted to be part of the solution this time. It all began with establishing a simple yet effective group chat for the team to focus on collaboration. It allows for exchanging ideas, asking for help, calculated risk-taking, and cultivating good rapport and trust.

I led the effort by showing my weaknesses and knowledge gaps. Doing so gave the team a clear signal: not everyone needs to know everything. I promoted the idea that, as a team, we need to support each other in overcoming our individual limitations. This approach helped foster conversations as equals where every member not only shared their ideas freely but also discovered how to serve the team more effectively, thereby building lasting trust.

At this stage in your career, you have the power to make a difference. Don’t hesitate to try different approaches. Observe how your team handles each change and adapt accordingly. Most importantly, collect feedback!

My tips for building trust as a Manager and also beneficial for Senior ICs:

• Show up when your team needs it.
• Listen openly and act quickly to resolve issues and blockers.
• Ask for feedback frequently.
• Create a safe space for the team.

“A Safe Space” means any place where:

• Anyone can openly challenge ideas without fearing repercussions.
• They feel comfortable disagreeing with one another.
• Anyone can admit when they make a mistake and know the team will be there to help.

Bring trust to your team today, by sharing this post with them!

Building Trust As a Director or Staff IC

As a director, the challenge of building trust extends beyond your teams. It goes across the entire engineering organization, which inevitably carries a different weight. In a way, this feels less natural. You must actively keep the trust level high, or project collaborations will fall apart quickly. You might lack day-to-day interactions, so you must plan how trust can be managed consistently.

Not too long ago, we needed to collaborate with a team in a different time zone. We both intended to make the relationship work, but we had to overcome the difficulties of having only a few overlapping working hours. There was a lot of transparency in surfacing concerns and challenges each team faced, which made the conversation simpler and more focused. I was eager to learn from them what an ideal collaboration looked like. This helped build trust and align us on goals. We eventually documented our strategy, which served as a reference for the future. We also settled for recurring check-ins, which helped maintain trust.

My top tips and habits for Directors and Staff ICs that I served my teams well:

• Ask for feedback, listen openly, act on it, and follow up. Communication channels should be open, especially for skip-level 1:1s.
• Encourage cross-team collaborations. This can take the form of a roundtable, a happy hour, or anything that helps avoid silos.
• Help and support your managers so they can iterate on trust-building within their teams.
• Be transparent by letting the team understand how decisions are made, the priorities, and what obstacles stand in the way of success.

Conclusion

Key strategies for building trust and collaboration include creating a safe space for team growth, clarifying alignment and challenges, and promoting open and transparent communication. As one's role grows within an organization, the scale of trust-building changes, significantly impacting the business and team's success. I hope it’s clear that you can make a change for the better, no matter where you are in your career.

A team with individuals who trust each other will outperform a team that doesn’t.

As I find myself further away from the coding aspect of my job, I'm still able to whip up a POC pretty quickly. The help of AI has been instrumental in making this possible, allowing me to prove a concept within a working day. Copilot has helped as a smarter autocomplete but I have yet to find its usefulness in resolving hard problems. In companies that create tech for others to consume, there's a plethora of ideas that have not been explored or implemented before. Some of the problems I have witnessed require such specific knowledge and context that generative AI is not able to compensate for it. It is also fair that I haven't tried too hard to make my prompts more refined and run some quality control on the output.

What works for me is having the expertise to tell when a generative model does a very poor job vs a decent one. Even when I explore things that are new to me (e.g. browser extension development), I'm still able to tell when ChatGPT/Claude/Whatever produces nonsensical results. This is still good, I can often refine the prompt and get to what I really want. If that was not the case, I'm not sure anything created by generative AI could really go beyond somewhat basic functionalities. This is to not to say that it can't. I'm more worried that people are so enamored by what it can do for you that they let it do the thinking too.

Thought

Generative AI has completely changed how engineers do their work and, inevitably, will change how anyone does their work. If you let it do all the thinking for you, I have a feeling you will only push it so far.

If you leverage it to unblock deeper thinking and understanding, then you can truly propel your growth AND make the best out of the latest models. I have mentioned this in a previous thought, today you can explore most topics in the way best fitting for you. No more digging through many books/videos/tutorials. You can even feed that material and interact with it until you are able to understand its content. This is part of what I am most excited about. Sadly I can also see (as some recent cases have reported already) how some people might find AI as a shortcut and I'm afraid that, if the keep going down that path, they will be left behind.

I immediately dove into reading and make it as easy as possible to do that instead of mindless scrolling. Little by little I was inspired to clean up my digital life and have been happier ever since. From a minimalistic home page, to few to none notifications enabled. It just felt so backwards that apps had control over my focus when it should be the other way around. I don't need to pick up my hone because of a random LinkedIn notification, and I definitely don't need to do that for an X notification. As notifications would pop up, I would long-press on it, and disable it. So refreshing.

At the time I thought I was done. I would check my phone because of a notification knowing that my filters were perfectly set up to only steal my focus when I deemed it necessary. I used browser extensions to make YouTube bearable and that felt like another cleanse. What I didn't realize at the time was that I didn't have the perfect formula. Things change, new platforms, new apps, new distractions. I slowly discovered how holding control over your Focus is not a one-time deal. You need to continuously stay on top of it or it becomes too easy to fall into old patterns.

Thought

You can't solve Focus unless you're willing to do a regular gut check. Everything is designed to keep you distracted, as soon as you realize you lost control, please do some digital spring cleaning!

I was so happy when I thought I had "solved" owning my focus. Then I found myself been pulled from something else, than something other than that, and so on. Be very mindful of apps you add to your phone, set up notifications from the start, and don't hesitate to mute anything that feels like noise. Even after I joined Substack, I almost immediately disabled all notifications. I instead dedicate some time every other day to browse it, that way I decide when it's worth for my focus to be on that rather than something else. Been able to decide where your focus should be is a never-ending effort but I encourage anyone to find ways to make it as simple as possible to remove distractions.

My Core Philosophy on Feedback

It took me just one experience to determine how to shape my management philosophy: performance reviews should be boring.

While they're a formal process that needs to align with company guidelines, if you get to a performance review with surprising feedback, your manager has failed. This philosophy works both ways - it's a partnership between managers and individual contributors.

Making This Work: A Two-Way Street

As an Individual Contributor

You need to seek feedback regularly. Use your 1:1s to check in with your manager about:

• Whether your approach to problems aligns with expectations
• How you're leading projects
• If you're meeting performance standards

By staying in continuous alignment with your manager on what "good" looks like and asking for specific feedback (e.g. meetings, projects, code reviews), you can adjust your behavior throughout the year rather than waiting six+ months.

As a Manager

I've learned to note down growth opportunities almost daily. It's crucial to build this habit and surface your findings as soon as possible. When I see behaviors that don't align with role expectations, I address them promptly while the experience is fresh.

I prefer giving people time to process feedback - not everyone digests it the same way. I try to share my input a day ahead so they can think it over and come prepared to discuss how they could improve. Instead of providing immediate solutions, I help them understand what meeting and exceeding expectations looks like in instances where they could have done better.

Why Surprises Might Happen

In my experience, I’ve seen a few situations where surprises made their way into a performance review:

1. First Performance Review You're still getting to know each other. Behaviors might build up to a pattern that only becomes visible when looking at the whole period. While this shouldn't come as a shock, seeing everything put together might be somewhat surprising.

• This should not be an excuse! You can mitigate it by doing “mid performance review check-ins”. This should push both parties to reflect on the previous X months. Some patterns might already come to light that can be discussed.

2. Poor Communication You might find yourself writing a review with new growth opportunities that haven't been previously discussed. I've made this mistake early in my career when I had more reports than I could effectively manage. It was an immediate learning lesson, and I promised myself not to repeat it.

• You should put in place systems that allow you to have more visibility on your team. Take notes regularly and discuss directly with your reports.

Making Reviews Less Stressful

By addressing things continuously, performance reviews become less stressful for both parties. It shouldn't be a moment of panic where you're trying to remember everything you've done. Instead, it should be a time to compile the notes you've collected through 1:1s and succinctly highlight:

• Completed projects
• Accomplishments
• Growth opportunities
• Progress made on previous growth areas

A Call to Action

If you receive a performance review with surprises, you need to have a tough conversation with your manager. Your growth and career progression depend on it. Find a system that works well for both of you to ensure there’s no unexpected feedback moving forward.

Remember, managers are people too. I've made some of these mistakes! When I had more reports than I could handle, things slipped through the cracks and I had a hard time keeping up. These experiences taught me valuable lessons about the importance of consistent communication.

Don't wait for 1:1s or performance reviews to give or receive important feedback. Make feedback and growth a consistent part of your communication. This way, when you get to the performance review, you can focus on patterns and overall progress rather than surprising new information.

The best performance reviews are boring ones - where you can look back on the continuous dialogue about achievements and growth opportunities, and use this time to plan for future development.

Parting Thought

To be candid, I felt robbed when I wasn’t given the chance to course-correct before the performance review. It seemed unfair, but it was an honest mistake from my manager.

Don’t be shy in leading upwards and expecting more from your manager. I could have delivered more and better have I known I was falling short. Nobody wins when we wait too long to seek or give feedback.

I have noticed a trend in many different size companies of chasing ideal theoretical maxima without really staying realistic. Unfortunately, decisions coming from these "visions" can vary dramatically based on the size of the company. I was guilty of this in some earlier startup experience. I think part of it was driven by the fact that I drank the cool-aid. I was knee-deep learning patterns and best practices and I convinced the team to follow them religiously.

I promise I had good intentions! At the time we were lacking code reviews (small team moving super fast and all). My goal was to minimize tech debt by aligning on state management in our React-based app. I documented in a README how the team should have gone about managing state and, with surprisingly no push back, everyone agreed. I like to believe that others just didn't have the energy to criticize the plan constructively so they went along with it, trusting my intuition.

What I did well was encouraging people to discuss drawbacks as soon as they found any, and to reach out if something just didn't make a lot of sense. Things went pretty smoothly until our most speedy developer called me up for some questions. Initially the back and forth was quite productive, I was able to cover some areas that he was unfamiliar with. Things went along fine until he second-guessed a specific pattern (I really wish I remember what it was). After some back and forth, I kind of ran out of satisfying answers. I caved and pat myself on the back for staying open-minded. Even though, at the time, I spent countless hours in React-land, my dream for the perfect state management didn't come fully to fruition. I just didn't encounter enough pain points to realize that some of the guidelines were, in the end, not very pragmatic. The team was suffering from it so we quickly adjusted.

This approach scales terribly. As teams grow bigger and communication channels are not as direct, enforcing ideal "visions" of what the future should look like might be too far from reality. I find it helpful to embrace the imperfections. Not everything will go according to plans, being resilient plays an important part here. Additionally, the bigger the company, the more communication should happen with representatives of teams that would be affected.

Thoughts

I'm not going to pretend I have a definitive answer to this. I don't find it necessarily bad to start from a vision of a perfectly crafted future as long as it eventually adapts to practical problem-solving. I have seen time and time again grandiose plans leading to nothing. I have seen frustration because of the excessive detachment from reality by authors of these plans.

If you witness something along those lines or if you're an author, you have to talk to people on the field in order to yield the best outcome for that initiative. The larger the company the higher the risk that those changes might be very hard to reverse. Be also open to talk more closely with few select teams and, if the plan is quite large, don't hesitate to run a pilot program to understand which gaps are there. Great leaders are open to big changes as long as they are focused on positive outcomes rather than enforcing a standardization for the sake of it.

Why I Care about Feedback

Our days are packed. When you add kids, and other responsibilities to the mix, your available time is slim to none. This leaves little room to dedicate undivided attention to mastering anything. That doesn’t mean you should give up. On the contrary, I urge you to discover how to be the most effective with the time you have. I reviewed books, papers, and lectures to learn how mastery is achieved, and found key behaviors that could help maximize your effort.

While there are several factors that can help your growth and path to proficiency, feedback comes up again and again. It’s one of the most challenging parts because it can disrupt the perception you have of yourself. It’s also one of the most powerful ingredients, as it supports your deliberate practice by attacking the weakest areas.

I care about feedback because it grounds me to reality, and only then I learn what to focus on next.

But what’s stopping you from seeking feedback?

What’s Holding You Back

Shane Parrish offers a good explanation in Clear Thinking. He calls it the “Ego Default”. This is a default behavior in response to anything undermining our sense of self-worth. Feedback directly critiques your work and can reveal truths you weren’t prepared for. Most of us have experienced this at least once in our life in school or work. That experience has shown us how uncomfortable it is to receive feedback.

The idea of how good we are at something is now under threat. Most people avoid this emotional rollercoaster, and live in the illusion of their level of mastery (likely as a defense mechanism). You might also be on the other side of the spectrum. You have impostor syndrome and are afraid that any feedback might confirm what you always feared. Fear is what governs a fixed mindset, while motivation to improve drives a growth mindset.

To support this, I found some research calling out the contrast between self-efficacy (i.e. the belief in your ability to succeed in a specific situation or accomplish a task) and feedback seeking. Individuals with low self-efficacy often avoid feedback out of fear of judgment and appearing incompetent. Things get more complex for individuals with high self-efficacy and it heavily depends on their mindset. Some feel at ease asking for feedback, as they don’t find the negative one will affect their ego or reputation. Others undervalue it, as they find it less useful to their already high performance.

I hope this gives you some reassurance that you’re not alone. Your feelings towards feedback are normal. Let’s explore where to go from here.

It Takes Courage, There is No Workaround

Without feedback, how do you know if you’re as good as you think—or worse than you fear? You can only rely on your perception or intuition to assess the quality of your work compared to others. That feels unreliable and biased. You might think you’re better than what you’re comparing yourself to, or you might see a masterpiece and conclude you’re never going to reach that level, so you might not start at all.

This creates an interesting problem. If you never receive feedback on your work, you never know if you’re as good as you think you are. You also never know if that unbearable feeling of incompetence is well placed.

I’m afraid there is no workaround. Find the courage to overcome this. If you’re not mentally prepared, feedback can feel brutal. Blinded by your irrational reaction, you won’t extract the real value of criticism and praise. Any time something threatens your self-efficacy, you might retreat to your safe place and protect the idealized image you hold of yourself. That’s a normal instinctual reaction, but there are ways to manage it (we will explore how later).

How do you get over your defense mechanism and seek feedback from others? Why would you even look for uncomfortable criticism of your work?

Understanding the Power of Feedback

I find that reasoning at the extremes might land the message more effectively. Imagine working on a canvas, endlessly refining it, only to discover years later that your work is far from exceptional. A single critique early on could have uncovered what you were missing and saved years of trial and error.

What if, instead of working in the shadows, you worked in the open? What if you waited a month to get feedback instead of a decade? In Mastery, Robert Green is effective in highlighting the importance of apprenticeship. A place where your views and knowledge are put to a test, your work is continuously criticized, and you’re focused on your weaknesses rather than bathe in a misplaced feeling of mastery.

Some of history’s greatest minds sought feedback consistently and were focused on their learning journeys. Take Leonardo Da Vinci, at the age of 14 he joined the workshop of Verrocchio, one of the greatest painters and sculptors of his time. He sought input from other bright contemporary artists and was able to leverage the apprenticeship to grow and become one of the most impressive individuals of his time (and some).

You might not be the next Leonardo Da Vinci and that’s OK. Whether you’re coding, writing, or leading a team, feedback is the bridge between where you are and where you want to be.

Does all Feedback Need to be Human sourced?

Human feedback is not the only way to improve and it can be complemented with non-human one. We live in an era where AI is omnipresent and can be used to your advantage. This can support a tight feedback loop and help you get started if you’re still hesitant to reach out to people.

If you go the AI route, you have to be willing to refine your prompts. These models are trained on a lot of existing information, you will likely get responses based on average results. If you’re behind the average, it will be help you get up to speed. In order to excel, I’m not confident in its ability to take you there. I recommend being open minded and giving it a try.

Like most things, it all depends on your context. If you’re trying to improve behaviors, peer feedback is the most impactful. If you’re trying to improve on your coding, use linters, write tests, check error logs, ask someone to review your code, or ask an AI to offer some guidance. The tighter the feedback loop, the quicker you can iterate and improve.

Don’t forget that one source of feedback should not exclude others. Any of these tools help best in conjunction with human input. If you balance this right, you can get a more complete picture with contextual insights from other people and quick iterations from tooling.

How to Stop the Misery

Until you sit down and think about what you’re so afraid of, you won’t be able to move forward. It all boils down to caring more about your growth than the vulnerability you feel exposing your work.

You can find examples everywhere, from accomplished people, to everyday life:

• Brandon Sanderson wrote over a dozen novellas before being published. Feedback from peers and editors helped improve his storytelling. He often recommends forming a writing group for this reason.
• Arnold Schwarzenegger often recounts how he’s not a self-made man and was supported and helped by many people in his life.
• Michael Jordan credited part of his success to his coach Phil Jackson’s feedback, even when it was rough.
• A manager adjusting his management style based on his team’s feedback.
• A teacher adjusting their methods based on student feedback.
• A startup founder constantly seeking feedback from early users to refine their product.

Be intentional about the type of feedback you’re looking for. No matter how harsh it can be, soak it all in and use it as a great opportunity to learn what to focus on next.

There’s no shortcut. Take a step back and be open to criticism. Robert Green comes in handy once more here:

“Get them [Masters] to give you the proper challenges that will reveal your strengths and weaknesses and allow you to gain as much feedback as possible, no matter how hard it might be to take. Accustom yourself to criticism. Confidence is important, but if it is not based on a realistic appraisal of who you are, it is mere grandiosity and smugness.”

The last sentence reminds me of the results from the research mentioned earlier, where some people with high self-efficacy dismiss feedback as unnecessary. This is where self-efficacy might be misplaced. And this is also where you don’t want to be.

Filter out the Bad

Is all feedback equally good? Should I listen to everything anyone around me is saying?

The short answer is no to both. You should ask for feedback from people you trust. I recommend asking your manager, your teachers, your peers, and direct reports. They have a different perspective on you and can provide a 360 view on your work.

Keep your circle small to avoid confusing or overwhelming information, prioritize people who are subject-matter experts, have demonstrated success in similar projects, or are able to provide constructive and actionable insights.

If you don’t know where to start, look for kind people in your life. Kind people are the ones you want feedback from, they will tell you things with honesty because they care. They won't sugar coat it just so they don't hurt your feelings. They understand the former is more important than the latter.

Sometimes you can’t control who’s going to give you feedback. Not everyone has your best interest at heart, you should weed these people out right away. Mean-spirited responses are easy to spot and simple to dismiss. Every once in a while, despite the abrasive or overly harsh tone, there might be some truth to the answers you receive. If you really value that specific person, remember that it’s not an assessment of you as a human being, but your work. Filter out the noise and extract the most important bits, throw away the rest.

For example, my early coding contributions were reviewed in a way that I found, at the time, abrasive. I took a deep breath and realized it wasn’t a personal attack. The reviewer was just getting to the point and all the feedback turned out to be quite valid. I learned how that person communicates and was able to focus on the important parts ever since.

Not all feedback is helpful. You can mitigate this by avoiding generic questions and digging into specifics. Whenever you see comments like “This could be better”, “I wouldn’t have gone this route”, ask follow up questions. Get to the bottom of it and if nothing useful comes out, you don’t have to keep it in consideration. Bias, overly harsh input, or non-expert sources are other examples of unhelpful feedback. They might even lead you in the wrong direction. This is where you have to learn how to take a step back and understand if what you’re hearing is aligned with your goals.

If after reading this you’re still unsure, start small and focus on advice that feels constructive and actionable rather than discouraging.

The Action Plan

Deep changes don’t happen overnight, but they have to start somewhere. Here’s an action plan to help evolve your mindset and propel your growth.

• Start Small: ask people you trust for informal feedback on smaller tasks. Get yourself comfortable with critique on minor work to build up confidence for more important ones.
  • Before writing a 1000 page novel, write a small novella and look for input from other writers..
  • Before doing a massive code refactor, start with a single package or file and seek other’s opinions.
  • Before going from theory to experiment, ask someone to review your assumptions.
• Be Specific: asking for effective feedback is an art, based on the type of work being reviewed make sure you have pointed questions. Avoid asking for generic feedback and offer a template to guide your reviewers. A few examples:
  • Is my test coverage sufficient? Did I miss any edge-case?
  • Does my document have sufficient examples? Are they clear?
  • Was the goal of the meeting I led clear? Did I provide sufficient context? Should it have been an email?
  • Is my style consistent? Did you find parts that didn’t fit well with the rest?
• Acknowledge and Reframe: fear is a normal response for anyone with low self-efficacy, you’re not alone. It’s important to identify feedback as an opportunity for development, not solely criticism. Stop seeing feedback as a judgment of self-worth and look at it as constructive guidance.
• Lean On Trusted Individuals: find people that have your best interest at heart and can provide constructive criticism. Especially if you’re struggling, it is important to find a safe place with people you trust. Look for:
  • Mentors
  • Peers
  • People who have been successful at it before you
  • Friends
• Embrace a Growth Mindset: any skill can be developed through effort and learning. A change in mindset can help against negative feedback, it’s an opportunity for improvement rather than a highlight of a limitation.

Conclusion

If you want to get better at anything, a feedback loop is indispensable. I hope this post gave you some peace in learning that some of your reactions to feedback, or really what’s holding you back, is normal. At some point, you have to decide if your growth goals are more important than discomfort.

It’s helpful to start small and accept comments on your work from people you trust and respect. You’ll find out that their praise holds a much different (and more significant) weight than any stranger out there.

At the end of the day it has to come from you. Until you’re ready to welcome feedback and get over the emotional barrier, you won’t be able to make the best of it. Be deliberate on how you seek someone else’s opinion on your work. Focus on weak areas and iterate.

• Are you trying to get better at writing? Write more and have someone read it. Ask for specific feedback and make changes.
• Are you trying to get better at drawing? Draw more and have someone review it. Point out areas you feel unsure about and use the feedback to address them.
• Are you trying to get better at public speaking? By now, you should know the steps to take.

Your growth depends on your willingness to seek feedback and act on it. Start small. Ask for one piece of feedback today. The more you iterate, the faster you’ll improve.

If you have a framework that’s been helpful for you (e.g. a set of questions), reach out and let me know! Alternatively we can figure out together how to focus your questions on the important aspects of your work.

Reads that inspired this post

Here’s a list of books that inspired me (no affiliate links):

• Mastery by Robert Greene
• Clear Thinking by Shane Parrish
• Extreme Ownership by Jocko Willink & Leif Babin
• The Making of a Manager by Julie Zhuo

I came back to X a year ago, with all good intentions to meet new people that shared my interests. What I found was another big mess. Superficial posts, copy pasted ideas, AI generated content, fake engagements. Individuals I looked up to (and I'm not even talking celebrities with millions of followers) were practically unreachable. The more I looked around the more I would find people trying to game "the algorithm", get in people's face often and build an audience.

It has become, to me, increasingly hard to find people who are more interested in creating a community than anything else. So in all the confusion and volume of noise flooding every platform, true gems are hard to find. But I also want to be realistic. I don't have the time I used to to go dig where like-minded people are hiding. In the process, I'm missing out on the best part of social media that, right now, I can't get a grasp on. Bluesky has been a bit refreshing, people seem to engage more, even those with an incredibly high number of followers. Similarly I noticed that on Substack (and I'm still trying to get the hang of it).

Thoughts

All the noise in the current world of social media makes it harder, for people who thrived in the 2000s, to build meaningful connections. Lacking the time to explore the right platform plays a big role in this, and I'm the first to admin this is something I have to change (if I care enough about it). I don't want to bathe in the distorted perception I had, when I was a teenager, of reality and how the internet was. People can be awful now and people could be awful back then, now social platforms are much more easily accessible.

We're missing the right formula that works today (or maybe it's just me). And I'm afraid to say that we might never get to it. At some point any platform that gets big enough will be infested with shallow conversations and average content. I have a feeling I just haven't looked hard enough and I really hope to be right.

Starting with reading, I'm changing the way I read books. I'm afraid I spent too much time worrying about how much ground I covered than the quality of the ground covered. Reading plenty of books loses meaning if you can't recall much. It becomes a vanity badge, but that's not what I want to get out of books I'm reading. I'm going to slow down, spend more time digesting what I read, and write notes in Obsidian at the end of each chapter. I found that to be a good way to help myself remember more of what I read. Reflecting more and consuming higher quality content.

I want to write less but better. While the idea of writing "Thoughts" was good to get me in the habit, I want to reduce the frequency of them and instead focus on bigger pieces reflecting on topics I am interested in. Rather than writing 3+ thoughts a week, I want to spend more time reviewing and refining focused posts monthly. I have spent a good amount of time getting some writing "out of my system" that I now feel the need to be more deliberate on how and what I write about. I think weekly "Thoughts" will likely stay but in a reduced frequency (closer to what I've been doing lately). I also want to get more external feedback. I believe that is a necessary step to get better at anything. I am blessed with wonderful coworkers who are willing to go through the pain of reading my drafts.

I want to run 100 miles this year. But, more importantly, I want to be able to run 5Ks comfortably at an increasingly faster pace and focus on reducing any ache. While I resumed a good running habit this year, consistency was a challenge which affected progress. From Thanksgiving on I was way more consistent and saw really good improvements. I want to keep that going all throughout the year.

Thoughts

I'm pretty happy about how 2024 went. I kept up wih my reading and writing habits. Looking back though, I'm not entirely satisfied with the quality of it all. I was worried too much about hitting specific numbers (30+ books) than I did about retaining that information. I believe it put unnecessary stress on something I genuinely enjoy. The biggest mistake was feeling constantly "rushed" (by what exactly I don't know), which pushed me to cut corners on anything that wouldn't count towards a metric or would take away time from it (e.g. writing notes down). That will change this year as I plan to retain much more of what I read.

Not too long ago my coworker (hey Nick!) surfaced this exact thought during an off-site. That resonated with me as we drifted into playbook-land rather than "how do I make this alert go away forever?". So my invite was to stop delegating this responsibility to a playbook that tells you "oh when this happens you usually have to go through these steps and that will make it go away". Instead we should work towards making that alert go away forever. What is the solution that will not wake me up at night for a similar issue? How can I stop using the playbook every time I see this alert?

This is why I enjoy new people coming onboard and calling out all the weird processes the team has in place. When you find yourself without an answer to explain the why, it's time to take the chance to change the process. Better yet, every once in a while, take a step back and look at your system as a whole. Which alerts are recurring more often? How do we stop that? Is there a permanent fix for this, if not why? Why do we keep following this playbook instead of getting to the bottom of it? How much time are we wasting investigating the same thing over and over again?

Thoughts

Playbooks should guide the high level process but not how to make an alert go away. Drive the initiative that brings a solution, make that alert stop from ever coming up again rather than replaying the same steps over and over. Take a look at your system and start from your most frequent alerts. Stop wasting your time (and your team's) having everyone follow a playbook that should be replaced by a permanent solution.

As I complained before in Distractions or The Illusion of Mastery it's hard to take control of your attention levels. I'm probably not the first to think about this, but I see how this instant gratification phenomenon has affected little things in life. From filling the dishwasher from the front, to keeping a plant alive (arguably not the best examples but hopefully you get the idea). Once I started to notice it, I could see it everywhere. And it gave me pause in every action I take in life. I inadvertently ask myself: am I doing this because it benefits me right now? Would future-me be happy about it?

I've been trying my best, ever since, to work on things that I might benefit from it years from now. A side project that I contribute to weekly, writing, journaling, reading, working out. Instead of chasing the immediate gain, I look at things that I would impress myself with in the future. I have tried to integrate this in my life daily, not always successfully but I keep trying. I'm trying to slow down, enjoy the ride, and learn as much as I can throughout the journey. Every year (maybe every quarter or so) I look back and asses if I made any progress, I adjust where necessary and try again. I am looking at long-term goals: what do I want to be able to do physically ten years from now? Where do I want my writing to be like 5 to 10 years from now? I admire efforts that take years to deliver and I constantly look around to find inspiration, and look back to see where I came from and how far I got.

Thoughts

I'm afraid that the aggressively attention-grabbing nature of many social apps have ruined how we approach short-term vs long-term goals. Spoiled by instant gratification, I see myself and my peers struggle to plan for the future and invest our time with focus on things that might take years to mature. My next long-term effort is the 5 year journal, let's see how that goes.

• Is there anything in your life you would like to achieve but are afraid of not being satisfied with it immediately?
• Have you tried working with bonsai?
• Is there anything, 10 years from now, you would love to impress yourself with because of your dedication and consistency?

One of the most significant selling points of a broker topology is its scalability. This can be achieved by being strongly decoupled, allowing individual components to scale without " worrying" about the rest of the system. The processors operate independently, so any failure doesn't affect the overall system's health. This also means that there are no inherent mechanisms in place to manage errors or retries (but that doesn't mean you can't; dead letter queues and retry policies are examples). As mentioned earlier, this decoupling helps scalability, making broker topologies a good choice for systems with high throughput demands (parallelization is "built-in").

Mediator topologies, on the other hand, are designed for fulfilling workflows. A mediator manages the lifecycle of an event and its related processes, ensuring state is tracked throughout. This is a big differentiator compared to a broker topology, where the broker itself does not worry about what happens in individual processors and the event they are handling. The mediator, by overseeing the processing end to end, is able to act on failures and course-correct before the processing continues to the next step. This added responsibility introduces scalability challenges. Since the mediator controls the workflow, it can become a bottleneck in high-performance systems. There are patterns to follow to mitigate the scalability limitations. You can get creative here; the book covers hierarchical mediators or distributed designs. Either way it's hard to escape complexity, which can make managing a mediator topology challenging.

I liked highlighting the difference between events and commands. In a broker topology, events can be ignored by processors, emphasizing loose coupling and flexibility. Mediators, however, treat messages as commands that must be processed, prioritizing reliability and workflow completion. It was the first time I read about this perspective (event vs command) when comparing the two topologies.

I also enjoyed the example distinguishing responsiveness and performance. Responsiveness measures how quickly a system allows you to move on to the next task, even if the previous one is still processing. Performance, on the other hand, refers to how fast a task is actually completed. With their ability to retry and track state, mediator topologies often improve responsiveness but may suffer in raw performance due to bottlenecks.

Thoughts

Broker topologies excel in scalability and simplicity, while mediator topologies bring reliability and state management at the cost of increased complexity. I'm not a fan of complex systems as they give a team headaches as soon as things go wrong. Depending on requirements, it becomes an art the way an engineering team can adapt by leveraging hybrid systems. But again, the more you steer away from a "classic" architecture, the more its complexity can bite you down the road. This is not an impossible task, but it requires a disciplined architectural design process.

That said, the key takeaway is not to memorize every detail of these topologies but to develop a high-level understanding of their strengths and weaknesses. This foundational knowledge empowers you to participate in discussions, make informed decisions, and adapt these patterns to your needs. I like to go back to the basics, mostly to dust off the tools in my toolset.

Finally (and I can't stress this enough), remember that simplicity is often harder to achieve than complexity. When designing or working with event-driven systems (or any system, really), aim to balance functionality and maintainability, making sure your architecture satisfies the requirements without unnecessary complexities. Keep It Stupid Simple.

Mastery isn’t something that can be sold. You can’t achieve mastery through shortcuts or quick tricks, even though many courses or programs promise otherwise. It’s true, some people have a natural inclination or talent that allows them to excel in certain fields, but for most of us, mastery comes from an intense, persistent dedication over time.

We live in a world where shortcuts to mastery are marketed everywhere. Courses, bootcamps, and memory programs promise that if you use their specific methods, you’ll reach expert level. I’ve experienced this personally—years ago, I took a memory improvement class that promised incredible results in memorization and speed reading. They taught techniques, like associating sounds with numbers or visual memory tricks, to help retain information. While helpful to an extent, these methods weren’t the magic solution to mastering memory retention.

What’s often hidden in the marketing of such programs is that these tools are just that, tools. They provide a foundation to support learning, but they don’t replace the hard work required to become a master. Skills like retention and recall are valuable but should be seen as parts of a larger, deliberate growth, not a guarantee of mastery.

Thoughts

If there’s one thing I’d like readers to take away, it’s this: mastery has no shortcuts. You can achieve a basic level of competence relatively quickly with consistent, focused practice, but true mastery demands far more time and commitment.

In the end, it’s about how effectively you use the time available to learn and grow in your chosen field. Try different methods, experiment with tools like tight feedback loops and flashcards, and find what resonates with you. But don’t obsess over the end result; instead, create a learning journey that’s sustainable and enjoyable. A true path to mastery isn’t about chasing shortcuts but developing a process that makes learning a consistent and fulfilling part of your life.

Mastery is a long road, but it’s also a rewarding one if you approach it with patience and dedication.

Once you’ve settled into these routines, it’s easy to overlook the mental effort required to manage day-to-day tasks. You forget things, commit to them without proper tracking, and later have that sinking feeling of “I forgot to write it down.” These small distractions pile up, pulling your focus away from more important tasks.

Recently, since I was promoted to Director of Engineering, I decided to step back and reevaluate my habits and processes. Being part of a new team and product has also forced me to challenge the assumptions I’ve carried for years. Fresh perspectives are invaluable—they can highlight inefficiencies we’re blind to after being too close to the work for too long.

As a software engineer at heart, I’ve been thinking about how to introduce more automation. For non-programmers, tools like Zapier or Make offer viable solutions, but I tend to shy away from third-party platforms unless they’ve been vetted and adopted company-wide. Trust is a big factor for me when it comes to sharing data, especially when it involves sensitive information.

Lately, I’ve been on a mission to automate as much of my workflow as possible. From my role as a lead to now as a director, I’m constantly evaluating the steps I take to see if they can be streamlined. My goal is to build systems that reduce mental load—not just for me, but for my team as well.

One thing I’ve come to realize is that creating new habits is similar to automating tasks. Make the new habit as effortless as possible. For example, if you take an allergy pill daily but keep forgetting, place it next to your toothbrush. You already brush your teeth daily, so it’s easy to integrate the new habit into an existing one.

For me, since I spend so much time in my browser, I’ve been experimenting with creating extensions that fit seamlessly into my workflow. These small automations make it easier to capture tasks, reduce distractions, and focus on what matters.

Automation is not just about eliminating repetitive tasks; it’s about creating systems that push tasks to you, instead of relying on memory. Whether it’s reminders, documents needing approval, or meetings, having these things surface automatically can be a game-changer.

At the core, it’s about making things easier to manage. One exercise I recommend is writing down where you spend your time every day for a week. Often, this simple activity can reveal opportunities to optimize your workflow. Look for the tasks that consume unnecessary mental energy and ask yourself: “Can this be automated?”

Thoughts

We’re often so focused on getting things done that we lose sight of how we could be doing them more efficiently. There are many opportunities for automation in our daily routines, but we won’t see them unless we take the time to pause, reflect, and evaluate.

Take a step back, write down your processes, and identify where you can automate or streamline. Doing this not only frees up time but also lets you focus on the things that truly matter—whether that’s the deeper work that requires focus or supporting your team in more meaningful ways.

The one thing worth noting, which I briefly highlighted in From Patterns to Frameworks, is Martin Fowler's effort in breaking down steps that most software developers consider muscle memory. By that, I mean we cobble together 5+ of these steps in one swoop, then check if anything breaks. There might be more productive ways to go about it, which is where, generally speaking, this book helps. It provides a detailed map of the refactoring steps to ensure you go from 0 to 100 without ever breaking anything. The frequent test-running habit supports ensuring that.

This is where some may get confused about the goal of the book (or these catalog chapters, to be precise). They are not recipes to be directly applied; developing the intuition on when they need to be used is your responsibility. It becomes clear when some of the patterns are the exact opposite of one another. They highlight the fact that the final choice of which path to take is up to the reader, and the book gives you the tools to help you make that decision. There were many trivial ones to review in this chapter, but there's still some valuable insight.

Isolate side effects whenever possible. "Historically", that's where most pain points arise; whenever side effects are hidden or mixed with other functionalities, it becomes harder to track down what causes the program to fall into a failed state. Clearly signaling when a function has side effects is a good communication habit, it might help trigger the reader's spidey sense. One of my favorite callouts was about the usage of boolean flags. Use them sparingly and not together back to back. When I see something like this:

const report = generateReport(entries, status, false, true, true, false);

I die inside a little bit. Now I have to check the function signature. This is generally not a big deal but it certainly introduces friction for someone reading through the code. I try to avoid this pattern as much as possible. A good intent that I share with the author is about making life easier for the caller. The snippet above is an example of the opposite of that.

Thoughts

Refactoring is a judgment call. Some cases are clear-cut; they are code smells that need addressing. Many other times, it's about you being able to find a good balance. Don't be afraid to make changes; even though I haven't had the chance to go about refactoring following the book's recommended steps, they are a good place to get started. A wrong refactoring will surface quickly as you go through the process. Overall, this chapter wasn't particularly illuminating; some of the observations are well put, but nothing new to me. I still enjoyed going through the various examples and would continue recommending this book to anyone doing active development.

The fear of failure can be paralyzing, making you second-guess yourself and hesitate to take on challenges. I used to view failure as purely negative, but I’ve come to realize it’s a crucial part of growth. Failure, in the right context, is an opportunity to learn. When you approach it with a growth mindset, it becomes a stepping stone toward improvement.

The competitive drive pushes me to seek an advantage—not always in direct competition with others, but in personal goals. It’s about striving to be better and continuously improving.

Competitiveness can be both a motivator and a source of stress. In its healthiest form, it encourages improvement and inspires those around you. Healthy competition pushes you to reach your full potential. But if not managed well, it can become overwhelming, leading to unnecessary pressure and anxiety.

I’ve found that too much pressure can distract you from the actual goal. It’s easy to create unnecessary stress by overestimating the challenge ahead or underestimating your own capabilities. The key is balancing the drive to win with the understanding that losing is sometimes part of the process.

A lesson I’ve learned over time is that success isn’t always about winning—it’s about being prepared and giving your best effort. What I’ve come to hate the most is facing a challenge knowing I didn’t prepare adequately. That feeling of unpreparedness can lead to disappointment, not because of the loss itself, but because I know I could have done better.

On the flip side, even if I lose after giving it my all, there’s a sense of satisfaction in knowing I did everything I could. It’s this mindset of preparation that allows me to learn from failure and grow, rather than being discouraged by it.

Early in my career, I interviewed with Google. Going in, I doubted myself, convinced that the challenge was too great. Though I prepared, I approached it with the belief that I would fail, which inevitably held me back. Afterward, I realized that I had missed an opportunity—not because I wasn’t capable, but because I didn’t trust my own preparation. Self-belief is just as important as preparation.

This experience taught me that mindset matters. If I had entered that interview with more confidence, I might have seen the outcome differently. It’s a lesson I carry with me in all challenges now: prepare thoroughly, trust the process, and believe in yourself.

As I’ve matured, I’ve shifted my focus from competing with others to competing with myself. The real challenge is in surpassing your own expectations, not just outdoing someone else. Whether it’s improving a technical skill, mastering a hobby, or advancing in my career, I’m always pushing myself to be better than I was yesterday.

That said, external motivators like naysayers or “nemeses” can still play a role. Early in my career, I often found myself driven by the need to prove others wrong. It wasn’t about undermining their expertise, but about showing that I was capable. These challenges pushed me to grow, and in many cases, I ended up forming strong relationships with the very people I felt compelled to prove myself to.

Thoughts

In the end, competitiveness is about balance. It can drive you to achieve great things, but only if you manage it wisely. You have to stay realistic—understanding that you won’t always win is crucial. What matters most is how you handle those moments and what you take away from them.

For me, competition is now about beating my own expectations. It’s less about external validation and more about pushing myself to reach new heights. Setting goals, preparing thoroughly, and trusting the process are what keep me moving forward.

So, set your goals, embrace challenges, and allow your competitive spirit to drive you. Just remember to keep it in check, and let it motivate you to grow, rather than stress you out. Competitiveness can be a healthy force—one that fuels improvement without overwhelming you.

One of the first times I led a team, I felt self-conscious. Impostor syndrome kicked in, and when I was having a hard time, I thought all I could do was handle it myself. I thought I should show strength and competence even in situations I've never been through. At no point did I feel I could lean on someone to share my thoughts with, including my manager. That's when I felt alone; I wasn't sure if what I was going through was normal, and I had no one to discuss this with.

This feeling worsens in challenging situations when you don't feel well-equipped to manage it. The problem is that you don't want to share this vulnerable side with other managers; it may feel like you don't want to expose a weak area of your leadership. But that's not true, and what's important to remember is that everyone goes through some struggles. I learned that just by talking to other leaders. The surprising thing was that it almost happened organically. I noticed another person was struggling with something similar, and I slowly opened the door for a casual conversation.

I took a leap of faith with a peer I felt comfortable with, and it was a big turning point. Fostering these relationships is crucial. They are hard to come by, but when you find one, don't let go. Talking about it aloud and hearing an unbiased opinion from a third party was an incredible help in allowing me to process events happening around me. Talking regularly with someone inevitably created a support system with 1:1s feeling closer to therapy sessions. Sometimes, you need to hear your advice from someone else, which hits you differently.

In my organization, I noticed there was no space for engineering leaders to discuss struggles and frustrations. So, I talked to my manager about it, who was very supportive and helped me set up recurring meetings. Once the awkwardness of the first time we met faded, it felt liberating! I helped create a safe space where people could share what they were going through with transparency and openness. As usual, I led by example by discussing my personal experience, which made others feel comfortable doing the same.

Thoughts

Being a leader can make you feel lonely. It's important to recognize that feeling and brainstorm what can be done about it. What worked for me (your mileage may vary) was finding someone who was going through similar struggles and investing in that relationship. I enjoy bringing the change I want to see; this motivated me to create a safe space for other leaders to discuss our day-to-day challenges openly. I think it's an even better idea to connect with leaders from completely different departments. At MongoDB, we have a recurring leadership development program that makes that possible. It was refreshing to learn what others struggle with, especially if you're going through the same journey.

This is to say that when that feeling creeps in, don't feel alone. Many leaders out there are going through the same pain and aches; it's part of the process. Embrace the challenge and use it as an opportunity to grow and connect with people in a similar situation.

Then I realized this pattern (ironic, uh!) in many other books. Some people have a great ability to distill patterns clearly and deduce frameworks from them. Whether they are technical or societal, it's a similar approach. Every author seems to be able to take a step back and deliberately analyze their actions and the associated outcomes. Then they write it down.

That is how most of the books I read come to exist. It is always fascinating to see patterns emerge, allowing you to better understand how a given system works (e.g., software architecture, leadership). Digging deeper into the "why" and "how" is not something I am used to doing; some behaviors seem natural and logical (e.g., prefer constructive criticism), but they exist for a reason, and there are countless examples of it. If you sit down and discuss WHY constructive criticism matters with someone, you'll get to the bottom of it quickly.

Thoughts

I admire people who slow down and reflect deeply on behaviors and habits. This is an excellent motivation to understand how systems work (e.g., society, software engineering), but to do so, you have to stop and think about it deliberately. I might try rationalizing some of my habits as an exercise, starting with why, how, and some examples.

I had some reassurance when I met up with some of my childhood friends (I had to take a 10-hour flight to do so). We casually started talking about this, and I realized it was more widespread than I imagined. I felt better and worse at the same time. I felt better because this is affecting everyone. I felt bad because this is affecting EVERYONE.

It's not a mystery that there is a continuous battle to grab your attention, but as days go by, it's hard to take a step back and realize its effect on you. But I would like anyone reading this to understand that it's not all your fault. Things are designed SPECIFICALLY to keep you glued to your screen, to keep that attention trapped.

My humble recommendation is to rewrite those habits and remove the problem altogether. If you're scrolling through Instagram too much, delete the app. You can always access it via browser where needed. Make it more challenging for yourself to fall into that trap again. I started to either remove apps or block them altogether. Eventually, the doom-scrolling just wasn't something I was tempted to do. I read more, write more, and work out again.

Thoughts

Plenty of books go into detail about how this attention-grabbing society is ruining our minds. It takes a deliberate effort to avoid any trap, and if you get distracted, you get sucked into the bad habits very quickly. Please don't feel bad about it; things are designed to get you hooked. This is part of what's behind a previous thought about Resiliency and Forgiveness. Go minimal with your digital life, and you'll experience a level of freedom you haven't felt in a while.

Today, I was reflecting on another trait I picked up from great leaders: the ability to stay focused during emergencies. The ability to stay calm during high-pressure moments is contagious. There is a distinctive difference between communicating a sense of urgency and panic. A sense of urgency arises when something needs to take priority over everything else; anyone contributing to the resolution of the problem should drop whatever they are doing and redirect their energy to the issue.

A clear example of this is an outage or an incident. In the tech industry, it's not about if it will happen but when. One thing I picked up a while ago was the ability of leaders to help the team stay focused. It's easy to scramble and panic when things go south, trying to revert whatever possible to remedy the issue. At times, though, that's not ideal and can give a false sense of confidence that a problem is resolved. Directions in these situations have to be specific with assigned responsibilities. Understand the impact, focus on the next steps, divide and conquer.

The real-life example that I always find helpful to explain this is the infamous "Someone call 911!". Just because someone said that out loud doesn't mean anyone will do it. This is why it's recommended to appoint a specific individual to do it, "You, call 911!". The same principle applies in any urgent situation; rather than declaring what needs to be done, it's essential to clarify who is responsible for what and reconvene for regular updates. This is simpler if you can stay calm and follow the process. Especially in critical moments, it is vital to follow whatever process is in place (and please draft one BEFORE you need it). That's what it's for, so you don't have to come up with the next steps during a high-pressure moment but can calmly follow protocol.

Thoughts

Don't rush it. When temperatures are high the worst that can happen is for things to slip through the cracks. If you lead with panic, others will panic too. Communicate the sense of urgency clearly and outline the next steps. I expect Senior individuals to confidently guide a process like this and help outline the plan. You don't have to have it all figured out, but there has to be a clear intention for the effort to be coordinated. Take a deep breath, review the process, and proceed accordingly.

Being aware of that, I try to push people in the right direction to help them build muscle memory. I can't even list the number of times I took the initiative on something as soon as I saw an opportunity, even (and especially) when it was out of my comfort zone. We naturally tend to gravitate towards things we're comfortable with. Sometimes we don't realize it but it's a cozy state that makes us feel like we're doing good. That's not bad and it's a perfect "parking zone", use those moments to recuperate and then...

Shake that off and pursue opportunities in grey areas. That's where the learning happens, that's when you can develop new relationships, and where your impact can be noticed. Work with your manager if you're unsure, let them know you want to do it more often. I showed this attitude to my managers in the past, this opened up more chances to grow as they started to send opportunities my way that were not directly visible, knowing I'd be up for it. I led the effort in moving our team to migrate to tools I was only vaguely familiar with. I got the chance to learn something new while simultaneously having a positive impact on the team. Go figure, I then became the go-to person for anything around that.

Thoughts

Don't wait around for opportunities to knock at your door. Discuss with your manager your intentions to learn and grow by taking on initiatives. Look around and find pain points either for your team or for the customer. Put together an informal proposal and show it to your manager and/or your peers. Taking initiative is crucial for strong growth. However, remember that growth can also happen within your comfort zone. Balance your efforts to take initiative with maintaining a sustainable work pace and self-care. Recognize that there are many ways to contribute and excel, and find the approach that works best for you.

An event-based model is reactive. Your system will behave differently based on the event it needs to react to. This is different from the more common request/response model where the behavior is deterministic. The event-driven model is fairly intuitive, I can use Atlas Triggers as an example. You can decide to react to specific MongoDB events (e.g. insert, update), and run a function based on that. The sky is the limit at that point as your function logic can go from sending a text notification for every new user sign-up to writing some metadata to a different collection. Given the user case, I'm more curious to explore (lightly) how the brokerage topology can help design reactive systems. This is something I haven't worked with before and thought I could use a refresher.

The brokerage model is highly scalable and responsive. It comes at the price of error handling. You would use a brokerage system when you don't need event orchestration (this is something a mediator topology would do). The mediator helps "move things along" by being in charge of how processing events are moved through the topology. For example, if you have steps 1 to 4, the mediator might expect an acknowledgment of successful processing before generating a processing event for the next step.

In a brokerage model, we have an initiating event that starts the workflow (e.g. a user signing up). In this case, the event broker handles different event channels (e.g. user sign-up channel). An initiating event would be sent to an event channel for processing. Event processors that are subscribed to this channel would then complete a task (processing) for any event sent to that channel (e.g. every time a user signs up). Once they're done, they send a processing event to the broker so that any other event processors interested in that event can execute their tasks. This can repeat multiple times until there's no event processor subscribed to a processing event. If you find this confusing that's ok, a visual would help with this (sorry!). Think of it as a group of task executors that only initiate when an event they're interested in comes in. Each of these executors will announce when they are done with their processing, this allows others to pick up that event. This design allows for simple extensibility as any other processor can be added to listen to any channel.

The problem? Error handling. If any of these event processors fails, there's no replay and no other processor is made aware of it. The mediator topology helps address these issue but sacrifices some of the scalability and responsiveness we mentioned earlier. There are ways to address error-handling in broker topologies but they add a layer of complexity.

Thought

This can be confusing without visual cues but hopefully, this is enough to get you interested in exploring more about event-driven systems. I'll follow up with other insights and limitations and I feel like it can be a good exercise to build a small broker-like event-driven system on your own. Don't worry about scalability, throughput and all that jazz. A simple implementation can help clarify how it all comes together. I've mostly worked with systems that need reliable processing of events, where failures need to be addressed and events retried. As usual, your choice of a broker topology over a mediator one depends on the system requirements.

Final disclaimer, I only gave a superficial overview of a broker topology. There are several other challenges (e.g. bottlenecks, single point of failure) that need addressing to design a robust system. I might touch on some of those in the future!

There are a few mental traps you can fall into. One is the belief that if you haven't achieved greatness or success (whatever these terms mean to you) compared to other people you look up to, then you're a failure. You think you'll never get a chance to shine and you just...give up. When I grew up I didn't have the awareness to understand that this is not true. I was so focused on the specifics (this person did this and that at my age already). That made me feel defeated for longer than I'd like to admit, so I carried on letting life take me anywhere. I felt late in life for everything I was trying to accomplish, which in turn sucked the joy out of anything I did. That started to wear off when I discovered more stories like mine. Individuals who started hustling at my age to eventually reach greatness later. You only fail when you give up.

The second trap is using comparison as a justification for what others achieved and an excuse for what you haven't. People who had an incredibly strong drive and will to escape their life condition (e.g. abuse, poverty). That's why they achieved so much (I thought), nothing else could have saved them. I have a decent life, but I would be stupid to take risks and bet everything on one thing (e.g. sports success, business). You now have a mental paralysis, you have an excuse for your current condition and a valid justification for others' success. Rather than seeing my condition as an advantage, I saw it as an excuse. So there was no reason for me to even try. You only fail when you give up.

Then I learned to look around and behind me more. Around me to the people who can do so much, and got there at their own pace. I look behind and see myself 10 years ago being a very different person, far away from who I am today.

Thoughts

This was prompted by a random thread on X, someone sharing the early work of Ken Thompson (the creator of Unix). They were denigrating themselves for not having achievements anywhere close to that. Or they were approaching a similar age and panicked they would never get to that level of "greatness". As I shared there, take a deep breath. Life is different for each one of us. You can start writing your story today. You just need to want it hard enough. I studied the "secret" to mastery, and it's all about deliberate practice and discipline. Leverage your condition instead of looking at it as a crippling mechanism.

As an IC I always took pride in the work I did, from the small projects to the large ones. That doesn't mean that my output was always the best I could deliver, it had to start from a few iterations that would get me there. Delivering projects that, at the time, didn't feel would be impactful, played an important role in my career. Peers noticed, managers noticed, and even across teams, people noticed. In one of my early experiences at a startup, I enjoyed creating tools that would allow us to move faster and streamline internal processes. In this case, I started with a small POC to create representations of rooms from a library of digital assets (e.g. a wardrobe, a bed, a chair). The goal was to understand if it could bring a measurable improvement. I prototyped with care not knowing that this tool would become a crucial part of all of our internal operations. It left a mark at the time, on our CTO, our CEO, and other coworkers that ended up using it daily, 9 to 5. This helped me set the tone for what I could accomplish and I leveraged it to gain trust on larger projects.

As a manager, I see and notice the type of effort people put into the projects they lead. Some don't realize the impact it can have on their career. In one instance we had a very large refactoring effort, with plenty of unknowns to discover. It was a challenging project because missing a smooth delivery meant disruption for every customer we had. The project lead at the time took the effort very professionally (as you would expect). The great surprise came when due to internal changes, that refactoring effort would have become less impactful. Instead of dragging their feet, or lowering their standards just to get it done, the project lead drove that to a conclusion beautifully. He coordinated with several teams, had to navigate a large codebase, and did all of that autonomously.

Anyone else could have "withdrawn" and lowered the effort, demotivated by the change of direction. This is where sticking to "giving it their best" was a career-making moment. This large effort, and the quality of its delivery over a year (yeah it was that large), put the project lead in a position to build a very solid case for a promotion. He was able to demonstrate he could deliver above his current seniority role consistently. The reward in the end was worth every drop of sweat. He got promoted and has been rock solid ever since.

Thoughts

It's easy to fall into the trap of not looking at the bigger picture. Sometimes you might believe things you're working on are not worth your effort. You're going to miss out! Talk to your manager to understand the impact a project and its delivery can have on your career. Either way, you should not be playing the guessing game. Any time you are given a chance to shine, give it your best. People notice. If you find yourself wondering if it's worth it or not, dig deeper. Why do you think that's not worth it? Discuss that with your manager and stay aligned.

The strong desire to write elegant code that allows my program to account for future requirements was something I was proud of. Until I realized I added complexity for a future that never came. Those requirements never manifested and I had to live with poorly made decisions. I can't provide a reliable guideline on how to go about this but I want to invite the reader (and my past self) to avoid trying to predict the future.

Being able to understand software requirements from the start is very rare. This is the nature of the tech industry in general, things evolve and change so rapidly that you might do more damage than anything in trying to stay ahead. Products are born and die quickly, so you have to be clever about what your focus should be on. I consider this to be powered by one simple factor: time is a precious resource. Whenever I think a substantial change feels needed I take a deep breath and give it way more thought before committing. Be nimble and attentive to where your time is spent.

I believe I was too dogmatic in my younger years. As I worked on a growing React project I made two mistakes that I remember clearly: committing to a specific folder structure, and refactoring our Redux state management. When I lay them out like this, they could seem reasonable. Eventually, they slowed down development more than I liked. My lack of understanding of how software evolves had me committing to this inflexible folder structure. I can't remember the details anymore, but I recall that it was a pretty flat folder tree. That meant that some completely unrelated components were next to one another, which made navigating the codebase frustrating. In the other case, I invested a lot of extra time into planning and refactoring our Redux stores, a refactoring that never saw the light of day. More urgent issues came up that required my full attention.

Both cases shared my lack of understanding that software evolves in ways we can't predict most of the time. This was not just anecdotal, Martin Fowler in "Refactoring" highlights this by inviting you to focus on the needs currently understood of your program. Speculation attempts on future flexibility are far less valuable than focusing on delivering greatly designed software for the needs we understand now. By adding unnecessary flexibility you add complexity to a system that will eventually become harder to change and less reliable.

Thoughts

I learned to be very cautious about my attempts to add flexibility to any program I contribute to. I bet on simplicity and resolving problems I'm aware of now, rather than trying to predict the future and increasing the complexity of my software. I tend to agree with Martin Fowler's general philosophy on small incremental changes, that would have made my time refactoring state management worth it. This doesn't mean running away from attempts to make things more flexible, experience will teach you when that is a good idea. The one thing you can't go wrong with is refactoring your system in a way that makes it easier to add functionalities without trying to predict what those functionalities will be. The way I look at it is that I prefer to focus on extensibility over flexibility. In other terms, design a system that can be easily extended rather than a system that takes into account many possible (but uncertain) future requirements.

The one thing I was really happy about from 2023 was hitting my reading goals. Technically I went way above my expectations and hit around 55 books. In the past, I would have pushed this to 60 for the following year, but I won't magically have more time to read books. I instead set a goal of 30. I believe that this is realistic and more in line with the long-term goal of keeping a good reading habit. Overall I've been trying to build new habits and continue to grow. I am exactly halfway through it so my progress is on point.

I also wanted to write more. This hits so many important growth areas including clear thinking, sharing what I learn to potentially benefit others, practicing something I generally enjoy doing, and producing more while consuming less. I made a mistake though, I started too strong and was able to write almost every day. This was somewhat intentional, I was working on creating a habit that felt natural and wanted to slow down later on. To this day I have 88 posts. I am incredibly happy with this progress. Writing doesn't feel like a chore and I wish I had more time to do it. I was able to Trick Myself to Write More early on, and it paid off nicely.

I wanted to focus on health and stop procrastinating seeing a doctor. As a dad, I feel overly responsible for staying healthy and being in decent shape for my little one. I want to be able to play as much as possible with her and for as long as possible. I started pretty well but winter sickness got me good. I had to stop for over a month and this destabilized my new-found habit. This is where Resiliency and Forgiveness played a key role. Instead of considering that a failure, I picked myself up and resumed as soon as I could. Seeing results is also a good motivator to keep going.

It wasn't all positive though and that's ok! I wanted to create longer posts once a month where I would go in-depth about topics I am passionate about. This felt reasonable at first, but I kept accumulating drafts as it was difficult to follow my train of thought by working on them every weekend. I will revisit this either this second half of the year or the next one. The best-case scenario would be an article every quarter but realistically, I would be quite happy with even just 2 every year. I also hit a wall around the end of March. That's when I was recovering from being sick and between that and poor sleep it was hard to stay the course. That's when I started relaxing my expectations to allow myself to recover quicker. Last but not least, I wanted to find a new love for small projects and software engineering in general. I still have mixed feelings about it, I was able to explore new areas which has been exciting, and I created a budgeting app that's been useful. I haven't closed the loop in many of the other projects, but I plan to do better. I consider that a stretch goal.

Thoughts

If you're a productivity nerd like me, you probably read about some of the lessons I learned in a book (or twenty). Setting realistic expectations played a key role in helping me create a sustainable new habit. I "attached" them to something I was already doing before and made it as easy as possible to pick them up with little to no effort (e.g. slowly transforming dog walks to dog runs, writing when I sit at my laptop after dinner). I don't have to think about them anymore, I just do them as part of my routine.

I accepted the fact that burnout can happen, and rather than fighting it and feeling guilty for not having a perfect streak, I used that as an opportunity to learn more about myself. I found out that the quality of my sleep has a tremendous effect on the "easiness" of keeping up with my growth habits. Rather than pushing through lack of sleep so that I can have a "perfect" streak, I take a proper amount of rest and pick up where I left off the day after. I recommend spending more time learning about what's holding you back. Keep a tight feedback loop and adjust accordingly until you find a good balance.

All in all, I feel better both physically and mentally, and I'm excited for what's ahead for the rest of 2024.

function processOrder(order) {
  console.log("Processing order for:", order.customerName);

  let total = 0;
  for (let item of order.items) {
    total += item.price * item.quantity;
  }

  console.log("Order details:");
  for (let item of order.items) {
    console.log(`Item: ${item.name}, Quantity: ${item.quantity}, Price: ${item.price}`);
  }

  logOrderDetails();
  console.log("Total price:", total);

  // ...
}

This is a trivial example just to get a point across. This function does more than process an order, one of them is logging. An initial refactoring step could be to extract the logging into its function like so:

function processOrder(order) {
  console.log("Processing order for:", order.customerName);

  let total = 0;
  for (let item of order.items) {
    total += item.price * item.quantity;
  }

  // Extracted function for logging
  function logOrderDetails() {
    console.log("Order details:");
    for (let item of order.items) {
      console.log(`Item: ${item.name}, Quantity: ${item.quantity}, Price: ${item.price}`);
    }
  }

  logOrderDetails();
  console.log("Total price:", total);

  // ...
}

This step felt odd to me. It's not immediate what the benefit is but I realized later that this is ONE STEP to prove that the logic for logging can be extracted. This breaks no test and is a step in the right direction. Eventually, we'll get to the point where this can be pulled out of the processOrder function and either be a class method or an independent piece of logic. I wasn't trusting the process, but I'm skeptical by nature so I was happy to see how it evolved. At first, I thought this could only work if you had a vision. Then I realized that a methodical approach to refactoring like this seems to guide you in the right direction. As you make non-breaking changes, some patterns will arise that can guide you into the next refactoring idea.

Thoughts

It takes good discipline to approach refactoring the way Martin Fowler does. It's a very methodical way that requires trusting the process. The big surprise was the dedication to make sure every change doesn't alter the observable behavior. It is purely perceived as a way to modify the internal structure only, while your program behaves the same. As soon as this definition of refactoring came up in Chapter 2, all the "awkward" steps made sense. As I look at how I review PRs I realize I do something along these lines pretty often. If a portion of the logic is hard to understand (or simply it's something I'm unfamiliar with), I tend to extract logic into its function, rename variables, and so on. Sometimes those small changes add up to a proposal in the review, other times they just live locally to facilitate my review. I want to give Martin's approach a try and see how that goes. There are a few more gems that came out of Episode 2 of the book club, but they would require a much larger conversation that I won't be able to fit into this 5-minute read-time post.

I strongly believe that if your work requires you to extend your hours beyond 9 to 5 then something is very wrong. I consider this a leadership failure, estimates and projects should be planned accounting for regular working days. Anything beyond that should be an exception. I won't hunt you down if you stay working longer hours, but you'll hear from me during our 1:1 that you have to take care of yourself.

The one thing I can often relate to is the need to "scratch an itch". I've been there, I've stayed up until 2 AM to get to the bottom of a blocker, I just couldn't let go. That's always your prerogative but I never expect you to do it. Some of the best engineers I've met, care a lot about the puzzle in front of them. When they face one, they also can't let go and spend extra time to get it solved. This is admirable but not sustainable. Proceed with care.

There are a few other situations where I can understand the extra hours. The first one is emergencies. I work hard to create a supportive team. This means that if anyone is bogged down dealing with a production issue, others are there to support and help out in any way they can. If this is not how your team would react, you need to work on strengthening relationships within it. If anyone on my team is in this situation, I'm the first one to show up. You lead by example, always.

The other scenario is something I recommend to anyone, especially early in their careers. The extra hours don't necessarily need to be actual work. You should continue spending time expanding your knowledge, filling any gaps, and being deliberate on what you want to study. This helped me tremendously in my first job. I was out of college, worked on research for the most part, and had a limited understanding of how production-grade software is developed. Every single evening I studied, took extra classes, and filled the gaps. After 1 year on the job, I was considered a technical leader.

No matter which path you take, none of it is sustainable without a work-life balance. What worked for me was focusing on what I found interesting and also fun at times. This was healthy because it didn't feel like work at all, when you create that type of balance you nurture a sustainable habit.

Thoughts

Any extra effort you put into growing and expanding your knowledge beyond your day-to-day work pays off. Don't just work extra or study extra for the sake of it. Have a Target and focus on what you need to get there. If that aligns with additional growth and visibility within your company, then maybe extra hours of work are exactly what you need. I generally recommend focusing on anything independent of where you work. Be deliberate about any skill that can be transferred, learning git well will benefit you no matter where you end up (I can make many more examples but I'll cut it short, hopefully, you get the idea). If your manager expects you to work extra hours, you're in the wrong place. I expect my team to respect the 9 to 5 and make sure they are set up for success. If the expectations for their role cannot be exceeded within their regular working day, something is wrong with how we evaluate performance.

This reminded me of some extensive amount of time I wasted back in 2017 (if I remember correctly). I was bootstrapping a lot of new projects at work, this included setting up Webpack over and over again. Unfortunately, it was often an extensive fight. This led me to spend evenings digging into the docs, and books, and playing with different configurations. Keep in mind that, most of the time, once you get the setup right, you'll rarely touch it (to be fair, that was at least my experience). Every time I had to go change something up, I had to re-learn the tooling.

Frustration led to "innovation" (I'm very hesitant to call it so in this case, but generally that's how it goes). So I built a layer of abstraction on top of it, which made the setup declarative and composable in a way that Webpack didn't provide natively. I never open-sourced it because it was not close to production-ready (maybe it was, I guess we'll never know). Going beyond the details of it all, I gained little to nothing from that experience. And I spent several months on it. Today I wish I could afford to do so!

This is part of the reason why I don't like to over-focus on a specific framework or a tool. I always recommend having strong fundamentals in your field, those will rarely go out of fashion. Tools, on the other hand, come and go (look at all the options we have today, for better or worse). There are a few things I learned from that experience, but nothing worth several evenings of my precious time.

Thoughts

Without getting too philosophical, we only have a limited amount of time in this life. If you put things in perspective, you realize that you should be very cautious about how you spend your time. Realistically, there are tasks (for lack of better wording) that are still hard to resist, or possibly they are just a gamble. Nowadays I timebox anything that I know won't contribute to getting closer to my target. If the ROI is high, I consider pursuing it; if not, I drop it. It took a few attempts before I learned this lesson. I won't get that wasted time back, and to this day, I wish I spent it on something else.

There's a caveat to all this that I think is important to highlight. Sometimes the ROI is not immediately clear, and you have to make a bet and take calculated risks. This is a skill that's hard to develop. It's also part of the reason why you should work on refining your intuition. This is something that Understanding Software Dynamics mentions several times. Before revealing the answer to anything OR looking at all the data available, attempt to guess what the outcome would be. Reveal the data, compare it to your intuition, and adjust accordingly.

All of this said, I consider my time spent speeding up our test suite for a specific feature a positive. It helped the team move a lot faster cutting out 20 minutes from our development lifecycle. I also consider the ungodly amount of time I spent learning the ins and outs of JS a great use of my time. I carried that expertise for a decade and should probably freshen up again.

The first topic of discussion came from me and it was about testing. The first thing recommended before you start refactoring is to make sure you have a robust set of tests. This is reasonable, and I admittedly don't have it as a habit. I'm a bit spoiled because we have a strong culture of testing at MongoDB. Most of the time I was able to rely on the existing suite to understand if any of my work introduced a breaking change. I think this approach is both good and bad. It's good because having a solid starting point makes refactoring more predictable. It's bad because you might be too generous in your assumptions about the existing test suite. So my real-life advice is to take a look at the existing test suite (if any) to ensure it's robust and testing the right things. This feels necessary as different folks might feel different about what should be tested. One time we had some legacy code that was testing implementation details, as soon as I made a change and optimized the body of that function, half of the tests failed. Build awareness of the code you intend to refactor by taking a hard look at the existing tests, this will guide you in understanding what the expected behavior is and if the current suite is acceptable. Nothing will stop you from adding or changing existing tests before you start refactoring.

Another interesting point discussed was the granular cycle of making a small change, running the test suite, and finally committing. Admittedly, I go about it a different way. My approach is about making as many changes as I can, as long as they are coherent and don't break tests. If they break tests, I undo them until I have valid changes. It feels more efficient but I can't tell if it's as effective. The tight feedback loop guarantees that you know, for any refactoring step made, which one broke your tests. This strictness might slow you down if you have a large set of tests to go through. On the other hand, you know that every change you make along the way is valid. Unsurprisingly I recommend being judicious about how you group your code changes. Find a balance between efficiency and effectiveness that works for you.

Thoughts

What a great experience so far! I was afraid some of my opinions would not be shared by others but I was happily wrong. We had a nice mix of Engineering Managers, Staff Engineers, Mid/Senior Engineers, so it was a well-rounded crowd. Everyone was able to chime in based on their experience and hopefully learn a thing or two along the way. It is a good exercise to read a book like this with a critical eye and discuss it with peers. It helps develop your intuition further and also gives some insight into how other people look at the approaches presented. Nothing was controversial and we all agreed that, while some refactoring techniques seemed overkill, they still communicated well the mental model Martin Fowler follows when rewriting code. Onto the next chapters now!

I was able to find the information I needed just fine but as I glanced at the explorer on the left side, I noticed a few notes that felt off. Some of them didn't make a ton of sense until I opened them, only then I was able to recall what they were about. This holds you back when exploring your notes, if you need to open them one by one to understand what they're about, you're doing it wrong.

I thought at first this was a reasonable mistake. I was titling my notes the way I would title a thought here or a blog post. It made no sense, I was trying to capture my attention or peak my interest so that I could go open the note. But that was not my intention. I realized (and I'm sure that if you read some of the books about note taking you might know this) that the punchline MUST be in the title. By reading that only, I should be able to tell exactly what the note is about.

That's not it though. I took the chance to review at random some of my notes (as you might guess, there's a plugin for that). If the title didn't capture the idea, I changed it. In doing so I discovered an additional mistake. While it is recommended that each note is about a specific and well-defined concept (also called "atomic notes"), I learned that it wasn't the case for me. I found myself unsure what the title should be because the note included different pieces of information. I was taking notes wrong and this exercise made that very clear.

Let's see an example, I had one note titled "Writing Guidelines" which would make sense for a blog post. The content included a few pointers and they were all very different from one another. On that same note, I mentioned that when you make an effort in writing something clearly it forces you to have clear ideas (or to make them so in the process), that readers have a limited attention span, and so on. I had no way to change the title effectively so I created separate notes. In our case: writing clearly forces you to have clear ideas, when writing remember that attention is a limited resource, ....

Thoughts

I underestimated how powerful proper note titles can be. It forces you not only to express the content effectively but also to make your notes truly atomic. This will inevitably lead to smaller notes in content and that's ok, it allows you to expand with examples that are coherent with the idea presented. I feel like I just leveled up my notes with "this one simple trick".

We chatted a bunch and the one lesson I got from him was to focus on the people you'll work with, that makes a world of difference. He had a very good example, he worked on Ads at Google and while the project/product wasn't the most thrilling, he was surrounded by people he admired that he was very happy to work with. I took that lesson to heart and applied that to any job hunt afterward. I have used this advice as a driving factor for any decision. At one point I had 3 offers on the table, I got the chance to meet everyone and I considered four aspects: the people, the career opportunities, the product potential/direction, and the compensation. In that order.

I want to say that 2 out of 3 were startups. One of them stressed me out the moment I entered the office, just looking around at people's faces and their anxiety was not a great selling point. On the other hand, the manager was great, and the projects they had lined up were pretty novel in the industry. Another one had tremendous growth and was profitable within a year, there were no career opportunities and they just needed another strong developer. While I liked the other devs, the founders looked like they didn't care much since this project was part of a larger "portfolio". The last company I interviewed for just clicked immediately, from the manager to my potential coworkers; it's hard to explain but it just felt right. They also happened to have an interesting project, so I was in a pickle for a moment. I ended up going with them because of the advice I was given a while before. They seemed to care at a human level and were focused on solving problems together.

I stand by that advice, and it's something I share with as many people as I can. You should keep in mind that just because you found the right people, it doesn't mean you don't have to focus on the product. Being surrounded by a supporting group is essential, and to grow, it helps to embrace and understand the product. There's no way around it: folks who understand the strong and weak parts of the product, who care about its evolution, and who focus on how to make an impact, often have the strongest career growth. This is nothing new, but early on, I stopped at "find good people" and didn't think about what came after that. So to you I say, find the right people to work with, focus on understanding the product inside out, and finally, find how you can deliver with high impact.

Thoughts

Not sure what prompted this today but I look back at that advice and feel forever grateful. I'm surrounded by great people now at MongoDB, not just coworkers, but folks who want to connect beyond the day-to-day job. This brings me peace because I know that, no matter what, I'll land on my feet with the right group of people. Products come and go; that's normal, but as long as you're in the right crowd you can still grow and be successful. You should spend some time reflecting on why that specific group of people works for you. Sadly, people also come and go, but if you can decode the magic ingredient, you'll know exactly what to look for for the rest of your life. I wrote about Being A Good Interviewer, and you can extract some clues from there on what you should expect. Write down the core values that matter the most to you, then ask questions to learn if the team you could join aligns with those values. This is part of the reason why I'm shocked when candidates have no questions for me; there's so much to learn about a company by asking directly to the interviewers.

Once you're in the right place, if that matters to you, the next step is to understand how to make an impact and then deliver. You don't have to do this in order. At the time of interviewing it's good to understand the strategic direction of the company and what possibilities are there to make an impact. Discuss this with your potential manager and use that to find out if it's a good fit or not.

It's not surprising how relevant the act of refactoring is for anyone who writes software. Sometimes it's just lack of experience, sometimes it's the best you can do then, and other times you just have to work with what you got. Either way, refactoring is essential. Building a good habit that is integrated into your team culture will make your codebase maintainable in the long run.

The simple attempt at refactoring your code will already tell you a lot about your design decisions.

A poorly designed system is hard to change

Based on this, we can look at the small picture (a single function) or the big picture (entire components and how they interface with one another). What will be evident, after a few minutes of staring at whichever component you're trying to refactor, is how difficult it's going to be. I'd argue that refactoring per se is never simple. If we think about improving the internal structure without altering any external behavior, there are possibly MANY ways in which this improvement can take place. This is risky business. You're not re-writing for a computer but for humans. Being able to do it in a universally good way is challenging.

Don't let that stop you. I think the first chapter starts pretty well, I appreciate that Martin Fowler explores a practical example. If you paid attention, we mentioned "not altering any external behavior". Thankfully there's a way for us to make sure that doesn't happen: tests! This is something I may not have done consistently in my refactoring efforts. I relied too much on existing ones. Usually, only AFTER my changes and learning more about the logic I was working on, did I have a better idea of what tests I needed to add. I don't think that's necessarily wrong but one approach doesn't exclude the other, making sure I have a strong test suite before I refactor is something I'll do more of moving forward. And you should too!

Thoughts

I couldn't resist the idea of picking up this book again. I liked it back then, and I plan on making the best of it as part of the book club discussions. I could tell you that refactoring is an art, and I partly believe so, but it's about discipline and experience. It's hard if you don't have a picture in mind of what good refactoring looks like, what patterns are simpler to follow, and generally how to make your code more understandable to other humans. I thankfully think very little of my coding abilities, this paid off more often than I thought. The reason is that I am generous at leaving comments explaining the WHY of my choices. This saved more than a few times when I had to pick up code I wrote a year+ before. After a while in the industry, you develop a feeling (sorry for not being particularly precise here, this is just a passing thought), when code you read doesn't seem right. You have put some effort into rationalizing that feeling, recognizing what doesn't feel right and chipping away at it until it does. Refactoring helps you build that mental model, but I'll confirm that once I'm done reading.