I got back from FrontKon in Prague today (well, technically yesterday, since I'm publishing this tomorrow), and I'm DEAD! 😂
The conference itself ...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
I guess I always blame myself.
The caveat of having a good attention to detail is that I tend to overthink a lot when I see something small and it gets spiral out of control. There is always a double edge sword of having a good skill. I don't want to sound ungrateful or anything like that. I am improving overtime and learning to see the positive side. It's one of those obstacles I have to face, even right now.
Recently, I always wonder why I never receive a single gem
Maybe there is a personal vendetta against me or that community curators just secretly don't like me. I am grateful for the community to have my support and to see that I am included.
But my brain keeps telling me that this "gem" feature is a label that it is a "good" article and regardless of the amount of engagement I have, it feels "negated".
I am grateful, I truly am. I just want to speak up about this because this is one instance of my blaming myself that I could have done better for the community and maybe I said something wrong and that I offended someone without me knowing.
I am not blaming anyone but myself. I'm sorry Sylwia if this came off as blaming you or any curators out there, but it's what I am feeling and I feel like I can't hide the fact anymore. Seeing this article was the breaking point for me to share this. Hope you are well though and looking forward to meeting you someday.
I totally get it, Francis! Unfortunately, when you're ambitious, you tend to expect a lot from others, but also from yourself!
I actually didn't give this article a gem because I didn't have time to read it properly (I was at a conference), and I always make sure to read an article carefully before awarding one.
But I often catch myself doing the same thing, wondering, "Why didn't my article do better?" or "Why did three people walk out during my talk?" and so on, and so on. 😅
I guess it's only natural when you really care about what you do.
You didn't have to Gem it @pascal_cescato_692b7a8a20.. I can understand if the article wasn't Gem worthy..
But you’re absolutely right, Francis… even though you’re wrong, of course 😁
First of all, I hadn’t read your comment when I gave it.
If I gave you a Gem, it’s because your article is interesting, it addresses a sensitive topic, and I enjoyed reading it…
Should I go on, or do those reasons seem sufficient to you?
And besides, as you can see, I didn’t give your comment a Gem… 😎
You’re absolutely right: blaming someone else is so… human! 😄
And, to be fair, it might have been me six months ago. But philosophically speaking, that version of me is no longer me… so I can safely blame him and shift the responsibility onto my former self. 😂
And between you and me, the backend is always predictable. It’s obviously the frontend — especially React — causing the problem.
Particularly when someone is trying to use it with Safari.
I mean… who even uses Safari? 😏😂
Hahahaha, Safari is a bug in the system all by itself! 🤣 The funniest part is that browsers have evolved so much, and Safari still manages to produce the most ridiculous bugs! 😂
And of course you're right, the you from six months ago was a completely different person!
I also once read that all the cells in the human body get replaced within seven years, so technically, any code you wrote seven years ago was LITERALLY written by someone else! 🤣🤣🤣
Hahaha, I completely agree! 😂
Although I have to admit that when royalties are involved, my legal self tends to override my philosophical self. 😏
“Those seven-year-old cells are not mine anymore, so that code was written by someone else” is a great philosophical argument…
…but fortunately, my lawyer says the royalties are still mine. 🤣
And Safari is basically Apple’s Internet Explorer — except Microsoft eventually replaced IE with Edge.
I’m still waiting for Apple to announce Safari 2.0: “We fixed some things. We broke three others.” 😂
Hahahaha, the funniest part is that Safari still manages to come up with the most ridiculous bugs, no matter how much browser technology has evolved! 🤣
And I absolutely love your philosophy: when it comes to bugs, you're a completely different person, but when it comes to money, suddenly you're the exact same one! 🤣🤣🤣
Hahaha, you have to admit that my philosophy is remarkably flexible! 🤣
When bugs are involved, I believe in the impermanence of the self. When money is involved, I firmly believe in the continuity of identity. 😂
I'm not saying I apply philosophy selectively… I'm just saying that some philosophical principles are more financially convenient than others. 😇🤣
When you start looking at yourself first instead of blaming everything else, that’s a sign of professional maturity.
There will always be obstacles and potholes along the road. At some point, you have to take accountability and learn to avoid them. Sure, some things are outside your control, but people are often too quick to decide what they can and can’t control.
Whenever I’ve really questioned my thoughts and decisions, I’ve found that much more was within my control than I’d assumed. It’s hard to admit, especially in hindsight, but that’s usually the reality.
Exactly! And I'm still learning this myself.
For example, sometimes users report bugs that seem so ridiculous you can't help but laugh a little. But then I catch myself thinking: is it really that ridiculous? Maybe the UX is actually confusing, and there's something we could improve?
So I think it's important not to go to either extreme, but asking ourselves "What could I do better?" is absolutely essential.
True 💯
11 out of 12, not bad, I am glad that I still count as a real software developer 🤔😉
By the way, your last observation is the reason I like AI coding agents so much. They do not have lives of their own so you can immediately question their intelligence 🤣
Hahahaha, there's definitely something to that! 🤣 And you'd think AI agents would be better developers since they never get tired... but as we all know, that's unfortunately not quite how it works! 🤣
Welcome back from Prague, Sylwia! 😂 Hope you've recovered from that 6 AM flight!
As a backend developer, I strongly object to #6. 🤣
If the API returns 200, the frontend is broken.
If it returns 500, the infrastructure is broken.
If the database crashes, DevOps is responsible.
And if Git blame shows my name... well, clearly that was a different person six months ago. 😇
Now with AI, we finally have someone new to blame for everything! 😂
Jokes aside, loved the ending. A little empathy goes a long way, especially when debugging someone else's decisions. 😄
Hahahaha, you sound exactly like my backend developers! 🤣🤣🤣
And if there's absolutely nobody left to blame, you can always go with: "Well, the requirements were different (and unclear!) at the beginning of the project!" 🤣
But yes, empathy really matters. Sometimes it's the only thing that can save us! ❤️
This made me smile, especially the “other developer turns out to be ourselves from six months ago” part. I’ve opened old code, muttered “who wrote this?” and then checked git blame. 😅
it’s also a good reminder that behind every questionable commit there’s probably a bad morning, a tight deadline, or a missing doc we’ll never see.
i’d like to think teams can build this kind of empathy on purpose, with blameless postmortems or kinder code reviews. Maybe it also grows naturally the day we realize we’ve been the “other developer” too. Thanks for the laugh and the thought. Hope you get some rest after Prague! ☕
Exactly! 🤣 I remember once looking at some CSS and thinking, "Who the hell wrote this nonsense?!" And of course, it turned out to be me. 🤣🤣🤣
The backend/frontend blame is funny, but distributed systems make that assumption surprisingly dangerous.
I’ve seen incidents where the backend gets blamed because latency suddenly jumps, while the actual trigger is a retry storm on the client side. A backend starts missing its deadline, the frontend retries, those retries increase backend load, latency gets worse, and suddenly the component that looks like the “cause” is actually one part of a feedback loop.
That’s why I’ve started finding request traces more useful than ownership boundaries during incidents. If you follow one request across the client, gateway, service, cache, and database, the original fault and the component amplifying it can be two completely different things.
Google’s SRE guidance describes this exact kind of cascading failure: retries can turn a relatively small overload into a much larger one.
So sometimes “the backend is broken” is technically true, but operationally almost useless. The better question is: what changed the system’s behavior, and where did the failure get amplified?
I really love this perspective! And I think it's a perfect example of exactly the kind of shortsightedness my article is poking fun at.
I'm glad you approached it this way (although I'd definitely have some questions about why the frontend had no exponential backoff in the first place).
And the absolute worst is when frontend and backend are two completely separate teams (like, WTF?) that just keep pointing fingers at each other instead of actually solving the problem. That's a nightmare. 😅
Yeah, the missing backoff is definitely a red flag, but I think the nastier version is when every team has a perfectly reasonable retry policy in isolation.
For example, imagine a request going through a browser client → API gateway → order service → payment service → database. If each layer decides independently that a timeout is worth retrying, the original user action can multiply into a surprisingly large number of downstream attempts.
That’s why I’m usually more suspicious of the retry topology than of one badly configured frontend. You can have exponential backoff and jitter everywhere and still create a nasty amplification effect if retries exist at several layers.
The payment case makes this especially ugly because now idempotency matters too. A timeout doesn't tell the caller whether the payment failed or whether the response simply got lost after the charge succeeded. Retrying blindly can turn a reliability mechanism into a duplicate transaction mechanism.
So during an incident, “why didn't the frontend back off?” is useful, but I’d also ask: “which layer owns the retry, what errors are actually retryable, and how many attempts can one logical request generate downstream?”
That question usually gets the teams pointing at the request path instead of at each other. 😅
Hahaha, okay, in this case, I completely agree! 😄 And you're absolutely right that exponential backoff alone won't save you if every layer independently decides to retry.
I think that's actually a great example of how something that makes perfect sense at the component level can become a disaster at the system level. Each team implements what looks like a perfectly reasonable resilience mechanism, and suddenly the whole system is making things worse instead of better. 🤣
And the payment example is particularly good because it shows that retries aren't just a performance or reliability concern anymore. They can have real business consequences.
Which brings us right back to the original point: instead of asking "whose fault is this?", maybe we should start by asking "how did we collectively design a system where this could happen?" 😅
@sylwia-lask Welcome back from FrontKon! Hope you get some well-deserved rest after that 3:30 AM flight routine.
The point on fundamental attribution error hits home. It is so easy to forget that behind a confusing pull request or odd architecture choice is usually a tight deadline, a missing doc, or a chaotic morning. Blaming "myself from six months ago" is definitely a regular habit on my end, but it's a good reminder that past decisions usually made sense given whatever constraints were happening at the time.
When you look back at legacy code, what's your go-to strategy for figuring out whether a weird design choice was a intentional workaround or just a temporary hotfix left behind?
Hahaha, these days my strategy is pretty simple: whenever I have to implement a workaround, I leave a comment explaining that it's a temporary solution and create a ticket for a proper refactor.
Whether that refactor ever actually happens is, of course, a completely different story. 🤣🤣🤣
For the existing workaround, I'd start with the commit that introduced it, the linked issue and the behavior it preserves. Then capture that behavior in a regression test before changing the branch.
I'd leave the next maintainer three things beside the code: why the exception exists, what would break if it were removed, and the condition for deleting it. If the history gives no answer, keep that uncertainty visible rather than treating an old ticket as proof that removal is safe.
Sylwia, item 2 does not work for me. I freelance, so the company is me. Your point on the fundamental attribution error is the part I will keep. We judge a late reply or a rough draft without seeing the power cut or the slow connection behind it.
I remember that when I read comments here. Your posts bring the whole community into one room. It is a full house again. I wish mine had that power 😁 I hope Prague was worth the 3:30 AM.
Thank you so much, Daniel! ❤️ Oh yes, I once gave a talk to a group of developers about the fundamental attribution error, and I remember how everyone really took it to heart. I think it's one of those things we often don't even realize we're doing until someone points it out to us!
And yes, Prague was absolutely worth that 3:30 AM wake-up call! Such a beautiful city and such a fantastic conference! 😄
Great Article!
I’m new to Dev.to and recently started sharing my posts here. I’d really appreciate your feedback and suggestions on my posts. It would help me improve and create better content. Thanks!
The line that hit me: "Quite often, though, that 'other developer' turns out to be ourselves from six months ago."
I'm three weeks into Python — 26 articles published. So I'm not the developer being blamed. I'm the developer who would cause the blame if I ever shipped anything to production.
But this post gave me something to think about from the other side.
When I write a tutorial and it breaks, I blame Python. When my script doesn't run, I blame the library. When an API returns something weird, I blame the API. In three weeks, I've blamed almost everyone on this list except myself.
And then I open the file, read my own code, and find the typo. Every. Single. Time.
The fundamental attribution error thing is real. I catch myself doing it constantly — "the docs are confusing" instead of "I didn't read them carefully." "The error message is useless" instead of "I didn't actually read the error message."
I'm not a senior dev yet. But I'm starting to notice that most of the bugs I find aren't in the language or the framework. They're in the assumption I made ten minutes ago and never tested.
Also, number 10 (CORS) made me laugh. I don't even know what CORS is yet, but I've already heard it blamed by every tutorial I've watched.
Exactly! That's precisely how it works! 😄
And by the way, I think one of the things that comes with being a senior developer is knowing when you actually SHOULD blame the framework or library, because sometimes a feature really is missing, or there's genuinely a bug in it.
Unfortunately, figuring that out usually means digging through a LOT of code before you can confidently say, "Okay, this time it's really not me!" 🤣
Anyway, best of luck on your coding journey!
The "another developer" entry made me laugh, mostly because the other developer is so often us from six months ago.
What I notice in client work is that blame tends to land where nobody wrote down what "done" meant. When a project changes hands and the next team finds odd code, the real gap is usually the missing reason behind it, not the skill of whoever wrote it. A two-line note on why a workaround exists saves more arguments than any code review.
That is one reason I like scoping work as a single, clearly bounded problem with written acceptance criteria. When the outcome is agreed up front, there is far less room for the later debate about whose fault the weird part is. Thanks for the series, it is a good reminder to be kinder in retros.
100% agree! I've actually been following this approach lately. Whenever I have to implement a workaround because a proper refactor would be too risky given the time constraints, I leave a comment explaining why and immediately create a ticket for the refactor.
Whether that refactor will ever actually happen is, unfortunately, a completely different story. 😅
You should make 13 points, and the 13th one should be:
12. Themselves
...
13. …And Eventually, Blame Their Luck.
13th blame for the luck, that's no coincidence I guess! 🤣
Hahahaha, I absolutely love this! 🤣 And I remember that, especially as a junior developer, I used to blame bad luck quite a lot! I'd copy something, delete something, move some code around, and suddenly everything would start working, even though the code was supposedly exactly the same! 🤣
And somehow, these things don't really happen to me anymore.
But recently, a friend who's learning to code told me about experiencing exactly the same thing, so my theory is that junior developers simply have to rely on luck a lot more! 🤣🤣🤣
I guess they just restart their computer, or restart their browser - in effect, it cleans their cache without them realizing, so they just call it luck 🤣
The frontend vs. backend blame game is way too real 😂
But here's my problem: when I'm responsible for both the frontend and backend, who am I supposed to blame? 😂
I guess my past self is the only option left!
Jokes aside, debugging gets easier when we stop looking for someone to blame and start looking for what's actually happening.
Hahahaha, exactly! When you're a fullstack developer, your past self is pretty much the only one left to blame! 🤣🤣🤣
sylwia, this is the perfect blend of relatable dev humor and actual psychological insight. the "fundamental attribution error" is so real in software development.
as a 12-year-old building entirely on a $150 phone over spotty 3g, my go-to scapegoat used to be "the browser" or "the network." but the real lesson i've learned is that if a tool breaks under constraint, it's not the environment's fault—it's my architecture's fault for not handling that edge case gracefully.
these days, my biggest temptation is to blame the ai agent when it hallucinates or generates bloated code. but 99% of the time, the actor-observer bias applies to me: i gave it a vague prompt, or i forgot to set up a deterministic fallback (like strict json validation). the ai is just a mirror reflecting my own setup.
the line "somewhere out there, another developer is probably blaming you" is the ultimate reality check. thanks for the reminder to lead with empathy (and maybe just clear the cache first). 🐯☕
Thanks so much for this comment! And as it turns out, the actor-observer bias applies even to solo developers. Now THAT is a fascinating observation! 😄
Wishing you all the best, and yes, you can never have too much empathy!
Also, huge respect for coding on a phone! I seriously need to give that a try someday.
sylwia, you nailed it! as a solo dev, i am constantly blaming "past me" for "current me's" problems. it's an endless cycle of self-deprecation followed by eventual understanding 😂.
thank you for the kind words about the phone setup. it's definitely a unique challenge, but it forces a level of architectural discipline and lightweight thinking that is hard to find when you have unlimited local resources.
wishing you the best with your upcoming technical article, and thanks again for fostering such a great, empathetic discussion here! 🐯
The list is missing the best one: blaming the user. "Works on my machine" is just blaming someone who can't defend themselves in the thread.
Hahahaha, you're right! 🤣 And of course, beyond the client, there's also the user, who, as it often turns out, can't read our minds and insists on using the app in ways we never anticipated in our perfectly designed happy path! 🤣
The happy path should legally require a disclaimer: "results may vary once actual humans are involved." The gap between the designed user and the real one is basically the entire QA industry. 🤣
Hahahaha, exactly! I also feel like no matter how much we test and double-check everything, some bugs will inevitably be discovered by actual users in production. And on the other hand, sometimes we spend ages perfecting a feature that no user will ever even touch! 🤣
So the strategy is: ship the version users can break, not the version they never see. Production is the only QA environment that never lies. 🤣
YES!!! 🤣 I've even heard people say that a feature has been "battle-tested in production" (or, as we say in Polish, "wygrzane na produkcji"). I guess that's when it finally earns its right to exist! 🤣
the six months ago yourself bit is the one that gets me every time. you open old code with fresh eyes, spend 20 minutes being furious at whoever wrote this, then git blame reveals your own username. the name is right there but somehow the cognitive dissonance holds for another few seconds.
the fundamental attribution error framing is interesting because it works in reverse too. when the code is good we attribute it to skill, when it is bad we attribute it to circumstances. the same person, the same session, evaluated completely differently based on outcome.
what is the most recent time you blamed legacy code only to realize you wrote it?
You know what? These days, I don't even blame myself anymore!
I think it's because I know the history of my project, and I know what it's like to work on it. Sometimes it makes perfect sense to implement a slightly hacky workaround and plan a proper refactor for later. Unfortunately, that "later" often turns into "never." 🤣
But understanding why certain decisions were made has actually helped me become much more empathetic, both toward myself and other developers. Because sometimes the code isn't pretty, but there was a perfectly good reason for writing it that way at the time. 😄
"later becomes never" is the whole career arc in three words. every codebase has that TODO cleanup comment timestamped like 2019 thats just... infrastructure now.
the empathy flip is real though. once you track WHY decisions got made rather than just judging the output even gnarly code becomes legible. context is basically the compiler for legacy decisions.
whats the most embarrassing thing youve rationalized as temporary long enough that it shipped to prod?
The one I'd add is the server clock. I spent an embarrassing while convinced a CMS was broken because every post I published through its API came back as "scheduled" instead of live. The host's clock was hours behind, so my "now" was its future, and it was politely doing exactly what it was told. It earns a place on the list because it's the rare case where blaming the infrastructure is actually correct, and you still end up feeling silly.
Hahahaha, oh yes! Time zones are the eternal curse of software development! 🤣🤣🤣
Sylwia, okay the ending got me. We really do know all the reasons why we messed something up, but somehow when someone else does it, we just go “what an idiot”. At the end of the day, being a little more understanding and kind really matters ❤️
Exactly! ❤️ I'm really happy that people took away not just a good laugh from this article, but also the deeper message behind it! 🥰
That's why I fell in love with the word "sonder". This is the meaning I snatched from Google:
Be kind even if the world is unkind.
I know it's hard but it's a lifelong learning process. Understand that strangers are completely unique and we will never experience what they gone through. Being kind is the least we can do to ease up their pain.
Oh, absolutely! I couldn't agree more that it's a lifelong learning process! ❤️ I still catch myself unfairly blaming someone from time to time, too. I guess the important thing is to recognize it when it happens and keep trying to do better. 😊
Get outta here with that thumbnail.
Hahahaha, what's wrong with it?!
If you are in toxic environment then this blaming to others is necessity otherwise you cannot survive :)
That's true! But in that case, I think the best solution is to get out of that toxic environment as soon as you can!
The messy code I wrote myself is still mine to maintain 🤪
Hahahaha, exactly! We really need to remember to be kind to our future selves! 🤣
Oh, come on come on come on — as a QA who deals with developers every single day, there's one phrase I hear ALL the time: "It works on my machine!"🤣
Hahahaha, of course I've said that more than once myself! 🤣 But I quickly learned that testers REALLY hate hearing it, so now I just say exactly the same thing, but in a more diplomatic way: "Hmm, I can't seem to reproduce this on my end. Could you give me some more detailed steps?" 😇
Same message, completely different reaction. Nobody gets annoyed anymore! 🤣
lol
The requirements!! Hands down every time 😂. You asked for x, y, z…. You got x, y and z… if you wanted w too, you should have put it in the requirements lol
Hahahaha, but that's how we've been trained as developers! 🤣 You delivered something different? How dare you! The client clearly asked for A, B, and C. If they want D, they can pay extra for it! 🤣
100 percent! How dare we assume!!
woh
Hello
The part about blaming our past selves is painfully relatable! 😅
Hahaha, right?! 🤣
67 comments😂
Haha, could be worse 😅
Time and myself, for sure. I’ve worked inside organizations and as a freelancer, and both had something easy to blame. At a company it’s the process or the deadlines. On your own there’s no company to blame, so it ends up being you.
I’d add imposter syndrome. 🥸 I doubt myself all the time, and that’s a big reason it’s been hard for me to put myself out there more. It’s kind of your point flipped around. When another dev ships a messy fix, I assume they were slammed or up against a deadline. When I do it, I start wondering if I’m as good as people think.
We definitely need to be more understanding of others, but we also need to be less hard on ourselves. I’m still working on that second part, and this comment is a small step. 🍻
Enjoyed this. I'm building wisst, an app for short one-idea articles where readers write one sentence about what they took before they can comment, so writers see what actually landed. It's in an Android beta and I'm looking for the first writers, if you'd like to try a short piece there: wisst.app/beta
Blaming the framework, the cache, the other dev, is how you avoid saying the loss out loud. As long as someone is at fault, the thing isn't dead, it's sabotaged, and sabotage is fixable. So the blame reflex is really an escape hatch, and it keeps you playing a board that already ended.
The question that changes the outcome isn't who broke it. It's what is actually lost, and what's still on the board. Usually more than it feels like, because a bad position has pieces you didn't count: a reputation, one relationship, the thing you learned that nobody can take back. The version of you that leaves from a good square starts the next game differently.
I wrote the long version of this here: dev.to/selah_moves/the-losing-move...
Point 12 is the same instinct, aimed inward. Be kind to the other dev, and be honest with yourself about the position. If you're the one standing in the lost position and want that read done blunt, that's what I do: [email protected], $25.
I graduated in 2021 btech cse it's 2026 I am unemployed never had a good job worked as data analyst for a year it's over software engineering is dead move on
Yeah, we've all been there and only half the time we were wrong... That's why I ended up with the 'auditability' standard. Mostly cuz I got into multi-agent orchestration and knowing which agent messed up was data I could use to improve the system as a whole. What it taught me, is that most of the time, your code isnt at fault... How your code interacts is. Sure, you can blame every part of the codebase for why it doesnt work, but fact is, if you designed it slightly different, it would slot in without fault... So next time you see a bug, flag it, fix it, do whatever protocol is for it, in the end we're all working in the same codebase, so no sense turning git blame on so you can name and shame whoever did it... Unless of course your boss has it out for you, then have that audit log ready so if anyone has an issue, you can show what was wrong, why it was wrong, how you fixed it and why you fixed it. That way your end is clean and anyone complaining can take it up with the person who wrote the failing code to begin with.
Or if you know it's a system they're actively working on, just dm them and bring to their attention, so they can fix it, or offer to patch it for them if it's impacting your work. No need to play a blame game, just constructive issue reporting.
That cache one hits way too close to home. You're sitting there staring at Supabase, looking at the admin dashboard like, "Bro, the data is literally right there in the database, why is the frontend showing nothing?!"
You start questioning your entire career choice, thinking your code is cursed, and then you realize Vercel or the browser CDN has just decided to stubbornly cache some random asset from three hours ago.
It’s always the cache. Every single time.
And when there's absolutely no one left to blame (not even past-me), there's always: 'The requirements were unclear from the start!' 🤣
Loved this article! Empathy really is the most underrated skill in software engineering.
what about those people who have no developer side ,how they can understand problems
There's one thing you forgot. Artificial Intelligence. For a lot of reasons.
Shouldn't we blame developers whose creations cannot transcend the imperfections of their creators? 🥸
oops 😬
The other developer was actually me part is TOO REAL lmaooo 😂
Really thoughtful post! Documenting real-world engineering hurdles and actionable solutions like this brings immense value to the community.