3 ms·

I had a CTO who would often send erratas with corrections in documentation written by and for ICs. He would also _frequently_ request that PMs would send him d

I had a CTO who would often send erratas with corrections in documentation written by and for ICs. He would also _frequently_ request that PMs would send him draft emails before they send those to third party suppliers. Note that all of these edits were not about content or data sensitivity or anything technical. It was purely grammar or just zero value adding re-wording. It was definitely the shortest position in my career, i got out as quick as I gracefully could. So yeah micro-managers do definitely exist.

khazhoux 4y ago
Ha, I send corrections (including minor grammar/spelling) to ICs under me. But I use it explicitly as a "teaching moment", and explain to them: * They should be mindful of all aspects of their work, including docs. * If I come across code that woefully misformatted, and comments are all over the place, with random whitespace, and zero effort on spelling (in comments or function/variable names), it causes me to think they don't pay attention to details -- that they don't care about their code. I find badly formatted code to be especially jarring with UI engineers, who should have some knack for visual quality. * I warn them that when /others/ in the company see our code and docs, if we look sloppy, they will implicitly form a judgement of us as a sloppy team. On the other hand, if the single contribution I ever provided for my team was spell-check... then yeah, I should leave.
- throwanem 4y ago
  > If I come across code that woefully misformatted, and comments are all over the place, with random whitespace, and zero effort on spelling (in comments or function/variable names), it causes me to think they don't pay attention to details -- that they don't care about their code. I find badly formatted code to be especially jarring with UI engineers, who should have some knack for visual quality. This is a tooling problem, not a people problem. There's not a language I know that doesn't have at least a tolerably decent formatter and linter out there, and a delightful side benefit of having those in your build chain is the end of style bikeshedding. I find "well, if it means that much to you, you can always open a PR on the style rules," and the knowledge that they'll need to justify their preference - and own all the whitespace PRs, and at least half the merge conflicts, if they wish not to be thought a jerk - quells most folks' desire to fight about their preferred number of spaces or what-have-you. Without any sort of reliable tooling support for a standard house style, I believe I might well come to regard the kind of insistence you describe as a demand to waste time on pointless busywork. Doubly so, if the person doing the insisting had made no evident effort to find and put into practice such tooling support.

khazhoux 4y ago

Ha, I send corrections (including minor grammar/spelling) to ICs under me. But I use it explicitly as a "teaching moment", and explain to them: * They should be mindful of all aspects of their work, including docs. * If I come across code that woefully misformatted, and comments are all over the place, with random whitespace, and zero effort on spelling (in comments or function/variable names), it causes me to think they don't pay attention to details -- that they don't care about their code. I find badly formatted code to be especially jarring with UI engineers, who should have some knack for visual quality. * I warn them that when /others/ in the company see our code and docs, if we look sloppy, they will implicitly form a judgement of us as a sloppy team. On the other hand, if the single contribution I ever provided for my team was spell-check... then yeah, I should leave.

throwanem 4y ago
> If I come across code that woefully misformatted, and comments are all over the place, with random whitespace, and zero effort on spelling (in comments or function/variable names), it causes me to think they don't pay attention to details -- that they don't care about their code. I find badly formatted code to be especially jarring with UI engineers, who should have some knack for visual quality. This is a tooling problem, not a people problem. There's not a language I know that doesn't have at least a tolerably decent formatter and linter out there, and a delightful side benefit of having those in your build chain is the end of style bikeshedding. I find "well, if it means that much to you, you can always open a PR on the style rules," and the knowledge that they'll need to justify their preference - and own all the whitespace PRs, and at least half the merge conflicts, if they wish not to be thought a jerk - quells most folks' desire to fight about their preferred number of spaces or what-have-you. Without any sort of reliable tooling support for a standard house style, I believe I might well come to regard the kind of insistence you describe as a demand to waste time on pointless busywork. Doubly so, if the person doing the insisting had made no evident effort to find and put into practice such tooling support.