> we have a rule that certain ticket discussions should go into a ticket itself

The last three companies I've worked at had the same rule, except with no exceptions. All discussions get recorded into the system, precisely for the reason that you state -- so there's a historical record of what was discussed, what was decided, and why.

Any "external" communications, such as with email or IM, are expected to be copy/pasted into the system so its permanently recorded in a useful way.

That's a lot of extra stuff to read through. Do you summarise the discussion too?

Most places that I've been at that have worked this way have had periodic "checkpoints" in the tracker (usually when the code involved is sent to QA), where the current state is summarized at a 10,000 ft level.

In practice, these records are only read from beginning to end when someone new to the issue at hand needs to come up to speed. Otherwise, the value is in being able to search through the record to find specific things.

Jira has the ticket description section which gets updated to the latest goals / spec as things change. The history is for context of "who said do this" / "why did we do x"

> I get asked sometimes why I wrote code a certain way by the very person who suggested the change

This drives me crazy. Even worse is when I get told out of the blue that something I did is wrong, by the supervisor who told me to do it that exact way some months ago.

This has happened almost everywhere I have worked, and none of those places kept change discussions to a specific ticket. I'm going to push for this approach more in the future, it sounds like the right solution.

Yep. When we started our support was done through individual emails or a general support email (not tied to a ticketing system). That was fine when we were a 5 person company with 3 big customers.

As we scaled, we had to transition to a ticketing system, for the reasons you mentioned.

Slack definitely feels backwards in some ways especially if you use it as a channel for dealing with customer requests, especially if multiple people at customer site are part of the slack group.

> which is better cause I get asked sometimes why I wrote code a certain way by the very person who suggested the change

It's been hard adapting to the... less structured environment I'm currently in, but this is the thing that really gets me.

Send the requester an email about the decision asking if you understand their request correctly. Then save your emails (keep copies of them off of company computers so you have access to them in the case of unlawful termination).

There are very few things considered an “unlawful termination” in at Will employment. A difference of opinion about an implementation is definitely not one of them.

A company is very unlikely to ever side with a subordinate over their manager.

I'm not sure if this is unlawful termination, but I have a friend who was recently terminated with cause. The cause was supposedly lying about something. He had proof in his emails that proved he was innocent, but he has no access to his emails and was told all his accounts were deleted immediately on termination. What actually happened is some higher ups who had no hand in his brainchild saw how successful it was and wanted him to put their names on it. He refused (in retrospect, stupidly) and thus was fired so that they could take it over and claim it as their own. Because he was fired for cause, he has no severance, unemployment, cobra health insurance, etc. If he had copies of his emails it would be an entirely different story.

Out of three, severance is not a government guaranteed thing. If he signed a contract before he was hired guaranteeing severance (which usually doesn’t happen) he could file a suit.

If he had his status changed from fired with cause to without cause, it would have made a difference in his unemployment. I do not believe that they could deny Cobra. Why would they? He would have to pay the full cost with no subsidy from the employer.

No, it's not job security related, just awkward.

I'm just choosing to believe I'm doing a poor job explaining the tradeoffs, and then time or someone else does a better job a few months later.