We’re starting a new, interesting project. It’s big, it’s new, it’s challenging. It involves working with multiple teams across the organisation. I want to work on it. Looks like I’m not going to.
Early indications are that I’ll instead be leading a different workstream. Another colleague will be leading the new, interesting project. Not good.
We’ve got a consultant on the team. He’s fairly experienced and quite good at structuring solutions. He also has strongly opinionated working practices, and refuses to change them unless he’s directly ordered to. We’re a friendly, consensual organisation, so we won’t order him, and he doesn’t change his tune. Not good.
But there’s an upside.
The consultant will be working on the new project. This means I won’t have to see his code. I won’t have to worry that there’s no documentation, or that every class has 50 2-line functions. I won’t need to hear him again explain that there’s no point to adding UI tests if we can’t have a full test suite of multiple layers of tests.
If anyone asks me in a year how something works in that project’s code, I can honestly say “I don’t know” without feeling bad about it. It’s not my failure that that code is not well documented. It’s not my failure if it’s not easy to read or understand. It’s not my failure if the context for the changes is lost over time. I won’t have the daily anxiety of needing to review and approve code that I know will be indecipherable in 6 months. Good.
The icing would be if I can convince the colleagues on my workstream to accept documentation, deeper implementations, and other similar practices as the norm. Not, as he said, a matter of taste.