Suramya's Blog : Welcome to my crazy life…

In my career I have heard the following way too many times:

Where is the Documentation? I am the documentation.
When asked how to perform a task people will tell you to talk to Person X

Sometimes things are not documented because people are busy, other times they don’t like writing documents, others feel that if they tell folks how to do something they are no longer the critical dependency and thus are in danger of being made redundant etc. Some others get a power boost to their ego when people have to come ask them how to get things done. This is especially true for the old style ‘neck-beard’ ‘gurus’ or the 10x developers.

Personally, I feel that unless I train people to replace me I can’t move up to the next interesting role or get promoted. In one of my previous companies when we would tell my manager that person X is the only one who knows how to do a task and they are working on it she used to respond asking “what if they get hit by a bus tomorrow and can’t come to work for a month. What are you going to do then?”. So We then started documenting everything and cross training on other systems in our department so that we could at least answer basic questions about it. If people were not giving us the information because they wanted to keep it to themselves, we were told to call them up whenever we needed the work done regardless of the time difference. Once folks got woken up at 3am a few times most of them were more than happy to train others. The couple of folks who still didn’t collaborate were warned and then ultimately let go.

I keep a running document of how I do things at work which is shared with others in the team. For personal projects and work I usually end up posting a blog entry about it so that I have a record of how something was configured/setup/fixed.

Moral of the story is that you should document everything, because otherwise 6 months or a year from now you will be looking back at a system wondering why something was done in a particular way. Or trying to figure out how to do something because you didn’t touch it for a while. Also, if things are documented then folks wont be bothering you answer questions about the same things and you can focus on more interesting problems/work.

– Suramya

Saw this in my feed a little while ago, and honestly if a company is using how you format code/your code formatting style to select people then I don’t think I would want to work with them in any case. That is because if they are that nitpicky about stuff that doesn’t really matter instead of focusing on actual skills then who know what kind of mess you will be dealing with when you are in their system.

Who would you choose?

I get it that you would want a consistent coding style across the codebase and there are scripts out there that let you reformat the code to the ‘correct’ style at the click of a button. In one of my previous companies I worked with 2 coders who each preferred a different code formatting style and had written macros in Emacs to format the code to their liking. Whenever each of them worked on a file, they would change the formatting and then make the changes. It was a bit annoying because when they changed the formatting the entire file would show up as modified when looking at the diff between the versions making it harder to code review. But that was still better than working with people who will judge your code quality on the formatting you used in it.

Also, for the record I prefer the 2nd option for code formatting 🙂

What do you think?

– Suramya