[Jugurtha]

I'll assume you want to continue working there...

Do you have any trace of this in writing?

You have your code reviews in some management system like GitHub and GitLab.

When you have talked with your manager, and when you talk with them, send a recap of the conversation for memo. Same for conversations you have with your coworker.

Make sure it will not become a he said she said issue. Every interaction in writing.

It will become obvious who's doing what, who's not doing their job, etc.

This will avoid the situation where they get fired and tell you "You didn't tell me" or that there were no warnings.

Keep calm and courteous. There are people who count on you losing your shit and say "See what I have to deal with?". Gaslighting and all.

Version control is not just for code.

When doing things in writing, do not exclude th possibility of reading what you wrote and thinking "Holy cow, I'm the asshole". Either way, verba volant, scripta manent.

[throwawaydev123]

> Do you have any trace of this in writing? Yes. One problem was they were merging their code without PR approvals, which caused many regressions. This is generally not allowed in our codebase. My manager was aware of it and the extra work it brought on to the team. It took months for them to correct this behavior, where as most devs, even interns correct in < week. And it only ended when I escalated the issue to my manager's manager. My manager's point though was that the coworker was "improving" which was... true. They had been submitting a higher percentage of PRs over the few months.

sorry for the vent... This was probably the most "solid" issue I had that wasn't subjective.

> Make sure it will not become a he said she said issue. Every interaction in writing. Good point, I should document our interactions even during meetings. I rely mostly on our written communications to think through our interactions but recollections of meetings are unclear. especially when I didn't view some interaction as memorable from my point of view at all but then later it's used as a vague example as "created fear" in a meeting.

> When doing things in writing, do not exclude th possibility of reading what you wrote and thinking "Holy cow, I'm the asshole". Either way, verba volant, scripta manent.

Also good advice. I am not by any means perfect in my communications and sometimes I really was the asshole in some situations.

[Jugurtha]

Writing things down, especially for action items, can clarify but also track decision making to improve it because some patterns become obvious.

For example, at some point when a colleague and I took over, I did a "post-mortem" of all the people who left the company (resignations and terminations) going back a year. I wrote down how these events took place, how they were perceived, etc. A pattern emerged and one of the things that exacerbated these events was information asymmetry. Our next step as people now involved in helping to manage was to reduce that asymmetry as much as possible, and to implement a more dignified way to fire people when it came to that, and the guardrails/flags to correct course to avoid getting to that point. We made sure the feedback was much more explicit when we dealt with people who'd keep on with a certain behavior after they acknowledge it was subpar. When we speak about it, and we document the thing and the intent to change that behavior, and we do it over and over, it serves to refresh memory if you truly are forgetful, and serves to prevent "but you never told me that" or "I didn't know you meant it that way" when someone is into that sort of things.

On the technical side we write good, detailed, issues. When we fix a bug/regression, we try and figure out what drove us to have that bug/regression in the first place. How did we go wrong in our thought process? How did a wrong assumption go unchecked?

These issues help us recognize patterns and notice we've already fixed N bugs that are similar to that one. We then go fix the underlying issues for a family of problems, technical, but also in terms of business process or thoughts. This can be refactoring, introducing tests, adding a checklist, documenting something, etc.

Why did I make that mistake and am I making similar mistakes? Can I solve for a root cause so that I cannot make that mistake again even if I wanted? How can someone else not make that mistake even if I never speak with them?

If we have a regression: why was this working and is not anymore? What changed? Why? How can we prevent that? This broke because I forgot a step in a process. It has happened before. How can I make the process succeed and decouple it from my memory or whether or not I had a good night of sleep? Can this be automated? Can a part of this be automated? We systematically go through that loop and introduce efficiencies that are needed to move fast as a small, tight, team so we can focus on what matters, instead of putting down fires, whether technical or administrative. We put fires, but if the fires start looking familiar, we handle the source. One way to figure out the fires look similar is by documenting things (issues, incident reports) because then the similarity is clear and staring at you and you go "duh!". Having these instances enables you to cluster into families of problems (technical, administrative, business) and solve a more general problem after you've solved one too many specific problem.

On the business side, I also analyzed our past projects and tried to figure out what worked and what didn't and the reasons behind them. This has shaped our current process of doing business. With that analysis, a certain number of things to clarify made it into a sort of checklist with our clients. For example, one of the things that doing that made us do is to explain very clearly to the decision makers that the people who will use our product [we do bespoke enterprise products leveraging machine learning] must be at the table. We need them at the table, or we know the project will fail. One other item is to make sure we nail down the problem with the client before we even get to the "ML" stuff or implementation. One other item was to make sure the person we are dealing with has decision power and the budget.

Doing this, we're much more profitable now with the third with one eigth of the number of projects and a high success ratio, because we don't start projects we know will fail [that don't check the boxes or where there are too many red flags].

I had a file called `lessons` where I documented mistakes. It could be anything, such as arriving almost late at a client meeting because I had assumed X, or not doing the proper diligence on something because of Y, or removing a line of code in a careless commit as I thought it did nothing because there was no reference to something, but it turns out it was used at runtime dynamically.

Therefore, when I say to document things, it's not only as a "cover your ass" or as an "exibit A" against people. It's to keep evidence against bullshit, even more so yours, and address it. The goal is to function, get the job done, learn, and build a better organization that can go on and do good thing.

Sorry for the sloppy writing and no editing. I wrote a bit about some of these issues here https://news.ycombinator.com/item?id=26182988

That answer contains links to other answers related to aligning the team, product, leveraging your time, communication, etc.