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 (24)
Wow, I probably raised the bar because I used to blame the compiler 🤣
Hahahaha, now that's a whole new level of blaming! 🤣🤣🤣
I didn't get a notification, I just discovered the article in the curated feed! What a shame!
Yep, as a BE dev, I agree that FE must be blamed for everything! And when that's not enough, we can always blame the analysts! 🤣🤣
But speaking of blame, have you also noticed that when something goes wrong in production, many teams focus more on finding someone to blame than on fixing the problem and making sure it doesn't happen again?
P.S. Whoever asked for another installment of your "You're a Real Software Developer Only If…" series must be a real expert! 😎🤣
Blaming frontend is tier 1 defense. The gold standard will always be 'well, it works perfectly on my machine' followed by quietly modifying the docker container settings and hoping nobody checks the git commit history.
Spoken like a true backend engineer. But let's be real, once you exhaust the 'it's a frontend bug' and 'the requirements were wrong' cards, there's always the ultimate scapegoat: DNS or the cloud provider's network latency.
Hahahaha, exactly! Now, who was it that suggested another installment of that series? WHO COULD IT POSSIBLY BE? 🤣🤣🤣
And yes, the absolute worst is when two teams are responsible for something, and instead of working together to solve the problem, they spend their time fighting over whose fault it is.
Or, even better, sometimes the teams would actually love to cooperate, but there's a full-blown Game of Thrones happening at the management level, so they're not even allowed to. 🤣
I’ve worked with pretty much all of them; right now, I’m at a massive company that outsources development teams to other firms. Essentially, this company provides IT systems to insurance companies worldwide. Currently, a colleague and I are working on a specific task involving a codebase that’s about seven years old. We frequently badmouth the programmer who built the system—someone who, naturally, left the company ages ago. We do this because he engaged in what you might call "CV-driven development" (CDD): he incorporated every possible dependency he felt like experimenting with, and he was certainly creative in that regard. ... Wait, hold on!
I don't usually make a habit of blaming others, by the way.
I almost forgot I blamed the javascript maintainer who is do not push forward the pipeline operator form proposal state to standard language element, so I try to hack from TS direction!
Hahahaha, working with that codebase sounds absolutely delightful! 🤣🤣🤣
And of course, here I am, playing the saint in my article, and I genuinely do try not to blame other developers... BUT I once worked on a project where the code was an absolute disaster.
Even as a senior developer, I had to spend a ridiculous amount of time trying to figure out what on earth the author of that architecture had been thinking. Basically, the whole thing was designed so that API calls were made almost directly from the templates, and implementing something as simple as a loading or error state was an absolute nightmare.
When I asked the developer who was still on the project, "WTF, why aren't you using a good old, proven architecture?", he couldn't give me an answer. 🤣🤣🤣
So yeah, I have absolutely no idea why the original developer decided to build it that way... but well, he did.
I definitely complain about legacy code a lot, including legacy code that I wrote myself 😹
I usually think "the person isn’t bad, the code is bad".
And I really agree with your point about not knowing someone’s health, mood, or situation. Nobody is at their best all the time, and unfortunately the code written on those bad days can survive for a very, very long time 😹
“Let’s just try to be a little more understanding toward one another.” is a really good line. 👍
I’ll keep that in mind…
while continuing to complain about legacy code and replace it piece by piece today 😹
Oh yes! I used to get really frustrated with legacy code too, often blaming the developers who wrote it (and let's be fair, sometimes rightfully so! 🤣).
These days, I try to look at it with a bit more perspective. Something like: "This code looks the way it does because two junior developers spent six months building it, doing the best they could with what they knew at the time."
So yeah, we can absolutely complain about it, but at the end of the day, someone still has to fix it! 🤣
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! 🤣
Hello Sylwia 😁
I read your post on DEV Community, and I wanted to thank you for it.
Your words are honest, and your experience is helpful to every developer. Thank you for sharing it with us.
I wish you more progress and success 🌸
With appreciation,
Aww, thank you so much for your kind words! ❤️ I really appreciate it! 🌸
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. 😅
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! 🐯
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
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: selah-19@ilands.app, $25.