Nature is random. So are us humans. However, we have the ability to simplify our lives by structuring.
Throughout our lifetime we keep meeting new people. We refer to them with their names. Imagine…
- what would the world be like if you would have referred to a friend as – the short guy from Delhi who drives fast
- calling out to him or referring him like this every now and then
- doing something similar for everybody you know !
Long ago, I read an article that emphasized the power of naming things. It was a convincing piece and I started practicing it. This gave encouraging results even in the initial few communications (documented, email, chat or verbal) that I had to do for my primary responsibility – i.e. developing software products. Confident, I tried various experiments to help team-mates benefit from the same. Some of these experiments worked, some didn’t. Eventually, this went beyond just naming, to bring structure to everything.
Refer to a sample discussion between two software engineers
Varun: Sam, so what design have you decided for maintaining history of logins and logouts from our application. Lets discuss it at a high-level so that you can document it
Sam: We’ll write one new class that will process the login, logout events. These events shall be coming from the service that manages the the user sessions. This new class will contain the logic for maintaining the history of logins and logouts. To persist this history, we shall use a service that already has a provision for batching the persistence requests.
Varun: Sam, appears that your design may be correct. But I’m not too sure, let me simplify it using terminology:
We’ll implement a new Listener for User Session Service. The listener shall use the Batched Database Service to persist the login and logout events in DBSam: Ya, ya. Thats what I meant
Notice the difference between how Sam and Varun explained the same thought. Using understandable terms, the explanation was concise and hence easy for review.
Unstructured thoughts are time-taking, tiring and due to confusion may end up being unproductive. This isn’t limited to software engineering roles. The people and teams who are able to achieve structured discussions, arrive at decisions with more confidence and that too in a much shorter time.
Most teams have members that are evidently more sorted even in the most chaotic of situations. How do they manage that? To some it may come naturally, others may have gained it by experience, the smartest ones would have proactively practiced structured discussions.
While your role and your team profile will govern a lot about how you practice it, keeping these thumb rules in mind will help
- Avoid using inherently ambiguous references like – “that module”, “our module”, “server”
- Give unique names. For eg when talking about user for an application, give them role names such as – “Manager”, “Admin”, “Team Leader” etc instead of referring to all of them as just “Users”
- Say no to synonyms. When naming we may end up giving more than one name to the same thing. Eg: A “vendor” or “supplier” may be used interchangeably. This would lead to confusion sooner or later
Its fairly simple, is relevant to all, requires no elaborate preparation and carries no risk. Start now !
kossip - by the people behind Ameyo: On technology and beyond 