Hacker News Reader

Clearly he's got some issues given the reaction. However, was he informed of the bug? Was there an expectation he would fix his own mistakes?

I don't work in IT/Software Engineering - I work in law. But when I find fault in other's work, it's a courtesy to let them know and give them an opportunity to address it. It's part of being a team player. I am not trying to be critical of you. It's just reading this reminded me of similar experiences where I was in a similar position to you. They were important experiences. People can feel bad when other people fix their mistakes when they aren't given the opportunity to be heard about it. It's so tempting to just say 'I will just do it myself' but you might find other people react poorly to this.

Of course, maybe things are different in the IT world where it may be challenging to identify who committed a buggy change to the code repository, or perhaps just a radically different culture of work. But at the end of the day we are all human.

It does appear you have developed an awareness of this, given what you noted in your reply to him (and props to you for that!). From there on, his behaviour was misguided and not appropriate.

No offense taken. Your questions are valid.

1. Would he be informed of the/a bug(s)? Absolutely. We monitor bug tickets submitted to our team throughout the day. It's a main part of our job.

2. Was there a strict code ownership per individual contributor? No. This team's culture was such that once one contributor's code was committed to the main repository, it is part of the team's responsibility, not just the original contributor. In fact, any kind of don't-touch-my-code attitude was heavily frowned upon, worthy of a warning. I understand other teams may have different cultures.

I was too young to know the office dynamics back then, but in hindsight from more life experiences since then, I now see that he was just a very insecure person. His former colleagues were advancing ahead of him, making 4x his salary, and the last thing he wanted was a young team member outperforming him. This observation itself is a life lesson for me.

Thanks for following up.

Because I wanted to ask why he would be so mean to you. That insecurity part answers that.

I understand the insecurity part, I don’t understand the behavior. Or maybe I do, I just consider the person an asshole first, and insecure second.

I don’t enjoy being corrected by my team members either, but that’s more out of frustration that I did something wrong in the first place.

The act of correction may be annoying at times, but you absolutely shouldn’t punish the initiative.

One point though: i personally don't like that as well as I see my bugs/issues as something I should fix.

I always prefer a short message like 'hey I saw a bug here and I will fix it. At least this gives me a heads-up.

But of course I wouldn't tell you that and I would definitely not hold a grudge against you because of it.

Not the original poster but I think things are just radically different by the sounds of it. Every company I have worked at, once the code is in the main revision everyone is responsible for it. At that stage the code has gone through many people from reviewers to testers, its not one single persons fault.

Easiest thing to do ia not to blame but to just find a solution and see as a team if it was a genuine mistake that is unavoidable or if you can make some adjustment to the process to ensure quality and reliability of your code.

People can specialise in a certain area of the codebase but no one 'owns' anything. Everyone needs to respect that any change to the code is a neccesary one. The 'expert' or original coder is usually a reviewer of the changes proposed anyway so thats when they can voice opinion on whether someone has misunderstood something or not.

Bugs/Features can be worked on by anyone without ego getting in the way.

This is exactly why we don't put @author comments in our code. Once the code is in the main line it's owned by the team.

It also helps to promote quality within the team because if you see something unreasonable you are empowered to take action (that may not be possible immediately because we all have our day jobs but at least adding a TODO for it)

The standard you scroll past is the standard you accept.

This only works if the team has a very high standard and some self restraint.

Otherwise notorious code churners who are addicted to a high commit count plow through the code base, regardless of whether they are area experts or not.

If you contradict them, they cite the common ownership rule and paint you as a non-team-player.

If they introduce bugs into the release and you point it out, you are the villain again.

All in all, many of these shared ownership code bases are a breeding ground for politics that suffer from the tragedy of the commons.

Very interesting stuff to read from the perspective of an unenlightened outsider.

This sounds like a leadership issue.

I personally would either point it out or actually leave the project.

We don't have to accept every shitty job as Software engineers.

Unfortunately it takes time to experience and see those issues and to learn to handle them properly.

I do prefer sustainable development and at least my track record shows that it is paying off: high security, high trust in the system, stress-free oncall etc.

If I can't sit in a beer garden on a nice august afternoon a little bit early because everything is falling in peaces I have done something wrong. Not saying that I'm spending all my time not working just saying to have the freedom to be more flexible in when and how I work.

This does demand pushback to management if someone outside of your team starts to sell things with deadlines without asking you.

This works up util a point.

If the code is owned by 4-30 people, its good.

If the code is owned by 120 people, then it takes way to long to tell what the quality standard is.

> The standard you scroll past is the standard you accept.

The challenge is how to get work done without spending 60 hours a week pointing out or solving code quality problems. To overcome this challenge requires accepting some standard of crappy code.

I think it is worth it in the lo g run.

In best case your team grows and the original hurdles are fixed.

It's always problematic for bad colleges which just do the same mistakes over and over and over again but what do you wanna do? Accept a potential security bug because it is too much effort?

If your code is so complex or big that you have 120 people on it, you should have enough people in governance positions and hierarchical quality gates.

> what do you wanna do? Accept a potential security bug because it is too much effort?

Yes. It is important to have the serenity to accept the things you cannot change.

In the choice between

A. Burning out on a fool’s errand of attempting to fix/prevent all the security bugs.

B. Giving up as you accept that people write security security bugs and as an individual contributor you have insufficient power to stop all of them.

C. Accepting the existence of bugs all around you and focusing on changing the small bits of code that you can.

The latter is preferable.

Software is a machine. You don't ask the other mechanics if you can go and replace a faulty part on an engine they rebuilt last week. The engine is broken, you fix it and move on.

I would still expect communication. After all I don't want someone else to take away a potential learning experience.

If someone else just fixes stuff for you all the time that just might not be good in the long run.

The bosses behavior is the worst I’ve ever seen.

Sure, if there is time, it is best to file a ticket and notify the code writer so he can fix his own bug. That’s how he learns, but an urgent bug?

The worst part is his reaction. He literally twisted the person’s words to the worst interpretation possible.

What a piece of shit colleague.

I feel like most people wouldn’t need this kind of bad lesson to know what not to do. And those who would are a lost cause anyway, as they probably know that what they’re doing is wrong.

Does this company use any form of stack ranking to determine bonuses?

It sounds like one possibility is your boss may have been trying to prevent you from getting to his level which would mean he would have to compete with you.

Stack ranking incentivizes people at higher levels to only allow incompetent people to get to their level because they’ll look better in comparison.

Looks like he set you up to fail no matter what you would have said back then.

True, at best he was talking purely cynical and out of frustration. Still handled really very well by not adding any more vitriol but rather talking about the facts. Eventually the OP even got promoted.

> He always welcomed criticism of his work.

What are some ways to do this effectively?

Just listen and try to steel man what they are saying as best you can before you start to consider how it might be wrong.

Try to get onto the path of thought that led them there, but let the questions that arise naturally for you hold off as long as you can.

To be clear this is like a policy, you will fail at it but it reminds you of the prinicals that you believe in.

I learn a lot doing this in more ways than i could explain in a book, never mind a comment.

doesnt matter how wrong or personally based the attack/criticism is. The more extreme the situation the more important it is to keep to the plan.

the lessons learned will cover all of existance as you will learn more about how people model the world, problems and solutions beyond the specifics of the problem at hand.

*if doing this drains you make a change of environment (e.g. job), however i find that the discussions you have like this change other peoples thinking more effectively, so its also how you sew the seeds of cultural change.

Similar to people with ptsd, your amygdala may be overactive. You can try different methods of reducing your general level of stress.

Personally, I try to detach it from myself and think in term of process, even if they are just internal processes (as in processes I created for myself).

Why was this bug not prevented? Did I follow the processes? If yes, why did they fail, and how can I change them not to fail next time? If not, why did I not follow them? How can I ensure that this will not happen again?

Also, can I share my experience? Can I learn from someone else experience? I think it's very good to say "I did this and that, which I thought would be enough, but it wasn't, how do you guys do it?".

Not saying it's perfect, and I always feel bad whenever there's a bug in code I wrote, but I'd rather hear about it, if only just to try to reduce the amount of time this happens in the future.

I like to think of criticism as scientific peer review. The purpose of that is not to criticise the person, but to strengthen the validity of their research by eliminating any remaining errors they may have missed.

Your peers aren't harming you by finding fault, they're strengthening your position by doing so.

I personally hate it when a bug slips through to production, and I always profusely thank anyone that spots one before it does. Or after. Whatever, as long as it gets fixed...

This is all going to vary from workplace to workplace, but:

1. Proactively ask individuals for code review.

2. Thank people, visibly and publicly, when they point out mistakes or offer good suggestions.

3. Be an example when you leave critiques; accept that beyond some agreed-on code standards, some things are subjective. Just because you wouldn't write code in a certain way doesn't mean the way they've written it is wrong.

You can see from the other comments that people like prescriptive actions that anybody can take. It's a lot harder to accept that you might have some behavioral or mental issues that you need to dig into which would then make all of these behaviors natural. Forcing yourself to be a steel man is pretending. Becoming a steel man is much harder but is possible for those who willingly seek treatment. If you're willing to ask this question it means you are a good candidate for treatment. Good luck.

How do you not immediately report this guy to HR? His behavior is absolutely verbal abuse.

Please don't play it emotionally and report it to HR. Folks from HR are there to take care of the manager and employer. Such a step could be suicidal.

Just as you have to earn the respect from everyone, each single individual in that org must earn your respect. Choose your confidants carefully. HR is for door in, and out.

I find this attitude to be the same as kids not telling on the bully because it’ll make things worse. The guy lost a four figure bonus for no sane reason. Keeping quiet isn’t going to make anything better. You either speak with HR or firstly maybe your boss’s boss. Maybe things are a bit different if you work in one of the places where you can be fired at will but generally you have employment rights that will protect you.

Never talk to the bosses boss without going to your boss first. By doing so, you are ignoring the chain of command and likely will you fired. How would you feel if someone you managed went behind your back to talk to your boss?

Agreed, I thought that was implied in my comment but reading back it isn’t.

I disagree that going above your boss first would lead to getting fired though (again with the exception of at will employment).

That kind of behavior is for me a red flag which would definitely lead to me scheduling a meeting with the boss of my boss.

If you really wanted to stay with that company because everything else is great, your only chance is to solve this with the boss of the boss.

5 figure bonus lost due to this is abuse.

That is such a bullshit meme that needs to die.

HR's exact goals vary between companies, but unless the company culture is toxic all the way to the top, part of their job is usually to reduce staff turnover (which is very expensive for the company), and in pretty much any company their job is to protect the company against lawsuits. Abusive managers are not well liked by HR.

That doesn't align with my experience. In my experience, they pretend to care about the employee, but when the employer is in the wrong, even in an obvious way, they will side with the employer in the blink of an eye every time instead of trying to reason with the employer.

The abusive boss is just an employee too

Maybe this is different here in Europe, but HR's role is to protect the company. HR in my experience does not do whatever a manager wants. Let's say you have a toxic direct, unless you have a 50 page document outlining every single transgression or bad behavior and the steps you took to mediate said behaviour, including corrective feedback, and statements by the toxic employee's peers supporting your observations, HR will often times do exactly nothing and happily ignore you, and even then, they could still propose "mediation" or "conflict resolution" procedures because they are afraid of an unfair dismissal law suit or whatever.

The employer, yes. Some low-level manager? Not at all. It is not in the employer's interest to take the side of a toxic manager who may cause several of their reports to quit.

HR doesn’t work for you.