[Neywiny]

I've had great success with gitlab and it's issue + mr (they use "merge requests" which tbh feels more appropriate) tracker. I make an issue ticket, dump all symptoms, logs, relevant configs, whatever into it. Then I make the MR, and put all my fix stuff in there. I like the separation of what the issue was vs what the fix was, while still keeping them linked. Really helps when somebody else does the other half.

ETA: none of this is as helpful as having my team and higher ups understand and appreciate what I do, though. That's step 1. Or step 0 if you can feel that out in the interview.

[imp0cat]

Gitlab and its ability to link together issues, MRs, branches and commits is a lifesaver.

[Neywiny]

Oh yeah the branches too. It's made it super easy for me to ticket the issue, maybe the MR + branch in one click, and add it as a worktree. Honestly worktrees have saved my multitasking. I know Jira/Bitbucket do similar, but that's not what I primarily use.

[croes]

Put if your MR is just one line of code and it took you two weeks, you still have the same problem.

[Neywiny]

Agreed. That's why the documentation is important. If the issue ticket says "I saw this but once. It took 2 days of reproducing and it could only be done if the moon was in a waning phase while 3 dogs bathed simultaneously" and "this is the log dump. You can see on line 3453 that we segfault" etc, it shows what you've been doing.

The way I felt the article should be interpreted is that yes, if after 2 weeks you have a 1 line change, that's going to get you fired. And debatably it should, given that it'll likely take somebody else another 2 weeks to fix a similar problem. Why would a manager want to pay 2 weeks salary for (what we call, unsure if commonly used) "tribal knowledge"? At least do a post-mortem/lessons-learnt