2 ms·
, When I was at Microsoft ~10 years ago there was a single guy who truly understood how tables in Word worked. I'm sure they've fixed it by now but back then if
by onion2k 4y ago
, When I was at Microsoft ~10 years ago there was a single guy who truly understood how tables in Word worked. I'm sure they've fixed it by now but back then if you wanted to touch the tables code in Word you had to talk to the tables guy to make sure you wouldn't break everything.*
Every business I've worked in over the past twenty years have two things in common - one person who knows a key piece of thetechnology, and there's a woeful lack of documentation around processes and understanding. There's often reasonably good code docs, but that only ever tells you what the code is trying to do; it doesn't tell you why the code exists in the first place, or what the code should do. If you ever need to check the code is correct there's rarely any resources apart from that one person. In the worst cases that person left a few years before.
I've become quite good at technical writing because I always end up establishing a project to fix the docs.
- jakub_g 4y ago> it doesn't tell you why the code exists in the first place, or what the code should do This is one of the worst things in most codebases I see. Today I was told to use function X to solve my problem. Checked: 0 docs on what it does and why/how; although used extensively in the codebase. Read existing code and try to infer it, every damned time.