Hacker News new | past | comments | ask | show | jobs | submit login

> returning a null array to represent no items, and returning a single object without an array to represent one item.

This just reminded me of a long ago incident at a former employer. I worked in back-office at a hedge fund and was responsible for maintaining several APIs & services written in C++. The APIs were pretty straight forward query for object(s), get back a vector of objects. If nothing was found, you'd get back an empty vector.

The company also had a program where they'd hire grad students right out of school and immerse them in the trading desk, working on trading algorithms and such. One such kid sent in a "bug report" directly to me, CCing all of front office. The "bug"? We was querying for something that didn't exist, so he got back an empty vector. He didn't check that it wasn't empty, and immediately accessed the front of the vector. Boom, segfault.

Normally, I would have been kind to such a junior dev, but their original email was very condescending and went to an unnecessarily large audience - like hundreds of people that didn't have time for this. His email read something to the effect of "Your API is crashing my code. Fix your API."

Instead, this junior got a whole other lesson instead. I replied all, and included all of back-office on the email (so the rest of the team was aware to watch out for this clown). "The API is working perfectly fine and as designed. The fuck up is on your end. You queried for something that doesn't exist and proceeded to dereference and empty vector. Fix YOUR fucking code."




I really don't like your story. The junior is clearly behaving immaturely and inappropriately by CCing others and not using an appropriate tone, but your response is to... retaliate by doing the exact same thing to him? What lesson is the junior supposed to learn here? That acting that way is A-OK as long as you have seniority and are factually correct? At least the junior has the "excuse" of being a junior, but really as a more senior person you should have known better.

Surely there must have been a better way for you to handle this situation.


I fundamentally disagree with the idea that it's a virtue to act politely and "professionally" in all circumstances, no matter what the provocation. I think it can be entirely reasonable (depending on specific circumstances) to publicly shame someone who has been publicly acting like an asshole.

Simply being wrong in public deserves a gentle correction (possibly in private, again, depending on the circumstances), but often I don't really care to be nice to people who aren't being nice. It's certainly possible that being nice all the time in situations like this gets you better outcomes overall, but we all have a limited amount of patience to dole out, and some people just don't deserve it sometimes.

And on the other hand, some people don't get the message when you respond politely. Responding politely in this case could just as easily teach the junior that his debugging strategy (blame anyone but himself) and dickish tone were completely ok. There's certainly a polite way to inform the junior that his behavior won't be tolerated, but I can't fault someone for simply responding in kind.


I had a similar situation where a certain person would blame my API for all of his problems in a very public manner. First few times I responded quietly pointing out the mistakes but then I started responding publicly pointing out that the person should first learn the programming language before blaming others with examples from previous interactions. The behavior stopped immediately. Sometimes you have to bully the bully and make clear that being new is not an excuse for bad behavior.


I'm not seeing anything wrong with what OP did. By CCing everyone, the junior is trying to make themselves look good by making OP look bad. The junior learned that if they act like an ass, especially an incorrect ass, the other employees won't tolerate it.


That's the DESIRE for what the junior learned. But is that what they actually learned? One could just as easily (or more easily) decide instead that this is the way business is done. It's literally all they've ever seen.


Responding politely could also teach the junior that it's ok to act like an asshole, because he'll get a polite response no matter what.

I suppose the ideal response would have been a polite correction, followed by a polite rebuke regarding the junior's tone and behavior, but I can't fault someone for responding to fire with fire on occasion.


A polite response does not have to be a meek response. You can be blunt, you can point out all the problems, while still being polite.

That also has the advantage of being 100% clear.

"You just told hundreds of people my code is poor. You attacked me, and my professional reputation, and you did it inaccurately. This gives me little reason to respect you or want to help you. Asking without copying the world and without assuming you were flawless would have done a lot to help your case. Because I AM professional and you are new to the profession, I'll hold back on the reflex to point out to every one of these hundreds of peers that influence your career how rude, presumptive, and WRONG you were. Instead, I'm pointing out in private that you are wrong and not behaving in a way someone looking to succeed is behaving. This tolerance is not something you should expect from me again, and you should be grateful to be getting it now because your behavior does NOT call for cooperation. If you do this again, the next person will likely not show this patience and understanding. Do you understand that you made the error in your code? Do you understand how your behavior invites people to think poorly of you? Do you understand how to change both your code and behavior for the future? "

This has the senior developer takes on more work instead of a sense of vindication. However, this is much more likely to get a positive result in the long term - there's no mystery hope that someone that clearly missed out on social repercussions will suddenly understand them when attacked.

Being a senior developer is not about winning battles, it's about learning to win without battles, and even more importantly, it's about TEACHING that.


I've gotta say, if I was a third party to the exchange that involved your suggested message I would think the senior developer was a pompous and condescending ass. In the UK we (or at least I) wouldn't consider what you wrote to be a polite response.


Funnily enough, my last team worked with a software supplier from the UK, and I’m 99.99% sure the above text was copy-pasted from an email reply to one of my overzealous team members. We thought it was over the top, but chalked it down to British culture


There is also a difference between teaching and grandstanding; the reality of the situation is that there is no single correct response for this kind of situations: the junior maybe was zealous, maybe he was trying to shame the senior, maybe he just copied in CC the wrong mailing list.

Obviously the original answer was not appropriate in every situation, but also likely it was appropriate in some.


So what they've learned is, if someone makes an incorrect assumption, sends a nasty email, and CCs the entire department, I get to respond by sending an email back pointing out their error and CCing an even larger audience.

I don't think that's necessarily a bad thing to learn, even for the junior...


There's no way to know in advance what someone will learn from an experience. You also don't know what they learn 'now', and what they might reevaluate and relearn years from now about that same situation. Basing your response decision primarily around what someone might learn isn't a great way to decide how to respond.

Couple folks I'm working with right now, and I had thought a couple of times "well, this wasn't a great scenario, but at least they'll learn ABC from it". One did, one didn't, and keeps making the same moves (I hesitate to say 'mistakes', but in my view they are).


> There's no way to know in advance what someone will learn from an experience.

Correct. You can, however, improve the odds. Being explicit about what you want them to learn as opposed to expecting a certain degree of interpretation cannot hurt your odds, though it can't guarantee them.

> Basing your response decision primarily around what someone might learn isn't a great way to decide how to respond.

In this context, what else was the point of the response? I was comparing to the STFU tell-off of the above post and the defense of it that they would learn from the experience.


> what else was the point of the response?

some other public reaction/recognition for the OP, not for the benefit of the original sender.

emotional venting? that's sometimes its own reward.


It wasn't wrong, but it also betrays that OP wasn't really a senior either. Just an older junior.


>Surely there must have been a better way for you to handle this situation.

The junior was in the wrong, so I think you'd agree that a correction is in order. Replying-all is one way to do such a correction. The alternative would be to force him to issue a retraction himself.


There's no need to shame people who are wrong.


True. If the junior dev was simply wrong, but polite about it, it might (and should) have ended without a shaming.

While there is perhaps no need to shame someone who is acting in a shameful way, I find it hard to criticize someone for doing so. Sometimes an aggressive statement deserves an aggressive response.


If they're trying to shame or chastise others, while being wrong, seems fair to me. Then again, I subscribe to the "play stupid games, win stupid prizes" school of dickish behavior correction.

Or, to defer to the ever-wise Gods of the Copybook Headings:

"What's good for the goose is good for the gander".


I've noticed that if you stay strictly professional, folks think higher of you and they feel shame for having done this. You also appear way wiser and likeable - all of which gives you more clout. And if you're more often right than your peers, everyone benefits by your having more clout.

I've been in this situation before and I've found this approach beneficial.



"I've noticed that if you stay strictly professional, folks think higher of you and they feel shame for having done this."

Some do, some think it is a sign of weakness and start behaving even more unreasonably.


And since the boss knows you are right because of your previous behaviour, all you need to do is ask the boss to take care of the disturbing element if it continues.


That's making a lot of assumptions about your 'boss'.


Yes I'm aware. I have been extrely lucky with my jobs so far.


Ah, but that's the kinder, gentler version of "what's sauce for the goose is sauce for the gander"[1] which seems even more apropos.

1: https://en.wiktionary.org/wiki/what%27s_sauce_for_the_goose_...


Normally that would be true.

But it's necessary to shame people who work the trade desks, or else they will never learn.


I honestly think people learn better if you don't shame them.


I honestly think it depends on the entire context including the people and all this generalization is useless and a waste of precious Internet bits.


not unless they're being dicks about it, like in this example ;)


Live by the sword, die by the sword.


Everyone dies from trying to dereference empty vectors that are != nullptrs at some point in their life. It isn't only APIs that can set traps...

Many people don't see mailing everyone as self promotion for showing off, most often they just don't know whom to address with stuff like this so they try shotgun mailing.

That alone can still be bad though, since it gives every recipient an opportunity to be distracted if they want to be.


It depends on the company. Often the best thing to do is fire back without escalating. With someone like that junior sending an email like that without first talking to someone is a good way to get fired or put on a PIP depending on how long they’d been with the company.


Really, there are many reasons to run internal mailing/distribution lists and designate emails from them in some manner, such as a subject prefix. One of which is that people are less likely to sent an email to the "Staff" list if most the correspondence there is from management and about company level things, and then it's also very appropriate to reply to the email with content that addresses the request (in this case, you're wrong, don't do that) and also a rider about how this is not the appropriate place for this, and they should submit to the appropriate list/form.


How did your API endpoint signal internal errors or parameter errors to the client?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: