Ask HN: Am I excessive in wanting to fire a dev?
I am the interim of the boss and in the code of one of my mate developer we had:
def compute_since_how_long(self, queue = None, start=time.time(), end=time.time() + 86400):
"""all horrors left as is"""
He made me tcpdump the mongo connection, check the sessions, the OS/hardware before checking the input/output of the function he coded and that was clearly the problem.
So even though I knew the fix, since I thought he needed to understand the problem, I asked him to fix the code (it is a part of the application he coded recently). And gave him the URL as a pattern.
He has a PhD, he know how to read, he is 35 married, and seems to be able to read a newspaper, he has no known cognitive deficiencies.
He left me with a test on value and not address
if start == sentinel:
I was pissed and he answered publicly, if it so easy for you why don't you fix it? (ofc I am not a victim and did not let it slip.)
And I was telling him like, well, how can you claim to be better than a PHP dev (I have been a PHP dev, but it still one of my favorite bashing at any dev) when you don't care about scopes, immutability, allocation of variables when you pretend to code into a language?
He answered what I was saying is unnice! And used the coworkers as witnesses of me being an asshole for this.
I want to kill him and it does not seems socially acceptable.
Do you have any alternative better plan than the murder I am planning?
29 comments
[ 2.0 ms ] story [ 70.8 ms ] threadSometimes it is all about technical details, costing, pricing efficiency and getting things done.
Because at the end, it is all about the money. And defects are expensive.
And you may prefer an efficient worker with bad attitude than a cool bro that introduces bugs in code like a priest in a brothel.
Because bugs cost more money than assholish workers.
AND now you start arguments with anyone that disagrees with you??
Take a chill pill, fix the bug, move on, laugh a little, and look the poor bloke in the eye and say you are sorry. People will respect you more, and maybe next time things won't get so blown out of proportion. Above all, relax, you got this bro :-)
You're winning an argument while you lose the war.
But, yes I was thinking the same myself. Whatever, I lost the war.
In fact, I prefer a boring life with less bugs on the long term and a bad reputation. But, it does not seems like a wise choice given the reactions.
I fully acknowledge my inadaptation to the actual era.
I think, I prefer to focus on the agenda of tomorrow and the tasks that must be done. You are right, customers come first.
There are battles that are not worth to be fought after all.
Well, tomorrow is another day. Thanks you all.
Everybody now knows (or should know) that the more modern type of developer environment - wear what you want, arrive when you want, stay home when you want, have all the free coffee you want - makes them MORE productive.
Pissing them off or giving them a shitty environment to work in makes them less productive.
And productivity = money.
Of course defects cost money. One defect means you lose money once.
Less productivity means you lose money every single day.
And kind of me shielding the devs from the operations wanting feedback and a quick resolution.
Production is noisy.
Just as it's important to be agreeable under uncertainty, it's important to say no under certainty.
"No, sorry, it doesn't make sense to start sniffing the wire protocol and checking the OS/hardware before testing the application logic first."
I think every Python dev I've met (myself included) has a funny/embarrassing story about default initialization in Python. It's a behavior which exists the way it does for a good reason, but nonetheless goes against most people's intuitions. So, we tend to get bitten by it at least once, and then we remember our embarrassment and avoid it going forward.
This is where you went wrong. What you said was very `unnice`. Rather than plotting to kill him, start plotting your apology. Then figure out whether you are a "Boss" or a "Leader". It makes all the difference in the world. If you find that you are a boss, quickly relinquish your position. If you are a leader then you will find a way to apologize and turn it into a teachable moment for yourself and for your co-workers.
Do a quick google search on "Boss vs Leader" to understand what I am getting at.
Not everyone you work with will have an equal or greater work ethic as yours. The harder you work, and the better you become at your work, the more apparent it will become development in many companies is less than ideal.
And that's ok. You'll be happier if you understand that.
You went on to dig deeper as a result of getting annoyed, which people who blindly succumb may not have done, and may lead to changes.
But please, stay focused on the bug, not the person. Address the process, not the person. The process is a stronger force.
One of the most effective ways to handle cases like this is to face the problem directly. In your case it may have been to send an email, containing only one sentence and nothing else (so there are no distractions) that says "I believe the problem is with scopes in compute_since_how_long -- can you please test this function?"
If I read that correctly, other coworkers also think you're an asshole, correct? If that's correct, that is pretty important. If you are seen by not only him as unkind, but also by others as unkind, you'll be fired once the opportunity presents itself. There are even tech companies with the motto "Fire the assholes" because it is often more productive to work with someone less technically competent, but less of an asshole, than it is to work with someone who is more competent, but more of an asshole.
In addition, I had to read your post a couple of times before it made sense. The next time you're bothered by an employee, you may want to consider that for each of your emails, texts, etc, that the other person may have to do twice the work to read it.
I've noticed in situations like these it will end in one of those situations so you don't really have to do anything.
Being assertive is important but being an asshole just adds distance between you and your team. You gain respect on the former and loose respect on the latter. I agree with partisan: 1. Take a deep breath and run it by your "boss" to gain perspective 2. Apologize to your developer for the poor choice of words and tone and tell him that you regret, and it would never happen again. 3. Once that's done, ask: "But do help me understand what you did here and why."
If he repeats his mistakes, take the "I don't think we are a fit" or "this arrangement is probably not a match for us" or whatever. After that's done, you can go to your boss and vent some more. :)
Hope it helps.
A woman I once knew told me this story. Her friend was a single mom while in grad school, when her water broke she took herself to the hospital on the bus... After she finished her PHD she was unable to cross the street without help.
Getting a PHD on a topic does not grant you some immense skill with said topic (it can...)
However you should have done the following:
1. Production comes first, if you CAN fix it, do it. Production problems are the only time when you can and should be the HERO!
2. Once production is fixed, THEN you give the person shit... and the way you do that is by making them CYA --- your PHD should have been writing the same test for EVERY public function in your system to catch the mistake for as long as it took.
3. Its a job, you don't have to be NICE... however being an asshole isn't going to get you anywhere.
4. If you have to put someone down, at least be funny about it, or try to be. I used to work in an office that had "tokens of shame" (beanie babies). Someone would mess something up, and the token would sit on their desk, till someone else saw fit to "pass it on" to the next person who dropped the ball. The other favorite is "I'll bet you a dollar this is your fault" of course no one ever thinks it is, and they take the bet (you have to get dollars out on the table) --- then when you show them make a big show of taking the buck.
1. Code ownership is not collective.
2. People's jobs are at risk over individual mistakes.
3. Team members are inclined toward bickering rather than just solving the problem.
4. Outrageous behavior toward other team members is deemed acceptable.
Good luck.
It seems to me this problem (and the related ignorance) could've been fixed in 10 minutes of working together instead of 36 hours of fighting about it.