by on

The aphorism “All models are wrong, some are useful” is applicable for analogies as well. Analogies are never one to one replacement but should help to bootstrap a new concept through a known concept. Use of analogy should stop there and from there on knowledge has to be built on first principles. Why use analogies instead of first principles? Many people will have less time and effort to understand a new concept especially during business discussions, it is better to help them learn a new concept using the right analogy.

A good example is learning about resistance, current and potential difference in electricity using flow of water. Once a student gets an idea then building the knowledge should be on electrical concepts alone. It is hard to continue the analogy trying to explain electro magnetism.

Photo by Brett Sayles on Pexels.com

I have majorly seen this problem coming up in software development where techies explain technical debt to managers and convince them to allow work to happen on that front. The debt analogy is an infamous example, managers love debts in business which helps them with a lot of working capital with less incentive to repay principal but keep paying interest. There is no interest repayment analogy in technical debt, rather it is not even a debt it is a deficiency. Deficiencies have to be addressed for growing well.

Choosing wrong analogies are much worse than using no argument at all. An example that surfaced was when we were discussing about team building and how sports teams are built; someone then took the analogy to the extreme and said programmers are like sports people and they would not be productive beyond a physical age limit. The conversation ended abruptly as the story went in a wrong direction.

As a listener we also should try to do our part to not stretch the analogies for deep understanding, instead use it as a way to quickly get onboard to a new concept.

by on

During my college days I stumbled on a short story in a local magazine which changed my attitude towards work.

A wealthy person employs a few people for housekeeping. Of the staff two of them are of similar experience but one of them is the head of the staff and other is just part of the staff. This results in the senior staff member sulking about not given the right position and salary for the same years of experience as the head. So one fine day this person goes and confronts the boss and asks the reason for difference in positioning. At the same time they hear some noise and conversation from the street, so the boss sends that person to check what is happening. The person returns back saying someone is selling tomatoes for very cheap price, so the commotion.

The boss calls the head of staff and asks to check what is happening, after a while the head of staff returns back with a crate full of tomatoes saying this is too good a deal to miss it, we will make some ketchup for the season. Also the head of staff has struck a deal with the seller for bulk buying of vegetables during the surplus seasons so they can prepare a variety of food for lesser expense.

Why this story stuck in mind was, until that point I felt only technical skills matter and as an aspiring programmer I will be seen as the magician who can make the computer do what a business owner wants to do. It turned out that business and product owners are looking for options to keep reducing their need to make decisions and push that to people executing the work.

Many people have a wrong idea about optionality and will still place the burden of decision making on someone else by just exploring various options and presenting back for decisions. Optionality does not mean giving a lot of choices and asking to choose one, it is about keeping the end result in mind and getting into action so a lot of decisions can be deferred until it really matters. This may result in minor setback if the option does not work out but leads to major gains when it works.

by on

My career turned 18 last month. In this journey, learning is the only thing that keeps me fresh and wanting for more experience.

I joined Thoughtworks first in 2008. I came to know about Thoughtworks through the master class series and geek nights that used to happen in 2006-07 times and got inspired to join. When I applied, I was surprised by the depth of the interviews and until I got relevant experience I was not able to crack it. I got into Thoughtworks only on my 3rd try, coming back working on the feedback after every failed attempt. This feedback was not about gaining knowledge (which would have been easy) instead it was about gaining wisdom which is seldom achieved without having hands on experience. I am an avid learner, but it was the first time I moved from mere fact hoarder to a person with expertise on something.

I finally cracked the interview and my learning grew multi-fold when I started interacting with the growing office in Chennai but also felt that there was a plateau that gets hit soon in the learning and it was easy to get going with the flow. My aspiration was to represent Thoughtworks in forums like Agile India and XP conferences but I was not able to find a way to grow myself into that. 

Our place was never short of mentors and luminaries, it is when I reached out to one of the mentors for advice on career. What I got was a book to read and get back with the summary back to my mentor. The book was ‘Talent is overrated’. It drove a simple point into my head that, intelligence or being gifted is not as important as deliberate practice. Someone with sustained development day on day will overtake gifted individuals and prodigies.

Photo by Pixabay on Pexels.com

I was looking for ways of deliberate practice, it is when I did two things that stuck with me forever. One was to write a blog regularly. Not even a month goes by without blogging which I keep continuing. The other was to establish learning communities wherever I am present. I started the learning Thursdays series with a bunch of like minded people and kept it running on every Thursday without fail. We would not find speakers but one of us will always have a topic ready to run and make sure the fire does not die down. Once we picked up the momentum we formed a community event and invited outsiders, as a geeknight series making sure to run every month without fail. Both of these helped me and other presenters shape up their presenting skills. 

These exposures helped me to always be prepared for a few topics on XP, agile practices, clean code and I was able to present them in different forums. One of my topics Whistle Blowers was presented in XP 2013 which was one of the first ideas to take examples from biology and applying that for evolving quality code. All of a sudden I could see how things are inter-related and this made it easy to present any information to any person in an easy to consume form. This happens only when unrestricted learning and chunking happens. From a person who had stage fright, I became someone who can do impromptu sessions on any stage.

I always like to keep this fire of learning communities up and running, so when a new office in Mahadevapura, Bangalore was established; I created ‘Learning Thursdays’ and later ‘Friday Socials’ by getting like minded people again. This group evolved into an active one which is running geeknights and other Thoughtworks meetups in the office. Once we stop learning collectively, that is the day we start regressing as a community. So I keep making sure that learning happens not just at a personal level but at a collective level in some form or the other wherever I go.