> What should I do when I see someone else is making a mistake?
> When you see others making mistakes, first help them see their mistakes and deal with them (e.g. by recycling this text, or by independently offering your analysis and answers to Steps 1 and 2 above).
> Remember you make mistakes too, and be tolerant of the time it may take people to accept that they have made a mistake. (But you don't need to allow them to insist they have not made a mistake.)
I especially appreciate this. Far too often I see people reacting to people's mistakes with anger and hostility, instead of first trying to 1) understand the situation, and 2) help the person who made the mistake (if there even was one) understand the mistake.
It should be noted that you should contact them about their mistake in the most private way possible, then escalating slowly as the need arises. This follows the "praise in public, punish in private" maxim.
If your brother sins against you, go and tell him his fault between you and him alone. If he listens to you, you have won over your brother.
If he does not listen, take one or two others along with you, so that every fact may be established on the testimony of two or three witnesses.
If he refuses to listen to them, tell the church. If he refuses to listen even to the church, then treat him as you would a Gentile or a tax collector.
Amen, I say to you, whatever you bind on earth shall be bound in heaven, and whatever you loose on earth shall be loosed in heaven.
You have to keep in mind that the way tax collection worked in that area at the time is that it was contracted out by the state. The contractor needed to deliver some amount of money to the state, and empowered to gather money from people; the difference between what they gathered and what they delivered to the state was their profit.
Tax collectors operating within this incentive structure were not likely to be very likable.
And just to drive the point home, the tax policy that this caused was occasionally literally genocidal, in the most strict meaning of the word.
This was possible because it was a slave society, and it was possible for the tax collector to collect your children into slavery in lieu of unpaid taxes. In some areas in Anatolia, which were close to the border of the empire and thus had a significant military presence that the tax collectors could fall back on, so the local population had no possibility to push back, entire societies were ended because the Roman publicans collected all children once they reached the age where they could be profitably sold (circa ~10 years or so, and sold usually to sexual slavery), and did so for long enough that the populations collapsed, never recovered, and were eventually replaced by other populations transplanted from elsewhere in the empire. (Later, the power of the publicani was seriously curtailed, in small parts because even the Romans thought that some of their practices were abhorrent. Albeit mostly because of internal power struggles with the senator class.)
So yes, people in the provinces had plenty of reasons to hate the tax collectors.
On the one hand, they were a cultural byword for a morally degraded profession at the time. "Tax collectors and prostitutes" is a phrase that comes up not infrequently in the gospels, and not just out of Jesus' mouth
So apparently the practice of tax collecting was a little weird in the Roman Empire.
On the other hand, he was known for having dinner with tax collectors and prostitutes. One of his 12 disciples was a tax collector.
In some places, tax collection was performed for an occupying power, e.g., the Roman empire. Hence, it was rightfully seen as "money taken away" instead of "funding public infrastructure".
This passage isn’t as much about forgiveness as correction. You are supposed to forgive no matter what (77 times). But this is if someone is doing wrong and needs to be corrected. If no matter what they will not stop their bad behavior then depending on how serious it is they cannot be allowed to keep being a part of the community.
This makes me think, it is opposite to what mostly is used in open source projects that have bugtrackers. Github is filled with countless 'mistakes' (issues/pr's) people made in the code they published. Should there be some kind of way to make issues private?
Before I was into open source I was always afraid to show my code to anyone because of the critique I could expect. But some coworkers helped me get the confidence I needed to go open source (within the company, not public internet). Being completely open about everything and accepting critique publicly really helped me grow as a developer to also be open to others. I wonder if I would have made the same transformation if I was only critiqued in private.
Bugs are not critiques. Working in software development, you learn extremely quickly that everyone writes bugs, and there is nothing to be embarrassed about. The openness of issue trackers even helps elevate that.
On the other hand, it's not normal and not often practiced to go digging to see whose mistake introduced a bug and call them out in public on it - that would be what shouldn't be done at all.
Not only (technical) bugs are reported, but also design decisions and such. A lot of those things often come down to difference in opinion. I've seen some developers be really adamant about how a bug was actually a feature.
> The openness of issue trackers even helps elevate that.
I agree partly. For me it helped see things different and make a positive growth. But I can image some staying afraid to enter or be deterred really quick never coming back.
>> This follows the "praise in public, punish in private" maxim.
So like the previous poster said. I am wondering if Github et al. should not contain a private channel.
I have a email on my Github page. And besides spammers I sometimes get questions regarding my projects. I don't know if it is due to people not understanding Github that well[0] or wanting to contact privately[1]. But for some reason they didn't open a public issue[2].
[0] I've met a lot of technical people that just are afraid of Github because it is complex. Electrical engineers, mechanics, embedded engineers. People I figure would understand software development concepts.
[1] Asking a stupid question publicly could also count toward making a public mistake depending on how secure someone feels about themselves.
[2] There is of course also the discussion if issues should be your projects helpdesk next to being an bug tracker. And raising an 'issue' for something that might just be a question might feel strange for some.
> I've seen some developers be really adamant about how a bug was actually a feature.
And sometimes they are feature, and it's the users that are mistaken on what the project they are using is offering them. It's a fine line, I'm sure, but different projects have different goals, and those goals will align to a specific user's needs differently depending on the user.
> So like the previous poster said. I am wondering if Github et al. should not contain a private channel.
It might depend quite a bit on the project. In an open source project with many contributors, there isn't really any meaning to "private" other than "limited to a subgroup of the people that care", and those people may have little to nothing with the design and implementation of the items in question. In a project that is mostly driven by one author that controls it and accepts some patches, that might be a lot different, and criticism may be received differently.
There's a whole spectrum there, and even if you provide the tools to allow different types of contact, what's to prevent people from using the wrong tool most the time? Rust, PHP, Perl, Bind, Apache etc aren't going to benefit much for a private list for first contact of regular bugs, but people would use it. Meanwhile someone's random personal project is still going to get people making public requests even if they prefer them private. In the end, I think we're all better served by a "public by default" for open source stuff, and for things people feel is actually private (security related items, for example), they'll look up a private contact or personal contact for someone related.
I contributed to launching a few products. After countless hours of design debates, code writing, code review, the baby was finally ready to see the world ... but nobody cared. Not even a drive-by troll bothered writing "this is completely useless".
My Motto: "That product sucks, but wow! It made it on the shelf."
In larger projects bugs are rarely caused by a single person. With many people contributing to a problem in the way of code and reviews. The best way forward is for everyone to own the bug and own any potential solutions.
I think though there are still some elements, there is also a difference between genuine mistakes (bugs) and "knowing the wrong thing, and choosing to do so".
The funny thing is, if you ponder for a while, you'll realize you'd have done some similar mistakes. But such reflection requires being honest to oneself and setting aside/rising above one's ego and doing an unbias reflection for few moments. Then a spontaneous smile will light up your face and unconsciously somewhere you've broken some string of ego otherwise holding you tightly all through your life.
Indeed. Whenever I get cut off on the freeway, I try to remember the times when I accidentally cut someone off but had no way to express "Oops, sorry!"
I recently had a coworker point out to me a grammatical error I keep repeating, flush vs flesh, that he had reminded me of a year ago.
I recently pointed out to a different coworker some whitespace inconsistency in a pull request in a similar fashion as I had pointed out a while back.
In digging deeper into both situations where I was the reporter or the reportee, the issue came down to legitimate lack of agreement on whether it was indeed a mistake.
Yea, unless you're professional writers, and I don't mean coders, that's not the right kind of things to focus on in pull requests. I mean, if someone happens to be great at code but really terrible at English, like you can't imagine they passed high school grammar, maybe it's a good idea to help them improve. But the average college educated developer writes well enough to write succinct and readable code comments and documentation. Or should be able to.
Even when we learn from a mistake it may still happen in the future. Hopefully we have reduced its frequency but it can still happen.
For example, I sometimes write "too be honest…". I've known it is wrong for decades, but occasionally am still not able to see it. Still happens about one out of every fifth time.
> I recently pointed out to a different coworker some whitespace inconsistency in a pull request in a similar fashion as I had pointed out a while back.
Ask them how you can help them not to make the same mistake again. Not knowing the specific situation makes it hard to offer specific advice, but in software there are specific tools (e.g. IDEs, linters, CIs, tests, etc.) that help people avoid known mistakes. Sometimes having better docs or specific checklist (e.g. "your bug must have these fields filled in before we can work on it") helps.
If that doesn't help, ask the manager the same - emphasizing you are not attacking the person but looking for a way to stop wasting time on correcting the same repeating mistake which adds to costs and decreases productivity. That may generate some resentment (so trying to resolve it directly first is prudent) but if you avoid framing it as a personal fault it would usually help.
The problem to be solved is why the person doesn't learn or change when they know about the mistake, not the mistake itself.
You might start by directly asking, "Why do you keep making this mistake?" It might be because they're careless, or lazy, or maybe they really don't believe it's a mistake (they just acknowledged the mistake to get you to go away). Or maybe they just need a little help, such as automated reminders to get them to check for those mistakes.
Sadly, there are people who will not learn from either kindness and teaching, or harshness and harrassment. In the workplace, you can make an appeal to the manager, but perhaps only after discussion with coworker has failed to produce the desired results.
Do you also feel a general lack of leadership and/or authority? Many things are best resolved by bringing the hammer down, but if no one is qualified to wield it you will be wasting your life trying to protect order from chaos.
Kindness doesn't solve a problem. It's better to employ empathy and reassurance which aren't necessarily the same thing as kindness. It seems that is perhaps what you otherwise implied.
I’m glad others out there see it this way. I made a minor mistake, and a former employer and manager used it to make me totally unable to work again by blowing it up as much as possible. It’ll blow back on them eventually, but in the meantime I’ve been made homeless and lost all my friends. Since lawyers are involved and profit from my mistake looking worse than it was, there will never be an honest reconciliation. The court of public opinion is the only way they might be convinced to show some kindness.
I think the anger and hostility usually happens when the person doesn't accept that they've made a mistake. So I think it goes both ways. If someone contacts you about a mistake, don't immediately get on the defensive. Instead, relish in the opportunity to learn.
> When you see others making mistakes, first help them see their mistakes and deal with them (e.g. by recycling this text, or by independently offering your analysis and answers to Steps 1 and 2 above).
> Remember you make mistakes too, and be tolerant of the time it may take people to accept that they have made a mistake. (But you don't need to allow them to insist they have not made a mistake.)
I especially appreciate this. Far too often I see people reacting to people's mistakes with anger and hostility, instead of first trying to 1) understand the situation, and 2) help the person who made the mistake (if there even was one) understand the mistake.
A little kindness goes a long way.
[Edit: formatting]