I enjoy writing documentation and writing tests. To me, writing documentation is like teaching others about the awesome product / features we have built, and also the different technical tradeoff decisions we had to make.
I can't grasp the mindset where an engineer builds something really cool that they are proud of, but don't enjoy talking about it / teaching people how to use it.
I look at it like this: explaining how you did the thing is part of doing the thing, so it's not complete until it's explained well enough for whoever your audience is. Not writing documentation cuts into time for doing the thing, i.e. cutting corners.
I don't really enjoy writing tests at the best of times, for example, because I've never had the enjoyment of inheriting a readable test suite. Most of the time you're looking at coverage hacks that test the runtime and, hopefully, cover some behaviour, and you're lucky if they can give you confidence through a refactoring. Mocks and stubs and spies are helpful tools but I've lost count of the amount of times that the actual purpose of the test is faked without anybody realising it.
But now, this time, there is a purpose and also organisational remit to change this situation and I'm going all in on rebuilding test architecture and writing examples of what we want to see. I'm actually enjoying something I never really enjoyed.
So it is with documentation, or dealing with bugs, or tech debt, or anything like that. It's not really about want or don't want, but why... and if you're on board with the why then it's gonna be better for you than if you're not.
That, of course, depends on solid leadership. So ultimately you're looking at how tight your org ship is.
- If I am able to focus on code, documentation or tests, I like doing it. Writing tests is sometimes lot more challenging than writing the code it tests. However context switching to difficult. I hate having to switch between the three
- The pressures of delivery makes it quite difficult to allocate meaningful time for either without cutting into scope.
- If your team does not value both to either read docs or maintain tests it become frustrating to be the only person doing it. If no one values it it can be demotivating.
- I have also seen teams either just focus on arbitary metrics like code coverage but not quality of tests or look at metrics like comment coverage/ number of lines of documentation, not whether docs are useful, how quickly someone is picking up by reading the spec, does it reduce bugs etc, quality and simplicity of language etc.
- It is a constant battle to keep both in up sync since i find it difficult to write code, tests and spec together. Once or twice a month I spend few days in trying to update both, which annoys me as they are out of date and I can only spend so much time on them.
And generally z others are as bored by that work as you, as simulated by new thing. Pretty often, the difference is not in how much you like boring parts, but in whether you are willing to do it anyway.
