About a week back was my last day at Tarka Labs. So many people have asked me why I have left a wonderful organization, this post is to gather and summarize my thought process...
A little about me, my name is Gaurav Agarwal. I was born 10019 days ago, as on the day of publishing this article, and I have no idea how many more are to come. I have an extremely blessed life and am thankful for all the stars that aligned to bring me to this world. I have found technology and business to be my calling ever since I was a child. Make no mistake, I wasn't a child prodigy in any way, just a curious soul - got my first computer at the age of 9, used it to experience video games and sometimes make presentations for school and for fun. I also ran small honest businesses since I was 11.
Some of my guiding principles to take on this new challenge and plunge into the unknown are:
Let me briefly, expand on each of these:
Let me first explain the concept of linear growth, in terms of money first...
You put in 'X' hours of time each week, you make 'Y' amount of money for each hour worked. You will have X*Y amount at the end of each week. This applies whether you are salaried, consultant or a trainer. You are trading time for money.
Once you stop working you make no more money. Of course you can increase 'Y' by certain percentages periodically using increments (raising your hourly rate as a consultant) or job changes. But you still can't generate revenue when you stop.
Investing is the first thing which comes to mind. It could be summarised in a tweet by Jon Yongfook (@yongfook).
A typical millionaire has around 7 sources of income.
— Jon Yongfook (@yongfook) September 24, 2018
1. Salary
2. Profit from business
3. Interest
4. Dividends
5. Rental income
6. Capital gains
7. Royalties
How diversified are you?
Everything other than salary falls into this category. Every other thing doesn't exactly require your attention for it to generate revenue for you.
Non-linear growth is not only about money, though. It can be extended into your learning and personal life as well.
It's about not putting all the pressure for your happiness and curiosity on one thing and one person. I will have only a special someone in my life forever, someone for whom I can strive to be better each day. But I can't expect them to come up with all the interesting conversations I would ever have for the rest of my life.
Growth in terms of learning means keeping your cup empty, taking life as it comes. I had strived to become super specialized in one or two things at one point of time, which isn't a bad thing. Personally, being a generalist programmer and natural curiosity makes me a learner. I dive into topics only when it's required, otherwise I know a thing or two about the things which are related to the current work at hand. For eg, I have programed in 12 different languages professionally. I was aware about the existence of those languages even before I would have ever had the opportunity to use them. I was familiar with the syntax and the general paradigm of the languages, except for one, Ruby, but that was only cause it was the first language I learnt right out of college. Which brings me to...
This is something which is a hit-or-miss when it comes to consulting or working in a traditional job. Sometimes all you want to do is solve interesting problems and then deal with the crud work. With consulting, being dependent on every client to bring interesting challenges all the time is delusional.
I find consulting > salaried job cause it gives me a greater freedom and flexibility it terms of saying no and walking away from a project which is going downhill. I especially lose interest when some false assumptions are made:
Like the mythical creature, these projects don't exist in the real world. No matter how detailed you go in your mock ups and interactions, you can't capture all of the edge cases and weird quirks of the user without actually building the product.
Deadline-driven development as defined in the linked article is self-explanatory. The main idea behind it is as a craftsman you tend to ship working products, products which you are proud of putting your name on. When all 3 dimensions (quality, cost or time, scope) of building a product are to be controlled for, it's usually quality which silently suffers, especially when there are...
I have been fortunate enough to work with Agile teams and get to see the power of feedback first hand. During the inception phase (requirements gathering phase - for readers familiar with waterfall model of development), some features seem too important to miss and yet others seem not so important. This is due to inherent human bias, we give importance to things based on their novelty, rather than usefulness.
That's how you get blockchain and ML being applied in every product out there when a simple version control or a complex control structure would do. I am in no way trying to downplay the usefulness of these technologies, see this cool demo.
To be able to build something useful, you either disrupt industries, where user feedback isn't useful until you have built the first iteration of the product, or you build a less disruptive MVVVP propping it up against the incumbents. See the story of Jio in India. The gist is they went ahead and launched a not so great service, gained customers and then worked through the issues to improve up to a stable enough modern 4G system. Which leads me to...
Perfection is a virtue only if applied to craftsmanship in moderation. Being embarrassed about what you have built is a common feeling among artists and makers. We hold ourselves to a higher standard than required while judging our work.
Anecdotally, it's only when I embrace my work with it's flaws and put it out in the world, will I ever get real feedback. This doesn't mean put things which are broken, that's a surefire way to lose credibility quickly.
What you need to do instead is build something which works, but isn't feature rich, can still be useful. Focus on providing value, versus building something perfect. Perfection can come as a result of polishing your work. After you grind away the rough edges and smoothen out the surface of your product. But even then, with software a final product is always a moving target.
Once the rubber hits the road, new use cases are discovered. Without observing how the software interacts with the user, we end up building a robotic solution which is only capable of interacting with other robotic systems. Treating humans as mere systems, and not as complex organisms with different tastes and sensibilities will lead to solutions which are way more complicated and unrealistic in their use cases than ever intended.1
We as a species for the first time in history have all the knowledge available to us at our finger tips, just a few taps away. We have never been this connected. Some of us, the lucky ones, even finding love through the medium of technology, others finding it easier to stay connected through the use of technology.
Software isn't just about building a product and making money out of it. Or building from mockups as is, see the cool demo above. When you build a system, which people interact with, complex use cases evolve which can't be anticipated. Any project or endeavor assuming no new use cases will be discovered or be found while building, unless it is an extremely bare minimum design, will fail.
As a generalist, building such software becomes easier when there is enough room to learn and evolve the system. After all, technology is best applied when it's augumented with human intelligence.2
Taking all these above points into consideration and keeping the ever-changing wide technological landscape in perspective, there is no reasonable way for one single human to stay relevant, alone!
We are social creatures not by design but through selection. We adapt and overcome challenges as a tribe and as a species. We get to enjoy this only through learning and sharing with each other.
When you are part of an organization, you don't seek out or even have as many opportunities to teach or learn when everyone seems to be at the same level. You tend to build this artificial bubble around you, and think only the people in your circle are competent. This creates a sense of isolation, an island of its own.
No man is an island and shouldn't strive to be one. I have learnt this over the years and began to imbibe it through my actions. Which brings me to...
I am not going to expand much on this topic. There is nothing new I would be talking about giving than what hasn't been said before. Charity begins at home, after all.
For me personally, giving is a form of releasing myself from all the debt, all the good things I have received throughout. I couldn't be happier without sharing my happiness with others.
I also realise giving at the expense of me time and personal time is risking too much. I need to be healthy and work on myself as much to be able to bring my best self.
By diversifying my experiences and varying them enough, I might make my 'Box of daily experience' rich and full of zeal.
Of course, novelty just for the sake of novelty isn't a worthwhile endeavour. I have been there done that, FOMO shouldn't be an issue. Neither the pursuit of a hedonist lifestyle.
Bring mithaibhai.com to life as a commercial entity in the next month or so... This is something which I have been intending to do since 2014.
Breathe life into 2 other projects and ideas I have been toying around with since the beginning of this year. One is codermana.com and the other being silkmon.com.
Build a way to make data from disparate sources easily accessible, there are multiple tools in this space. I would be building one focussed on the Indian Markets exclusively. This is something I had been intending to do since 2012. There is a hobbyist project out there, which is quite close to what I was intending to build and I would probably reach out and collaborate on building it.
Give my all to the personal relationships which matter the most to me. This will not be at the expense of work or vice versa, as has often been the case.
Figure out avenues, training programs, sessions both online and offline which can help in sharing and bringing forth the untapped potential locally.
Build several toy programs and games, like YAES and Chain Reaction, as completely open source, for the explicit purpose to learn and as a means to share my learning. Most of the development will be recorded and streamed, so that anyone wanting to hack on it together can join and talk about. This would serve 2 purposes, one to kill the aspect of isolation which would happen working alone; the second is being able to watch other people code along and think, has always been a great learning experience. I have always been a heavy proponent of Pair Programming.
Talks and presentations! Talk more and meet more people in the industry, you may never know who is excited about the same ideas as you. Rust, Go and FRP community in Chennai are still in infancy just like the languages, there is still a lot of room for them to grow.
And not just talk in terms of technical details but to cultivate a sense of craftsmanship and all the other related things to development. Building something is about 20% code and rest is deciphering the human aspects of it.
Build a network of like minded individuals for the sole purpose of being able to nerd it out and solve real world challenges. This world needs more people who can take action. I have been identifying more of such individuals over the course of 1 year, and it is only the beginning.
Figure out new things and challenges to solve. I am hoping this would arise naturally when I get deep down into the trenches.
Most importantly, being as honest, open and humble while doing all of the above stuff. There are no hidden agendas, no ulterior motives. Being as naked and vulnerable as possible, come what may!
I hope I will have positive things to report back at the end of these experiments. These are my thought process, promises, hopes and dreams for the next 2 years of my life. Please post your comments, questions and concerns in the comment section below or DM me on twitter (@algogrit). Thank you for reading!
Other links and references have been inlined to keep this section short.