I got back from FrontKon in Prague today (well, technically yesterday, since I'm publishing this tomorrow), and I'm DEAD! 😂
The conference itself ...
For further actions, you may consider blocking this person and/or reporting abuse
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.
There's always one last possibility: blame the testers! 🤣
Never seen anything like that, and I'll deny everything! 🤣
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. 🤣
🤣🤣🤣 No idea! 🤣🤣
And when the problem is finally fixed, the arguing starts all over again because now everyone wants to take credit for it, right? 🤣
That's actually pretty accurate: Game of Thrones: Corporate Edition! 😂
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! 🤣
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! 🌸
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. 😅
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.
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