I got back from FrontKon in Prague today (well, technically yesterday, since I'm publishing this tomorrow), and I'm DEAD! 😂
The conference itself was fantastic, of course. Both my panel discussion and my talk went really well, and the Czech developer community is starting to feel like family. Greetings from your favorite senior software vývojářka! 😀
I'll write my usual, more technical article next week. I want to approach the topic from a slightly different angle, so I need a bit more time for research. Meanwhile, flights from Gdańsk to Prague depart at the absolutely murderous hour of 6 AM, which means that at 3:30 AM today, I was still in Prague!
And since some of you have recently been asking for another installment of my "You're a Real Software Developer Only If…" series, here you go!
Who or what has every software developer blamed at least once? Here's my list!
1. Another Developer
Obviously, if the code is terrible, it's never our fault. Someone else must have messed it up. A colleague from our team, someone from another team, or the developer who worked on the project before us.
Quite often, though, that "other developer" turns out to be ourselves from six months ago. 😅
2. The Company
Because the processes are terrible, the standards are nonexistent, and management clearly has no idea what they're doing. The poor developer has been thrown into this corporate machine and is now forced to fight an endless battle against the system.
Things get a little awkward when you're self-employed and your company consists of… well, you. xD
3. Legacy Code
The application could be just six months old, and somehow there will already be legacy code somewhere. And naturally, that legacy code is responsible for every bug, every delay, and every missed delivery deadline!
4. The Framework
It's buggy! It's unpredictable! It's missing half the features we need!
If I wrote my own framework, now THAT would be something! And why haven't I done it yet? Well, I never promised anyone I would! 😅
5. The Client
Let's be real: our jobs would be so much easier and more enjoyable if it weren't for that annoying client who keeps asking for things and complaining about everything. 🤣
6. The Backend
This is personally my first suspect whenever something goes wrong. If something doesn't work, it MUST be the fault of whoever wrote the backend.
I mean, come on. Are you seriously suggesting that something could possibly be wrong with MY code???
7. The Frontend
And this is exactly what backend developers think about the frontend whenever someone reports a bug.
Yes, yes, I know. In the age of AI, many of us have become full-stack developers, whether we wanted to or not. But deep down, our hearts will always belong a little more to one of those "ends." ☺️
8. The Requirements
Obviously. They're either too vague, poorly written, or based on some completely ridiculous idea invented by the stakeholders.
And even if the requirements are absolutely perfect, there's probably something missing from the documentation anyway. 😉
9. The Cache
Come on, admit it. If you've never told someone to "clear your cache," can you even call yourself a software developer???
10. CORS
Often the first suspect for junior developers whenever some mysterious error appears. Never mind that everything was working perfectly fine yesterday. It's probably CORS!
11. The Browser
An obvious one. I mean, is it OUR fault that people still insist on using Safari???
12. …And Eventually, Themselves
Now, let's get a bit more serious for just a moment. There are two kinds of complaining. The first is just harmless grumbling, the same way we complain about bad weather. It's particularly popular in countries like Poland, where complaining is practically a form of small talk.
But there's another kind. Of course, I'm not talking about situations where a project or the people you work with are genuinely toxic. Those situations absolutely exist, and sometimes you really do need to sit down and think about what to do next.
But in other cases? Sometimes it's worth stopping for a moment and asking ourselves where WE fit into this picture of everything and everyone we're blaming.
There's actually a well-known psychological phenomenon called the fundamental attribution error. In simple terms, it describes our tendency to overestimate someone's personality or character and underestimate their circumstances when explaining their behavior.
There's also a closely related concept called the actor–observer bias, which describes a tendency to explain our own behavior in terms of circumstances while explaining other people's behavior in terms of their personal characteristics.
And that's particularly interesting here. Think about what happens when WE mess something up: our code isn't exactly a masterpiece or we missed a deadline. We can usually come up with perfectly reasonable explanations. And often, those explanations are completely valid!
Maybe we were feeling a little sick, so our productivity dropped. Maybe the plumber wouldn't stop talking, and we lost half the morning. Maybe the library documentation was terrible. A million things could have happened.
But what happens when ANOTHER developer messes something up? What do we think? Unfortunately, quite often, it's simply: "What an idiot."
But here's the thing. That other developer has a life, too. They have their own problems, crying children, plumbers who show up late, and a thousand other things going on that we know absolutely nothing about.
We don't have access to their thoughts or their circumstances. So our brains take a shortcut. And suddenly, instead of thinking "maybe something happened," we decide that the person is simply incompetent.
And that's the thought I'd like to leave you with today. I was going to add some profound, philosophical conclusion here, but everything I came up with sounded suspiciously like something written by Sylwia Coelho.
So let's keep it simple. Let's just try to be a little more understanding toward one another. ❤️
And next time you find yourself blaming another developer, remember: somewhere out there, another developer is probably blaming you. 😂
If you enjoy my content, you can also follow me on LinkedIn.
Top comments (81)
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. 😇🤣
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! ❤️
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! 🤣
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?" 😅
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. 🤣🤣🤣
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! 😄
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!
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 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! 🤣
"Wygrzane na produkcji" — I'm stealing that, it's perfect. Every language has its own version of this truth; the bug that survives production is the one that finally gets a name, a ticket, and a fix. Great thread, Sylwia — made my day. LOL🤣
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more