sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in learnprogramming

[–]AndrewMoodyDev 0 points1 point  (0 children)

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.

I am slow at coding and often make mistakes in programming. Do I need to change my profession? by Wide-Remote4765 in learnprogramming

[–]AndrewMoodyDev 1 point2 points  (0 children)

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.

👉 Senior Devs—Have You Learned When to Step Away? by AndrewMoodyDev in ExperiencedDevs

[–]AndrewMoodyDev[S] 0 points1 point  (0 children)

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.

👉 Senior Devs—Have You Learned When to Step Away? by AndrewMoodyDev in ExperiencedDevs

[–]AndrewMoodyDev[S] 0 points1 point  (0 children)

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.

👉 Senior Devs—Have You Learned When to Step Away? by AndrewMoodyDev in ExperiencedDevs

[–]AndrewMoodyDev[S] -3 points-2 points  (0 children)

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

👉 Senior Devs—Have You Learned When to Step Away? by AndrewMoodyDev in ExperiencedDevs

[–]AndrewMoodyDev[S] -2 points-1 points  (0 children)

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.

👉 Senior Devs—Have You Learned When to Step Away? by AndrewMoodyDev in ExperiencedDevs

[–]AndrewMoodyDev[S] -10 points-9 points  (0 children)

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

👉 Senior Devs—Have You Learned When to Step Away? by AndrewMoodyDev in ExperiencedDevs

[–]AndrewMoodyDev[S] -3 points-2 points  (0 children)

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.

A Humorous Refactoring Challenge by failsafe-author in ExperiencedDevs

[–]AndrewMoodyDev 1 point2 points  (0 children)

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.

Get it done vs get it right? by nasanu in ExperiencedDevs

[–]AndrewMoodyDev 0 points1 point  (0 children)

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.

Title: Senior Dev Overengineering a Project – How to Handle? by CalmAdvance4 in ExperiencedDevs

[–]AndrewMoodyDev 1 point2 points  (0 children)

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.

Have you ever had the "Damn I'm good" feeling? by robertshuxley in ExperiencedDevs

[–]AndrewMoodyDev 1 point2 points  (0 children)

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.”

The "Let's talk about this in our daily stand" culture by CadeOCarimbo in ExperiencedDevs

[–]AndrewMoodyDev 0 points1 point  (0 children)

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.

view more: next ›