User:Icyflame/Unsolicited advice to future maintainers

Hey, I would preface this by saying that I have worked or am still working in a typical KGP Society, a Robotics research group, a well-run start-up and under a professor at an institute other than IIT KGP. So, I have some experience with diverse work environments, each with separate incentives.

Have a look at Minimum Viable Maintainer if you haven't already. This document serves as an extension to that.

Things to remember when writing a SOP

State the WHAT, elaborate on the HOW

Often times, it is really fun to think of an idea, and keep on adding to it and make it into a good product, albeit in your mind.

Advice that I adhere to when I find myself going berserk with an idea is: STOP! Now, think about how you plan to implement whatever you had till now. Then, continue with your idea extension process.

State the incentives

1. Planning a collaboration? : Why would the other party spend their time on this?
2. Planning a project that requires N developers? Why would these people want to work on this?
3. Planning to build a product? : Why would people use it? How is it better than the status quo and everything that has been tried in the past to address the problem?

Other important things I learnt along the way

Listen to others, think before you start typing

Slack and IM make communication easy ... and complicated. Let me explain:

1. Communication is easy if the parties communicating have a common goal, and are putting in a non-trivial amount of effort into keeping the conversation sane, unblocking themselves and getting to that common goal.
2. Communication is easy if the parties communicating have conflicting goals, but listen to the other party and are willing to change their stance if reasonable, technically sound arguments are posed.
3. Communication is easy if the parties communicating have opposite goals, are unwilling to change their stance, but would still comply with someone else's opinion because of their inherent belief that the other person is more experienced than them.
4. Communication is complicated if one of the parties communicating is responding without reading and understanding the points being made in a discussion.
5. Communication is complicated if one of the parties doesn't know enough to comment about something but still chooses to do so. See Dunning Kruger Effect.
6. Communication is complicated if an inexperienced party pretends to know how often something might happen, despite the experienced party clearly explaining the reasons for their claim. (See Dunning Kruger Effect)
7. Communication is complicated if one of the parties is not interested in reading the points that are being made or have been made in the past by the other parties and their only interest is to propagate their own point of view, because of reasons such as: ease, naivete, lack of the required experience

If a solution approach seems complicated, Don't shy away from it. Embrace it.

Does a proposed solution to a given problem sound very complex and extremely time-consuming? Don't shy away from it. Try to get it done. Really try, spend your time (and money) doing it.

Most of the times, you will solve the problem. Or you will come really close to it! That's good enough for the first time you do something complicated.

But a few of the times, things won't work out. You ended up totally wasting your time. But is it really a waste of time?

You just discovered a very complex solution to a problem. If it is a common problem, why isn't there an easier solution? Investigate, solve, spread the word. You just made life easier for a lot of people.

And in all the other cases, you just learned that something was very complicated. So complicated that you can probably share your experience about doing it, once you manage to crack it. That's one hell of a story to tell everyone!

Notes on User:Amrav/Minimum Viable Maintainer

Personally, I feel that building trust and communicating effectively are the most important of the points made in the first part of that document. I woud like my maintainer to be trust-worthy, and I would like them to be easily approachable, even in cases where there is a conflict.

    it's the day-to-day stuff that's much harder, more fascinating, and ultimately, what will matter in driving Metakgp forward.

Yes, it's the stuff that happens every day that will pose a novel and irritating problem to solve.