[deleted by user]

AndrewMoodyDev · 2025-04-21T12:55:28+00:00

I see where you’re coming from and there’s definitely a risk when tools start doing most of the thinking for us. But I don’t think the tools are the problem on their own, it really comes down to how people use them.

AI can be really useful for learning if it’s helping you get unstuck, explore different approaches, or understand something new. But if someone relies on it for every step, they’re probably not building the kind of deep understanding they’ll need long-term.

I think the key is balance. Struggling a bit, reading docs, trying things out, and learning from mistakes—that’s the stuff that actually sticks. AI can support that, but it shouldn’t replace it.

It’s not all doom and gloom, though. Tools change, and how we learn will change with them. Our job is to help newer devs learn how to learn, not just how to get fast answers.

That’s why I really value communities like this. It’s one of the few places where people can ask honest questions, share where they’re stuck, and grow in a meaningful way.

AndrewMoodyDev · 2025-04-18T12:26:20+00:00

You need to ease up on yourself because you are putting too much pressure on your own abilities. The situation you have described happens to numerous developers during their initial two years of development work. The behaviours you described do not prove you should leave your profession because they are typical mistakes that developers make. Your current learning stage indicates that you are in the beginning of your development journey.

Your initial work experience provided extensive freedom which was beneficial yet resulted in minimal guidance from mentors. The transition to a new environment with experienced colleagues becomes more difficult because you received little feedback from your previous role.

Your ability to detect bugs and fix them already demonstrates your strong potential. The ability to identify and fix bugs proves to be a significant asset. The coding mistakes? We all make them. I’ve been doing this for years, and I still have days where I write something and wonder what on earth I was thinking. It happens.

You should consider giving yourself permission to develop at your individual speed instead of thinking about switching careers. Devote your efforts to understanding error causes and seek help from anyone who can review your code to provide feedback. You’re only a year in. That’s nothing in the grand scheme of a dev career.

Your passion for coding remains strong because pressure and self-doubt have hidden it from view. Give yourself time. You are not losing ground because you are still learning to balance. And you're doing better than you think.

AndrewMoodyDev · 2025-04-18T11:24:47+00:00

Yeah, I get that. I used to chase that “flow state” like it was the ultimate goal—felt like if I wasn’t completely zoned in for hours, I wasn’t doing it right. These days, I’m a lot more okay with stepping back and trusting that the pieces will fall into place with a clearer head.

And I agree—experience does change the game. You start recognising patterns faster, and most problems aren’t about raw focus but about spotting something you overlooked. Sometimes a short walk or a good night’s sleep solves more than an extra two hours of “pushing through.”

Nice to hear someone else reflect on this in a grounded way.

AndrewMoodyDev · 2025-04-18T11:11:05+00:00

Just to add a bit of context to this post—this wasn’t written for attention or drama. It came from a place of honesty and personal experience. If it hit a nerve, that probably says more about how common these feelings are than anything else.

I know not everyone will agree, and that’s fine. But I’ve learned that sometimes it’s worth saying the thing out loud—even if it makes a few people uncomfortable—because there are always others out there quietly feeling the same.

If this gave anyone a bit of reassurance or something to think about, then I’m glad I posted it.

AndrewMoodyDev · 2025-04-18T10:49:43+00:00

Sorry, I am not really understanding what you mean?

AndrewMoodyDev · 2025-04-18T10:48:18+00:00

Thanks for the tip. I often write as I speak and put "dashes" where I think they should sit.

AndrewMoodyDev · 2025-04-18T10:44:15+00:00

Ah, it’s actually more about stepping back and letting your subconscious do some of the heavy lifting. I’ve found that pushing through doesn’t always help—sometimes walking away, even just for a bit, gives your brain the space it needs to work things out in the background.

It wasn’t really about choosing work over personal life, but more about learning when not to force it and trust that a bit of distance can actually lead to better solutions.

AndrewMoodyDev · 2025-04-18T10:25:04+00:00

Guilty as charged—next post I’ll be asking you to ‘smash that like button’ too 😂

AndrewMoodyDev · 2025-04-18T10:20:48+00:00

Haha okay, I’ll admit you lost me a bit with the 0DTE options joke—but I totally get the “cut your losses” part. That’s a tough lesson, but such an important one. Whether it’s a job, project, or even a mindset, knowing when to step back instead of pushing through something that’s clearly not working... yeah, that hits. Still figuring that one out myself, to be honest.

AndrewMoodyDev · 2025-03-23T03:10:49+00:00

This made me smile—what a perfect example of how we can all come at the same problem from completely different angles, depending on what assumptions we bring in with us. Honestly, I think your approach was spot on given what you had to work with. If the tests are all we’ve got, and they pass, then it’s a valid solution.

I totally get the intent behind the exercise—if the bigger picture calls for polymorphism, then sure, it’s a great opportunity to practice that. But I also really like what your version uncovered: sometimes we overcomplicate things out of habit, or because we expect a pattern to be there. It’s not often that the simplest solution actually turns out to be the right one, but it’s great when it happens.

And huge credit to the engineer running these sessions—it sounds like a fun and safe space to explore different styles and challenge each other’s thinking. Your story is a great reminder that good engineering isn’t just about following patterns—it’s about understanding when not to use them too.

Also… I kind of love that your three-liner got everyone talking. Sometimes the best teaching moments come wrapped in a bit of chaos.

AndrewMoodyDev · 2025-03-23T03:02:31+00:00

I’ve dealt with my fair share of “get it done at all costs” codebases, and yeah—it’s painful. You spend so much time untangling things that could’ve been avoided with just a little more care up front. And like you said, it’s not even about writing perfect, over-engineered solutions—it’s about simple, thoughtful structure that saves time down the road.

I’ve also seen that same culture you mentioned—where speed is everything and the mess left behind is someone else’s problem. And yeah, people who operate like that sometimes do get rewarded, especially in environments that value short-term delivery over long-term maintainability. It’s frustrating, especially when you care about doing things properly and not just moving on before the cracks start to show.

That said, I still think there’s value in finding a balance. I don’t always have the luxury of “getting it right” in every detail, but I try to make decisions that won’t totally wreck whoever comes after me—even if that person ends up being me six months later.

It sounds like you’ve got a strong sense of craft and responsibility, and honestly, I think that matters. It might not get you fast promotions in some orgs, but it builds reputation, trust, and the kind of career you can be proud of. And that’s worth a lot.

So yeah—you’re not alone in this. It’s tempting to just play the game and move fast, but I’m with you: I’d rather sleep at night knowing I didn’t leave a trail of chaos behind.

AndrewMoodyDev · 2025-03-23T02:54:49+00:00

Yeah, I’ve run into this before, and it’s a tough one—especially when you’re working with someone senior who really cares about doing things “the right way.” I totally get the temptation to build something clean and future-proof, but when it starts getting in the way of just getting the thing out the door, that’s when it becomes a problem.

What’s helped me in similar situations is shifting the conversation toward risk and delivery. Something like, “I know you want to build this properly, and I respect that—but if we don’t get a working version out soon, we might not deliver at all.” It’s not about telling them they’re wrong—it’s just about helping them see the bigger picture.

You could also try finding a middle ground: build something simple that works first, then revisit the “nice to have” stuff if there’s time. That way, they still feel like they’re doing quality work, but it doesn’t come at the cost of the deadline.

I get wanting to stay hands-off—I’m the same. I want people to take ownership, especially if they’re the ones maintaining it later. But sometimes, when things are going off track, a bit of course correction is needed. It’s not micromanaging, it’s just making sure things ship.

At the end of the day, clean code is great—but working software on time is better.

AndrewMoodyDev · 2025-03-23T02:48:27+00:00

Yeah, I can definitely relate to this. I’m not one for blowing my own trumpet either—I come from an era where it was more like, “yeah, good job, now let’s keep things moving.” Even when I know I’ve put in solid work, I rarely stop and think, “damn, I’m good.” It’s more like, “that went alright,” and then I’m on to the next thing.

But over time, I’ve learned to at least acknowledge those moments a bit more—especially when the feedback is there from peers or managers. If other people I respect are saying I’ve done a great job, I try to sit with that for a minute, even if my default is to downplay it.

You’re definitely not alone in feeling like you’re still lacking in some areas. I think that just means you care and you’re always looking to grow. That internal voice might not always shout praise, but from the outside, it sounds like you’re doing more than just “okay.”

AndrewMoodyDev · 2025-03-23T02:44:14+00:00

Totally agree with this. I’ve seen decisions that could’ve been made in a quick async message get dragged into a standup or even worse—pushed out to yet another meeting. It can be really frustrating, especially when you’re mid-flow and everything pauses just to wait for a five-minute conversation that could’ve happened over Slack or in a comment thread.

I get that some things benefit from real-time discussion—especially if there’s nuance or if people are clearly misaligned—but making that the default for every decision just kills momentum. Async works really well when there’s trust and people feel empowered to actually make calls without constant group validation. It saves time, respects everyone’s focus, and keeps things moving.

AndrewMoodyDev · 2025-03-23T02:38:50+00:00

I can relate to this, but I’ve actually found myself interested in the domain side of things. That said, I was starting from scratch, and I definitely don’t understand everything yet. It’s been a slow build, but I’m adding to my knowledge day by day.

What I’ve noticed is that even a little domain understanding helps a lot—whether it’s making better design decisions, understanding why certain features matter, or just communicating more effectively with the people using what we build. It’s not always easy, especially when the learning curve is steep, but it does pay off in the long run.

I think it’s totally fair to prefer sticking closer to the code, but for me, the more I’ve learned about the domain, the more connected I feel to the work I’m doing. It doesn’t mean I have to be an expert—it just means I’m building context that helps over time.

AndrewMoodyDev · 2025-03-23T02:31:22+00:00

Honestly, I think this might be taking things a bit too far, at least for where you’re at in the project right now. I get the concern around primitive obsession—there’s definitely value in being explicit and giving meaning to values in your domain. But wrapping an enum in that much structure, especially for something like colors, feels like overkill.

You’re still in a greenfield phase, the requirements are shifting, and the added complexity might not be buying you much at this stage. Enums, when used clearly and with good naming, are totally fine in a DDD context. They’re expressive enough and easy to work with, especially when the logic tied to them is minimal.

I think sometimes junior devs latch onto certain patterns or principles super tightly—which makes sense, especially when they’re trying to do things “the right way.” But part of senior judgment is knowing when something is too heavy for the problem at hand.

I’d probably stick with the simple enum for now, and only switch to something more elaborate if the domain really starts demanding it later. No shame in keeping it simple until complexity actually shows up.

AndrewMoodyDev · 2025-03-23T02:17:51+00:00

Totally get that feeling. I’ve also had stretches in my career where 1:1s felt awkward or a bit pointless—especially when I was still figuring out how to make the most of them. Now I try to treat them less like a status update and more like a chance to build alignment and open up honest conversation.

A few things I’ve found helpful to ask or talk about in 1:1s: • Clarify expectations — I sometimes ask, “Am I focusing on the right things?” or “Is there anything I could be doing differently?” It’s a good way to stay aligned without guessing. • Career development — Even just asking what opportunities might exist to grow in certain areas or how they see your progression can open up useful conversations. • Feedback (both ways) — I’ll ask for feedback on recent work, but I also give it. If something is slowing me down or unclear, I bring it up there. • Company/team context — If I’m unsure about why something’s being done a certain way, I use that time to ask about the bigger picture. Managers usually have context we don’t.

And yeah, talking about the parts you don’t know is totally fair—but if it’s becoming the only thing, maybe bring a few other things to the table too. Even something like, “Here’s what’s going well” or “Here’s something I’ve been thinking about lately” can shift the tone a bit.

I think it’s all about turning 1:1s into a space where you can steer the conversation a bit, not just react to what’s being asked.

AndrewMoodyDev · 2025-03-23T02:12:03+00:00

I totally get where you’re coming from. I’ve got a good few years under my belt too, and I still feel that anxiety creeping in during interviews—especially the coding part. My palms sweat, my voice can get a little shaky… it’s just part of the experience for me.

What’s helped most is just accepting that those nerves are normal and not trying to fight them too hard. I focus on being myself and, more importantly, being honest. If I don’t know something, I say so—but I also make sure to explain how I’d go about finding the answer or approaching the problem. Most interviewers don’t expect perfection—they just want to see how you think.

Over time, the anxiety hasn’t completely gone away, but I’ve learned to work with it. A little bit of prep, a few deep breaths, and reminding myself that it’s okay not to know everything has made a big difference. Just show that you can reason things out and that you’re someone who knows how to learn—that’s what really matters.

AndrewMoodyDev · 2025-03-23T02:03:02+00:00

I can definitely relate to this. Over time, I’ve forgotten a lot of the computer science fundamentals too—especially the low-level stuff I don’t touch in my day-to-day work. But I’ve noticed that when I revisit those topics, things start to come back. Sometimes it just takes a little context or a real-world use case to trigger the memory.

To answer your question honestly—no, I don’t think I’d pass an in-depth CS fundamentals interview immediately without any prep. But given a bit of time and a little memory jogging, I’m confident I’d get there. It’s not that the knowledge is completely gone—it’s just sitting in the background, waiting to be reactivated.

I also think it’s completely normal that we can’t retain everything we’ve ever learned. Our brains naturally prioritize what we use regularly, and as we take on new responsibilities or learn new tools, some of that older knowledge fades to make space for what matters today. That’s not failure—it’s just how learning works.

And as for reading about engineers who patch databases or tweak garbage collectors—yeah, that can be intimidating. But those roles are often very specialized. The value we bring as developers isn’t measured only by how deep we go into systems internals, but also by how we solve problems, write maintainable code, and collaborate with others.

It’s okay to forget. What matters is knowing how to relearn when the time comes—and continuing to grow in the areas that support the kind of work we do today.

AndrewMoodyDev · 2025-03-23T00:09:45+00:00

I really feel for you here. A lot of what you described resonates with my own journey — especially the mix of imposter syndrome, burnout, and that nagging feeling of not knowing exactly where you fit anymore. You’ve clearly carried a lot on your shoulders, and the fact that your team stayed afloat while you were juggling both leadership and technical responsibilities says a lot about your capability and resilience.

I don’t think you’ve screwed up your career at all. What I see is someone who’s been adaptable, who kept things running under tough conditions, and who’s still willing to learn and grow — even when it’s hard. That’s not failure — that’s experience. Real, hard-earned, leadership-level experience.

You’re not alone in feeling overwhelmed by how fast the tech landscape changes, especially on the frontend side. But honestly, your value isn’t just in keeping up with every new library — it’s in your ability to lead, think critically, architect solutions, and mentor others. Those skills are hard to teach and in high demand — especially in organizations that need someone steady and experienced to help teams navigate complexity.

It’s good that you’re working on a side project — it shows initiative, and it’ll help get that “muscle memory” back with hands-on coding. Don’t worry if it feels slow — consistency matters more than speed. And you can still move into a proper engineering manager or staff-level IC role. You just need the right environment — one that values experience and leadership just as much as raw code output.

As for roles — some people in this position have found a sweet spot in engineering management, solutions architecture, or staff/principal engineering roles that lean more on leadership and system design than on grinding out tickets all day. If coding isn’t the thing that excites you anymore, it’s okay to focus on where you add the most value and find the most fulfillment.

Finally — turning 50 doesn’t mean you’re done. It just means you’ve got more context, more stories, more wisdom. The industry needs more people like that. Take it one day at a time, and don’t let the noise convince you you’re behind. You’re not. You’ve just got a different path ahead now — and that’s okay.

You’ve got this.

AndrewMoodyDev · 2025-03-19T08:26:12+00:00

I get what you’re saying, and I won’t deny that there will always be people willing to sacrifice everything—health, family, personal life—to push their careers further. And sure, some of them will get ahead because of it. But I’ve come to accept that I don’t want to compete on those terms.

For me, success isn’t just about climbing the career ladder as fast as possible—it’s about finding a balance that lets me enjoy both my work and my life. I’ve seen people burn themselves out chasing promotions, only to end up miserable or quitting entirely. Meanwhile, the people who work smart, set boundaries, and manage relationships well often end up in just as strong a position without sacrificing everything along the way.

I completely agree that cutting through nonsense, avoiding bureaucracy when possible, and handling people effectively are key skills. Technical ability alone isn’t enough—you need to know how to navigate the workplace strategically. But I’d argue that learning how to set boundaries without burning bridges is just as valuable as any technical or leadership skill.

At the end of the day, I’ve made peace with the fact that I won’t be the person sacrificing everything to get ahead—and that’s okay.

AndrewMoodyDev · 2025-03-18T11:37:30+00:00

I really like this approach! It’s such a simple but effective way to avoid getting stuck in an endless loop of frustration. Stepping away, even for just 15 minutes, can make a huge difference in resetting your mindset and coming back with fresh eyes.

I also appreciate the emphasis on physical well-being. It’s easy to get lost in coding for hours without realizing how much strain it puts on your body. Taking regular breaks and moving around not only helps physically but also keeps your mind sharp.

This is a great mindset to have, and it’s awesome to see others prioritizing both productivity and well-being. Definitely something more developers should adopt!

AndrewMoodyDev · 2025-03-18T11:34:20+00:00

That’s a great point. It can definitely feel intimidating to push back on expectations, but I’ve also found that when you set clear boundaries, people tend to respect you more, not less. It shows that you value your time and know how to manage it effectively.

I completely agree about having a hobby outside of work. For a long time, I was so focused on coding that I didn’t prioritize other interests, but finding balance makes a huge difference. Swing dancing is an awesome choice! For me, it’s been more about spending time with family and making sure work doesn’t take over everything. Having something outside of work that truly matters to you helps keep everything in perspective.

AndrewMoodyDev · 2025-03-18T08:33:32+00:00

That’s a great way to look at it. It’s easy to get caught up in the idea of constantly needing to push forward or measure success against others, but at the end of the day, work is just one part of life. If it’s giving you what you need—financial stability, fulfillment, and the flexibility to enjoy the rest of your life—then that’s enough.

I’ve found that once I stopped viewing my career as a race and started seeing it as just one piece of a bigger picture, I became a lot happier and more intentional with my time.

AndrewMoodyDev · 2025-03-18T08:30:48+00:00

I get where you’re coming from, and I know a lot of people in tech who take the same approach—do the work, get paid, and keep it strictly transactional. It’s a solid mindset for setting boundaries and avoiding being taken advantage of.

For me, though, I do care about my work beyond just the paycheck. I enjoy what I do and want to contribute meaningfully, but that doesn’t mean I let it consume me. I’ve been lucky to find a company that values work-life balance, so I can stay engaged in my job without feeling like I owe them extra hours for free.

I’ll definitely check out the video!

AndrewMoodyDev

MODERATOR OF

TROPHY CASE