[Music] of course we joke about it we meme about it it's a really hard reality of our lives but you

know we have gotten used to it we expect crazy regulatory changes at any given moment i say
that because that comes before technical skills of course you need talent and technical skills and
expertise to build you know systems you have to sit and write software they look at the peers and
suddenly you know that other organization has 50 people so we have to hire we need product
managers we need more developers we need more dedicated designers right but we need to
build a certain thing it needs to be able to handle let's say a million users whatever in that you
know context let's go serverless or let's pick this cloud that's that is that's very top-down thinking
yeah so it has to be rst principles you know and you know i've been getting annoyed and i've
been getting frustrated and that typically is inspiration to you know tinker and write something on
your own right so the unit conversions you know i could just write a simple bash script for myself
a lot of forces really altruism right some of the most valuable projects in the world that all of us
you know billions of people use are made by a handful of people who make it because they like
making it they struggle to make a living with you know with a di cult job and at the same time
they contribute their personal time and e ort into a fast project that they give out to the entire
world for free back then it was just me when we started zero that tech was just me and i was
sitting there i'd go sit with non-tech folks nd their problems you know write python scripts to
automate and at some point you know i had too many you know people got the taste of
automation it wasn't even tech it was automation and the stack has largely stayed the same it's
go python for stu postgres redis kafka nats and all performing what they do best our annual bill
is probably not even like an instagram campaign for many startups that's how low the bill is at the
end of the day no matter how sophisticated your ci cd system is it's a linux linux program that is
going to be killed or you know sig helped or restarted that's it hey welcome to yet another
episode of scale of pod and uh today we have uh someone with us uh that has been very fairly
demanded from every episode we have shot until now people have commented that uh please
bring dr kailash nathan episode so we have him today thank you so much for taking out your time
thank you right um so we will of course uh have a lot of things to talk about i would de nitely start
o with my pet question that i've been doing for every episode is like what does a day in your life
look like and then mostly in context of work and i've gotten very di erent answers so i'd love to uh
yeah rstly again thanks thanks for having me here hearing dr kerashnaz is a little awkward you
could just call me here i know i won't do that anymore but that's like i've seen like nathan post like
dr k every time and i really like that yeah that's that's my nickname so uh how it day looks it has
changed drastically over the last few years and there have been distinct faces but what has been
constant here and maybe a little peculiar in our industry is the regulatory weight and you wake up
you have certain plans for the day could be writing software it could be you know certain
meetings the meeting to gure out technical non-technical decisions suddenly there could be this
regulatory thunderbolt that completely changes uh your day and the subsequent 30 days where
you have to pass absolutely everything so that's really a reality of life and over the last couple of
years there have been crazy number of regulatory changes in the industry all for the better but
really di cult ones so days are really unpredictable you know you get on with a certain project
that you've been working on and suddenly you have to pause suspend absolutely everything and
re ght uh for the next several days so there's been a lot of that lately right right and and on a
more personal note like apart from like everything that's happening in zero then everything do you
get time on a regular basis to sort of tinker around with things i've seen of course a lot of your
open source projects like does that happen in pockets of time do you try to schedule some time
for that scheduling is impossible but i nd i try to nd time regularly uh late evenings largely and
mostly you know full weekends so i dedicate a lot of time i i feel if i don't do that i'll start maybe
getting bored of things in general so for me nding time for hobby is is a necessity and of course i
you know enjoy it it's a win-win but yes very regularly right uh another question around that was
very interesting i've had a lot of answers from quite a few folks is about like when you are
managing a team and you know uh been doing it for a while uh sort of the importance of uh
writing code and i've gotten fairly di erent answers from people as well so what is it for you like
you know how much is it just hobby how much do you think you really need to do that to stay
abreast of things staying abreast of things as a speci c goal is something that i don't really think
about because i write code on a regular basis anyway so i never had to i was i've never been at a
point where i think back and think that oh i'm maybe losing touch but that said that's absolutely
necessary unfortunately we get to see especially in our industry you know heavily regulated
capital markets industry lots of people who completely lost touch with technology in general
making very technical decisions and often wrong ones so i think that is very necessary right but
because uh i regularly write software just like you know all of us in our tech team it hasn't really
fi
ff
fi
fi
ffi
ff
fi
fi
ff
fi
ff
fi
fi
fi
fi
ffi
ff
fi
been a thought and why do i write it i mean i like it uh if of course if i couldn't write software i
wouldn't be you know doing whatever i'm doing right um so i have a question around because
you're saying about like regulatory uh you know nightmares and that happened and i think it's
fairly discussed in terms of like uh say a business impact or like sometimes whole ntech
companies piloting because of that yeah i obviously want to you know use this opportunity to also
delve a little bit into how does it impact uh like a tech team working on something for example i
mean i'm a regular user of zero that's my trading platform and uh i think you have to directly pay
for mutual funds now i think a couple of months back yeah yeah it sort of changed because i just
love my funds in one place stocks and mfs in the same place yeah now i have to do that upi thing
yeah um so when something like that just suddenly drops yeah right and i guess you don't really
get a lot of forewarning or something around stu like that usually right yeah so when something
like that drops like uh from a tech perspective like what are your usually next steps like maybe a
well-oiled machine everything is going on and suddenly you have to cater to this so thankfully i
think one of the things that we cracked early on as a team was handling scenarios like this if we
didn't have a very speci c and rather sane framework for handling these regulatory scenarios i
think we'd have found it extremely hard to cope with like the huge number of changes that we've
seen over the last many years and if a tech team is constantly pressurized and burdened with
making regulatory changes scrapping systems you've built just because regulations change if you
don't truly internalize and accept that that is the reality of life in the industry it's very di cult to
survive so thankfully very very early on like almost a decade ago we kind of realized this and how
we build software you know architectural decisions software decisions business slash product
feature decisions all of that is heavily based on this regulatory framework so one of the exercises
that we do is to try and foresee what could you know common sense uh changes you know that
oh it works a certain way but there's a high probability that three years from now you know it
might change because of regulations so that foresight as an exercise we try to incorporate into all
our software decisions even things that even writing modules for certain software you kind of you
know expect that ah this might have to be scrapped so when you do that uh and all your decision
making in any business idea any product any you know software architecture when it all
incorporates these tiny things these this form of decision making over time it kind of puts you in a
place where things aren't as hard yes you still have to scrap systems but you foresaw that anyway
and if you get 80 of that right right i mean of course it's super annoying having to delete
everything stop everything but it's not impossible we could have been once you get to a certain
scale and you know risk increases it would have been extremely risky to just scrap things if things
were not built to be scrapped so everyone in the team you know of course we joke about it we
meme about it it's a really hard reality of our lives but you know we have gotten used to it we
expect crazy regulatory changes at any given moment and thankfully our systems and processes
are 80 percent always ready to be tweaked and scrapped so we cope with it but it's been a it's
been a long exercise of thinking like that you know long time in the making and we got really lucky
that we wired ourselves to accept that makes sense uh i i have a uh you know a question about
also sort of the product uh philosophy yeah uh especially in zero that's context and i uh thought
of if i ever get somebody to talk to at zero then ask about this because uh for example every day
like there are hours during the night when some of the functionality in on the app and all stop right
and it's a philosophical decision i believe because somebody can build a product not having
those things in place like how did it come to be i just really want to have a you know broader
perspective around how did it come to be like why do you have maintenance time every day as a
ux it does not a ect me i'm very ne because 2 am at night i'm not trading stu but it does
happen so how did it come to be like that it's not a philosophical decision you know we are
forced to have uh maintenance windows not just us it's basically the norm in the industry okay
and uh back in the day it would be like a seven hour you know uh down time where all systems go
down and you know lots of stu happens but today we've brought it down to let's say an hour an
hour and a half so why it happens is that this industry is uh eod end of the day end of the day it's
settlements and all correct so this entire industry base runs on end of the day settlements all the
real-time trades that you do investments that you do throughout the day yeah they are real-time
that them being real-time is kind of an illusion the actual settlement only happens at the end of the
day right so for us if we process let's say 10 10 15 million orders in a day we get 15 million orders
worth of data dumps from the exchange on on a volatile day that can be delayed so you get uh
data from many di erent sources you know like dozens of massive dumps at the end of the day
you have to crunch everything you have to do settlements you have to recon gure users accounts
you know balances cetera you have to send copies of the results to many di erent institutions
exchanges deposits trees etc so that these are really long and complex processes right there
ff
ff
fi
ff
fi
ff
ff
fi
ff
fi
ffi
 could be you could have six data dumps that you were waiting for but the seventh one could be
randomly two hours late right so when these processes are happening and these are really uh
complex processes and we've put in humongous amounts of work to you know bring them down
for from 20 hours to eight hours to four hours to let's say 20 minutes just last week we rewrote our
entire contract note you get that pdf at the end of the day process right yeah yeah so that had
over time this is i think the fth rewrite in the last seven years okay so with this new rewrite
everything is done in 20 minutes including you know pushing out let's say a million emails but
while these things are happening the state that you see on your trading platform that's already
stale but once the new states are computed new balances new positions new results new
everything they have to be loaded into all these systems now just processing itself could involve
let's say you know uh recomputing 100 billion rows of nancial records you know historical prices
yeah yeah so all of this has to happen and the new states have to be loaded onto the trading
platform so we've made it so that while all of these things are happening you can still access
everything but the loading process the sheer volume and size of data that has to be refreshed the
new states that take some time right and like i said we've brought that window down to let's say
an hour and it's it's an unfortunate it's an unfortunate side e ect of the nature of end of the day
settlements and if you haven't put in huge amounts of engineering e ort it'll be hours and hours
and you'd be down for let's say eight hours throughout the night but yeah it's not a philosophical
decision we are forced to force by yeah that kind of uh situation and and it's an ongoing exercise
to bring that window you know uh down as much as possible continuously got it got it got it uh
makes a lot of sense now uh so uh hearing about of course like uh the process that goes behind
like you're saying you know millions of trades happening every day yeah you know and then
reconciling all of that data and then this is obviously a question about uh like how do you
achieving all of this with a small team lines it's a question that keeps coming a lot of places i've
seen i've seen i think once you replied on a reddit thread about that yeah we are really just 30
people yeah i i've known a few of people in your team from some time back so i really know that it
is 30 people for the audience you know you're not faking it but uh i mean it's it's uh very uh
common for a lot of people in the industry to early stage career places their work they have
probably seen uh like pretty big tech teams yeah and and maybe the uh you know the perspective
that it gives a lot of people is that okay uh moving around this amount of data millions of users it's
probably just not something we can even achieve with less than 300 engineers or something uh
right uh so i'd love to uh you know get uh you know your perspectives around like of course at
zero the how is it being achieved with so uh less people and i love that you had a point there that
this should be the norm for a lot of industries as well um so yeah how is it possible where are the
places where it can be possible it's rstly it's very di cult to answer uh so the question typically
comes top down how can you do all of this with let's say 30 people yes but we never set out to
do any of this with any number of people we started out really small and things just happened to
be so it's very important to go uh from the bottom up when looking at this exactly that that you
know so there's no formula for replicating tomorrow let's say you want to build a product like
xeroda but maybe that something that only happens one uh one tenth of the scale now could you
do that with ve people or ten people or fty people it's impossible to say or no so it's literally a
function of the time that we've put in and how the team has come to be now uh as i said earlier
everyone in the team has a certain way of thinking you know that regulatory framework the
framework of risk that we operate and we really understand right now if you were constantly burnt
out by that and if you were unable to collaborate a 30 member team could never build any of this
so the key is that we gel really well with each other you know we know how to have fun we know
how to you know work around our mistakes and laugh about our mistakes and also laugh at our
successes so i think the way the team has evolved over the last nine plus years uh to this tight-
knit gang plays probably the most important role in this outcome how how a 30 member team can
build stu uh or you know large scale stu they have to work really really well with each other i
say that because that comes before technical skills now of course you need talent and technical
skills and expertise to build you know systems you have to sit and write software right but if you
had a bunch of people who were exceptionally technically skilled but who couldn't work with each
other especially in a in an environment like this heavily regulated you know the team would fall
apart fall apart in no time right and so that really is key how we've stuck to our principles how
we've been grounded since day one when we had 5000 users let's say in 2013 to today you know
10 plus million users we are our attitudes have not changed you know we stick together we
collaborate well we write software scrap software rewrite software for the sixth time we have fun
and uh that also means that the decisions are objective and technical the moment you have let's
say tech versus management divide yeah i think it's impossible i mean it doesn't matter if you
ff
fi
fi
fi
fi
ff
ffi
fi
ff
ff
 have 30 people 40 people 100 people i mean it would be very very di cult right for people to stick
together they have to be in an environment that they are comfortable in especially you know
technical folks who are creative and writing software is not only scienti c it's also a creative
endeavor so again you'd see that there's no formula here it's really about people and how people
work with each other and thankfully again from the very very beginning at zeroda we we haven't
had the technical versus management divide as in you know you suddenly get email requirements
from the management no questions asked and you're supposed to build it you'll never be able to
build quality software uh with solid philosophies and rational if that's how it functioned where
someone sent you a requirement you had no idea why and you were forced to do it right so from
the very beginning we we've been conscious of that and that uh tech how the tech team works
with non-tech teams it's been philosophical and it's been very collaborative everyone sits down
together so anyone could bring up an idea propose an idea people can shoot it down people are
free to shoot ideas down in fact probably 95 percent of all ideas that we've proposed have been
shot down objectively and tech in non-tech teams they they know you know we have the right
culture where people respect such objective decisions right so that also has meant that people
with deep nancial domain knowledge mostly non-tech folks now today tech folks also
understand lots of you know with nancial bits but in the early days it was all the domain
knowledge were with the nance folks but because we were able to work hand in hand it was
possible to bring that deep nancial knowledge and create and the creative endeavor of endeavor
of writing software for nance together people sat together all of us have always sat together on
the same oor you just walk up have a discussion decision you know debate decide right so it's
it's really that it's really that culture that has enabled us to build whatever we built with just 30
people and it just happened to be and of course skills and the right kind of technical decisions are
absolutely necessary wrong decisions could be disastrous so of course there's that too we put in
humongous amounts of engineering e ort and r d e ort right but going back to that number how
can such a small team achieve something like this absolutely how the team works with each other
it's the culture and philosophies makes sense yeah uh so i mean uh and this is a i think a
discussion around like what sort of the team size you need to achieve something and i've had
with other folks as well in the past and i remember actually early days when i used to run a startup
and we had like three full-time engineers and a couple of interns and uh there was a time i had
come to a conference in bangalore and there were some other tech founders and we were talking
about and then they said like you know what kind of numbers and all you're doing and i say that
okay you know maybe one or two million uh a year we are doing in revenues we have some you
know probably free users we have about uh you know half a million of them some 10 20 000 paid
users at this scale how are you running with four engineers and uh i think i mean i i just uh asked
him the counter question is like you know okay he was doing probably in revenues a little less i'm
like okay ne that's uh regardless of that but your systems look very similar to me yeah there's
some video being played there's some notes people are writing some questions being sold mcqs
and also educational system very similar yeah you do have like 30 people in the team like why do
you have that i mean that's also a question because uh i did not form a team thinking to before
people i never needed more than that yeah and you were saying uh we uh had this idea then we
raised some funding then we thought okay to build this we will need 30 people so i think the uh
thinking comes from okay to build these 10 things we will need 30 people that's the reason he
had 30 people rather than uh probably starting to build it and see where it goes yeah maybe that
does play a bit of a i think uh because there are enough examples of uh things built at a very big
scale both in terms of features that are there users that are there and you had a team of maybe 10
people 20 people i mean whatsapp was very famous for that when they got acquired they had
something 19 people or so and people started 1 billion people working on that app how is it
possible that's right but i really like that piece of the answer which is like you have to sit down
with the i mean non-tech rather than talking about it in those terms like have somebody with
domain expertise and understand what they want solve that problem together yeah um and it still
is like that you're saying absolutely nothing has absolutely nothing has changed we still debate
ideas sometimes debates go on for days and ideas are always shot down anybody's free to
propose an idea so you have to if you feel that any idea that you raise will be immediately shot
down by the management i don't think you'll be at your creative best in such an environment so
it's it's ingrained in the culture that anybody can propose any anything anybody can question
anything and the outcomes have to be objective you know we can we could have a really tight
decision but you know you write down bullet points on the left left side and right side and
whatever weighs slightly more that's the objective decision and that has in hindsight worked really
well for us and to go back to the anecdote you just shared i really don't know how that works i
fi
fl
fi
fi
fi
fi
fi
ff
ff
ffi
fi
 don't know how it's possible to reduce humans uh humans who are especially creative let's say
software developers or you know product folks how you can reduce them to units and say that
this particular piece of software requires uh six human units or 30 human units i i really don't
understand how that works and i've never seen that example play out really well that approach
sorry play out really well anywhere so when when and i think there's a huge this is huge
component of fomo there uh let's say you have a product that is becoming bigger growing and
you receive funding and you have three engineers i mean people will ask questions how can you
build you know what are we applying to build with three engineers so you start doubting yourself
and i've seen this quite a bit even in really young startups who are just maybe a year or two too
old they look at the peers and suddenly you know that other organization has 50 people so we
have to hire we need product managers we need more developers we need more dedicated
designers right so a lot of external factors in uence decision making and how to build tech teams
and you end up with massive teams where everyone's a little lost yeah there's a little bit of
manufactured complexity also in your systems because conveys obviously due to e ect there as
well absolutely absolutely because if you have let's say 50 people they have to do something right
so you automatically implicitly and subconsciously start creating you know complicating your
architecture complicating your design to give everyone enough work so it's a vicious cycle and it
just keeps on getting worse the more complex it becomes the more people you need and beyond
a certain number of uh people you have to now have other people who manage communication
and results and all and suddenly you get really rigid hierarchies and you keep on growing so once
you grow you have to keep on growing so and and as i said i've never seen a successful example
of someone saying this particular piece of software needs ex-human units and it working out
exactly like that you can't you can't it's like you said it's possible for 20 people to build a
whatsapp uh that can handle billions of users it's possible for 2000 people to build terrible let's
say no net banking applications that don't work so yeah um on that case uh because he talked
about that uh tech and business thing and then um jacob was here on the episodes of scale apart
and he was talking about uh an anecdote where um the vcs had an interview with the ceo and the
cto and then they were like very impressed that you know how how did both of you have the
same answers as to what you want to do in the next ve years and then and jacob uh say this uh
part which i had in the teaser of that episode as well right absolutely completely totally hate the
word the business i mean the tech is the business you know the same thing and business are not
separate things but but that's it the the this divide whether it's in minds of people or it's actually
there it does exist in a lot of uh places right um and then our audience being like the you know the
engineers and the tech people um so my question is uh like as an engineer and you're growing
you started building things you know hacking around maybe you've joined a company you're
working on things uh how do you also sort of gather more perspective about the business how do
you not think of okay this is what i was told to build i don't know what how it is going to be used
and that kind of sometimes mindset can percolate if you are in a environment where you have a
tech versus business thing yeah but i think part of the bonus is also with the engineers too uh
because it's a bridge and everybody has to come to the middle yeah so at a more philosophical
level when somebody's growing as an engineer how do you go about making sure that you go at
least to the center of the bridge for the tech versus business divide so i think uh i think it's di cult
honestly for young engineers folks who are just starting out it's very di cult because their
worldview hasn't formed they don't know that they have an opinion and in many organizations
engineers unfortunately have no voice or opinion and even in you know tech companies right so i
think the burden the weight really lies with the management in culture in an organization you know
it has to come from top down right and no matter how hard engineers try engineers cannot really
create an engineering culture if the management isn't up for it if they are not in on it so if to have
to cross a bridge there has to be a bridge yeah and it's very di cult in an organization that
doesn't really have the right culture of collaboration between tech and non-tech folks it's very
di cult to build that bridge you you have entire managerial frameworks you know this whole
requirements thing where requirements come in you're supposed to build it nancial let's say in a
nancial company nancial decisions are made by someone sitting somewhere there's no
rationale you get a thing saying oh add this button at this report prd yeah yeah and you're
supposed to just do it yeah and you're supposed to report to your manager now if there's no
culture that has been established by the management themselves it's impossible for engineers to
even attempt to cross the bridge because that bridge has to be built and sustained by the
management if the management is open i mean people will immediately people who are willing to
contribute will naturally immediately gure out that oh it is possible to have a dialogue right and
it's just that and most in many organizations unfortunately where there's this tech versus non-tech
fi
ffi
fi
fi
fl
fi
ffi
ffi
fi
ff
ffi
 divide there's no dialogue you get you know you get requirements you build you don't even know
why you're building it could be wrong it could it could weigh negatively on the software
architecture but why would a non-managed non-tech management care about software
architecture right so it has to be top down it has to be the culture has to be established by the
management makes sense uh here and then i will play a bit of a devil's advocate here and it's
probably the question is not coming from perspective that is uh personal but uh uh say speaking
on behalf of let's say a non-tech and a you know business oriented founder let's say yeah um and
then we talked about it when we met at force india as well so it's uh why should we invest in an
engineering rst culture let's just say somebody says that okay i have a bunch of requirements if
the tech team just builds it i will go ahead and keep building my team ahead and you know yeah i
don't need an engineering culture to exist in my team yeah and fortunately unfortunately wherever
you put it but i have seen this sort of dialogue also from people right right and then i think that the
result of that is like a lot of times people very passionate and very highly motivated engineers get
into a company which like from the outside looks like doing great business but they're like you
know we just left a year later because we did not feel like having a good engineering culture yeah
so i mean before coming to i think the engineering culture and hacker and open space i will talk
about that as well but yeah what's the uh you know need even for building an engineering culture
uh you would say i think you touched upon it uh a little while ago where you know this whole tech
versus non-tech thing i think that line is now blurring so if you remember there used to be tech
enabled businesses it used to be a thing correct but today everyone is kind of a tech business
even companies that run on excel sheets you know are kind of digital tech businesses and we
have this entire category of terms like food tech i know travel tech you know ntech whatever
these were all uh tech enabled businesses where business was nanced like zeroth for example
you know zeroth primary business is nancial services right so uh maybe eight nine years ago
zero that would be looked upon as a com as an organization that o ers some technology as a
means merely as a means to provide nancial services right but today it's completely changed
you know people see zeruda as a technology provider not just a nancial services provider so has
turned into an engineering tech company right and so it's it's a way of looking at that if you
consider that your business just needs tech as one of the small little pieces to run the business of
many other pieces then it's very di cult to have an engineering culture there are if an organization
if a certain business relies heavily on technology and even if it's let's say nancial services or food
services or agriculture or whatever but if engineering and technology are a core proposition of the
business and that requires self-awareness you can always compartmentalize saying oh there's
this tech team they'll build whatever we want but our business is nance my it team exactly my id
so but we are nancial folks we only do nance and you know tech is just a means so if you look
at the business from that perspective sorry as i mentioned it's very di cult to establish an
engineering culture because it's just one of the necessary evils right but as i said the lines of
blurred music has become a technology company from a pure nancial company so there are the
o ers technology plus nancial services now and that is that has that transformation has played a
key role in zero da and maybe reinventing or re-establishing itself as a di erent kind of a player
over the last you know let's say half decade now if that wasn't the case maybe zero would be an
entirely di erent kind of company which o ered some nancial services but you know there
wasn't uh i know scale or growth or whatever in in today's terms so what is the necessity here if a
certain business uh if technology and engineering is core to a certain business and realizing that it
is or whether it is or whether it is not it's really the rst big leap makes sense so if it is core you
need to have uh that becomes the core proposition of your business going forward that de nes
your future and it becomes imperative to have a good technology team and what exactly is a
good technology team team with people who are happy doing what they're doing and i mean
content not super happy maybe but you know people who don't hate what they're doing correct
and and again technology as it grows as complexity grows you can't just have you know you
can't just get two developers and get them to x certain things build new things you know chuck
them out get to people it's an ongoing like a very long-term underwear right the developers who
build software that software enters their mind space and it lives in their heads yeah and any knob
that you need to tweak the correct way you know quickly x a certain thing or quickly scrap a
certain thing build new features it's all in their heads yeah it's just like a completely imagined
spaceship kind of thing you have in your head you know the live parts it is some sort of a diagram
in your head not sometimes not even easier to visualize but absolutely so it's not like a
commodity where let's say you have a mixer grinder that breaks down you can take it to any
mechanic and because it's a commodity it's so simple it's trivial they can all x it but complex
software it needs people who built that software with deep understanding of its nuances and the
ff
ff
fi
fi
fi
ffi
fi
fi
fi
ff
fi
fi
fi
fi
fi
fi
fi
fi
ff
ffi
ff
fi
fi
fi
fi
 million decisions that have been taken over the years to operate it right now all of that those
things lives in the minds of in your engineers and product folks and if their minds are not happy
and they're churning and you know your engineering team is constantly losing people new people
coming out of course that is going to re ect immediately physically and heavily negatively on your
software you'll have poorly built software you'll end up with legacy software nobody can rewrite
like the legacy software overnight and all the people who liked it built it they've gone because you
don't really have an engineering culture so from a maybe a transactional perspective i'm not a fan
of this perspective but from a purely transactional perspective a sel sh perspective for a business
if a business is going to rely on tech if tech is tech and engineering are going to be core to it and if
they don't cultivate an engineering uh culture i mean it's going to be disastrous for them we can
yeah we can just we just have to look around us massive organizations with unlimited resources
legacy organizations who produce terrible software who are struggling today right and the nance
industry you know has so many great examples right it's all because of that they refused to
accept that technology was core to them they you know they ended up keeping it as just one of
those things that has to be serviced and there's no tech talent why would people want to work in
why would creative people who like creative endeavors want to work in an environment where
there's no creativity it's just a means to you know delivering certain kinds of business right right
so absolutely imperative for businesses uh to do this if they really want to survive yeah yeah uh
and there's bringing to another question of course because we were talking about engineering
culture right um what in your opinion is a good engineering culture also i'd love to love to ask
because like if you walk into a tech team and like what do you expect to see which would make
you say that okay this team has great engineering culture and i say that from perspective of let's
say somebody wants to join some company how do they decide whether this place has great
engineering culture or not uh that's also a tricky one culture is very subjective what culturally
works for let's say zeruda may not work for a di erent environment fair enough so it's highly
subjective right and that really is the very de nition of culture right it's an amalgamation of things
that change exactly accumulated with things which are appropriate for a certain environment right
so as i said our culture heavily is built around understanding and accepting the risk in the
business in a non-risky environment the culture would be completely di erent but there are
certain principles that are common rstly people have to be chill with each other irrespective of
you know people have to have uh people have to be able to make fun of each other without
reservations uh people you know nobody nothing is sacrosanct right we have in our team we have
memes about everyone there are new memes that are made every day i think there are like six or
seven di erent smileys in very non- attering poses of my face and each smiley you know denotes
a di erent kind of you know situation yeah so there's all of that and that's just a tiny part of uh the
overall facet which is you know people have to be able to gel well with each other yeah that's one
thing and secondly what i would de nitely weigh uh sorry give heavy weightage to is how people
operate how systems are designed whether they are from rst principles or not so that is also a
part of culture that thinking that we need to build a certain thing it needs to be able to handle let's
say a million users whatever in that you know context uh let's go serverless or let's pick this cloud
that's that is that's very top-down thinking yeah so it has to be rst principles you know what are
these million users do they even need this certain feature so should we even bother building it so
it has to always start from uh from the absolute bottom from complete from rst principles so how
a team makes engineering decisions architectural decisions that are going to be with them for the
next decade you know that will de ne their very survival that comes from rst principles thinking
and teams that get together and collaborate on rst principles tend to i think tend again tend to
gel well with each other because you know there's no reservations you're free to shoot down
things objectively saying oh no that's not a good idea because you know abcd is wrong that's
only possible when the thinking is from rst principle when the you know when what it's bottoms
up so it's really that the people should be able to gel well with each other and technical business
and engineering decisions within that team should be objective and should be from rst principles
i think these are kind of two hallmarks of good engineering culture and of course lots of things
change it's subjective but these are you know largely universal i think makes sense i think i
de nitely relate to that point about breaking down the barriers and the memes and all because i
have uh at one point of time worked in a much larger company with a hierarchical setup and there
are people in my team much older than me so to even write a code review and saying that
something objectively i just have it's the review on the code not on the person right yeah you still
have to see the manager because okay that person might get o ended and then obviously it's not
it's not a great environment to be able to uh discuss the you know technical merits of something if
those barriers exist in the rst place yeah for sure uh about the uh no uh other partner spelled uh
fi
ff
ff
fi
fi
fl
fi
fi
fl
fi
fi
ff
fi
fi
fi
ff
fi
ff
fi
fi
fi
fi
 right rst principles thinking now um for rst uh and i will actually of course like you said
serverless there are very concrete examples of using say uh you know nosql dbs and very
interesting blog articles that you had written about how you have been scaling postgres at uh
there right and again i i see because teaching so i see a lot of people uh youngsters and maybe a
little disadvantage being mongodb is a company um right and then not to throw shade on them i
mean there's de nitely good use cases of that uh but but of course if it gets marketed a lot versus
something like you know using uh mysql of postgres there's nobody to market that's an open
source project uh solvently people develop a habit of say building a lot of projects and of course if
a particular tool has way too many libraries available easy to quickly use people can sort of get
into it uh and maybe that's also a great way to start that's ne but as you grow as an engineer
how do you sort of keep yourself grounded to the rst principles if you could have a word of
advice around that i think it's about self-awareness and awareness in general yeah so somebody
who starts out young and let's say their foundation are no no sqldbs like you said nothing wrong
with them they have their use cases and they've never been able to work with relational
databases how do you even know what you don't know now that's a big trap how do you know
that you may be wrong so it's very di cult and if you fall into that trap of you know it's always
buying into hype you wouldn't even know that you know you're wrong maybe right so it's it's very
important to have hands-on experience on a wide variety of engineering you know topics and
aspects there's literally no other way if you've never built a new and a relational a system that
uses relational databases you wouldn't even know you can't even make that decision so it's very
important to work on as many hands-on projects as possible but how do you know that you have
to work on maybe somebody has to i know tell maybe somebody has to mentor or guide but that
starting point just that just growing that awareness that's it once you have that awareness then
like a billion resources on the internet you can learn whatever you want you can build whatever
you want but it's just that starting point people have to know that what we know uh may not there
there there are huge number of things outside of what we know what our narrow focus all the time
just that realization and self-awareness that that's what's most critical right and that's the starting
point so i don't really have any solutions on how someone can gain that but like i said maybe
maybe it's accidental uh maybe it's just you know people feel that or maybe they need some
handholding got it got it uh around that i think uh and then uh we talked about like uh what are the
things we would uh want to talk about here and you said about like you know building projects
versus uh products kind of thing and i really uh you know what what uh youngsters say vibed with
that because uh when i uh teach some classes and you know after teachings let's say concepts
of okay how to build an api how to build a you know orm and all of that okay now go ahead and
build a project yeah and one of the largest feedbacks i think probably 70 of people come back
and say i spent a couple of days could not come up with an idea yeah to build something yeah
and then and it sometimes feels very uh it doesn't work like hey you know you don't really have to
come with an idea that's unique enough or not like however just build a blogging app or
something like that build a calculator maybe but yeah just go ahead and build yeah right uh i
mean you have also obviously seen a lot of engineers grow via this you know uh tinkering culture
and you yourself call yourself a tinkerest so uh how much this is important and you know why is it
important for people to develop this you would say i think it's paramount it's probably one of the
most critical things required to be a good engineer and and to be able to learn uh what we were
just discussing prior if you don't know what you don't know how do you even get started yeah
and building things hands-on breaking things getting experience realizing that oh i can do this or i
can't do this it's a it's a it's the single biggest step unless you write software hands-on you can't
learn you know you can read resources watch podcasts and videos for forever for years you'll
never be able to produce you know decent software but if you start writing software and produce
bad software and improve it and the very act of writing software and producing bad software
you're automatically improving you know that tiny badness you can you know you'll x it and you
would have learned something so nothing absolutely nothing beats that and all engineers in the
world who are good they're all self-taught so so it's basically it's basically that the act of writing
software hands-on is the single biggest requirement to being uh to being a good engineer right
right right yeah uh i would like to take an example there i mean uh and i just uh recently checked
out when you're published dns.toys uh and and uh i was having a discussion with my friend
saman and he's uh he's a engineer at a big tech company and he was like i just loved it because i
opened the github repository and i look at the code and i see okay no 20 di erent classes or
something it's just you know whatever we need to get it done the the code inside each function
looks very clear and concise but everything is in one single le that's ne i i'd like to you know
probably like go a little uh deeper into like how did that idea come to your mind like why playing
fi
fi
ffi
fi
fi
fi
fi
fi
ff
fi
 around with the dns protocol to like give answers like time zones and everything so that the
answer to that also answers your previous question like you said sometimes students come up
and say i don't know what to build that's actually a very legitimate problem it's like a writer's
block you can't come up with unique ideas every day and sometimes you look for many many
years to you really have the drive to build something but you don't know what to build right and
you can't bring yourself to building let's say you know trivial things you want something new or
unique but if you look at uh most hobby projects out there most foss they've all largely they're all
largely born out of real world problems that people faced or frustration like most of my open
source projects that i've published i've stumbled upon them not because i was looking for certain
ideas i had a certain problem i encountered a problem i built software to solve that problem then i
realized oh this can be extended given out to others you pick any large or small open source
software out there it's largely it largely the genesis would have been basically that you know
people facing a certain problem and then trying to solve that so yes to experiment i'm sorry i'm
still trying to try answering your previous questions uh that that that urge to tinker has to be there
but if you go looking for ideas it's you know you're probably setting yourself up for
disappointment but when you come across a problem you have to jump on it and you know write
some software you know tinker yeah so dns toys is an ex is a great example uh for that i had no i
had no vision to write any you know dns related things but uh i found i i nd myself entering
random queries into google every day you know unit conversions or whatever and over a period
of time i've seen that from simple you know expression matching you know 10 gb to 5 mb yeah
it's a simple you know string passing thing i don't know google's overly sophisticated technology
and maybe machine learning models you know you don't it's very sometimes it's di cult to get
answers to those straightforward questions also you get absurd answers you know it just goes as
a query and the you know result doesn't show up especially speci cally with unit conversion or
you know simple one-line queries to which you really quickly need answers and you know i've
been getting annoyed and i've been getting frustrated and that typically is inspiration to you know
tinker and write something on your own right so unit conversions you know i could just uh write a
simple bash script for myself yeah but you know that wouldn't be as much fun so then i gured
maybe you know it could be a service online where i can just quickly get an answer to some of
these commonly common queries that i raise every day on the terminal now that could be you
know an http service you could query it with girl but girl it just didn't you know just seemed a little
inadequate and then i randomly had that had this thought i don't know what had primed me to
dns i mean dig is everywhere dns is a product it's a super super simple protocol it's universal it's
ancient it's raw it's so beautiful right you send a query you get an answer udp and it's just so
good yeah then i thought you know why can't i abuse that it's raw it's you know more rst
principles than let's say curl because atp is a you know yeah more complex protocol compared to
dns so i thought you know someone would have done it someone would have abused dns of
course people abused dns for everything yeah yeah but then i saw that nobody had abused dns
to get queries to answers and it makes perfect sense you send a dns query the whole system is
around the concepts of sending a question and getting answers like why not you know add this
unit conversion thing to that then i was like oh i also you know tend to check weather every day
you know bangalore temperature bangalore weather we always google that and you know why
not add a weather service then i thought oh there are these other things sometimes you know you
get a really big number uh let's say 10 or 11 digit number and you know i nd it hard to mentally
pass you know i have to count decimals yeah so you know i google you know numbers to english
words or whatever land on some random website paste that so that's also a query that i
frequently need answered so why not add that so i added a bunch of things and suddenly i had a
dns server that could answer some of these queries and it was universal like you know just that
it's purity the protocol's purity was very attractive yeah so i made it you know i then of course if
you're typing it every day it has to have a really short domain name if i have dns answers and
questions.com that'd be that de es the point so i looked for a domain and found dns.toys so i can
just say bangalore.weather dig bangalore.weather at dnstoys and i get the answer yeah and that
really satis ed you know that urge it scratched my itch yeah of course i i turned it into a website
published the repository and you know it became an open source project right right but that's
really the genesis of many you know hobby projects that it's that one problem that you want
solved it's it bugs you annoys you that itch you want scratched and just because you know you're
an engineer you know when you can do dns why do http yeah so all of those things put together
you know hobby project is born right right right actually that reminds me of something very similar
i had done this story feels so familiar because uh so i it was uh you know just before the
pandemic time and i was doing a few consulting with some people who were outside india
fi
fi
fi
fi
fi
ffi
fi
fi
 di erent places yeah and you know we'll meet at 1 pm okay who's 1 pm or 1 pm 1 my 1 pm all of
that stu then i used to you know uh start guring out that uh also the calendar software
everybody uses does not necessarily always match like google is still probably 90 but somebody
using outlook so you make an event in outlook send it to google sometimes the because of dst
and everything something happens uh and i had gone to a hackathon we had sponsored and i
was there just mentoring some people then at night there was nothing to do and uh at that time i
was learning view as a front-end framework and uh it just uh clicked my mind that hey just using
the routing uh the you know hash parameters and everything uh so i found this the domain name
available sharetime.in send me the sharetime dot in uh slash ist slash 1700 if you write you can
share this url to anybody if they open it in their own time zone it just picks the time zone from the
computer and says ist 5 pm is 10 am at your time zone yeah yeah so it's like the url is very easy to
share because share time in yeah tell the time zone yeah yeah uh but i think the beauty is that it
was ridiculously simple what i thought that i want yeah but to implement it i gured that uh when i
was using some time passing libraries uh so i gured that these three letter time zones that we
use like ist and all um that's not the iit standard the iot standard is something like asia slash
kolkata yeah like that yeah and and the rabbit hole kept digging like i gured that okay kst is three
things kaliningrad standard time korea standard time yeah so together sometimes three letters
need disambiguation yeah so then i have to add a disambiguation layer in the middle like okay
build that uh then i gured that chrome has a bug that they have not updated asia slash calcutta
to asia slash kolkata yet even write a bug on chrome's bug tracker and i found out that there is a
thread going on for last ve years yeah and somebody's like hey iit has updated it when will you
guys do it and like refox has done it safari has done it but chrome is not yeah and then i found
out some uh message from some cryptographic cryptocurrency exchange somebody wrote that
our trades are failing because asia slash calcutta kolkata in the browser is happening yeah so
guratively i was very simple like i just thought that i would build it in ve hours or something and
from there got to learn so many things yeah as a result of that so i think even for example
something like dns.toys if somebody wants to just clone it and run it on their own they will learn
so much about how to run a dns server as well yeah in that process yeah so that's that's a great
example of rabbit holes so you wanted you try to scratch that itch of just doing one date
conversion but if you hadn't bothered you wouldn't have learned so many things but because you
bothered to do it hands-on you were driven you learned so many things yeah this is what
engineers need to do you know they need to build things with their bare hands you know they
have to do you know even the tiniest of projects but nothing is really tiny in that sense you know
date passing is a really complex thing yeah and you went down the rabbit hole absolutely yeah
yeah and it was i think uh like the end of the journey it was just so ful lling for me itself is uh and
then i sent you a bunch of friends so nowadays like when somebody asks me from singapore
dubai or somebody like went to meet and i just typed them share time dot in ist and like so they
read it in that time zone and then somebody suggested that if i open it from my time zone can i
get a thumbnail preview in whatsapp itself so that i don't have to open i'm like oh okay see that's
great i'll build that next that's a great idea right yeah so you can just send the url the og tags will
work and you don't even actually have to open the url then yeah uh so yeah in piggybacking on all
of these di erent technologies and that's a brilliant hack you should do it if you haven't already
yeah yeah that's the whenever the next weekend i get some time that's the next thing on my
agenda yeah to do that um but yeah i hope like uh if people are hearing i mean they they you
know whatever the itches they have been having so far they do scratch some of them and you
know build some of those projects it'd be really uh bene cial uh but i will take a segway from
there too actually because you talk about building these things and also open sourcing then this is
the reason why i have discovered so many of your projects because they are open source and of
course rst of all thanks to you because you share those uh instead of just incurring and keeping
them um now opens also something of course um you know sort of a bit uh i would say abused
misused word also in some places uh gets used sometimes as developer relations and branding
agendas also some places uh for me going up open source was um i gured out how to hack the
kernel of a uh you know basically reload the kernel of a android phone so then i gured okay linux
kernel is gpl so i can download change uh stu and i gured that okay phones come with
processors with speed limited you can actually bump them up you can overclock a phone as well
yeah and then overclocking desktops or something people knew okay phones can be
overclocked and then stu like that i did and then i gured he um in fact i opened my rst github
repository because of that reason i gured okay if it's a gpl code if you make a modi cation it was
supposed to publish it yeah just the spirit of that word is so uh i think uh got very uh invigorated
by that hey that's such a nice spirit that this entire community has you make changes publish it
fi
ff
fi
ff
ff
fi
fi
fi
ff
fi
fi
ff
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
 back yeah and of course since then uh i have contributed to a lot of open source projects and
everything um but but from also an awk perspective because there was this false pledge at rst
united you were talking to about uh orgs as well if i talk to individual engineers a lot of them really
appreciate if their org actually uh supports open source development or supports their engineers
to contribute to open source and i feel that for a lot of engineering it's a very big motivating factor
uh what do you have to say to orgs or to engineering leaders as well like you know why should
somebody you know focus on this and like i said sometimes it's very transactional sel sh reasons
also exist probably but yeah you know how important is it both for you know individuals or also
for i think it's very important and a part of we spoke about building engineering culture exactly the
necessity right i think this is one of the facets of building a solid engineering culture right and
when i say engineering culture i also mean hacker culture so if people aren't in on consuming
open source software and everybody builds everything on you know foss today yeah and if
they're not keen on tinkering and you know publishing stu back uh that the engineering culture
kind of takes a small set back there so a solid engineering culture it's about collaboration and you
have to collaborate internally with tech teams and non-tech teams but it's also about
collaborating with others outside and for what i don't really have you know quanti able answer
like you said for some organizations it could be transactional it could be marketing it could be a
way to attract people to to hire them which is fair i mean all of those things exist in the world they
can all coexist but some organizations do it just for the heck of it just for the spirit so there's no
right or wrong here i mean i prefer a certain perspective but many organizations do it for sel sh
reasons like i said it's fair but it is it's important because it enables all of these things it lets it
makes engineers better engineers also because when you write something for yourself how you
write that how you think how you architect software it's very di erent from when you have to build
something for others when you write software for other parties and open source software millions
of people could use it people you've never seen people in completely di erent geographies
di erent cultures di erent perspectives di erent requirements they'll take your software and use it
in ways that you never ever imagined exactly so when you write something for others for unknown
users it's a whole di erent framework you're writing it with as many holes closed as possible as
many cases addressed as possible yes as clean and architecture as possible and that just makes
you a better engineer anyway and you'll start applying those principles in your internal projects
also thinking that you know i'm not writing this for myself for today i'm writing it for whoever it
could be tomorrow so there are many bene ts to that and you know building a culture
transactional sel sh reasons just being practicing being able to write better software by writing it
for others and of course giving you consume all this open source giving back and when people
derive utility from the software that you publish it's immense amounts of goodwill as well that may
not translate to money but you know it's if you care about it it's a lot of satisfaction right so many
of these reasons like a number of reasons why it should be done right right right um i think i feel
it's a little unfortunate in india it happens way less i feel because uh yeah uh i mean maybe i mean
zero that de nitely does razer pay i have seen uh ipkart uh there was a time i used to follow this
a lot of great stu they used to open source um but it's not something very very prevalent versus i
know a lot of my friends who have probably you know moved out of india and in us and a lot of
times they end up picking up a job because they they found some open source uh project which
they needed for some of their own use they found out this is made by this org and they're like i
would love to work at a place which has made something like this yeah uh so this is something
that i think de nitely should uh improve in our uh tech culture here in india i guess absolutely it is
so dis disproportionate it's actually shocking we have i know dozens i know 100 you know
unicorns massive companies unlimited resources tech companies that build you know cutting-
edge technology most of them are in bangalore but if you look at the number of open source
projects that come out of india it is so disproportionately small it's practically non-existent
compared to this massive you know wave of digitization at every level at the government level at
the governmental level at the industry level young companies old companies cutting edge
startups startups that are expanding all across the world all of these things have come out of india
but the same industry which uses open source software to build all of this build all the valuations
build all their products produces so little to the point that it's non-existent i think it's a cultural
issue it goes back to exactly what we we've been discussing if you have a tech versus
management divide if you have a management that isn't keen on engineering culture there'll be no
encouragement to get people to you know open source things and if you pick i know dozens of
really big popular large tech startups here and if you look at the management i think it'd be a sad
realization that many of them are not really engineers although these are all tech companies
they're all led by people who don't really care about engineering if you don't care about
ff
fi
fi
fi
ff
ff
ff
ff
fi
fl
ff
ff
ff
fi
fi
fi
fi
 engineering why you do care about encouraging your developers or tech teams to produce
software to give out to others what do you gain from that right nothing so it's it's a very it's a sad
cultural issue uh and again before the before this started we had a brief chat about force events in
bangalore like how early 2000 saw a large number of you know thriving open source communities
all across india there was a open street map movement was big the wikipedia movement was big
you know lots of students got participated and entered force via wikipedia yeah there were lots of
force events you know hacker events but over the last 10 years now india has become this techno
innovation business hub but force-related events have kind of almost vanished all the
communities they've vanished and many of these events today happen under very corporate
umbrellas there are tech events not exactly open source events are you know coming yeah today
when we have unlimited resources when the private tech industry has unlimited resources to
conduct and encourage such events and groups and organizations we don't really see anything
so i think it's all very cultural from engineering hacking slash tech we've gone to like a techno
business realm altogether which is fair but you need to have both yeah yeah yeah so of course
maybe it'll come back around we'll see even even you know techno business and i mean it's it's
fairly common to hear probably from my perspective because you know there are people hiring
engineers from scala so we get to hear from exactly the people who are hiring yeah we're getting
very di cult to hire uh good engineers yeah that's a term i keep seeing being thrown around uh
but i gured that yeah i mean if you don't create the atmosphere where whatever is your de nition
of a good engineer thrives then you will have this complaint for sure right absolutely absolutely
and it's the ethical responsibility of tech companies who bene t from all open source software
and tech and yes good engineers who've come out from you know these ecosystems to
contribute back and help produce a thriving engineering culture everywhere right right right um
also uh from uh you know uh and this is maybe a you know imagine a question coming from
somebody fairly young like early twenties or something getting into tech and i keep getting this
question myself and then i try to answer the best i can but love to uh get an answer from you for
those people as well um there are people who have maybe just heard about a little bit okay you
know there's this guy very good engineer he started his career with open source stu like that
people hear such stories and then people ask like okay how do i get into open source and then
obviously that's a very vague question in that strength yeah but nevertheless like you said there's
a big chasm of not knowing what you don't know yeah if somebody's even interested up to that
point yeah right yeah i mean i gured heard from some people that it's great to participate in
some open source communities or contribute to some open source projects or build some of my
own projects i heard from somewhere could be good for me yeah yeah and sometimes just at that
point there's a question like how do i go about doing it uh what would be your answer to
somebody very young just getting started what should be their motivations and then you know uh
probably i would not ask what should be their motivations i think the motivation is fairly there they
want to get in just want to know how they should go about doing it uh this is a question that i see
very frequently yeah i want to get into open source how do i yes i think it's di cult to be very
honest if you want to start contributing to large existing projects you need a certain level of
expertise and understanding and you know some of these are very overwhelming absolutely
absolutely and for projects that are run for large projects maintained by you know skilled teams of
people why would they accept contributions which are not meaningful yeah so this whole
question of how do i contribute an existing project is a slightly problematic one true especially for
beginners true true so to get started with open source you have to step get started with hacking
and engineering you have to become a software developer rst you don't have to have you know
10 years of industry experience but you have to have hands-on experience of having built
something right so before you get into open source get into engineering you have to write
software you know write a date time calculate or you know play around with the dna server build
something yeah and when that happens the doorways automatically open up for instance like that
example with your toy project was great you just wanted daytime conversion but that you picked
a date library you went into the into a rabbit hole of issues maybe one of those issues that you
found in a date library you'd know how to x and you could send a x there yeah but if you start
out by saying i want to contribute open source where do i start nothing will happen you can never
start exactly so you have to start by becoming a software engineer you know build your own
projects hands-on projects and in that process you'll start using other software libraries and
whatnot and that will open up pathways right so that is i think the only way to really do meaningful
open source contributions it won't it can it has to come to you when you're working on those
things hands-on building your own projects or building stu at work or whatever but if you just
wait they're saying how do i get started i need to get started nothing will happen so you have to
fi
ffi
fi
fi
ff
fi
fi
fi
ffi
ff
fi
get started by writing software makes sense that that's uh de nitely a great place no no uh i'll uh
probably uh go deeper into that particular arbitral of you know um how to i mean get started to
open source too then there's an excerpt of questions which come from people about also uh how
to go about their engineering careers and and uh i mean we discussed it back when we met like
you know about that sadly sometimes a lot of it is for more driven maybe the former can give you
a good place to start but if that's what keeps on driving you might not end up with the correct
direction uh and all right uh i would like to also uh probably predicate that with one background
and i remember a long time back i saw an interview with linus torwells and he was saying that um
and there was a lot of outrage in india about that interview because he just said something which
we would perceive to be anti-india but he said that you know uh what i see is i don't see
somebody from india creating uh something like linux kernel and the interviewer press it on like
why and he said that you know when i was starting with you know minix and you know hacking
around with bsd and i created the linux kernel i was not thinking like uh how i will get a job next i
had just you know i was in nland i had completed my university degree and i did not need a job
right now uh the i think the nnish government pays uh some uh bursary amount for a couple of
years till you gure out a job and you can so it's like i was just hacking around you know there
was some old you know solaris boxes lying somewhere plugging some hard disks and seeing if i
can write a better driver for that yeah and all of this stu i was doing and then out of that linux got
born and i was not i did not set out to build something like yeah they knocked out there and then
he talked about how like i was not nding a good version control system so i wrote gate and all of
that right uh like i have come to india a bunch of times and i've met you know indian engineers
and somebody right out of college is thinking so hard about jobs and that's a background that we
should also keep in mind i believe because we are not a very rich country we are a poor country
and a lot of people have a lot of responsibilities probably education loans when they're getting out
of it despite given that background how do you say people should go about like like the early
phases of their careers what kind of things they should you know learn and what uh can be good
motivations to sort of keep learning more things see it's very di cult to talk about motivation i
mean it has to come from within correct correct when it comes why it comes when the spark
happens to be a hacker or you know do things for the joy of it it's very di cult and like you rightly
said we can't compare our economic conditions especially over the last few decades with say our
western counterparts there when you have great social security it's it's possible to think like a
hacker you know i'm not going to think about a career i'm not going to think about a job i'll just
hack around because you have great social security but again like you rightly said we don't really
have that sort of social security here people have big economic uh obligations right and to meet
those obligations you have to nd a job right after college you're mostly forced to nd a job yes so
it becomes really di cult unfortunately because of that the ecosystem the environment here isn't
really ripe for hacking and once you and then we've talked about culture or the lack of a lack there
of engineering culture in our industry even the new age tech industry which is ush with cash even
that lacks it now when you when a young student who has economic obligations to meet enters
the industry and if it's the large big it industry you know it's a they get churned there there's no
engineering it's just services it's don't work unfortunately or if let's say they entered this new tech
industry which has all the resources you know well-paid jobs and all of that but there's no
engineering culture too chaotic there i guess exactly i mean if without that culture right what
sparks this whole idea of motivation there has to be something right it has to be people around
you it has to be the environment you are in it could be the communi it could be a community
could be a conversation that you have right about hacking with someone could be anything that
sparks and the spark has to sustain now the probability of that spark occurring is low because
you know because of whatever reasons we don't really have that engineering slash hacker culture
not in the old industry ironically not in the new industry and not really in our educational
establishments most of them as well again for whatever reasons you know large sections of
educational establishments are wired geared towards producing graduates who get into this you
know this churn yeah i mean there are strong socio-political cultural reasons for that economic
reasons for that we can't really blame anyone but that's the reality right so when you come out
when you go into any of these parts when you take any of these parts the probability of you
getting started you getting that motivation you're getting that spark to do something try
something have fun is low it happens but it is really low so it's a problem it's something i think
about all the time when people especially say our colleges don't uh produce you know fast
hackers why is that so many you know millions of people who nish engineering degrees but how
many open source projects come out of india right so these are all really complex reasons and uh
it's it's a bit of a lose-lose where you know sadly yeah in in all these areas and parts so it's just
fi
ffi
fi
fi
fi
fi
ff
fi
fi
ffi
ffi
fl
fi
really hard now how do you get motivation i don't really have an answer i think it has to that spark
has to come from somewhere so the people who have the ability to let's say set up ecosystems or
help create environments that ourish yeah like strong engineering cultures people who have the
resources to do that i think it's their ethical responsibility like i said i know many of these big
startups that we have who are ush with cash who use tons of open source software what they
could do to give back to society and this is not about producing projects for github correct the
second third nth order e ects of this engineering culture could be huge for a country like india
right if we had more and more people creating software public goods for other people to use just
because they like using it it's extremely valuable for you know humanity in general right yeah yeah
but you can't tell anyone to be motivated or to create software it has to come from within so what
we can do is people with access to resources whatever we have to consider it ethical
responsibility and create environments like that right so i i didn't answer your question but i don't
really have an answer right these are the might these are i think maybe you'd probably use this
opportunity to also probably uh push a very personal pain point especially with uh like at scaler
exactly uh the stu that i have personally faced is uh and then again this is probably like a bit of a
complaint against i would say uh tech companies who also say that it's di cult to hire uh we have
often gone to uh tech companies who are interested in hiring people and i've said that okay see
some times obviously like very big companies they have a certain process it's a pipeline kind of a
thing solve some lead code problems system design interview and go but there are people where
you know it's a smaller company it's a you know very product focused engineers the cto open to
talk yeah and we have sat down and they said we want exactly somebody like this somebody
let's say who understands operation logistics who can you know build an end-to-end project in
let's say node.js they have very speci c idea of what they're looking for in mind rather than a
broad brush good engineer and even despite that uh what i have faced a lot is that i say that okay
if you have a very speci c requirement like this in mind how about i suggest you something that
uh you know you uh spend a little bit of engineering hours with us to help us build a project and
we roll out that project and some of the learners at scala they will build it and your engineers can
spend maybe a couple of hours a week just uh you know code review what they have done
mentor with that project and you do it for a month some of the people you whom you know you
really love build that project you can hire them yeah you can't get a better signal than that yeah
and and i'm gonna be doing most of the heavy lifting for you right i am really interested in you
know letting some of my students build some projects and even they would be very invigorate
because it's like a big unicorn company and their engineer is mentoring you in a project yeah and
even there then the pushback is like okay we don't uh we won't have time to spend on this or
maybe you know uh we don't have the bandwidth to do something like this and there i feel i mean
that's probably the point where i would say that that's my complaint here is that you know if you
have a very speci c kind of engineer you're looking to hire and you want all those signals and i'm
creating you a canvas where you can actually get those signals from people it's it's sad if you
don't want to even spend that amount of time yeah this is not like you know publish an open
source project with licensing and everything i mean even maybe there's even less e ort than that
i'm just saying you know a couple of your senior engineers spend two weeks three three hours a
week right and then mentor a project right um and and i personally have seen that work so well so
uh when i was at uh zamato and i think uh the two of the best hires in my team i did was via
something we call trial week where somebody would come in a week work with us right only thing
is it's a little discriminatory to people who can't take out such a time maybe they're working
somewhere and they can't come and spend a week so fairly junior people you can hire like that
yeah you're having somebody senior who has a family were established in a certain city you can't
say that you know just leave your job and one week come and hack with us yeah then we will hire
you uh but the two people i hired they were the strongest hires in the team for sure because
you've worked with them for a week i mean yeah it's obviously better than take an interview but i
think yeah if companies do actually put out that e ort yeah it really compounds a lot back uh to
them and then with like you're saying the resources that they have it's just uh you know probably
like a sincere appeal that they do that because i also have anecdotes like when i um ran my rst
company as a startup and we used to do everything open source uh as telling you that i'm like we
did not think that we were a startup because we were just teaching people then edtech as a word
was not so common back then and um and it was my i did not believe that the software you were
writing was anything unique i mean just playing video writing some commands it's it's very run-of-
the-mill uh right o the shelf type of software but of the shelf did not work there was some lms
systems that did not work so we are okay we will write our own software for that but okay let's
make it open source one of the best uh outcomes of that was um people who joined our tech
fi
ff
ff
fi
ff
fl
fl
fi
ff
ffi
ff
fi
 team were all people who were students in that place they gured that the tools that we're using
to learn not adequate i will add some code and i'm like hey why don't you come on board and join
us yeah there was this whole entire online id like complete something like a vs code kind of an
environment and that was entirely written by uh people who are not employees of the company
it's just people gure that okay i can tinker with it and then i can add to that uh so i think that that
value sometimes uh also that message is also with the leaders is also they don't see it because
i've worked with some european companies where i see that they very much understand that
second third fourth order e ects also and they have seen those bene ts um but maybe i don't
know we as a ecosystem have not yet seen those fruits of the second third order and that could
be a reason absolutely i mean see it's a lot of foss is really altruism right some of the most
valuable projects in the world that all of us you know billions of people use are made by a handful
of people who make it because they like making it they struggle to make a living with you know
with a di cult job and at the same time they contribute their personal time and e ort into a fast
project that they give out to the entire world for free and if you look at the large for larger force
ecosystem most projects would be like that why do people do it right it's of course you you did
for fun you do it for satisfaction but you know there's also this aspect of maybe it's a very touchy
word altruism so it i think like like the examples you mentioned right they're great so companies
want to hire the best engineers uh they want to use the best open source projects available from
across the world to build their companies right why can't they give back how can it just be always
consumption we'll pick up the best software we'll hire the best engineers we will you know do
ridiculous we'll throw out ridiculous o ers to attract the best talent right but where does this best
talent come from you can't become a great engineer by you know reading books or watching
videos you have to have you have to you have to be involved in all of these things you have to
work on lots of projects you have to collaborate with others you have to be familiar with fast
projects you have to produce fast projects for this you know whatever we've been discussing you
need a thriving ecosystem here of engineering culture of appreciation for engineering yes yes so
you can't expect to nd uh great engineers all the time in unlimited supply if you don't contribute
back whatever it is yeah to create an ecosystem that produces such engineers right right so it's
very it's very short-sighted and blind of organizations here to just expect to be able to always nd
great engineers while never doing anything to produce great engineers right and why do you
produce great engineers it's just it's you know it's like i said it's also an it's ethical responsibility
even if you can't foresee the outcome we publish this open source project or let's say we run this
community event or do whatever we fund some open source projects what do we get back
maybe nothing but at some point all of these things you know these all of these things have to
happen on a large scale for good outcomes to happen for everyone but if you transactionally look
for very speci c outcomes i sponsor this conference i want this back that doesn't scale and then
you can't you know complain that there are no great engineers here because nobody's doing
anything to produce great engineers and how do you produce great engineers all of these things
without looking for speci c outcomes yeah yeah i have like a handful of friends from my college
days who have fairly probably i would say burned themselves out of the india ecosystem at this
uh point because of this because these were uh people who with whom i would go like almost
one or two hackathons every month they love doing stu like that you know working on open
source project participate in google summer of code uh and i had a group of some 10 15 people
and a lot of those people are now at a point where uh you know they're like there isn't an indian
tech starter which is even pitching that hey come here because we hack on cool stu yeah and
nobody's even doing that pitch and i want that pitch and a lot of those people have eventually
moved out uh especially they nd some places especially you know uh amsterdam france those
kind of places there are a lot of companies who are actually literally pitching that you know like uh
forget how many users we have or you know how many requests per second we process all of
that just come because we build cool stu we go to hackathons we participate in conferences we
build open source projects and then you know come because of that it's a very direct pitch and
uh i think people should actually look up on that and see that it's a pitch that actually works with a
lot of engineers who really want actually that out of the work they just want to have fun yeah they
want to hack on stu and you're probably missing out on great engineers are looking for that if
you know you don't create an environment where you let them do that in the rst place and then
of course the other second third order e ects uh around that as well um i did uh like to take a
segway into uh something else uh which is uh we were earlier talking about you know as like the
tech versus business thing you are saying that um the the tech is the product and it's a from
going from tech enabled to actually being tech products happening across a lot of these verticals
uh what sort of the i mean going ahead looking at the industry probably wider industry but also
ffi
fi
fi
ff
fi
fi
ff
fi
ff
ff
ff
ff
fi
fi
fi
ff
ff
fi
 nance uh something that you have been doing for so many years that uh what does like sort of
more emerging pieces of tech look like because i have obviously read that nathan had shared
about ai and nance thing but but nevertheless uh i don't like you know a lot of new things uh
coming up uh i mean yeah i blocked you and all of that but apart from the hype words uh what
sort of the future of tech in this domain looks like going ahead uh di cult to answer yeah but i
think you know big revolutions happening in ai ai many di erent kinds of ml and ai technologies
becoming commoditized etc will accelerate better technology for sure but ai won't just come and
change nance right or you know suddenly there's this thing called blockchain and it'll completely
revolutionize a certain thing it doesn't work like that these are all building blocks exactly
somebody has to come take the right building blocks nd the right problems to solve and use
these building blocks meaningfully to solve these things if you look at let's say the let's kite our
investment platform you look at kite in 2022 and you look at uh trading platforms that were
available on the desktop they weren't really mobile platforms oh forget mobile app our web app
versus web apps that were available 10 years ago uh i mean fundamentally nothing really has
changed fundamentally as in you log in you see stu you press a button you know it's all on the
web page you can place orders etc but these systems are light years uh apart yeah and lots of
like a million subtle things have changed it's still a web app it uses javascript it was a web app it
you know used to use javascript what has changed is sensibilities have changed right uh the you
know these not just us you know many newer companies care about user experience and just by
focusing on good user experience we've see you know we've had a large number of products
emerge high quality products that you can't even compare with what existed 10 years ago but
technology they may be the same thing maybe it's just you know slightly better web frameworks
slightly better mobile frameworks so i think changes drastic changes is going to come like this
lots of little pieces coming together to give produce better and better quality software i don't think
there'll be anything let's say in nance tomorrow that'll completely change how people you know
interact with nances like a mic drop kind of a thing exactly i don't know this is not happening
yeah that doesn't that doesn't that is that's very rare that happens very rarely and if you again if
you look at how people treat investing online today you know there are 18 year olds signing up
versus how it happened 10 years ago only 60 plus people of the 50s and 60s stated it's
completely changed yeah but did that happen overnight no it happened over a decade maybe
accelerated over the last four or ve years so any sort of change is going to be like that maybe
people will start using machine learning technologies to solve very speci c problems and they'll
be a big ux boost then someone will come build on top of that right so ve years from now when
we look back maybe things will look drastically di erent right but i don't think there'll be one
discerning point where one technology comes in revolutionizes everything let's say in nance
yeah and speci cally with nance at the end of the day it's about money if it's about people
making money losing money software technology ux etc secondary an ugly app that makes
people money people will use that you know rather than a beautiful app that loses their money
correct so at the end of the day with nance speci cally it's basically that all these incremental
things help people you know improve on certain things but nothing major but if you look at certain
other industries for example uh things like uh gpd3 etc the possibilities are very exciting and
maybe they some of these technologies will completely disrupt how people produce art you know
there are all these you know stable di usion there wasn't release just two days ago now people
can run uh stable di usion on a commodity gp and produce insane art correct programmatically
correct sorry if it's a simple english problem now that could completely rede ne how stock
images work yeah so designing youtube thumbnails for example is something that you know if
you're doing it remotely with the designer yeah and you have a vision in your mind and you just try
to communicate that to the designer and then they come back with it and those iterations
sometimes i feel like even if it does not replace the entire cycle i can just put a prompt into
something like daily or stable di usion yeah get a rough image and send that to the designer that
you know i want something like this absolutely changes the game completely completely and
millions of blogs will suddenly have you know very contextual great looking images right so once
in a while technologies like that come along and disrupt things overnight but that is very rare if
you look at the last 10 years you can think of two or three of these technologies that completely
change the game practically overnight for certain for a lot of industries but you can't aim for those
because they are black swan you want kind of things there exactly so drastic overnight changes
happen very rarely but mega changes over a few years and decades happen all the time but you
can't pinpoint when that happened it's you know it's really complex right right right right i did have
a few questions about uh and i just remember that is about uh some of the folks uh who got to
know that you would be coming uh about uh you know uh zeroth tech stack as well by the way
fi
fi
fi
fi
fi
ff
fi
fi
ff
fi
fi
ff
ff
fi
ff
fi
ff
ffi
fi
fi
fi
fi
 yeah and and that's something a lot of people are interested in knowing uh so i'd start from of
course uh the rst is something which is more closer to me is like i have been a mobile engineer
for a long long time uh i mean xeroda was probably the rst one to take a bet on utter it wasn't
so popular back then it was very alpha beta level uh yeah so but what uh made you do that and
then versus i think you had a react native app also long long back originally uh so how's that
played out and i would say probably zooming out like you were saying rst principal level thinking
yeah so what are the you know probably ingredients that went into taking a decision like that and
how is that played out yeah it was a big decision it was a hugely risky decision and utter was
pre-alpha yeah and i don't think anybody was using utter for anything except for the utter
team's own demo apps yeah there was nothing else and ajin from the tech team has written a
great blog post describing this entire journey yes on why we made that decision so just to quickly
summarize the gist of it uh we had a native android app uh our trading platform and for ios it was
written in react native right and of course it maintaining two di erent code bases for two di erent
platforms is a huge pain right and uh this was a time when we were making a lot of changes you
know not just regulatory changes we were evolving as a product so things had to be new things
have to be built constantly and building two things in two di erent ways in two stacks and two
code bases and releasing them at the same time of course it's problematic correct so it was very
clear to us that we wanted a uni ed platform where at least 80-90 percent e ort would be the
same and react nato was something that we bet on but it opped it was it wasn't mature this was
back in 2017-18 right it wasn't mature enough we had way too many di culties there were
performance issues and we stumbled upon utter which looked very promising its architecture
was promising uh its the language of choice dart which was a new invention that had you know
certain bene ts the way it was architected looked promising yeah like drawing the pixels directly
is actually i have always loved that because you know you take the unity and all game engine
philosophy to an app yeah because when you think of cross platform then the biggest problem is
like how android draws things and how ios draws things is di erent yeah if you keep ghting it like
react native is actually ghting it yeah you will keep on ghting it and the platforms will keep on
innovating and you will have to keep on ghting it versus if you really want true cross platforming
just circumventing that and just draw the pixels directly to the screen yeah it does come at a little
bit of i think graphic rendering cost for sure versus like native android but i really like that
philosophy when it originally came out yeah and i think for mobile it was workable because mobile
applications did tend to look very di erent yeah the problem with cross platform ui gui libraries is
that they are impossibly hard to pull o which is why even today we don't really have great cross-
platform ui frameworks for windows linux and mac you have to keep nding ghting os apis it's
extremely di cult to unify yeah and the thing about direct painting uh is that for operating system
apps you know they use os widgets lots of elements right and if you don't nail that pixel by pixel it
feels like an alien app on mobile phones people are used to you know seeing di erent kinds of ui
so it was possible to get away with that here but the same attempt on desktop is really
problematic so an app that looks like a windows app on a mac will completely throw people o
correct so that's the downside of painting you have to reinvent you know native look and feel and
controls and nuances from scratch which is an impossible project when it comes to desktops but
for mobile yes absolutely like you said uh it allowed utter to bypass you know all these quirks
yeah so we were uh greatly smitten by utter as a technical framework we liked how it was
architected but now the decision just because something looks great techno technically doesn't
mean you know you can bet your entire future on it there are many other considerations we didn't
know dart so there were many objective decisions that went into it is it is dart viable can we learn
that is it possible so we answered that question by experimenting we built a prototype in like two
weeks of what we wanted to do right list views with you know real-time market ticks were a
problem you know it has to render at 60 fps so we built a you know 500 item list view in uh utter
so we saw that the listview had a bunch of issues but you know it was open source we were
con dent that we could x it while utter was evolving as an alpha program these big issues that
it had at that point we with actual with a hands-on experience of two weeks and technical
dissection and looking at how it was built architecture we built con dence enough to realize that
oh these issues you know let them be there we can work around them right then the nal question
is can you bet your technology on this uh how can you what are the factors that would allow you
to bet your future on this technology what if you know google kills the project uh what if there's no
community around it what if people don't like write libraries for it so that was a very di cult but
objective decision again for us where we realized that the pain that we were facing with native a
native code based plus react native was far greater than it's a google killing of this in three years
we gured if we could just port this and run it for three four years because it was open source by
fi
fi
ffi
fi
fi
fi
fi
fi
fl
ff
ff
fl
fi
fl
fl
fl
fi
fi
fl
ff
ff
ff
fi
fi
fi
ffi
ff
fi
ff
fl
fl
fi
fi
ffi
fl
ff
fl
ff
 patching it ourselves maintaining it ourselves and all the bells and whistles it had suited our
requirement it would still be worth it right so that trade-o you know despite all these issues
despite all these risks it would still be worth it that's the most critical pivotal decision point yeah
and we're like ne let utter be killed if it's getting killed we would it would still be worth it for three
four years right so to arrive at that decision of course we had to make you know actual hands-on
we had to build a prototype i mean we couldn't just look at the github issue and decide so it was
a very careful objective technical rst principles decision making process that started out as a
very technical thing that went on to a tangent of business and organization like the risk right and
we made the decision and it turned out to be a great decision right yeah i mean uh that's uh fair
enough and uh i think i have seen places where like you're saying if google admin owns a kind of
a thing so uh at target uh there used to be a library that we were using for 3d rendering some
models so that you can virtually try out some products that you want to buy and stu like that uh
and it had two versions i think one where uh you would actually use direct 3d models another one
was where you could just sketch it out in some pseudocode kind of language and some 3d
models google stopped supporting like they abandoned the the sketch uh thing and target started
maintaining it because it was very important for us to actually use it and the decision to actually
buy into that was right from day one that if google does not actually maintain it we can do it
because we understand the system how it works and it's important for us and there isn't any
better solution for us right now yeah yeah so yeah that's a great trade-o you even have to
visualize the worst case outcome when picking on picking a technology yeah and once you are
once you know that objectively we can handle the worst case uh outcome if it were to come then
you're kind of safe and 90 of such decisions don't turn out to be don't turn out to be disastrous
yeah yeah the worst case like they have covered for that yeah exactly yeah makes sense uh so
coming from that uh mobile architecture to also um to to uh you know web systems in the back
end um and then i've heard uh from folks in your team as well some friends who i have is you
know it's fairly simplistic uh compared to what i see today uh is especially when i'm teaching is
that a lot of people like uh once uh they they get started with actually building things there's a lot
of questions around okay what you're teaching me will you teach me how to build in
microservices or you know will you teach me how to deploy a server less to the cloud or
something like that and uh you know while occasionally it can be exasperating because i'm like
let's start building something we will gure out we can separate into services we can you know
serverless or you know vps however deployed let's let's see we will go there uh but i think the
hype of a lot of those terms have permeated uh and and you know if it was only hype it was one
thing but their people were actually building stu which is getting in uenced by that hype today
it's something i feel i recently wrote a very long twitter thread about like probably very contrary
and unpopular twitter opinions but there are a lot of folks like uh ammo and then ajay they
retweeted they say that you know these are probably good points it's sad that it's unpopular uh
but then i would like to delve a little bit into how's your tech stack look like and you know how do
you go about doing deployments um i see it's very unconventional that you roll a lot of things in-
house versus using a lot of cloud-based services um so if you could run me through a little bit of
that uh so the tech stack has evolved greatly over the last you know decade and but not really in
principle in the physical manifestations if you change databases we've changed you know
programming languages but the approach has always been rst principle so when we really
started out we didn't really have a road map when we started out almost a decade back we didn't
have a roadmap to build a trading platform we wanted to build technology to solve problems
inside uh zarotha rst so in the very beginning it was python scripts that cut down let's say one
hour of manual csv processing to let's say two seconds and it was mind-blowing for the people
there right and uh so that's that's really the origin the right tool to solve a physical problem the
right job that's that's how we started out we didn't say we need full stack we need a trading
platform we need uis nothing so these then we started you know solving slightly bigger problems
back then it was just me when we started zero that tech it was just me and i was sitting there i'd
go sit with non-tech folks nd their problems you know write python scripts to automate and at
some point you know i had too many you know people got the taste of automation it wasn't even
tech it was automation they're like oh can you automate this can you automate that and that's
how we were slowly very slowly trying becoming a you know digital business from pure uh o ine
paper stu to you know slightly more digital from a brokerage rm to a trading platform that
exactly that transition was slow and very organic uh support system was a single gmail inbox that
you know let's say 20 people logged into that obviously doesn't work then we brought in i
installed os tickets an open source you know ticketing system so all these tiny pieces at some
point i realized i was getting way too many things that i could handle it's time to build a tech team
ff
fi
fi
fl
fi
fi
fi
ff
ff
fi
fi
fl
ff
ff
ffl
so after several months after starting zerudada technology as an organization with a roadmap to
you know build technology in nance we hired our rst engineer so only when i exhausted you
know my capacity then the two of us started doing whatever i was doing and at some point we
were like oh we need more hands then the third person then the fourth person so the team grew
very very organically and as did the stack right so the in the very beginning as i said it was python
because you know i was okay writing python i could write decent python and it was python
automation stu then we started to store databases sorry we had to store transactional data at
some point suddenly there was postgres because you know i'd always known postgres had
worked with postgres certain things for whatever reason had to be my skill databases i knew that
also so we use that os tickets for example uses mysql and os tickets is a php uh system yeah all
those old software yeah yeah wordpress era software exactly wordpress era and that required
some uh tweaking so suddenly php was also a small part of the stack so we picked the right tools
for the right job for overstick for support ticketing it was this it was appropriate for something else
it was that that was appropriate at some point after lots of digitization after lots of you know
backend dashboards and whatnot with let's say django because we are already using python at
some point we suddenly had an end user product on our roadmap so that was built in python uh
we used redis for caching because everyone was using redis for caching it was memcached or
redis at that point yeah and it is was slowly picking up sorry gaining popularity so we built a
django based uh system i think there was also this library framework called cherry pie which was
simpler than django okay but it was a python stack so our apps grew features grew complexities
grew issues grew databases uh grew data size grew lots of end of the day number crunching that
was based on proprietary really bad windows software which was norm in the industry we started
rewriting in python in-house so suddenly the this data back-end python based stack happened
but python redis and postgres were really the you know big pieces and 2017 is when by then we
had uh then of course the mobile app happened yeah uh right after we built kite the web app at
some point this was also you know random in serendipitous we were o ering a vendor-based
trading platform to end users they made a new release and i was horri ed to see that release
because i remember that it only worked on ie6 in 2015 or late 2014 and that was completely
unacceptable at that point that we would build our own online trading platform wasn't even a
question it wasn't even on a road map then you know picked angularjs that turned out to be a
disastrous decision you know there was this angular v1 v2 yeah angularjs angular all that stu this
yeah the version change uh they rewrote it in typescript and stu all of that yeah lots of things
were happening and we found it to be it's a complex framework also it's not very easy to grasp
but we won of kite our rst end user web app in that sense trading platform was written in
angularjs python backend redis and postgres but angular we immediately regretted it was so
painful and di cult and hard and just a year later we rewrote the entire thing in vue.js today vue.js
is our basic our web app stack for the front end and 2017 is when digital signatures became a
thing now you could open a stock broking account online prior to 2017 you know we'd korea you
like a 40 page booklet you had to do 40 50 signatures scan print yeah i say a direct way of doing
things yeah yeah yeah yeah and there was only possible way there was no legal way to open an
account online it had to be o ine so you can imagine that the industry was very slow because
who would want a courier then you make one mistake miss one signature it gets korea back to
you so the drop-o rates were like 98 then digital signatures happened we could generate a pdf
from the back end people could just you know with a few clicks do a digital signature and no
more couriering of you know documents that's when it really started picking up you know online
investments as a thing post 2017. this was also a time when we as the scale-up happened this
was also a time when we started facing a lot of uh issues downtime issues because all of these
things that we're building in-house were on top of legacy systems that the industry was using
anyway like oms order management platform the back o ce system and the mega projects that
we were handling was to take all of these pieces in-house and write them from from scratch it was
like glued to legacy yeah yeah yeah so even if you're let's say you're a bank and you release a
great looking net banking app the underlying system would be you know like a very legacy core
banking system and you'll have to start replacing pieces bit by bit so the most amount of work
that we've done back then was uh on the one hand we we were doing product engineering
building new features you know new ui new x on the other hand we were replacing these really
dirty messed up legacy systems and nine out of ten things that went wrong when we had down
times were issues in these legacy systems which were completely outside of a control so that was
extremely frustrating in 2013-14 i was experimenting with go uh it was a newish programming
language at that point and i was experimenting because you know i felt like you know i was just
thinking tinkering around so we had this one particular use case for the trading platform where uh
ffi
ff
ff
fi
ffl
fi
fi
ffi
ff
fi
ff
ff
 you know you log into the trading platform you see your stocks here in your watch list they tick in
real time right so they can take two three times a second and you can add a bunch of things so
that whole that's a live tcp connection websocket connection and you to push tick packets to it
now python wasn't ideal for that so i experimented with websocket libraries in java c plus plus a
bunch of things even node.js to nd the right tool for the right job but didn't want c plus plus to be
added to the stack you can build anything in c plus plus but it's complex and being able to write a
lot of code and yeah and grasp the lot of code that is written later on is what i feel with c plus plus
absolutely and and people can write it in completely di erent styles using completely di erent sub
technologies and it's not great in that sense and i was experimenting with go and go was a you
know maybe a beta language oh no i think it was 1.0 but it wasn't big but i'd liked it and it had
great concurrency primitives and concurrencies is what you need to handle lots of live websocket
connections so i thought you know what this piece i will write and go and that became the rst go
program that we wrote uh in uh tech stack so everything was python python backend you know
python data crunching python web servers suddenly we had this one go program that was that
would accept websocket connections and stream right and that gave me personally some
con dence and experience in writing a go program for a production use case and i mean our
scale was really today we have let's say million plus users who log in and trade at the same time
back then we had let's say three thousand so you can't even compare right and that three
thousand suddenly became ve thousand ten thousand fteen thousand twenty thousand fty
thousand concurrent users you know as online account opening went up so we go was turned
out to be a great choice for live low latency not sub nano second not in that terms but let's say
sub ms request response stu super low on resources easy to write easy to deploy and go from
handling just that one ticking piece you know suddenly started making its way into other pieces
some python pieces we wrote in go right and a lot of bottlenecks lots of chokes that we were
experiencing you know disappeared then it turned out that go was a great choice for this stu that
we were doing which is handling huge amounts of requests per second responding to requests in
milliseconds and suddenly most of the applications that we had were backend applications that
were written in python that were handling uh front-end requests and user requests became go
and go became an integral part of our stack so that transition has been happening and the
biggest then you know complexity increased uh we were running a large number of applications
not micro services per se but you know services so kite the trading platform is a collection of let's
say three or four you know large services completely independent now when you have services
they need to communicate and yeah this is a data business do you have a customer database
that later has to be synchronized to the trading platform to the back of this platform to the
compliance platform synchronization web hooks etc were becoming a pain like it's time to have a
message centralized message bus and suddenly kafka became a part of a centralized message
bus and we are to the number of ticks activity subscriptions etcetera increase so today let's say
we are broadcasting 50 60 million ticks per second into websocket connections so when we were
slowly growing to that point you know we wanted ticks to be moved around in the back end
through our systems before they they were broadcast for websockets nats turned out to be a you
know great piece they're super easy to run super lightweight just run it works forever and and the
stack has largely stayed the same it's go python for stu postgres redis kafka nats and all
performing what they do best just because we are writing a new program you know it won't use
kafka just because we have kafka we only use kafka for synchronizing one-way data
synchronization or whatever and uh lately we we've exhausted what postgres can do i think so i
don't think we want to store a trillion rows in postgres you know shard etc then at some point
you're now ghting the database so i've been keeping an eye on click house as a database for the
last ve or six years since pre-alpha and i think one or two years ago cloud are published a blog
saying they used click house and it was a beautiful blog i really like cloud are's engineering yeah
events uh storing exactly events correct so that was my point of validation for click house that i
was looking for and turns out click house reduced uh reduces our storage space of several
terabytes by let's say 90 percent uh and uh queries that would take maybe one or two seconds
which is really slow for us yeah uh suddenly became two milliseconds so it turns out it's a great
database for storing massive amounts of immutable nancial transactional data so now that's a
big part of our stack and we're moving lots of things so whenever and moving terabytes of data
moving hundreds of billions of rows of data that we've built over years to a whole new database
it's not an easy decision right right but we know that that short-term pain that we will face right
now will help us for the next many many years right so that's how the tech stack evolves when
there's a solid objective use casing we need to introduce this new technology it will x all these
problems then we introduce that so today if you look at the tech stack it largely looks like this
fi
fi
fi
fi
ff
fi
fi
ff
ff
fi
fl
fl
fi
ff
fi
fi
ff
 utter for mobile apps vue.js for you know web apps uh go back ins some python backends and
lots of python for data crunching postgres click house redis that's about it right so we never think
of concepts like microservice or monolith or whatever you don't you write software you don't write
architecture conceptual architectural frameworks right so let's say you have a problem to solve
you and and we work with linux all the programs are linux programs so you you write a program
that linux program that works on linux that is super easy to deploy if it's a single binary great if it
needs two di erent programs all right but it'll never require 10 di erent pieces there'll be no 10
micro services correct so you start out by writing software that solves a problem then you start
out by making it run on linux because that's your environment then you probably add a web
server it has if it has to you know interact with the outside world if it has to communicate with
another program elsewhere you evaluate should it be a web hook or can we just connect it to a
you know one-way kafka bus or whatever right correct and you start always from one linux
program and slowly expand it outwards exactly as it grows maybe it'll split into two or three
programs maybe the technology will change maybe websocket will become something else it
doesn't matter but you don't start out by saying that serverless you know this managed services
etc and like you pointed out we are very vary of managed services don't want to be vendor
logged in the regulatory agility that we need as in there's a regulation you have a ve-day deadline
you need to change everything we need complete control over our data over our over every
aspect of our stack so we don't use any managed databases all these mega massive instances
database instances they're all self-hosted just spin up a linux system and you know you run
postgres or whatever and it's all managed by everything is managed by a team of let's say one
two two three people right and we sell forced absolutely almost everything even our hrms
employee leave management system in employee internet everything it's you know self-hosted
instances of erp next nancial stu data crunching stu trading platform stu and over the years
we've rewritten and gotten rid of all the old legacy external dependencies and brought everything
in-house and i think it's a we don't do justice to let's say a postgres beautiful brilliant piece of
software when we think that oh who will manage postgres uh most organizations will not have to
store half a trillion rows probably you'll have to store a million or a few million rows and it's
absolutely ne these are all robust technologies that you can easily run on a simple linux system
so so i think people are afraid to take responsibility for software and the cost that you pay is
vendor lock-in humongous amounts of nancial cost i know that so our crm right it's uh it's we
use erp next and frappe heavily to build all these dashboards if you're unaware it's an erp system
indian open source project yes yes i have seen yeah yeah yeah and at some we were so smitten
by we so appreciated it that we became investors in the company we funded it as a false
company at some point so just the open source ticketing system that we've been using for many
years it looks a little ugly but it's fast thousand people log in every day so you know zerada has a
thousand people today uh outside tech lots of people who have to pick up the phone and answer
nancial queries compliance legal you know documents uh and it works well it runs on one server
once a year we log in to archive data and that's a thousand people right and i know how much
sas ticketing solutions cost per user right just on our crm just on our ticketing system we are
saving millions of dollars every year just on these two things and we sell foster maybe 100
di erent things right lots and lots of things and it's the same 30 people who build systems who
build end user products who also maintain these in-house systems yeah and maintenance is you
know sometimes you log in once a year sometimes it's running for many years you don't have to
yeah and and people also i think it's a tendency to not look at risk holistically some systems can
go down let's say it's an internal dashboard so what if it's down for 10 minutes or an hour it
doesn't matter it's not going to a ect anything but that that everything has to be always up
hundred percent we need a managed sas for that that fomo that irrational fomo also drives a lot of
these decisions but for sure we are a pro table enterprise today and a signi cant amount of our
pro t margins come from our decisions to self-host and keep the stack lean right our you know
aws bill we use aws heavily for our you know hosting applications is laughable it's not even our
annual bill is probably not even like an instagram campaign for many startups that's how low the
bill is and all of these things play into the future of the organization right if you want a sustainable
organization where tech is nimble you're regulatory nimble you're actually making pro ts and you
just need a few people to handle and run everything it all plays in so it's it's the tech stack but not
speci cally the tech stack it's the rst principles used to construct this tech stack that has really
mattered yeah so i um absolutely love that you know uh another postgres example as well i think
if you are able to scale up to a million and then if you reach 100 trillion then you'll gure something
out in that space uh and i have done self-managed like they have seen open source projects do
their own bug tracking with something like redmine or bugzilla yeah works fairly well like they're
fl
fi
ff
fi
fi
fi
ff
fi
ff
ff
fi
fi
fi
ff
ff
fi
ff
fi
fi
fi
 probably tracking more bugs than a lot of companies at fairly large scale they're probably tracking
more bugs than that yeah why are those two probably one ten dollar server and they're running it
on that's what we do gitlab sorry i forgot to mention gitlab is a part of a stack that's where we
host all our repositories that that's our ci cd system bug tracking issue tracking works really well
self-hosted instance of gitlab yeah yeah i have burnt my hands on uh managed postgres so we
used to run postgres on our uh and just talking of since on 1617 our startup and um we did not
get into aws because initially just felt like okay whatever we want to run if we can just uh we were
bootstrapped they didn't have a lot of money and no investments nothing and we are fairly young
so just to take the risk of okay if you put something on aws there are horror stories out there blogs
of people running millions of dollars in bills so you start o something like digitalocean yeah like
okay if you take a ve dollar server you're not gonna spend more than ve dollars because it's a
vps it's not auto scale or anything yeah so we started o like that and our database used to be
hosted on our own vps right um and then a couple of years later uh they pitched that we have
managed databases now and they poked and prodded us for a few months and actually try it out
so we tried it out uh problem happened uh someday site was not working when things went down
and you're like trying to debug okay what's happening uh why it happened okay um everything
seems ne we every time we restart the entire uh vps everything works ne yeah but but if there's
some spike on on the db it uh you know the db the managed database it resets the connection
and after that reset somehow does not connect okay we're trying to gure out what's happening
and uh keep debugging a few minutes later we are like okay if we copy the url from the api it
works if we copy the url from the dashboard it does not work okay strange enough so we look at
the you know uh url that's on the dashboard and the one that we just copied it's the same then
there's a copy button on the web clipping clipboard button right we click on that and we copy and
we paste and we see that what is actually shown is not the same thing that is copied because
when you click on the copy button it actually makes an api call and fresh gets a fresh one yeah
but the string that is shown there if you just drag with your mouse and right click and copy you
get a wrong one but if you click the copy button you get the right one and then for an hour or so
we did not think that something would be wrong with their database because so many clients are
using they must be right something must be wrong with us yeah if you have been hacking around
you know like you know the rst thing you blame is yourself something must be wrong in your
code some glue not working then we're like no we'll just move back our dp we'll manage it
ourselves this does not happen when we manage it ourselves at least yeah and we realized when
we moved back we saved a lot of cost and better reliability because this does not happen so yeah
there's this de nitely uh so you're talking about gitlab as a ci cd uh as well um i think a lot of
people do uh focus on both in terms of learning and sort of trying to establish like pretty elaborate
cicd setups like you know i code review something here automatically will get deployed
everything will work and all of that stu what i have so far found out i might be wrong is that
people spend a lot of their day trying to chase that utopia without actually achieving that utopia i
agree yeah so how does your ci cd stack look like uh right now like how do you deploy things and
all these maintenance and stu how does it happen it's quite simple like you said you know
people put in a lot of e ort into the process of achieving the nest most automated slickest ci cd
pipeline and that's just basic e ort at the end of the day you you're working on software and
there's a new version of the software and you have to get it somewhere that's about it i mean
everything else and and a simple good enough path so our cid ci cd system is actually quite uh
simple we have a job le for many of these repositories and a lot lots of them we've created a
template that many repositories can use so that people understand how di erent repositories are
working so for go programs when stu is pushed to gitlab there's an automated you know lint
plus test that runs and just a common sense sanity check then there's a build step that compiles
the go binary and dumps it to uh s3 you know some designated bucket right so that is really the
build system really done and then we have another deploy step and for critical applications that is
manual for us we don't really care about you know deploying 100 things in a day but every
deployment because of the risk we are extremely extremely extremely careful about deployments
right so insane amounts of testing weeks and months so that step for most of our critical apps is
manual you have to go click a button you know that little play button on the gitlab ui and that is
when the actual app will get deployed now the deployment environment we wanted a uniform
environment for all our applications and we tried out k-8s as a uniform deployment environment
where you know people can write a manifest yaml le and you know it'll eighty percent ninety
percent it'll work for all di erent projects because otherwise otherwise people roll their own
deployment build schemas and you know becomes non-uniform over time but uh that didn't really
work out case turned out to be insanely complex there were you know yaml manifest within yaml
fi
fi
fi
fi
ff
ff
fi
ff
ff
ff
ff
fi
ff
ff
fi
fi
fi
fi
ff
manifest within manifest and we had to write tools to make sense of these manifests so that pilot
you know we phased out and uh sorry i forgot to mention this nomad hashicorp hashicorps
nomad yeah as a orchestration plus deployment stack is something we piloted and we are
deploying everywhere now okay so we've written a and and hashicorps nomad is really simple it's
not like k-8s which is like a full- edged cloud operating system in that sense nomad is an
orchestrator you say you need you know 10 number of ec2 instances and this binary should be
copied to these 10 instances and they should run and port 5000 will be exposed you know it's
simple and the nomad job le kind of looks like a simple nginx le also very easy to understand
probably 20 30 lines of code and you have this environment so this binary that is dumped in s3
when the deployment happens this nomad script is run and nomad is keeping track of n number
of ec2 instances running for let's say kite ticker or some other program requires you know these
other instances it'll instantly pull the binary from s3 and copy to the right location via ssh nomad
agents run and it'll send a signal to restart the app and deployment happens so nomad is great in
that sense because that all that orchestration of pulling your program from somewhere copying it
to the right easy to instances managing ec2 instances or managing it managing an automated
restart all of that nomad handles so there's that before we had nomad before we had k-8s it was
just manually created ec2 instances and some simple script would copy the program dump it
there and do a restart right at the end of the day no matter how sophisticated your ci cd system is
it's a linux linux program that is going to be killed or you know cigarette or restarted that's it so
you don't change your perspective from that so we use nomad to clean it up and make uniform
deployment templates across all our projects so people know that what is happening and it works
well so cact is really simple upload to github test runs build is created and put push to an s3
bucket that s3 bucket could be an ec2 instance it doesn't matter it's all simple plugable and from
there when we press the deploy button for critical apps nomad will pick up the program binary go
binary or a python program or whatever copy to number of ec2 instances that we've con gured to
run and you know send the reload signal right right makes sense i mean i have gone through that
go to kubernetes and come back thing myself as well i gured for me it was like more drastically
like go to kubernetes come back to just docker compose le that's enough like one docker
compose deploy everything on a single server yeah that would work uh so that's uh great and uh
i've been asking a lot of questions they'll just have one last one uh right um so uh this is about uh
and i had seen uh uh i think last year's has geek even when i talked about scaling with common
sense yeah right uh i think there's a last piece around that tech stack i would want to ask which is
not about particular technologies but uh let's say you've seen you know starting with you know
few hundred users to millions yeah uh right i mean scale obviously across all of your systems
don't work linearly like everything does not just scale to ten times because you just scaled to ten
times yeah uh nevertheless when somebody's building software yeah uh right uh i mean there is
obviously the age-old debate about premature scrailing and all yeah but pragmatically what are
the some of things one should keep in mind uh like what will happen if things scale what should i
not do so that i don't burn myself at scale yeah but also like not over complicate things so again
no easy answer yeah it's a rst principle based approach your decisions have to be as less wrong
as possible it's very di cult to make long-term right decisions with technology right so as less
wrong as possible now let's say you need a database and you pick postgres which is battle
tested now that's actually a decent decision you know that people have scaled postgres
databases to massive scale so it's not a complete unknown red is for example if you were to pick
some sort of a cache or in-memory database you could just pick redis because it's so well
documented that redis is battle tested to kind of work forever right right so when you pick these
pieces to add to your stack you pick pieces objectively and carefully right and assembling the
stack is like 80 of the work if you pick the wrong database then you're kind of screwed you have
to rewrite your app you know you can't migrate so just get careful consideration and in which you
pick robust technologies right tools for the right job before you even start writing code is that and
maybe there are other considerations also so i cited this example of using go which was a hobby
uh tinkering project for me to write a production uh ticker program right a live market ticker for for
a trading platform we could have we were python was a stack and there were other things like c
plus plus etc but this just turned out to be the best tool for that job although it wasn't a part of
that stack decided to introduce that language into the stack so sometimes you have to make
those decisions maybe you know python really well but the task at hand requires something
where go is better suited so maybe that decision to pick the right tool for the right job foregoing
our familiarity that also factors in so it's a bunch of these things then of course you shouldn't start
out you know people have this tendency to build things for 10 million users that'll never ever
come so we have to be extremely grounded and realistic so that realism will automatically
ffi
fi
fi
fl
fi
fi
fi
fi
 translate to an architecture where it's good enough to scale to a certain point uh and after that if
you really need to scale it should it would be modular enough to you know kill replay swap etc but
if you're going to build something for 100 million users or 10 million users on day one your entire
architecture you're going to focus so much on those invisible goals and problems that you will
never be able to focus on your business logic or product so keeping things modular and speaking
of modularity we also touched upon risk earlier where people think that every system has to be
100 up all the time that's never the case so that is also an important factor when you design
software when you design an architecture we should allow modules to fail gracefully for worst
case scenarios for example on a trading platform not all features are equally important maybe
there are a lot of you know let's say charting features etc worst case scenario people should be
able to see their portfolio buy and sell etc and maybe a certain charting feature not working is
acceptable but the site should not crash because of that exactly so when you think of it that way
when you look at your software holistically and decide that this is the most critical function this
has to have hundred percent uptime right but you know this can have 99 this can have 98. this
doesn't actually matter then you automatically architect your system to fail gracefully and
modularly just because this fails doesn't mean the entire thing should should fail just because this
fails it doesn't mean that your business is a ected so that grading modules of a product or a
technology stack and letting them fail gracefully will also make your system robust by doing that
you're automatically making them pluggable and swappable so we are swapping out postgres for
click house today despite having massive databases but you know that's how it allows that
modularity kind of allows you to do that right and you don't mix concerns like if you invent let's
say you pick a nosql database and if you're to do a lot of relational reporting you write end up
writing huge amounts of business logic and app code in your app in memory joints yeah in
memory joins you reinvent sql in your thing then you are that's not modular you can't swap it out
you put in so much e ort here so you should know that you know sql is the right thing to do it and
i'll you know o oad it to sql because it's a skill tomorrow when you switch uh let's just swap out
another sql db with minor tweaks you can port all your business logic so it's being modular and
i'm not talking about monolith service microservice but modular in architecture is important right
right and this modularity should never be should i mean i'm stressing should never be visualized
in terms of hosted services oh no you know function here edge thing here some you know snsq
here or whatever it should be visualized in terms of let's say linux software and modular in design
rather than modular and implementation i mean if it doesn't design the implementation will follow
suit exactly modular not in terms of external services but the software's own architecture so when
i see whenever i see architecture diagrams where someone is proposing a product and you know
it's full of let's say managed services from a certain cloud it's you know the high probability that
you know it turns out to be disastrous because they've designed their software to be entirely
dependent on completely external facets which you have little control of but if you're writing
software you should focus on software make it as self self-contained as possible and only give
away control to external service and resources if you absolutely need right right i think a factor
there i would say a lot of people do not consider also is i was giving a talk recently at a
conference about microservices and i was saying that okay and then there was a nice case study
uh i'm more than made on twitter which was like if you insert load balances uh let's say you have
a monolith you separate the data layer and the controller layer okay and you are load balancer
between them yeah so that data layer has its own load balancer now right suddenly the
architecture looks so nice i have separated my concerns and you know if somebody hits the
controller layer it will probably not fail i can scale it more data is separate but then without giving
any other context like discussing anything further uh how much does this a ect the availability um
uh anything like if you just simply take like p99 p9 in every layer you just add a new layer it will go
down it does not by default go up yeah now you doing that extraction yeah if you actually put an
e ort into making the availability higher because of that extraction maybe you don't need to reach
the data layer for a lot of use cases yeah then maybe you get an advantage yeah but if you don't
then the default is you lose out absolutely and then the other piece is also uh and that was part of
what i was explaining in the talk is like there were a lot of people who were you know founders of
tech companies and then they were talking about like whether they need to do microservices or
not yeah and i'm telling them that what's very important is the boundaries you draw in your
system you need to draw the correct ones yeah i was giving them an example like if you have a
blogging app if you have let's say the api layer the business logic layer and the data layer if you
separate at this way yeah like all the apis in one service all the business logic in one service all the
data what will happen is between them each hop will have a deceleration serialization penalty
yeah whether inside your system or outside the penalty would be there absolutely right and but if
ff
ffl
ff
ff
ff
 you split by features let's say yeah and let's say if user sign-in is not available so my user service
is down but still people can publicly you know like index the articles google search works and
your article reading works yeah that's a much better split you a don't get the penalty of the
deceleration serialization yeah second year split it across things which you need and not need
rather than layer layer you have to grade those modules to fail independently and as gracefully as
possible yeah so dependency is one of the biggest bottlenecks a dependency and every network
dependency that you have is a you know is prone to disaster and failure and if you have a system
where you have lots of services all of them speak to each other over network mesh etc right
something goes wrong you can't even debug so software should be as self-contained as possible
by default so that that's why it's problematic saying i'll start out with the monolith or i'll start out
with the microservice architecture there's no such thing as a microservice architecture that works
for all software all people all teams all business all environments around the world it's just it's just
a loose name it's a vague name for a loose set of concepts right you may end up writing many
services you may end up with just one service or software but you don't know that entirely
depends on so many factors that are so private and intimate you know to a certain business so
there are no universal architectures that just work great i think thanks for answering all the
questions the last question one of the answers that take away i think really great where you say
that you know let's not think about writing microservices let's write software i think yeah i hope
that that becomes a very important takeaway uh from this uh but once again you know thanks for
coming here spending the time and this conversation i really really hope it will spark some
motivation to build things for people build software right software absolutely thank you thank you
so much it was a fun chat thank you and i think i've entered quite a bit yeah thanks for providing
me with an avenue to end thank you thank you so much thanks [Music] of course we joke about it
we meme about it it's a really hard reality of our lives but you know we have gotten used to it we
expect crazy regulatory changes at any given moment i say that because that comes before
technical skills of course you need talent and technical skills and expertise to build you know
systems you have to sit and write software they look at the peers and suddenly you know that
other organization has 50 people so we have to hire we need product managers we need more
developers we need more dedicated designers right but we need to build a certain thing it needs
to be able to handle let's say a million users whatever in that you know context let's go serverless
or let's pick this cloud that's that is that's very top-down thinking yeah so it has to be rst
principles you know and you know i've been getting annoyed and i've been getting frustrated and
that typically is inspiration to you know tinker and write something on your own right so the unit
conversions you know i could just write a simple bash script for myself a lot of forces really
altruism right some of the most valuable projects in the world that all of us you know billions of
people use are made by a handful of people who make it because they like making it they
struggle to make a living with you know with a di cult job and at the same time they contribute
their personal time and e ort into a fast project that they give out to the entire world for free back
then it was just me when we started zero that tech was just me and i was sitting there i'd go sit
with non-tech folks nd their problems you know write python scripts to automate and at some
point you know i had too many you know people got the taste of automation it wasn't even tech it
was automation and the stack has largely stayed the same it's go python for stu postgres redis
kafka nats and all performing what they do best our annual bill is probably not even like an
instagram campaign for many startups that's how low the bill is at the end of the day no matter
how sophisticated your ci cd system is it's a linux linux program that is going to be killed or you
know sig helped or restarted that's it hey welcome to yet another episode of scale of pod and uh
today we have uh someone with us uh that has been very fairly demanded from every episode we
have shot until now people have commented that uh please bring dr kailash nathan episode so
we have him today thank you so much for taking out your time thank you right um so we will of
course uh have a lot of things to talk about i would de nitely start o with my pet question that
i've been doing for every episode is like what does a day in your life look like and then mostly in
context of work and i've gotten very di erent answers so i'd love to uh yeah rstly again thanks
thanks for having me here hearing dr kerashnaz is a little awkward you could just call me here i
know i won't do that anymore but that's like i've seen like nathan post like dr k every time and i
really like that yeah that's that's my nickname so uh how it day looks it has changed drastically
over the last few years and there have been distinct faces but what has been constant here and
maybe a little peculiar in our industry is the regulatory weight and you wake up you have certain
plans for the day could be writing software it could be you know certain meetings the meeting to
gure out technical non-technical decisions suddenly there could be this regulatory thunderbolt
that completely changes uh your day and the subsequent 30 days where you have to pass
fi
fi
ff
ff
ffi
fi
ff
fi
ff
fi
 absolutely everything so that's really a reality of life and over the last couple of years there have
been crazy number of regulatory changes in the industry all for the better but really di cult ones
so days are really unpredictable you know you get on with a certain project that you've been
working on and suddenly you have to pause suspend absolutely everything and re ght uh for the
next several days so there's been a lot of that lately right right and and on a more personal note
like apart from like everything that's happening in zero then everything do you get time on a
regular basis to sort of tinker around with things i've seen of course a lot of your open source
projects like does that happen in pockets of time do you try to schedule some time for that
scheduling is impossible but i nd i try to nd time regularly uh late evenings largely and mostly
you know full weekends so i dedicate a lot of time i i feel if i don't do that i'll start maybe getting
bored of things in general so for me nding time for hobby is is a necessity and of course i you
know enjoy it it's a win-win but yes very regularly right uh another question around that was very
interesting i've had a lot of answers from quite a few folks is about like when you are managing a
team and you know uh been doing it for a while uh sort of the importance of uh writing code and
i've gotten fairly di erent answers from people as well so what is it for you like you know how
much is it just hobby how much do you think you really need to do that to stay abreast of things
staying abreast of things as a speci c goal is something that i don't really think about because i
write code on a regular basis anyway so i never had to i was i've never been at a point where i
think back and think that oh i'm maybe losing touch but that said that's absolutely necessary
unfortunately we get to see especially in our industry you know heavily regulated capital markets
industry lots of people who completely lost touch with technology in general making very
technical decisions and often wrong ones so i think that is very necessary right but because uh i
regularly write software just like you know all of us in our tech team it hasn't really been a thought
and why do i write it i mean i like it uh if of course if i couldn't write software i wouldn't be you
know doing whatever i'm doing right um so i have a question around because you're saying about
like regulatory uh you know nightmares and that happened and i think it's fairly discussed in terms
of like uh say a business impact or like sometimes whole ntech companies piloting because of
that yeah i obviously want to you know use this opportunity to also delve a little bit into how does
it impact uh like a tech team working on something for example i mean i'm a regular user of zero
that's my trading platform and uh i think you have to directly pay for mutual funds now i think a
couple of months back yeah yeah it sort of changed because i just love my funds in one place
stocks and mfs in the same place yeah now i have to do that upi thing yeah um so when
something like that just suddenly drops yeah right and i guess you don't really get a lot of
forewarning or something around stu like that usually right yeah so when something like that
drops like uh from a tech perspective like what are your usually next steps like maybe a well-oiled
machine everything is going on and suddenly you have to cater to this so thankfully i think one of
the things that we cracked early on as a team was handling scenarios like this if we didn't have a
very speci c and rather sane framework for handling these regulatory scenarios i think we'd have
found it extremely hard to cope with like the huge number of changes that we've seen over the
last many years and if a tech team is constantly pressurized and burdened with making regulatory
changes scrapping systems you've built just because regulations change if you don't truly
internalize and accept that that is the reality of life in the industry it's very di cult to survive so
thankfully very very early on like almost a decade ago we kind of realized this and how we build
software you know architectural decisions software decisions business slash product feature
decisions all of that is heavily based on this regulatory framework so one of the exercises that we
do is to try and foresee what could you know common sense uh changes you know that oh it
works a certain way but there's a high probability that three years from now you know it might
change because of regulations so that foresight as an exercise we try to incorporate into all our
software decisions even things that even writing modules for certain software you kind of you
know expect that ah this might have to be scrapped so when you do that uh and all your decision
making in any business idea any product any you know software architecture when it all
incorporates these tiny things these this form of decision making over time it kind of puts you in a
place where things aren't as hard yes you still have to scrap systems but you foresaw that anyway
and if you get 80 of that right right i mean of course it's super annoying having to delete
everything stop everything but it's not impossible we could have been once you get to a certain
scale and you know risk increases it would have been extremely risky to just scrap things if things
were not built to be scrapped so everyone in the team you know of course we joke about it we
meme about it it's a really hard reality of our lives but you know we have gotten used to it we
expect crazy regulatory changes at any given moment and thankfully our systems and processes
are 80 percent always ready to be tweaked and scrapped so we cope with it but it's been a it's
fi
ff
fi
fi
fi
ff
fi
fi
ffi
fi
fi
ffi
been a long exercise of thinking like that you know long time in the making and we got really lucky
that we wired ourselves to accept that makes sense uh i i have a uh you know a question about
also sort of the product uh philosophy yeah uh especially in zero that's context and i uh thought
of if i ever get somebody to talk to at zero then ask about this because uh for example every day
like there are hours during the night when some of the functionality in on the app and all stop right
and it's a philosophical decision i believe because somebody can build a product not having
those things in place like how did it come to be i just really want to have a you know broader
perspective around how did it come to be like why do you have maintenance time every day as a
ux it does not a ect me i'm very ne because 2 am at night i'm not trading stu but it does
happen so how did it come to be like that it's not a philosophical decision you know we are
forced to have uh maintenance windows not just us it's basically the norm in the industry okay
and uh back in the day it would be like a seven hour you know uh down time where all systems go
down and you know lots of stu happens but today we've brought it down to let's say an hour an
hour and a half so why it happens is that this industry is uh eod end of the day end of the day it's
settlements and all correct so this entire industry base runs on end of the day settlements all the
real-time trades that you do investments that you do throughout the day yeah they are real-time
that them being real-time is kind of an illusion the actual settlement only happens at the end of the
day right so for us if we process let's say 10 10 15 million orders in a day we get 15 million orders
worth of data dumps from the exchange on on a volatile day that can be delayed so you get uh
data from many di erent sources you know like dozens of massive dumps at the end of the day
you have to crunch everything you have to do settlements you have to recon gure users accounts
you know balances cetera you have to send copies of the results to many di erent institutions
exchanges deposits trees etc so that these are really long and complex processes right there
could be you could have six data dumps that you were waiting for but the seventh one could be
randomly two hours late right so when these processes are happening and these are really uh
complex processes and we've put in humongous amounts of work to you know bring them down
for from 20 hours to eight hours to four hours to let's say 20 minutes just last week we rewrote our
entire contract note you get that pdf at the end of the day process right yeah yeah so that had
over time this is i think the fth rewrite in the last seven years okay so with this new rewrite
everything is done in 20 minutes including you know pushing out let's say a million emails but
while these things are happening the state that you see on your trading platform that's already
stale but once the new states are computed new balances new positions new results new
everything they have to be loaded into all these systems now just processing itself could involve
let's say you know uh recomputing 100 billion rows of nancial records you know historical prices
yeah yeah so all of this has to happen and the new states have to be loaded onto the trading
platform so we've made it so that while all of these things are happening you can still access
everything but the loading process the sheer volume and size of data that has to be refreshed the
new states that take some time right and like i said we've brought that window down to let's say
an hour and it's it's an unfortunate it's an unfortunate side e ect of the nature of end of the day
settlements and if you haven't put in huge amounts of engineering e ort it'll be hours and hours
and you'd be down for let's say eight hours throughout the night but yeah it's not a philosophical
decision we are forced to force by yeah that kind of uh situation and and it's an ongoing exercise
to bring that window you know uh down as much as possible continuously got it got it got it uh
makes a lot of sense now uh so uh hearing about of course like uh the process that goes behind
like you're saying you know millions of trades happening every day yeah you know and then
reconciling all of that data and then this is obviously a question about uh like how do you
achieving all of this with a small team lines it's a question that keeps coming a lot of places i've
seen i've seen i think once you replied on a reddit thread about that yeah we are really just 30
people yeah i i've known a few of people in your team from some time back so i really know that it
is 30 people for the audience you know you're not faking it but uh i mean it's it's uh very uh
common for a lot of people in the industry to early stage career places their work they have
probably seen uh like pretty big tech teams yeah and and maybe the uh you know the perspective
that it gives a lot of people is that okay uh moving around this amount of data millions of users it's
probably just not something we can even achieve with less than 300 engineers or something uh
right uh so i'd love to uh you know get uh you know your perspectives around like of course at
zero the how is it being achieved with so uh less people and i love that you had a point there that
this should be the norm for a lot of industries as well um so yeah how is it possible where are the
places where it can be possible it's rstly it's very di cult to answer uh so the question typically
comes top down how can you do all of this with let's say 30 people yes but we never set out to
do any of this with any number of people we started out really small and things just happened to
ff
ff
fi
ff
fi
fi
ffi
fi
ff
ff
ff
fi
ff
 be so it's very important to go uh from the bottom up when looking at this exactly that that you
know so there's no formula for replicating tomorrow let's say you want to build a product like
xeroda but maybe that something that only happens one uh one tenth of the scale now could you
do that with ve people or ten people or fty people it's impossible to say or no so it's literally a
function of the time that we've put in and how the team has come to be now uh as i said earlier
everyone in the team has a certain way of thinking you know that regulatory framework the
framework of risk that we operate and we really understand right now if you were constantly burnt
out by that and if you were unable to collaborate a 30 member team could never build any of this
so the key is that we gel really well with each other you know we know how to have fun we know
how to you know work around our mistakes and laugh about our mistakes and also laugh at our
successes so i think the way the team has evolved over the last nine plus years uh to this tight-
knit gang plays probably the most important role in this outcome how how a 30 member team can
build stu uh or you know large scale stu they have to work really really well with each other i
say that because that comes before technical skills now of course you need talent and technical
skills and expertise to build you know systems you have to sit and write software right but if you
had a bunch of people who were exceptionally technically skilled but who couldn't work with each
other especially in a in an environment like this heavily regulated you know the team would fall
apart fall apart in no time right and so that really is key how we've stuck to our principles how
we've been grounded since day one when we had 5000 users let's say in 2013 to today you know
10 plus million users we are our attitudes have not changed you know we stick together we
collaborate well we write software scrap software rewrite software for the sixth time we have fun
and uh that also means that the decisions are objective and technical the moment you have let's
say tech versus management divide yeah i think it's impossible i mean it doesn't matter if you
have 30 people 40 people 100 people i mean it would be very very di cult right for people to stick
together they have to be in an environment that they are comfortable in especially you know
technical folks who are creative and writing software is not only scienti c it's also a creative
endeavor so again you'd see that there's no formula here it's really about people and how people
work with each other and thankfully again from the very very beginning at zeroda we we haven't
had the technical versus management divide as in you know you suddenly get email requirements
from the management no questions asked and you're supposed to build it you'll never be able to
build quality software uh with solid philosophies and rational if that's how it functioned where
someone sent you a requirement you had no idea why and you were forced to do it right so from
the very beginning we we've been conscious of that and that uh tech how the tech team works
with non-tech teams it's been philosophical and it's been very collaborative everyone sits down
together so anyone could bring up an idea propose an idea people can shoot it down people are
free to shoot ideas down in fact probably 95 percent of all ideas that we've proposed have been
shot down objectively and tech in non-tech teams they they know you know we have the right
culture where people respect such objective decisions right so that also has meant that people
with deep nancial domain knowledge mostly non-tech folks now today tech folks also
understand lots of you know with nancial bits but in the early days it was all the domain
knowledge were with the nance folks but because we were able to work hand in hand it was
possible to bring that deep nancial knowledge and create and the creative endeavor of endeavor
of writing software for nance together people sat together all of us have always sat together on
the same oor you just walk up have a discussion decision you know debate decide right so it's
it's really that it's really that culture that has enabled us to build whatever we built with just 30
people and it just happened to be and of course skills and the right kind of technical decisions are
absolutely necessary wrong decisions could be disastrous so of course there's that too we put in
humongous amounts of engineering e ort and r d e ort right but going back to that number how
can such a small team achieve something like this absolutely how the team works with each other
it's the culture and philosophies makes sense yeah uh so i mean uh and this is a i think a
discussion around like what sort of the team size you need to achieve something and i've had
with other folks as well in the past and i remember actually early days when i used to run a startup
and we had like three full-time engineers and a couple of interns and uh there was a time i had
come to a conference in bangalore and there were some other tech founders and we were talking
about and then they said like you know what kind of numbers and all you're doing and i say that
okay you know maybe one or two million uh a year we are doing in revenues we have some you
know probably free users we have about uh you know half a million of them some 10 20 000 paid
users at this scale how are you running with four engineers and uh i think i mean i i just uh asked
him the counter question is like you know okay he was doing probably in revenues a little less i'm
like okay ne that's uh regardless of that but your systems look very similar to me yeah there's
ff
fi
fl
fi
fi
fi
fi
fi
fi
ff
fi
ff
ff
ffi
fi
some video being played there's some notes people are writing some questions being sold mcqs
and also educational system very similar yeah you do have like 30 people in the team like why do
you have that i mean that's also a question because uh i did not form a team thinking to before
people i never needed more than that yeah and you were saying uh we uh had this idea then we
raised some funding then we thought okay to build this we will need 30 people so i think the uh
thinking comes from okay to build these 10 things we will need 30 people that's the reason he
had 30 people rather than uh probably starting to build it and see where it goes yeah maybe that
does play a bit of a i think uh because there are enough examples of uh things built at a very big
scale both in terms of features that are there users that are there and you had a team of maybe 10
people 20 people i mean whatsapp was very famous for that when they got acquired they had
something 19 people or so and people started 1 billion people working on that app how is it
possible that's right but i really like that piece of the answer which is like you have to sit down
with the i mean non-tech rather than talking about it in those terms like have somebody with
domain expertise and understand what they want solve that problem together yeah um and it still
is like that you're saying absolutely nothing has absolutely nothing has changed we still debate
ideas sometimes debates go on for days and ideas are always shot down anybody's free to
propose an idea so you have to if you feel that any idea that you raise will be immediately shot
down by the management i don't think you'll be at your creative best in such an environment so
it's it's ingrained in the culture that anybody can propose any anything anybody can question
anything and the outcomes have to be objective you know we can we could have a really tight
decision but you know you write down bullet points on the left left side and right side and
whatever weighs slightly more that's the objective decision and that has in hindsight worked really
well for us and to go back to the anecdote you just shared i really don't know how that works i
don't know how it's possible to reduce humans uh humans who are especially creative let's say
software developers or you know product folks how you can reduce them to units and say that
this particular piece of software requires uh six human units or 30 human units i i really don't
understand how that works and i've never seen that example play out really well that approach
sorry play out really well anywhere so when when and i think there's a huge this is huge
component of fomo there uh let's say you have a product that is becoming bigger growing and
you receive funding and you have three engineers i mean people will ask questions how can you
build you know what are we applying to build with three engineers so you start doubting yourself
and i've seen this quite a bit even in really young startups who are just maybe a year or two too
old they look at the peers and suddenly you know that other organization has 50 people so we
have to hire we need product managers we need more developers we need more dedicated
designers right so a lot of external factors in uence decision making and how to build tech teams
and you end up with massive teams where everyone's a little lost yeah there's a little bit of
manufactured complexity also in your systems because conveys obviously due to e ect there as
well absolutely absolutely because if you have let's say 50 people they have to do something right
so you automatically implicitly and subconsciously start creating you know complicating your
architecture complicating your design to give everyone enough work so it's a vicious cycle and it
just keeps on getting worse the more complex it becomes the more people you need and beyond
a certain number of uh people you have to now have other people who manage communication
and results and all and suddenly you get really rigid hierarchies and you keep on growing so once
you grow you have to keep on growing so and and as i said i've never seen a successful example
of someone saying this particular piece of software needs ex-human units and it working out
exactly like that you can't you can't it's like you said it's possible for 20 people to build a
whatsapp uh that can handle billions of users it's possible for 2000 people to build terrible let's
say no net banking applications that don't work so yeah um on that case uh because he talked
about that uh tech and business thing and then um jacob was here on the episodes of scale apart
and he was talking about uh an anecdote where um the vcs had an interview with the ceo and the
cto and then they were like very impressed that you know how how did both of you have the
same answers as to what you want to do in the next ve years and then and jacob uh say this uh
part which i had in the teaser of that episode as well right absolutely completely totally hate the
word the business i mean the tech is the business you know the same thing and business are not
separate things but but that's it the the this divide whether it's in minds of people or it's actually
there it does exist in a lot of uh places right um and then our audience being like the you know the
engineers and the tech people um so my question is uh like as an engineer and you're growing
you started building things you know hacking around maybe you've joined a company you're
working on things uh how do you also sort of gather more perspective about the business how do
you not think of okay this is what i was told to build i don't know what how it is going to be used
fl
fi
ff
 and that kind of sometimes mindset can percolate if you are in a environment where you have a
tech versus business thing yeah but i think part of the bonus is also with the engineers too uh
because it's a bridge and everybody has to come to the middle yeah so at a more philosophical
level when somebody's growing as an engineer how do you go about making sure that you go at
least to the center of the bridge for the tech versus business divide so i think uh i think it's di cult
honestly for young engineers folks who are just starting out it's very di cult because their
worldview hasn't formed they don't know that they have an opinion and in many organizations
engineers unfortunately have no voice or opinion and even in you know tech companies right so i
think the burden the weight really lies with the management in culture in an organization you know
it has to come from top down right and no matter how hard engineers try engineers cannot really
create an engineering culture if the management isn't up for it if they are not in on it so if to have
to cross a bridge there has to be a bridge yeah and it's very di cult in an organization that
doesn't really have the right culture of collaboration between tech and non-tech folks it's very
di cult to build that bridge you you have entire managerial frameworks you know this whole
requirements thing where requirements come in you're supposed to build it nancial let's say in a
nancial company nancial decisions are made by someone sitting somewhere there's no
rationale you get a thing saying oh add this button at this report prd yeah yeah and you're
supposed to just do it yeah and you're supposed to report to your manager now if there's no
culture that has been established by the management themselves it's impossible for engineers to
even attempt to cross the bridge because that bridge has to be built and sustained by the
management if the management is open i mean people will immediately people who are willing to
contribute will naturally immediately gure out that oh it is possible to have a dialogue right and
it's just that and most in many organizations unfortunately where there's this tech versus non-tech
divide there's no dialogue you get you know you get requirements you build you don't even know
why you're building it could be wrong it could it could weigh negatively on the software
architecture but why would a non-managed non-tech management care about software
architecture right so it has to be top down it has to be the culture has to be established by the
management makes sense uh here and then i will play a bit of a devil's advocate here and it's
probably the question is not coming from perspective that is uh personal but uh uh say speaking
on behalf of let's say a non-tech and a you know business oriented founder let's say yeah um and
then we talked about it when we met at force india as well so it's uh why should we invest in an
engineering rst culture let's just say somebody says that okay i have a bunch of requirements if
the tech team just builds it i will go ahead and keep building my team ahead and you know yeah i
don't need an engineering culture to exist in my team yeah and fortunately unfortunately wherever
you put it but i have seen this sort of dialogue also from people right right and then i think that the
result of that is like a lot of times people very passionate and very highly motivated engineers get
into a company which like from the outside looks like doing great business but they're like you
know we just left a year later because we did not feel like having a good engineering culture yeah
so i mean before coming to i think the engineering culture and hacker and open space i will talk
about that as well but yeah what's the uh you know need even for building an engineering culture
uh you would say i think you touched upon it uh a little while ago where you know this whole tech
versus non-tech thing i think that line is now blurring so if you remember there used to be tech
enabled businesses it used to be a thing correct but today everyone is kind of a tech business
even companies that run on excel sheets you know are kind of digital tech businesses and we
have this entire category of terms like food tech i know travel tech you know ntech whatever
these were all uh tech enabled businesses where business was nanced like zeroth for example
you know zeroth primary business is nancial services right so uh maybe eight nine years ago
zero that would be looked upon as a com as an organization that o ers some technology as a
means merely as a means to provide nancial services right but today it's completely changed
you know people see zeruda as a technology provider not just a nancial services provider so has
turned into an engineering tech company right and so it's it's a way of looking at that if you
consider that your business just needs tech as one of the small little pieces to run the business of
many other pieces then it's very di cult to have an engineering culture there are if an organization
if a certain business relies heavily on technology and even if it's let's say nancial services or food
services or agriculture or whatever but if engineering and technology are a core proposition of the
business and that requires self-awareness you can always compartmentalize saying oh there's
this tech team they'll build whatever we want but our business is nance my it team exactly my id
so but we are nancial folks we only do nance and you know tech is just a means so if you look
at the business from that perspective sorry as i mentioned it's very di cult to establish an
engineering culture because it's just one of the necessary evils right but as i said the lines of
fi
ffi
fi
fi
fi
ffi
fi
fi
fi
fi
ffi
fi
fi
fi
ff
ffi
ffi
fi
fi
fi
ffi
 blurred music has become a technology company from a pure nancial company so there are the
o ers technology plus nancial services now and that is that has that transformation has played a
key role in zero da and maybe reinventing or re-establishing itself as a di erent kind of a player
over the last you know let's say half decade now if that wasn't the case maybe zero would be an
entirely di erent kind of company which o ered some nancial services but you know there
wasn't uh i know scale or growth or whatever in in today's terms so what is the necessity here if a
certain business uh if technology and engineering is core to a certain business and realizing that it
is or whether it is or whether it is not it's really the rst big leap makes sense so if it is core you
need to have uh that becomes the core proposition of your business going forward that de nes
your future and it becomes imperative to have a good technology team and what exactly is a
good technology team team with people who are happy doing what they're doing and i mean
content not super happy maybe but you know people who don't hate what they're doing correct
and and again technology as it grows as complexity grows you can't just have you know you
can't just get two developers and get them to x certain things build new things you know chuck
them out get to people it's an ongoing like a very long-term underwear right the developers who
build software that software enters their mind space and it lives in their heads yeah and any knob
that you need to tweak the correct way you know quickly x a certain thing or quickly scrap a
certain thing build new features it's all in their heads yeah it's just like a completely imagined
spaceship kind of thing you have in your head you know the live parts it is some sort of a diagram
in your head not sometimes not even easier to visualize but absolutely so it's not like a
commodity where let's say you have a mixer grinder that breaks down you can take it to any
mechanic and because it's a commodity it's so simple it's trivial they can all x it but complex
software it needs people who built that software with deep understanding of its nuances and the
million decisions that have been taken over the years to operate it right now all of that those
things lives in the minds of in your engineers and product folks and if their minds are not happy
and they're churning and you know your engineering team is constantly losing people new people
coming out of course that is going to re ect immediately physically and heavily negatively on your
software you'll have poorly built software you'll end up with legacy software nobody can rewrite
like the legacy software overnight and all the people who liked it built it they've gone because you
don't really have an engineering culture so from a maybe a transactional perspective i'm not a fan
of this perspective but from a purely transactional perspective a sel sh perspective for a business
if a business is going to rely on tech if tech is tech and engineering are going to be core to it and if
they don't cultivate an engineering uh culture i mean it's going to be disastrous for them we can
yeah we can just we just have to look around us massive organizations with unlimited resources
legacy organizations who produce terrible software who are struggling today right and the nance
industry you know has so many great examples right it's all because of that they refused to
accept that technology was core to them they you know they ended up keeping it as just one of
those things that has to be serviced and there's no tech talent why would people want to work in
why would creative people who like creative endeavors want to work in an environment where
there's no creativity it's just a means to you know delivering certain kinds of business right right
so absolutely imperative for businesses uh to do this if they really want to survive yeah yeah uh
and there's bringing to another question of course because we were talking about engineering
culture right um what in your opinion is a good engineering culture also i'd love to love to ask
because like if you walk into a tech team and like what do you expect to see which would make
you say that okay this team has great engineering culture and i say that from perspective of let's
say somebody wants to join some company how do they decide whether this place has great
engineering culture or not uh that's also a tricky one culture is very subjective what culturally
works for let's say zeruda may not work for a di erent environment fair enough so it's highly
subjective right and that really is the very de nition of culture right it's an amalgamation of things
that change exactly accumulated with things which are appropriate for a certain environment right
so as i said our culture heavily is built around understanding and accepting the risk in the
business in a non-risky environment the culture would be completely di erent but there are
certain principles that are common rstly people have to be chill with each other irrespective of
you know people have to have uh people have to be able to make fun of each other without
reservations uh people you know nobody nothing is sacrosanct right we have in our team we have
memes about everyone there are new memes that are made every day i think there are like six or
seven di erent smileys in very non- attering poses of my face and each smiley you know denotes
a di erent kind of you know situation yeah so there's all of that and that's just a tiny part of uh the
overall facet which is you know people have to be able to gel well with each other yeah that's one
thing and secondly what i would de nitely weigh uh sorry give heavy weightage to is how people
ff
ff
ff
ff
fi
fl
fi
fi
fl
ff
fi
fi
ff
fi
fi
fi
fi
fi
ff
ff
fi
fi
fi
 operate how systems are designed whether they are from rst principles or not so that is also a
part of culture that thinking that we need to build a certain thing it needs to be able to handle let's
say a million users whatever in that you know context uh let's go serverless or let's pick this cloud
that's that is that's very top-down thinking yeah so it has to be rst principles you know what are
these million users do they even need this certain feature so should we even bother building it so
it has to always start from uh from the absolute bottom from complete from rst principles so how
a team makes engineering decisions architectural decisions that are going to be with them for the
next decade you know that will de ne their very survival that comes from rst principles thinking
and teams that get together and collaborate on rst principles tend to i think tend again tend to
gel well with each other because you know there's no reservations you're free to shoot down
things objectively saying oh no that's not a good idea because you know abcd is wrong that's
only possible when the thinking is from rst principle when the you know when what it's bottoms
up so it's really that the people should be able to gel well with each other and technical business
and engineering decisions within that team should be objective and should be from rst principles
i think these are kind of two hallmarks of good engineering culture and of course lots of things
change it's subjective but these are you know largely universal i think makes sense i think i
de nitely relate to that point about breaking down the barriers and the memes and all because i
have uh at one point of time worked in a much larger company with a hierarchical setup and there
are people in my team much older than me so to even write a code review and saying that
something objectively i just have it's the review on the code not on the person right yeah you still
have to see the manager because okay that person might get o ended and then obviously it's not
it's not a great environment to be able to uh discuss the you know technical merits of something if
those barriers exist in the rst place yeah for sure uh about the uh no uh other partner spelled uh
right rst principles thinking now um for rst uh and i will actually of course like you said
serverless there are very concrete examples of using say uh you know nosql dbs and very
interesting blog articles that you had written about how you have been scaling postgres at uh
there right and again i i see because teaching so i see a lot of people uh youngsters and maybe a
little disadvantage being mongodb is a company um right and then not to throw shade on them i
mean there's de nitely good use cases of that uh but but of course if it gets marketed a lot versus
something like you know using uh mysql of postgres there's nobody to market that's an open
source project uh solvently people develop a habit of say building a lot of projects and of course if
a particular tool has way too many libraries available easy to quickly use people can sort of get
into it uh and maybe that's also a great way to start that's ne but as you grow as an engineer
how do you sort of keep yourself grounded to the rst principles if you could have a word of
advice around that i think it's about self-awareness and awareness in general yeah so somebody
who starts out young and let's say their foundation are no no sqldbs like you said nothing wrong
with them they have their use cases and they've never been able to work with relational
databases how do you even know what you don't know now that's a big trap how do you know
that you may be wrong so it's very di cult and if you fall into that trap of you know it's always
buying into hype you wouldn't even know that you know you're wrong maybe right so it's it's very
important to have hands-on experience on a wide variety of engineering you know topics and
aspects there's literally no other way if you've never built a new and a relational a system that
uses relational databases you wouldn't even know you can't even make that decision so it's very
important to work on as many hands-on projects as possible but how do you know that you have
to work on maybe somebody has to i know tell maybe somebody has to mentor or guide but that
starting point just that just growing that awareness that's it once you have that awareness then
like a billion resources on the internet you can learn whatever you want you can build whatever
you want but it's just that starting point people have to know that what we know uh may not there
there there are huge number of things outside of what we know what our narrow focus all the time
just that realization and self-awareness that that's what's most critical right and that's the starting
point so i don't really have any solutions on how someone can gain that but like i said maybe
maybe it's accidental uh maybe it's just you know people feel that or maybe they need some
handholding got it got it uh around that i think uh and then uh we talked about like uh what are the
things we would uh want to talk about here and you said about like you know building projects
versus uh products kind of thing and i really uh you know what what uh youngsters say vibed with
that because uh when i uh teach some classes and you know after teachings let's say concepts
of okay how to build an api how to build a you know orm and all of that okay now go ahead and
build a project yeah and one of the largest feedbacks i think probably 70 of people come back
and say i spent a couple of days could not come up with an idea yeah to build something yeah
and then and it sometimes feels very uh it doesn't work like hey you know you don't really have to
fi
fi
fi
fi
fi
ffi
fi
fi
fi
fi
fi
fi
fi
ff
fi
fi
fi
come with an idea that's unique enough or not like however just build a blogging app or
something like that build a calculator maybe but yeah just go ahead and build yeah right uh i
mean you have also obviously seen a lot of engineers grow via this you know uh tinkering culture
and you yourself call yourself a tinkerest so uh how much this is important and you know why is it
important for people to develop this you would say i think it's paramount it's probably one of the
most critical things required to be a good engineer and and to be able to learn uh what we were
just discussing prior if you don't know what you don't know how do you even get started yeah
and building things hands-on breaking things getting experience realizing that oh i can do this or i
can't do this it's a it's a it's the single biggest step unless you write software hands-on you can't
learn you know you can read resources watch podcasts and videos for forever for years you'll
never be able to produce you know decent software but if you start writing software and produce
bad software and improve it and the very act of writing software and producing bad software
you're automatically improving you know that tiny badness you can you know you'll x it and you
would have learned something so nothing absolutely nothing beats that and all engineers in the
world who are good they're all self-taught so so it's basically it's basically that the act of writing
software hands-on is the single biggest requirement to being uh to being a good engineer right
right right yeah uh i would like to take an example there i mean uh and i just uh recently checked
out when you're published dns.toys uh and and uh i was having a discussion with my friend
saman and he's uh he's a engineer at a big tech company and he was like i just loved it because i
opened the github repository and i look at the code and i see okay no 20 di erent classes or
something it's just you know whatever we need to get it done the the code inside each function
looks very clear and concise but everything is in one single le that's ne i i'd like to you know
probably like go a little uh deeper into like how did that idea come to your mind like why playing
around with the dns protocol to like give answers like time zones and everything so that the
answer to that also answers your previous question like you said sometimes students come up
and say i don't know what to build that's actually a very legitimate problem it's like a writer's
block you can't come up with unique ideas every day and sometimes you look for many many
years to you really have the drive to build something but you don't know what to build right and
you can't bring yourself to building let's say you know trivial things you want something new or
unique but if you look at uh most hobby projects out there most foss they've all largely they're all
largely born out of real world problems that people faced or frustration like most of my open
source projects that i've published i've stumbled upon them not because i was looking for certain
ideas i had a certain problem i encountered a problem i built software to solve that problem then i
realized oh this can be extended given out to others you pick any large or small open source
software out there it's largely it largely the genesis would have been basically that you know
people facing a certain problem and then trying to solve that so yes to experiment i'm sorry i'm
still trying to try answering your previous questions uh that that that urge to tinker has to be there
but if you go looking for ideas it's you know you're probably setting yourself up for
disappointment but when you come across a problem you have to jump on it and you know write
some software you know tinker yeah so dns toys is an ex is a great example uh for that i had no i
had no vision to write any you know dns related things but uh i found i i nd myself entering
random queries into google every day you know unit conversions or whatever and over a period
of time i've seen that from simple you know expression matching you know 10 gb to 5 mb yeah
it's a simple you know string passing thing i don't know google's overly sophisticated technology
and maybe machine learning models you know you don't it's very sometimes it's di cult to get
answers to those straightforward questions also you get absurd answers you know it just goes as
a query and the you know result doesn't show up especially speci cally with unit conversion or
you know simple one-line queries to which you really quickly need answers and you know i've
been getting annoyed and i've been getting frustrated and that typically is inspiration to you know
tinker and write something on your own right so unit conversions you know i could just uh write a
simple bash script for myself yeah but you know that wouldn't be as much fun so then i gured
maybe you know it could be a service online where i can just quickly get an answer to some of
these commonly common queries that i raise every day on the terminal now that could be you
know an http service you could query it with girl but girl it just didn't you know just seemed a little
inadequate and then i randomly had that had this thought i don't know what had primed me to
dns i mean dig is everywhere dns is a product it's a super super simple protocol it's universal it's
ancient it's raw it's so beautiful right you send a query you get an answer udp and it's just so
good yeah then i thought you know why can't i abuse that it's raw it's you know more rst
principles than let's say curl because atp is a you know yeah more complex protocol compared to
dns so i thought you know someone would have done it someone would have abused dns of
fi
fi
fi
fi
ff
ffi
fi
fi
fi
 course people abused dns for everything yeah yeah but then i saw that nobody had abused dns
to get queries to answers and it makes perfect sense you send a dns query the whole system is
around the concepts of sending a question and getting answers like why not you know add this
unit conversion thing to that then i was like oh i also you know tend to check weather every day
you know bangalore temperature bangalore weather we always google that and you know why
not add a weather service then i thought oh there are these other things sometimes you know you
get a really big number uh let's say 10 or 11 digit number and you know i nd it hard to mentally
pass you know i have to count decimals yeah so you know i google you know numbers to english
words or whatever land on some random website paste that so that's also a query that i
frequently need answered so why not add that so i added a bunch of things and suddenly i had a
dns server that could answer some of these queries and it was universal like you know just that
it's purity the protocol's purity was very attractive yeah so i made it you know i then of course if
you're typing it every day it has to have a really short domain name if i have dns answers and
questions.com that'd be that de es the point so i looked for a domain and found dns.toys so i can
just say bangalore.weather dig bangalore.weather at dnstoys and i get the answer yeah and that
really satis ed you know that urge it scratched my itch yeah of course i i turned it into a website
published the repository and you know it became an open source project right right but that's
really the genesis of many you know hobby projects that it's that one problem that you want
solved it's it bugs you annoys you that itch you want scratched and just because you know you're
an engineer you know when you can do dns why do http yeah so all of those things put together
you know hobby project is born right right right actually that reminds me of something very similar
i had done this story feels so familiar because uh so i it was uh you know just before the
pandemic time and i was doing a few consulting with some people who were outside india
di erent places yeah and you know we'll meet at 1 pm okay who's 1 pm or 1 pm 1 my 1 pm all of
that stu then i used to you know uh start guring out that uh also the calendar software
everybody uses does not necessarily always match like google is still probably 90 but somebody
using outlook so you make an event in outlook send it to google sometimes the because of dst
and everything something happens uh and i had gone to a hackathon we had sponsored and i
was there just mentoring some people then at night there was nothing to do and uh at that time i
was learning view as a front-end framework and uh it just uh clicked my mind that hey just using
the routing uh the you know hash parameters and everything uh so i found this the domain name
available sharetime.in send me the sharetime dot in uh slash ist slash 1700 if you write you can
share this url to anybody if they open it in their own time zone it just picks the time zone from the
computer and says ist 5 pm is 10 am at your time zone yeah yeah so it's like the url is very easy to
share because share time in yeah tell the time zone yeah yeah uh but i think the beauty is that it
was ridiculously simple what i thought that i want yeah but to implement it i gured that uh when i
was using some time passing libraries uh so i gured that these three letter time zones that we
use like ist and all um that's not the iit standard the iot standard is something like asia slash
kolkata yeah like that yeah and and the rabbit hole kept digging like i gured that okay kst is three
things kaliningrad standard time korea standard time yeah so together sometimes three letters
need disambiguation yeah so then i have to add a disambiguation layer in the middle like okay
build that uh then i gured that chrome has a bug that they have not updated asia slash calcutta
to asia slash kolkata yet even write a bug on chrome's bug tracker and i found out that there is a
thread going on for last ve years yeah and somebody's like hey iit has updated it when will you
guys do it and like refox has done it safari has done it but chrome is not yeah and then i found
out some uh message from some cryptographic cryptocurrency exchange somebody wrote that
our trades are failing because asia slash calcutta kolkata in the browser is happening yeah so
guratively i was very simple like i just thought that i would build it in ve hours or something and
from there got to learn so many things yeah as a result of that so i think even for example
something like dns.toys if somebody wants to just clone it and run it on their own they will learn
so much about how to run a dns server as well yeah in that process yeah so that's that's a great
example of rabbit holes so you wanted you try to scratch that itch of just doing one date
conversion but if you hadn't bothered you wouldn't have learned so many things but because you
bothered to do it hands-on you were driven you learned so many things yeah this is what
engineers need to do you know they need to build things with their bare hands you know they
have to do you know even the tiniest of projects but nothing is really tiny in that sense you know
date passing is a really complex thing yeah and you went down the rabbit hole absolutely yeah
yeah and it was i think uh like the end of the journey it was just so ful lling for me itself is uh and
then i sent you a bunch of friends so nowadays like when somebody asks me from singapore
dubai or somebody like went to meet and i just typed them share time dot in ist and like so they
fi
ff
ff
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
 read it in that time zone and then somebody suggested that if i open it from my time zone can i
get a thumbnail preview in whatsapp itself so that i don't have to open i'm like oh okay see that's
great i'll build that next that's a great idea right yeah so you can just send the url the og tags will
work and you don't even actually have to open the url then yeah uh so yeah in piggybacking on all
of these di erent technologies and that's a brilliant hack you should do it if you haven't already
yeah yeah that's the whenever the next weekend i get some time that's the next thing on my
agenda yeah to do that um but yeah i hope like uh if people are hearing i mean they they you
know whatever the itches they have been having so far they do scratch some of them and you
know build some of those projects it'd be really uh bene cial uh but i will take a segway from
there too actually because you talk about building these things and also open sourcing then this is
the reason why i have discovered so many of your projects because they are open source and of
course rst of all thanks to you because you share those uh instead of just incurring and keeping
them um now opens also something of course um you know sort of a bit uh i would say abused
misused word also in some places uh gets used sometimes as developer relations and branding
agendas also some places uh for me going up open source was um i gured out how to hack the
kernel of a uh you know basically reload the kernel of a android phone so then i gured okay linux
kernel is gpl so i can download change uh stu and i gured that okay phones come with
processors with speed limited you can actually bump them up you can overclock a phone as well
yeah and then overclocking desktops or something people knew okay phones can be
overclocked and then stu like that i did and then i gured he um in fact i opened my rst github
repository because of that reason i gured okay if it's a gpl code if you make a modi cation it was
supposed to publish it yeah just the spirit of that word is so uh i think uh got very uh invigorated
by that hey that's such a nice spirit that this entire community has you make changes publish it
back yeah and of course since then uh i have contributed to a lot of open source projects and
everything um but but from also an awk perspective because there was this false pledge at rst
united you were talking to about uh orgs as well if i talk to individual engineers a lot of them really
appreciate if their org actually uh supports open source development or supports their engineers
to contribute to open source and i feel that for a lot of engineering it's a very big motivating factor
uh what do you have to say to orgs or to engineering leaders as well like you know why should
somebody you know focus on this and like i said sometimes it's very transactional sel sh reasons
also exist probably but yeah you know how important is it both for you know individuals or also
for i think it's very important and a part of we spoke about building engineering culture exactly the
necessity right i think this is one of the facets of building a solid engineering culture right and
when i say engineering culture i also mean hacker culture so if people aren't in on consuming
open source software and everybody builds everything on you know foss today yeah and if
they're not keen on tinkering and you know publishing stu back uh that the engineering culture
kind of takes a small set back there so a solid engineering culture it's about collaboration and you
have to collaborate internally with tech teams and non-tech teams but it's also about
collaborating with others outside and for what i don't really have you know quanti able answer
like you said for some organizations it could be transactional it could be marketing it could be a
way to attract people to to hire them which is fair i mean all of those things exist in the world they
can all coexist but some organizations do it just for the heck of it just for the spirit so there's no
right or wrong here i mean i prefer a certain perspective but many organizations do it for sel sh
reasons like i said it's fair but it is it's important because it enables all of these things it lets it
makes engineers better engineers also because when you write something for yourself how you
write that how you think how you architect software it's very di erent from when you have to build
something for others when you write software for other parties and open source software millions
of people could use it people you've never seen people in completely di erent geographies
di erent cultures di erent perspectives di erent requirements they'll take your software and use it
in ways that you never ever imagined exactly so when you write something for others for unknown
users it's a whole di erent framework you're writing it with as many holes closed as possible as
many cases addressed as possible yes as clean and architecture as possible and that just makes
you a better engineer anyway and you'll start applying those principles in your internal projects
also thinking that you know i'm not writing this for myself for today i'm writing it for whoever it
could be tomorrow so there are many bene ts to that and you know building a culture
transactional sel sh reasons just being practicing being able to write better software by writing it
for others and of course giving you consume all this open source giving back and when people
derive utility from the software that you publish it's immense amounts of goodwill as well that may
not translate to money but you know it's if you care about it it's a lot of satisfaction right so many
of these reasons like a number of reasons why it should be done right right right um i think i feel
ff
fi
ff
fi
ff
ff
ff
fi
ff
fi
ff
fi
fi
fi
ff
ff
fi
ff
fi
fi
fi
fi
fi
fi
fi
 it's a little unfortunate in india it happens way less i feel because uh yeah uh i mean maybe i mean
zero that de nitely does razer pay i have seen uh ipkart uh there was a time i used to follow this
a lot of great stu they used to open source um but it's not something very very prevalent versus i
know a lot of my friends who have probably you know moved out of india and in us and a lot of
times they end up picking up a job because they they found some open source uh project which
they needed for some of their own use they found out this is made by this org and they're like i
would love to work at a place which has made something like this yeah uh so this is something
that i think de nitely should uh improve in our uh tech culture here in india i guess absolutely it is
so dis disproportionate it's actually shocking we have i know dozens i know 100 you know
unicorns massive companies unlimited resources tech companies that build you know cutting-
edge technology most of them are in bangalore but if you look at the number of open source
projects that come out of india it is so disproportionately small it's practically non-existent
compared to this massive you know wave of digitization at every level at the government level at
the governmental level at the industry level young companies old companies cutting edge
startups startups that are expanding all across the world all of these things have come out of india
but the same industry which uses open source software to build all of this build all the valuations
build all their products produces so little to the point that it's non-existent i think it's a cultural
issue it goes back to exactly what we we've been discussing if you have a tech versus
management divide if you have a management that isn't keen on engineering culture there'll be no
encouragement to get people to you know open source things and if you pick i know dozens of
really big popular large tech startups here and if you look at the management i think it'd be a sad
realization that many of them are not really engineers although these are all tech companies
they're all led by people who don't really care about engineering if you don't care about
engineering why you do care about encouraging your developers or tech teams to produce
software to give out to others what do you gain from that right nothing so it's it's a very it's a sad
cultural issue uh and again before the before this started we had a brief chat about force events in
bangalore like how early 2000 saw a large number of you know thriving open source communities
all across india there was a open street map movement was big the wikipedia movement was big
you know lots of students got participated and entered force via wikipedia yeah there were lots of
force events you know hacker events but over the last 10 years now india has become this techno
innovation business hub but force-related events have kind of almost vanished all the
communities they've vanished and many of these events today happen under very corporate
umbrellas there are tech events not exactly open source events are you know coming yeah today
when we have unlimited resources when the private tech industry has unlimited resources to
conduct and encourage such events and groups and organizations we don't really see anything
so i think it's all very cultural from engineering hacking slash tech we've gone to like a techno
business realm altogether which is fair but you need to have both yeah yeah yeah so of course
maybe it'll come back around we'll see even even you know techno business and i mean it's it's
fairly common to hear probably from my perspective because you know there are people hiring
engineers from scala so we get to hear from exactly the people who are hiring yeah we're getting
very di cult to hire uh good engineers yeah that's a term i keep seeing being thrown around uh
but i gured that yeah i mean if you don't create the atmosphere where whatever is your de nition
of a good engineer thrives then you will have this complaint for sure right absolutely absolutely
and it's the ethical responsibility of tech companies who bene t from all open source software
and tech and yes good engineers who've come out from you know these ecosystems to
contribute back and help produce a thriving engineering culture everywhere right right right um
also uh from uh you know uh and this is maybe a you know imagine a question coming from
somebody fairly young like early twenties or something getting into tech and i keep getting this
question myself and then i try to answer the best i can but love to uh get an answer from you for
those people as well um there are people who have maybe just heard about a little bit okay you
know there's this guy very good engineer he started his career with open source stu like that
people hear such stories and then people ask like okay how do i get into open source and then
obviously that's a very vague question in that strength yeah but nevertheless like you said there's
a big chasm of not knowing what you don't know yeah if somebody's even interested up to that
point yeah right yeah i mean i gured heard from some people that it's great to participate in
some open source communities or contribute to some open source projects or build some of my
own projects i heard from somewhere could be good for me yeah yeah and sometimes just at that
point there's a question like how do i go about doing it uh what would be your answer to
somebody very young just getting started what should be their motivations and then you know uh
probably i would not ask what should be their motivations i think the motivation is fairly there they
fi
ffi
fi
fi
ff
fi
fl
fi
ff
fi
want to get in just want to know how they should go about doing it uh this is a question that i see
very frequently yeah i want to get into open source how do i yes i think it's di cult to be very
honest if you want to start contributing to large existing projects you need a certain level of
expertise and understanding and you know some of these are very overwhelming absolutely
absolutely and for projects that are run for large projects maintained by you know skilled teams of
people why would they accept contributions which are not meaningful yeah so this whole
question of how do i contribute an existing project is a slightly problematic one true especially for
beginners true true so to get started with open source you have to step get started with hacking
and engineering you have to become a software developer rst you don't have to have you know
10 years of industry experience but you have to have hands-on experience of having built
something right so before you get into open source get into engineering you have to write
software you know write a date time calculate or you know play around with the dna server build
something yeah and when that happens the doorways automatically open up for instance like that
example with your toy project was great you just wanted daytime conversion but that you picked
a date library you went into the into a rabbit hole of issues maybe one of those issues that you
found in a date library you'd know how to x and you could send a x there yeah but if you start
out by saying i want to contribute open source where do i start nothing will happen you can never
start exactly so you have to start by becoming a software engineer you know build your own
projects hands-on projects and in that process you'll start using other software libraries and
whatnot and that will open up pathways right so that is i think the only way to really do meaningful
open source contributions it won't it can it has to come to you when you're working on those
things hands-on building your own projects or building stu at work or whatever but if you just
wait they're saying how do i get started i need to get started nothing will happen so you have to
get started by writing software makes sense that that's uh de nitely a great place no no uh i'll uh
probably uh go deeper into that particular arbitral of you know um how to i mean get started to
open source too then there's an excerpt of questions which come from people about also uh how
to go about their engineering careers and and uh i mean we discussed it back when we met like
you know about that sadly sometimes a lot of it is for more driven maybe the former can give you
a good place to start but if that's what keeps on driving you might not end up with the correct
direction uh and all right uh i would like to also uh probably predicate that with one background
and i remember a long time back i saw an interview with linus torwells and he was saying that um
and there was a lot of outrage in india about that interview because he just said something which
we would perceive to be anti-india but he said that you know uh what i see is i don't see
somebody from india creating uh something like linux kernel and the interviewer press it on like
why and he said that you know when i was starting with you know minix and you know hacking
around with bsd and i created the linux kernel i was not thinking like uh how i will get a job next i
had just you know i was in nland i had completed my university degree and i did not need a job
right now uh the i think the nnish government pays uh some uh bursary amount for a couple of
years till you gure out a job and you can so it's like i was just hacking around you know there
was some old you know solaris boxes lying somewhere plugging some hard disks and seeing if i
can write a better driver for that yeah and all of this stu i was doing and then out of that linux got
born and i was not i did not set out to build something like yeah they knocked out there and then
he talked about how like i was not nding a good version control system so i wrote gate and all of
that right uh like i have come to india a bunch of times and i've met you know indian engineers
and somebody right out of college is thinking so hard about jobs and that's a background that we
should also keep in mind i believe because we are not a very rich country we are a poor country
and a lot of people have a lot of responsibilities probably education loans when they're getting out
of it despite given that background how do you say people should go about like like the early
phases of their careers what kind of things they should you know learn and what uh can be good
motivations to sort of keep learning more things see it's very di cult to talk about motivation i
mean it has to come from within correct correct when it comes why it comes when the spark
happens to be a hacker or you know do things for the joy of it it's very di cult and like you rightly
said we can't compare our economic conditions especially over the last few decades with say our
western counterparts there when you have great social security it's it's possible to think like a
hacker you know i'm not going to think about a career i'm not going to think about a job i'll just
hack around because you have great social security but again like you rightly said we don't really
have that sort of social security here people have big economic uh obligations right and to meet
those obligations you have to nd a job right after college you're mostly forced to nd a job yes so
it becomes really di cult unfortunately because of that the ecosystem the environment here isn't
really ripe for hacking and once you and then we've talked about culture or the lack of a lack there
fi
ffi
fi
fi
fi
fi
fi
ff
ff
fi
fi
ffi
fi
ffi
ffi
fi
of engineering culture in our industry even the new age tech industry which is ush with cash even
that lacks it now when you when a young student who has economic obligations to meet enters
the industry and if it's the large big it industry you know it's a they get churned there there's no
engineering it's just services it's don't work unfortunately or if let's say they entered this new tech
industry which has all the resources you know well-paid jobs and all of that but there's no
engineering culture too chaotic there i guess exactly i mean if without that culture right what
sparks this whole idea of motivation there has to be something right it has to be people around
you it has to be the environment you are in it could be the communi it could be a community
could be a conversation that you have right about hacking with someone could be anything that
sparks and the spark has to sustain now the probability of that spark occurring is low because
you know because of whatever reasons we don't really have that engineering slash hacker culture
not in the old industry ironically not in the new industry and not really in our educational
establishments most of them as well again for whatever reasons you know large sections of
educational establishments are wired geared towards producing graduates who get into this you
know this churn yeah i mean there are strong socio-political cultural reasons for that economic
reasons for that we can't really blame anyone but that's the reality right so when you come out
when you go into any of these parts when you take any of these parts the probability of you
getting started you getting that motivation you're getting that spark to do something try
something have fun is low it happens but it is really low so it's a problem it's something i think
about all the time when people especially say our colleges don't uh produce you know fast
hackers why is that so many you know millions of people who nish engineering degrees but how
many open source projects come out of india right so these are all really complex reasons and uh
it's it's a bit of a lose-lose where you know sadly yeah in in all these areas and parts so it's just
really hard now how do you get motivation i don't really have an answer i think it has to that spark
has to come from somewhere so the people who have the ability to let's say set up ecosystems or
help create environments that ourish yeah like strong engineering cultures people who have the
resources to do that i think it's their ethical responsibility like i said i know many of these big
startups that we have who are ush with cash who use tons of open source software what they
could do to give back to society and this is not about producing projects for github correct the
second third nth order e ects of this engineering culture could be huge for a country like india
right if we had more and more people creating software public goods for other people to use just
because they like using it it's extremely valuable for you know humanity in general right yeah yeah
but you can't tell anyone to be motivated or to create software it has to come from within so what
we can do is people with access to resources whatever we have to consider it ethical
responsibility and create environments like that right so i i didn't answer your question but i don't
really have an answer right these are the might these are i think maybe you'd probably use this
opportunity to also probably uh push a very personal pain point especially with uh like at scaler
exactly uh the stu that i have personally faced is uh and then again this is probably like a bit of a
complaint against i would say uh tech companies who also say that it's di cult to hire uh we have
often gone to uh tech companies who are interested in hiring people and i've said that okay see
some times obviously like very big companies they have a certain process it's a pipeline kind of a
thing solve some lead code problems system design interview and go but there are people where
you know it's a smaller company it's a you know very product focused engineers the cto open to
talk yeah and we have sat down and they said we want exactly somebody like this somebody
let's say who understands operation logistics who can you know build an end-to-end project in
let's say node.js they have very speci c idea of what they're looking for in mind rather than a
broad brush good engineer and even despite that uh what i have faced a lot is that i say that okay
if you have a very speci c requirement like this in mind how about i suggest you something that
uh you know you uh spend a little bit of engineering hours with us to help us build a project and
we roll out that project and some of the learners at scala they will build it and your engineers can
spend maybe a couple of hours a week just uh you know code review what they have done
mentor with that project and you do it for a month some of the people you whom you know you
really love build that project you can hire them yeah you can't get a better signal than that yeah
and and i'm gonna be doing most of the heavy lifting for you right i am really interested in you
know letting some of my students build some projects and even they would be very invigorate
because it's like a big unicorn company and their engineer is mentoring you in a project yeah and
even there then the pushback is like okay we don't uh we won't have time to spend on this or
maybe you know uh we don't have the bandwidth to do something like this and there i feel i mean
that's probably the point where i would say that that's my complaint here is that you know if you
have a very speci c kind of engineer you're looking to hire and you want all those signals and i'm
fi
ff
fi
ff
fl
fl
fi
fi
ffi
fl
 creating you a canvas where you can actually get those signals from people it's it's sad if you
don't want to even spend that amount of time yeah this is not like you know publish an open
source project with licensing and everything i mean even maybe there's even less e ort than that
i'm just saying you know a couple of your senior engineers spend two weeks three three hours a
week right and then mentor a project right um and and i personally have seen that work so well so
uh when i was at uh zamato and i think uh the two of the best hires in my team i did was via
something we call trial week where somebody would come in a week work with us right only thing
is it's a little discriminatory to people who can't take out such a time maybe they're working
somewhere and they can't come and spend a week so fairly junior people you can hire like that
yeah you're having somebody senior who has a family were established in a certain city you can't
say that you know just leave your job and one week come and hack with us yeah then we will hire
you uh but the two people i hired they were the strongest hires in the team for sure because
you've worked with them for a week i mean yeah it's obviously better than take an interview but i
think yeah if companies do actually put out that e ort yeah it really compounds a lot back uh to
them and then with like you're saying the resources that they have it's just uh you know probably
like a sincere appeal that they do that because i also have anecdotes like when i um ran my rst
company as a startup and we used to do everything open source uh as telling you that i'm like we
did not think that we were a startup because we were just teaching people then edtech as a word
was not so common back then and um and it was my i did not believe that the software you were
writing was anything unique i mean just playing video writing some commands it's it's very run-of-
the-mill uh right o the shelf type of software but of the shelf did not work there was some lms
systems that did not work so we are okay we will write our own software for that but okay let's
make it open source one of the best uh outcomes of that was um people who joined our tech
team were all people who were students in that place they gured that the tools that we're using
to learn not adequate i will add some code and i'm like hey why don't you come on board and join
us yeah there was this whole entire online id like complete something like a vs code kind of an
environment and that was entirely written by uh people who are not employees of the company
it's just people gure that okay i can tinker with it and then i can add to that uh so i think that that
value sometimes uh also that message is also with the leaders is also they don't see it because
i've worked with some european companies where i see that they very much understand that
second third fourth order e ects also and they have seen those bene ts um but maybe i don't
know we as a ecosystem have not yet seen those fruits of the second third order and that could
be a reason absolutely i mean see it's a lot of foss is really altruism right some of the most
valuable projects in the world that all of us you know billions of people use are made by a handful
of people who make it because they like making it they struggle to make a living with you know
with a di cult job and at the same time they contribute their personal time and e ort into a fast
project that they give out to the entire world for free and if you look at the large for larger force
ecosystem most projects would be like that why do people do it right it's of course you you did
for fun you do it for satisfaction but you know there's also this aspect of maybe it's a very touchy
word altruism so it i think like like the examples you mentioned right they're great so companies
want to hire the best engineers uh they want to use the best open source projects available from
across the world to build their companies right why can't they give back how can it just be always
consumption we'll pick up the best software we'll hire the best engineers we will you know do
ridiculous we'll throw out ridiculous o ers to attract the best talent right but where does this best
talent come from you can't become a great engineer by you know reading books or watching
videos you have to have you have to you have to be involved in all of these things you have to
work on lots of projects you have to collaborate with others you have to be familiar with fast
projects you have to produce fast projects for this you know whatever we've been discussing you
need a thriving ecosystem here of engineering culture of appreciation for engineering yes yes so
you can't expect to nd uh great engineers all the time in unlimited supply if you don't contribute
back whatever it is yeah to create an ecosystem that produces such engineers right right so it's
very it's very short-sighted and blind of organizations here to just expect to be able to always nd
great engineers while never doing anything to produce great engineers right and why do you
produce great engineers it's just it's you know it's like i said it's also an it's ethical responsibility
even if you can't foresee the outcome we publish this open source project or let's say we run this
community event or do whatever we fund some open source projects what do we get back
maybe nothing but at some point all of these things you know these all of these things have to
happen on a large scale for good outcomes to happen for everyone but if you transactionally look
for very speci c outcomes i sponsor this conference i want this back that doesn't scale and then
you can't you know complain that there are no great engineers here because nobody's doing
ffi
fi
fi
ff
fi
ff
ff
ff
fi
fi
ff
ff
fi
fi
 anything to produce great engineers and how do you produce great engineers all of these things
without looking for speci c outcomes yeah yeah i have like a handful of friends from my college
days who have fairly probably i would say burned themselves out of the india ecosystem at this
uh point because of this because these were uh people who with whom i would go like almost
one or two hackathons every month they love doing stu like that you know working on open
source project participate in google summer of code uh and i had a group of some 10 15 people
and a lot of those people are now at a point where uh you know they're like there isn't an indian
tech starter which is even pitching that hey come here because we hack on cool stu yeah and
nobody's even doing that pitch and i want that pitch and a lot of those people have eventually
moved out uh especially they nd some places especially you know uh amsterdam france those
kind of places there are a lot of companies who are actually literally pitching that you know like uh
forget how many users we have or you know how many requests per second we process all of
that just come because we build cool stu we go to hackathons we participate in conferences we
build open source projects and then you know come because of that it's a very direct pitch and
uh i think people should actually look up on that and see that it's a pitch that actually works with a
lot of engineers who really want actually that out of the work they just want to have fun yeah they
want to hack on stu and you're probably missing out on great engineers are looking for that if
you know you don't create an environment where you let them do that in the rst place and then
of course the other second third order e ects uh around that as well um i did uh like to take a
segway into uh something else uh which is uh we were earlier talking about you know as like the
tech versus business thing you are saying that um the the tech is the product and it's a from
going from tech enabled to actually being tech products happening across a lot of these verticals
uh what sort of the i mean going ahead looking at the industry probably wider industry but also
nance uh something that you have been doing for so many years that uh what does like sort of
more emerging pieces of tech look like because i have obviously read that nathan had shared
about ai and nance thing but but nevertheless uh i don't like you know a lot of new things uh
coming up uh i mean yeah i blocked you and all of that but apart from the hype words uh what
sort of the future of tech in this domain looks like going ahead uh di cult to answer yeah but i
think you know big revolutions happening in ai ai many di erent kinds of ml and ai technologies
becoming commoditized etc will accelerate better technology for sure but ai won't just come and
change nance right or you know suddenly there's this thing called blockchain and it'll completely
revolutionize a certain thing it doesn't work like that these are all building blocks exactly
somebody has to come take the right building blocks nd the right problems to solve and use
these building blocks meaningfully to solve these things if you look at let's say the let's kite our
investment platform you look at kite in 2022 and you look at uh trading platforms that were
available on the desktop they weren't really mobile platforms oh forget mobile app our web app
versus web apps that were available 10 years ago uh i mean fundamentally nothing really has
changed fundamentally as in you log in you see stu you press a button you know it's all on the
web page you can place orders etc but these systems are light years uh apart yeah and lots of
like a million subtle things have changed it's still a web app it uses javascript it was a web app it
you know used to use javascript what has changed is sensibilities have changed right uh the you
know these not just us you know many newer companies care about user experience and just by
focusing on good user experience we've see you know we've had a large number of products
emerge high quality products that you can't even compare with what existed 10 years ago but
technology they may be the same thing maybe it's just you know slightly better web frameworks
slightly better mobile frameworks so i think changes drastic changes is going to come like this
lots of little pieces coming together to give produce better and better quality software i don't think
there'll be anything let's say in nance tomorrow that'll completely change how people you know
interact with nances like a mic drop kind of a thing exactly i don't know this is not happening
yeah that doesn't that doesn't that is that's very rare that happens very rarely and if you again if
you look at how people treat investing online today you know there are 18 year olds signing up
versus how it happened 10 years ago only 60 plus people of the 50s and 60s stated it's
completely changed yeah but did that happen overnight no it happened over a decade maybe
accelerated over the last four or ve years so any sort of change is going to be like that maybe
people will start using machine learning technologies to solve very speci c problems and they'll
be a big ux boost then someone will come build on top of that right so ve years from now when
we look back maybe things will look drastically di erent right but i don't think there'll be one
discerning point where one technology comes in revolutionizes everything let's say in nance
yeah and speci cally with nance at the end of the day it's about money if it's about people
making money losing money software technology ux etc secondary an ugly app that makes
fi
fi
fi
fi
fi
ff
fi
fi
fi
fi
fi
ff
ff
ff
ff
fi
ff
ff
ffi
fi
fi
fi
ff
fi
people money people will use that you know rather than a beautiful app that loses their money
correct so at the end of the day with nance speci cally it's basically that all these incremental
things help people you know improve on certain things but nothing major but if you look at certain
other industries for example uh things like uh gpd3 etc the possibilities are very exciting and
maybe they some of these technologies will completely disrupt how people produce art you know
there are all these you know stable di usion there wasn't release just two days ago now people
can run uh stable di usion on a commodity gp and produce insane art correct programmatically
correct sorry if it's a simple english problem now that could completely rede ne how stock
images work yeah so designing youtube thumbnails for example is something that you know if
you're doing it remotely with the designer yeah and you have a vision in your mind and you just try
to communicate that to the designer and then they come back with it and those iterations
sometimes i feel like even if it does not replace the entire cycle i can just put a prompt into
something like daily or stable di usion yeah get a rough image and send that to the designer that
you know i want something like this absolutely changes the game completely completely and
millions of blogs will suddenly have you know very contextual great looking images right so once
in a while technologies like that come along and disrupt things overnight but that is very rare if
you look at the last 10 years you can think of two or three of these technologies that completely
change the game practically overnight for certain for a lot of industries but you can't aim for those
because they are black swan you want kind of things there exactly so drastic overnight changes
happen very rarely but mega changes over a few years and decades happen all the time but you
can't pinpoint when that happened it's you know it's really complex right right right right i did have
a few questions about uh and i just remember that is about uh some of the folks uh who got to
know that you would be coming uh about uh you know uh zeroth tech stack as well by the way
yeah and and that's something a lot of people are interested in knowing uh so i'd start from of
course uh the rst is something which is more closer to me is like i have been a mobile engineer
for a long long time uh i mean xeroda was probably the rst one to take a bet on utter it wasn't
so popular back then it was very alpha beta level uh yeah so but what uh made you do that and
then versus i think you had a react native app also long long back originally uh so how's that
played out and i would say probably zooming out like you were saying rst principal level thinking
yeah so what are the you know probably ingredients that went into taking a decision like that and
how is that played out yeah it was a big decision it was a hugely risky decision and utter was
pre-alpha yeah and i don't think anybody was using utter for anything except for the utter
team's own demo apps yeah there was nothing else and ajin from the tech team has written a
great blog post describing this entire journey yes on why we made that decision so just to quickly
summarize the gist of it uh we had a native android app uh our trading platform and for ios it was
written in react native right and of course it maintaining two di erent code bases for two di erent
platforms is a huge pain right and uh this was a time when we were making a lot of changes you
know not just regulatory changes we were evolving as a product so things had to be new things
have to be built constantly and building two things in two di erent ways in two stacks and two
code bases and releasing them at the same time of course it's problematic correct so it was very
clear to us that we wanted a uni ed platform where at least 80-90 percent e ort would be the
same and react nato was something that we bet on but it opped it was it wasn't mature this was
back in 2017-18 right it wasn't mature enough we had way too many di culties there were
performance issues and we stumbled upon utter which looked very promising its architecture
was promising uh its the language of choice dart which was a new invention that had you know
certain bene ts the way it was architected looked promising yeah like drawing the pixels directly
is actually i have always loved that because you know you take the unity and all game engine
philosophy to an app yeah because when you think of cross platform then the biggest problem is
like how android draws things and how ios draws things is di erent yeah if you keep ghting it like
react native is actually ghting it yeah you will keep on ghting it and the platforms will keep on
innovating and you will have to keep on ghting it versus if you really want true cross platforming
just circumventing that and just draw the pixels directly to the screen yeah it does come at a little
bit of i think graphic rendering cost for sure versus like native android but i really like that
philosophy when it originally came out yeah and i think for mobile it was workable because mobile
applications did tend to look very di erent yeah the problem with cross platform ui gui libraries is
that they are impossibly hard to pull o which is why even today we don't really have great cross-
platform ui frameworks for windows linux and mac you have to keep nding ghting os apis it's
extremely di cult to unify yeah and the thing about direct painting uh is that for operating system
apps you know they use os widgets lots of elements right and if you don't nail that pixel by pixel it
feels like an alien app on mobile phones people are used to you know seeing di erent kinds of ui
ffi
fi
fi
ff
fi
ff
fi
ff
fi
ff
ff
fi
fl
fi
fl
fi
fi
fl
ff
ff
ff
fi
fi
ffi
ff
fi
fi
ff
fl
fl
fi
fl
ff
 so it was possible to get away with that here but the same attempt on desktop is really
problematic so an app that looks like a windows app on a mac will completely throw people o
correct so that's the downside of painting you have to reinvent you know native look and feel and
controls and nuances from scratch which is an impossible project when it comes to desktops but
for mobile yes absolutely like you said uh it allowed utter to bypass you know all these quirks
yeah so we were uh greatly smitten by utter as a technical framework we liked how it was
architected but now the decision just because something looks great techno technically doesn't
mean you know you can bet your entire future on it there are many other considerations we didn't
know dart so there were many objective decisions that went into it is it is dart viable can we learn
that is it possible so we answered that question by experimenting we built a prototype in like two
weeks of what we wanted to do right list views with you know real-time market ticks were a
problem you know it has to render at 60 fps so we built a you know 500 item list view in uh utter
so we saw that the listview had a bunch of issues but you know it was open source we were
con dent that we could x it while utter was evolving as an alpha program these big issues that
it had at that point we with actual with a hands-on experience of two weeks and technical
dissection and looking at how it was built architecture we built con dence enough to realize that
oh these issues you know let them be there we can work around them right then the nal question
is can you bet your technology on this uh how can you what are the factors that would allow you
to bet your future on this technology what if you know google kills the project uh what if there's no
community around it what if people don't like write libraries for it so that was a very di cult but
objective decision again for us where we realized that the pain that we were facing with native a
native code based plus react native was far greater than it's a google killing of this in three years
we gured if we could just port this and run it for three four years because it was open source by
patching it ourselves maintaining it ourselves and all the bells and whistles it had suited our
requirement it would still be worth it right so that trade-o you know despite all these issues
despite all these risks it would still be worth it that's the most critical pivotal decision point yeah
and we're like ne let utter be killed if it's getting killed we would it would still be worth it for three
four years right so to arrive at that decision of course we had to make you know actual hands-on
we had to build a prototype i mean we couldn't just look at the github issue and decide so it was
a very careful objective technical rst principles decision making process that started out as a
very technical thing that went on to a tangent of business and organization like the risk right and
we made the decision and it turned out to be a great decision right yeah i mean uh that's uh fair
enough and uh i think i have seen places where like you're saying if google admin owns a kind of
a thing so uh at target uh there used to be a library that we were using for 3d rendering some
models so that you can virtually try out some products that you want to buy and stu like that uh
and it had two versions i think one where uh you would actually use direct 3d models another one
was where you could just sketch it out in some pseudocode kind of language and some 3d
models google stopped supporting like they abandoned the the sketch uh thing and target started
maintaining it because it was very important for us to actually use it and the decision to actually
buy into that was right from day one that if google does not actually maintain it we can do it
because we understand the system how it works and it's important for us and there isn't any
better solution for us right now yeah yeah so yeah that's a great trade-o you even have to
visualize the worst case outcome when picking on picking a technology yeah and once you are
once you know that objectively we can handle the worst case uh outcome if it were to come then
you're kind of safe and 90 of such decisions don't turn out to be don't turn out to be disastrous
yeah yeah the worst case like they have covered for that yeah exactly yeah makes sense uh so
coming from that uh mobile architecture to also um to to uh you know web systems in the back
end um and then i've heard uh from folks in your team as well some friends who i have is you
know it's fairly simplistic uh compared to what i see today uh is especially when i'm teaching is
that a lot of people like uh once uh they they get started with actually building things there's a lot
of questions around okay what you're teaching me will you teach me how to build in
microservices or you know will you teach me how to deploy a server less to the cloud or
something like that and uh you know while occasionally it can be exasperating because i'm like
let's start building something we will gure out we can separate into services we can you know
serverless or you know vps however deployed let's let's see we will go there uh but i think the
hype of a lot of those terms have permeated uh and and you know if it was only hype it was one
thing but their people were actually building stu which is getting in uenced by that hype today
it's something i feel i recently wrote a very long twitter thread about like probably very contrary
and unpopular twitter opinions but there are a lot of folks like uh ammo and then ajay they
retweeted they say that you know these are probably good points it's sad that it's unpopular uh
fi
fi
fi
fl
fi
fi
fl
fi
fl
ff
fl
ff
fi
fl
ff
ff
fi
ffi
fl
ff
 but then i would like to delve a little bit into how's your tech stack look like and you know how do
you go about doing deployments um i see it's very unconventional that you roll a lot of things in-
house versus using a lot of cloud-based services um so if you could run me through a little bit of
that uh so the tech stack has evolved greatly over the last you know decade and but not really in
principle in the physical manifestations if you change databases we've changed you know
programming languages but the approach has always been rst principle so when we really
started out we didn't really have a road map when we started out almost a decade back we didn't
have a roadmap to build a trading platform we wanted to build technology to solve problems
inside uh zarotha rst so in the very beginning it was python scripts that cut down let's say one
hour of manual csv processing to let's say two seconds and it was mind-blowing for the people
there right and uh so that's that's really the origin the right tool to solve a physical problem the
right job that's that's how we started out we didn't say we need full stack we need a trading
platform we need uis nothing so these then we started you know solving slightly bigger problems
back then it was just me when we started zero that tech it was just me and i was sitting there i'd
go sit with non-tech folks nd their problems you know write python scripts to automate and at
some point you know i had too many you know people got the taste of automation it wasn't even
tech it was automation they're like oh can you automate this can you automate that and that's
how we were slowly very slowly trying becoming a you know digital business from pure uh o ine
paper stu to you know slightly more digital from a brokerage rm to a trading platform that
exactly that transition was slow and very organic uh support system was a single gmail inbox that
you know let's say 20 people logged into that obviously doesn't work then we brought in i
installed os tickets an open source you know ticketing system so all these tiny pieces at some
point i realized i was getting way too many things that i could handle it's time to build a tech team
so after several months after starting zerudada technology as an organization with a roadmap to
you know build technology in nance we hired our rst engineer so only when i exhausted you
know my capacity then the two of us started doing whatever i was doing and at some point we
were like oh we need more hands then the third person then the fourth person so the team grew
very very organically and as did the stack right so the in the very beginning as i said it was python
because you know i was okay writing python i could write decent python and it was python
automation stu then we started to store databases sorry we had to store transactional data at
some point suddenly there was postgres because you know i'd always known postgres had
worked with postgres certain things for whatever reason had to be my skill databases i knew that
also so we use that os tickets for example uses mysql and os tickets is a php uh system yeah all
those old software yeah yeah wordpress era software exactly wordpress era and that required
some uh tweaking so suddenly php was also a small part of the stack so we picked the right tools
for the right job for overstick for support ticketing it was this it was appropriate for something else
it was that that was appropriate at some point after lots of digitization after lots of you know
backend dashboards and whatnot with let's say django because we are already using python at
some point we suddenly had an end user product on our roadmap so that was built in python uh
we used redis for caching because everyone was using redis for caching it was memcached or
redis at that point yeah and it is was slowly picking up sorry gaining popularity so we built a
django based uh system i think there was also this library framework called cherry pie which was
simpler than django okay but it was a python stack so our apps grew features grew complexities
grew issues grew databases uh grew data size grew lots of end of the day number crunching that
was based on proprietary really bad windows software which was norm in the industry we started
rewriting in python in-house so suddenly the this data back-end python based stack happened
but python redis and postgres were really the you know big pieces and 2017 is when by then we
had uh then of course the mobile app happened yeah uh right after we built kite the web app at
some point this was also you know random in serendipitous we were o ering a vendor-based
trading platform to end users they made a new release and i was horri ed to see that release
because i remember that it only worked on ie6 in 2015 or late 2014 and that was completely
unacceptable at that point that we would build our own online trading platform wasn't even a
question it wasn't even on a road map then you know picked angularjs that turned out to be a
disastrous decision you know there was this angular v1 v2 yeah angularjs angular all that stu this
yeah the version change uh they rewrote it in typescript and stu all of that yeah lots of things
were happening and we found it to be it's a complex framework also it's not very easy to grasp
but we won of kite our rst end user web app in that sense trading platform was written in
angularjs python backend redis and postgres but angular we immediately regretted it was so
painful and di cult and hard and just a year later we rewrote the entire thing in vue.js today vue.js
is our basic our web app stack for the front end and 2017 is when digital signatures became a
ff
ffi
ff
fi
fi
fi
fi
fi
fi
fi
ff
fi
ff
ffl
ff
 thing now you could open a stock broking account online prior to 2017 you know we'd korea you
like a 40 page booklet you had to do 40 50 signatures scan print yeah i say a direct way of doing
things yeah yeah yeah yeah and there was only possible way there was no legal way to open an
account online it had to be o ine so you can imagine that the industry was very slow because
who would want a courier then you make one mistake miss one signature it gets korea back to
you so the drop-o rates were like 98 then digital signatures happened we could generate a pdf
from the back end people could just you know with a few clicks do a digital signature and no
more couriering of you know documents that's when it really started picking up you know online
investments as a thing post 2017. this was also a time when we as the scale-up happened this
was also a time when we started facing a lot of uh issues downtime issues because all of these
things that we're building in-house were on top of legacy systems that the industry was using
anyway like oms order management platform the back o ce system and the mega projects that
we were handling was to take all of these pieces in-house and write them from from scratch it was
like glued to legacy yeah yeah yeah so even if you're let's say you're a bank and you release a
great looking net banking app the underlying system would be you know like a very legacy core
banking system and you'll have to start replacing pieces bit by bit so the most amount of work
that we've done back then was uh on the one hand we we were doing product engineering
building new features you know new ui new x on the other hand we were replacing these really
dirty messed up legacy systems and nine out of ten things that went wrong when we had down
times were issues in these legacy systems which were completely outside of a control so that was
extremely frustrating in 2013-14 i was experimenting with go uh it was a newish programming
language at that point and i was experimenting because you know i felt like you know i was just
thinking tinkering around so we had this one particular use case for the trading platform where uh
you know you log into the trading platform you see your stocks here in your watch list they tick in
real time right so they can take two three times a second and you can add a bunch of things so
that whole that's a live tcp connection websocket connection and you to push tick packets to it
now python wasn't ideal for that so i experimented with websocket libraries in java c plus plus a
bunch of things even node.js to nd the right tool for the right job but didn't want c plus plus to be
added to the stack you can build anything in c plus plus but it's complex and being able to write a
lot of code and yeah and grasp the lot of code that is written later on is what i feel with c plus plus
absolutely and and people can write it in completely di erent styles using completely di erent sub
technologies and it's not great in that sense and i was experimenting with go and go was a you
know maybe a beta language oh no i think it was 1.0 but it wasn't big but i'd liked it and it had
great concurrency primitives and concurrencies is what you need to handle lots of live websocket
connections so i thought you know what this piece i will write and go and that became the rst go
program that we wrote uh in uh tech stack so everything was python python backend you know
python data crunching python web servers suddenly we had this one go program that was that
would accept websocket connections and stream right and that gave me personally some
con dence and experience in writing a go program for a production use case and i mean our
scale was really today we have let's say million plus users who log in and trade at the same time
back then we had let's say three thousand so you can't even compare right and that three
thousand suddenly became ve thousand ten thousand fteen thousand twenty thousand fty
thousand concurrent users you know as online account opening went up so we go was turned
out to be a great choice for live low latency not sub nano second not in that terms but let's say
sub ms request response stu super low on resources easy to write easy to deploy and go from
handling just that one ticking piece you know suddenly started making its way into other pieces
some python pieces we wrote in go right and a lot of bottlenecks lots of chokes that we were
experiencing you know disappeared then it turned out that go was a great choice for this stu that
we were doing which is handling huge amounts of requests per second responding to requests in
milliseconds and suddenly most of the applications that we had were backend applications that
were written in python that were handling uh front-end requests and user requests became go
and go became an integral part of our stack so that transition has been happening and the
biggest then you know complexity increased uh we were running a large number of applications
not micro services per se but you know services so kite the trading platform is a collection of let's
say three or four you know large services completely independent now when you have services
they need to communicate and yeah this is a data business do you have a customer database
that later has to be synchronized to the trading platform to the back of this platform to the
compliance platform synchronization web hooks etc were becoming a pain like it's time to have a
message centralized message bus and suddenly kafka became a part of a centralized message
bus and we are to the number of ticks activity subscriptions etcetera increase so today let's say
fi
ff
fi
ffl
ff
fi
ff
fi
ffi
ff
fi
fi
ff
 we are broadcasting 50 60 million ticks per second into websocket connections so when we were
slowly growing to that point you know we wanted ticks to be moved around in the back end
through our systems before they they were broadcast for websockets nats turned out to be a you
know great piece they're super easy to run super lightweight just run it works forever and and the
stack has largely stayed the same it's go python for stu postgres redis kafka nats and all
performing what they do best just because we are writing a new program you know it won't use
kafka just because we have kafka we only use kafka for synchronizing one-way data
synchronization or whatever and uh lately we we've exhausted what postgres can do i think so i
don't think we want to store a trillion rows in postgres you know shard etc then at some point
you're now ghting the database so i've been keeping an eye on click house as a database for the
last ve or six years since pre-alpha and i think one or two years ago cloud are published a blog
saying they used click house and it was a beautiful blog i really like cloud are's engineering yeah
events uh storing exactly events correct so that was my point of validation for click house that i
was looking for and turns out click house reduced uh reduces our storage space of several
terabytes by let's say 90 percent uh and uh queries that would take maybe one or two seconds
which is really slow for us yeah uh suddenly became two milliseconds so it turns out it's a great
database for storing massive amounts of immutable nancial transactional data so now that's a
big part of our stack and we're moving lots of things so whenever and moving terabytes of data
moving hundreds of billions of rows of data that we've built over years to a whole new database
it's not an easy decision right right but we know that that short-term pain that we will face right
now will help us for the next many many years right so that's how the tech stack evolves when
there's a solid objective use casing we need to introduce this new technology it will x all these
problems then we introduce that so today if you look at the tech stack it largely looks like this
utter for mobile apps vue.js for you know web apps uh go back ins some python backends and
lots of python for data crunching postgres click house redis that's about it right so we never think
of concepts like microservice or monolith or whatever you don't you write software you don't write
architecture conceptual architectural frameworks right so let's say you have a problem to solve
you and and we work with linux all the programs are linux programs so you you write a program
that linux program that works on linux that is super easy to deploy if it's a single binary great if it
needs two di erent programs all right but it'll never require 10 di erent pieces there'll be no 10
micro services correct so you start out by writing software that solves a problem then you start
out by making it run on linux because that's your environment then you probably add a web
server it has if it has to you know interact with the outside world if it has to communicate with
another program elsewhere you evaluate should it be a web hook or can we just connect it to a
you know one-way kafka bus or whatever right correct and you start always from one linux
program and slowly expand it outwards exactly as it grows maybe it'll split into two or three
programs maybe the technology will change maybe websocket will become something else it
doesn't matter but you don't start out by saying that serverless you know this managed services
etc and like you pointed out we are very vary of managed services don't want to be vendor
logged in the regulatory agility that we need as in there's a regulation you have a ve-day deadline
you need to change everything we need complete control over our data over our over every
aspect of our stack so we don't use any managed databases all these mega massive instances
database instances they're all self-hosted just spin up a linux system and you know you run
postgres or whatever and it's all managed by everything is managed by a team of let's say one
two two three people right and we sell forced absolutely almost everything even our hrms
employee leave management system in employee internet everything it's you know self-hosted
instances of erp next nancial stu data crunching stu trading platform stu and over the years
we've rewritten and gotten rid of all the old legacy external dependencies and brought everything
in-house and i think it's a we don't do justice to let's say a postgres beautiful brilliant piece of
software when we think that oh who will manage postgres uh most organizations will not have to
store half a trillion rows probably you'll have to store a million or a few million rows and it's
absolutely ne these are all robust technologies that you can easily run on a simple linux system
so so i think people are afraid to take responsibility for software and the cost that you pay is
vendor lock-in humongous amounts of nancial cost i know that so our crm right it's uh it's we
use erp next and frappe heavily to build all these dashboards if you're unaware it's an erp system
indian open source project yes yes i have seen yeah yeah yeah and at some we were so smitten
by we so appreciated it that we became investors in the company we funded it as a false
company at some point so just the open source ticketing system that we've been using for many
years it looks a little ugly but it's fast thousand people log in every day so you know zerada has a
thousand people today uh outside tech lots of people who have to pick up the phone and answer
fl
fi
fi
fi
ff
fi
ff
fi
fi
ff
ff
ff
fl
fl
ff
fi
fi
 nancial queries compliance legal you know documents uh and it works well it runs on one server
once a year we log in to archive data and that's a thousand people right and i know how much
sas ticketing solutions cost per user right just on our crm just on our ticketing system we are
saving millions of dollars every year just on these two things and we sell foster maybe 100
di erent things right lots and lots of things and it's the same 30 people who build systems who
build end user products who also maintain these in-house systems yeah and maintenance is you
know sometimes you log in once a year sometimes it's running for many years you don't have to
yeah and and people also i think it's a tendency to not look at risk holistically some systems can
go down let's say it's an internal dashboard so what if it's down for 10 minutes or an hour it
doesn't matter it's not going to a ect anything but that that everything has to be always up
hundred percent we need a managed sas for that that fomo that irrational fomo also drives a lot of
these decisions but for sure we are a pro table enterprise today and a signi cant amount of our
pro t margins come from our decisions to self-host and keep the stack lean right our you know
aws bill we use aws heavily for our you know hosting applications is laughable it's not even our
annual bill is probably not even like an instagram campaign for many startups that's how low the
bill is and all of these things play into the future of the organization right if you want a sustainable
organization where tech is nimble you're regulatory nimble you're actually making pro ts and you
just need a few people to handle and run everything it all plays in so it's it's the tech stack but not
speci cally the tech stack it's the rst principles used to construct this tech stack that has really
mattered yeah so i um absolutely love that you know uh another postgres example as well i think
if you are able to scale up to a million and then if you reach 100 trillion then you'll gure something
out in that space uh and i have done self-managed like they have seen open source projects do
their own bug tracking with something like redmine or bugzilla yeah works fairly well like they're
probably tracking more bugs than a lot of companies at fairly large scale they're probably tracking
more bugs than that yeah why are those two probably one ten dollar server and they're running it
on that's what we do gitlab sorry i forgot to mention gitlab is a part of a stack that's where we
host all our repositories that that's our ci cd system bug tracking issue tracking works really well
self-hosted instance of gitlab yeah yeah i have burnt my hands on uh managed postgres so we
used to run postgres on our uh and just talking of since on 1617 our startup and um we did not
get into aws because initially just felt like okay whatever we want to run if we can just uh we were
bootstrapped they didn't have a lot of money and no investments nothing and we are fairly young
so just to take the risk of okay if you put something on aws there are horror stories out there blogs
of people running millions of dollars in bills so you start o something like digitalocean yeah like
okay if you take a ve dollar server you're not gonna spend more than ve dollars because it's a
vps it's not auto scale or anything yeah so we started o like that and our database used to be
hosted on our own vps right um and then a couple of years later uh they pitched that we have
managed databases now and they poked and prodded us for a few months and actually try it out
so we tried it out uh problem happened uh someday site was not working when things went down
and you're like trying to debug okay what's happening uh why it happened okay um everything
seems ne we every time we restart the entire uh vps everything works ne yeah but but if there's
some spike on on the db it uh you know the db the managed database it resets the connection
and after that reset somehow does not connect okay we're trying to gure out what's happening
and uh keep debugging a few minutes later we are like okay if we copy the url from the api it
works if we copy the url from the dashboard it does not work okay strange enough so we look at
the you know uh url that's on the dashboard and the one that we just copied it's the same then
there's a copy button on the web clipping clipboard button right we click on that and we copy and
we paste and we see that what is actually shown is not the same thing that is copied because
when you click on the copy button it actually makes an api call and fresh gets a fresh one yeah
but the string that is shown there if you just drag with your mouse and right click and copy you
get a wrong one but if you click the copy button you get the right one and then for an hour or so
we did not think that something would be wrong with their database because so many clients are
using they must be right something must be wrong with us yeah if you have been hacking around
you know like you know the rst thing you blame is yourself something must be wrong in your
code some glue not working then we're like no we'll just move back our dp we'll manage it
ourselves this does not happen when we manage it ourselves at least yeah and we realized when
we moved back we saved a lot of cost and better reliability because this does not happen so yeah
there's this de nitely uh so you're talking about gitlab as a ci cd uh as well um i think a lot of
people do uh focus on both in terms of learning and sort of trying to establish like pretty elaborate
cicd setups like you know i code review something here automatically will get deployed
everything will work and all of that stu what i have so far found out i might be wrong is that
fi
ff
fi
fi
fi
fi
fi
fi
ff
fi
ff
fi
ff
ff
fi
fi
fi
fi
fi
fi
people spend a lot of their day trying to chase that utopia without actually achieving that utopia i
agree yeah so how does your ci cd stack look like uh right now like how do you deploy things and
all these maintenance and stu how does it happen it's quite simple like you said you know
people put in a lot of e ort into the process of achieving the nest most automated slickest ci cd
pipeline and that's just basic e ort at the end of the day you you're working on software and
there's a new version of the software and you have to get it somewhere that's about it i mean
everything else and and a simple good enough path so our cid ci cd system is actually quite uh
simple we have a job le for many of these repositories and a lot lots of them we've created a
template that many repositories can use so that people understand how di erent repositories are
working so for go programs when stu is pushed to gitlab there's an automated you know lint
plus test that runs and just a common sense sanity check then there's a build step that compiles
the go binary and dumps it to uh s3 you know some designated bucket right so that is really the
build system really done and then we have another deploy step and for critical applications that is
manual for us we don't really care about you know deploying 100 things in a day but every
deployment because of the risk we are extremely extremely extremely careful about deployments
right so insane amounts of testing weeks and months so that step for most of our critical apps is
manual you have to go click a button you know that little play button on the gitlab ui and that is
when the actual app will get deployed now the deployment environment we wanted a uniform
environment for all our applications and we tried out k-8s as a uniform deployment environment
where you know people can write a manifest yaml le and you know it'll eighty percent ninety
percent it'll work for all di erent projects because otherwise otherwise people roll their own
deployment build schemas and you know becomes non-uniform over time but uh that didn't really
work out case turned out to be insanely complex there were you know yaml manifest within yaml
manifest within manifest and we had to write tools to make sense of these manifests so that pilot
you know we phased out and uh sorry i forgot to mention this nomad hashicorp hashicorps
nomad yeah as a orchestration plus deployment stack is something we piloted and we are
deploying everywhere now okay so we've written a and and hashicorps nomad is really simple it's
not like k-8s which is like a full- edged cloud operating system in that sense nomad is an
orchestrator you say you need you know 10 number of ec2 instances and this binary should be
copied to these 10 instances and they should run and port 5000 will be exposed you know it's
simple and the nomad job le kind of looks like a simple nginx le also very easy to understand
probably 20 30 lines of code and you have this environment so this binary that is dumped in s3
when the deployment happens this nomad script is run and nomad is keeping track of n number
of ec2 instances running for let's say kite ticker or some other program requires you know these
other instances it'll instantly pull the binary from s3 and copy to the right location via ssh nomad
agents run and it'll send a signal to restart the app and deployment happens so nomad is great in
that sense because that all that orchestration of pulling your program from somewhere copying it
to the right easy to instances managing ec2 instances or managing it managing an automated
restart all of that nomad handles so there's that before we had nomad before we had k-8s it was
just manually created ec2 instances and some simple script would copy the program dump it
there and do a restart right at the end of the day no matter how sophisticated your ci cd system is
it's a linux linux program that is going to be killed or you know cigarette or restarted that's it so
you don't change your perspective from that so we use nomad to clean it up and make uniform
deployment templates across all our projects so people know that what is happening and it works
well so cact is really simple upload to github test runs build is created and put push to an s3
bucket that s3 bucket could be an ec2 instance it doesn't matter it's all simple plugable and from
there when we press the deploy button for critical apps nomad will pick up the program binary go
binary or a python program or whatever copy to number of ec2 instances that we've con gured to
run and you know send the reload signal right right makes sense i mean i have gone through that
go to kubernetes and come back thing myself as well i gured for me it was like more drastically
like go to kubernetes come back to just docker compose le that's enough like one docker
compose deploy everything on a single server yeah that would work uh so that's uh great and uh
i've been asking a lot of questions they'll just have one last one uh right um so uh this is about uh
and i had seen uh uh i think last year's has geek even when i talked about scaling with common
sense yeah right uh i think there's a last piece around that tech stack i would want to ask which is
not about particular technologies but uh let's say you've seen you know starting with you know
few hundred users to millions yeah uh right i mean scale obviously across all of your systems
don't work linearly like everything does not just scale to ten times because you just scaled to ten
times yeah uh nevertheless when somebody's building software yeah uh right uh i mean there is
obviously the age-old debate about premature scrailing and all yeah but pragmatically what are
fi
ff
ff
fi
ff
ff
fl
ff
fi
fi
fi
fi
fi
ff
fi
the some of things one should keep in mind uh like what will happen if things scale what should i
not do so that i don't burn myself at scale yeah but also like not over complicate things so again
no easy answer yeah it's a rst principle based approach your decisions have to be as less wrong
as possible it's very di cult to make long-term right decisions with technology right so as less
wrong as possible now let's say you need a database and you pick postgres which is battle
tested now that's actually a decent decision you know that people have scaled postgres
databases to massive scale so it's not a complete unknown red is for example if you were to pick
some sort of a cache or in-memory database you could just pick redis because it's so well
documented that redis is battle tested to kind of work forever right right so when you pick these
pieces to add to your stack you pick pieces objectively and carefully right and assembling the
stack is like 80 of the work if you pick the wrong database then you're kind of screwed you have
to rewrite your app you know you can't migrate so just get careful consideration and in which you
pick robust technologies right tools for the right job before you even start writing code is that and
maybe there are other considerations also so i cited this example of using go which was a hobby
uh tinkering project for me to write a production uh ticker program right a live market ticker for for
a trading platform we could have we were python was a stack and there were other things like c
plus plus etc but this just turned out to be the best tool for that job although it wasn't a part of
that stack decided to introduce that language into the stack so sometimes you have to make
those decisions maybe you know python really well but the task at hand requires something
where go is better suited so maybe that decision to pick the right tool for the right job foregoing
our familiarity that also factors in so it's a bunch of these things then of course you shouldn't start
out you know people have this tendency to build things for 10 million users that'll never ever
come so we have to be extremely grounded and realistic so that realism will automatically
translate to an architecture where it's good enough to scale to a certain point uh and after that if
you really need to scale it should it would be modular enough to you know kill replay swap etc but
if you're going to build something for 100 million users or 10 million users on day one your entire
architecture you're going to focus so much on those invisible goals and problems that you will
never be able to focus on your business logic or product so keeping things modular and speaking
of modularity we also touched upon risk earlier where people think that every system has to be
100 up all the time that's never the case so that is also an important factor when you design
software when you design an architecture we should allow modules to fail gracefully for worst
case scenarios for example on a trading platform not all features are equally important maybe
there are a lot of you know let's say charting features etc worst case scenario people should be
able to see their portfolio buy and sell etc and maybe a certain charting feature not working is
acceptable but the site should not crash because of that exactly so when you think of it that way
when you look at your software holistically and decide that this is the most critical function this
has to have hundred percent uptime right but you know this can have 99 this can have 98. this
doesn't actually matter then you automatically architect your system to fail gracefully and
modularly just because this fails doesn't mean the entire thing should should fail just because this
fails it doesn't mean that your business is a ected so that grading modules of a product or a
technology stack and letting them fail gracefully will also make your system robust by doing that
you're automatically making them pluggable and swappable so we are swapping out postgres for
click house today despite having massive databases but you know that's how it allows that
modularity kind of allows you to do that right and you don't mix concerns like if you invent let's
say you pick a nosql database and if you're to do a lot of relational reporting you write end up
writing huge amounts of business logic and app code in your app in memory joints yeah in
memory joins you reinvent sql in your thing then you are that's not modular you can't swap it out
you put in so much e ort here so you should know that you know sql is the right thing to do it and
i'll you know o oad it to sql because it's a skill tomorrow when you switch uh let's just swap out
another sql db with minor tweaks you can port all your business logic so it's being modular and
i'm not talking about monolith service microservice but modular in architecture is important right
right and this modularity should never be should i mean i'm stressing should never be visualized
in terms of hosted services oh no you know function here edge thing here some you know snsq
here or whatever it should be visualized in terms of let's say linux software and modular in design
rather than modular and implementation i mean if it doesn't design the implementation will follow
suit exactly modular not in terms of external services but the software's own architecture so when
i see whenever i see architecture diagrams where someone is proposing a product and you know
it's full of let's say managed services from a certain cloud it's you know the high probability that
you know it turns out to be disastrous because they've designed their software to be entirely
dependent on completely external facets which you have little control of but if you're writing
ffl
ff
ffi
fi
ff
 software you should focus on software make it as self self-contained as possible and only give
away control to external service and resources if you absolutely need right right i think a factor
there i would say a lot of people do not consider also is i was giving a talk recently at a
conference about microservices and i was saying that okay and then there was a nice case study
uh i'm more than made on twitter which was like if you insert load balances uh let's say you have
a monolith you separate the data layer and the controller layer okay and you are load balancer
between them yeah so that data layer has its own load balancer now right suddenly the
architecture looks so nice i have separated my concerns and you know if somebody hits the
controller layer it will probably not fail i can scale it more data is separate but then without giving
any other context like discussing anything further uh how much does this a ect the availability um
uh anything like if you just simply take like p99 p9 in every layer you just add a new layer it will go
down it does not by default go up yeah now you doing that extraction yeah if you actually put an
e ort into making the availability higher because of that extraction maybe you don't need to reach
the data layer for a lot of use cases yeah then maybe you get an advantage yeah but if you don't
then the default is you lose out absolutely and then the other piece is also uh and that was part of
what i was explaining in the talk is like there were a lot of people who were you know founders of
tech companies and then they were talking about like whether they need to do microservices or
not yeah and i'm telling them that what's very important is the boundaries you draw in your
system you need to draw the correct ones yeah i was giving them an example like if you have a
blogging app if you have let's say the api layer the business logic layer and the data layer if you
separate at this way yeah like all the apis in one service all the business logic in one service all the
data what will happen is between them each hop will have a deceleration serialization penalty
yeah whether inside your system or outside the penalty would be there absolutely right and but if
you split by features let's say yeah and let's say if user sign-in is not available so my user service
is down but still people can publicly you know like index the articles google search works and
your article reading works yeah that's a much better split you a don't get the penalty of the
deceleration serialization yeah second year split it across things which you need and not need
rather than layer layer you have to grade those modules to fail independently and as gracefully as
possible yeah so dependency is one of the biggest bottlenecks a dependency and every network
dependency that you have is a you know is prone to disaster and failure and if you have a system
where you have lots of services all of them speak to each other over network mesh etc right
something goes wrong you can't even debug so software should be as self-contained as possible
by default so that that's why it's problematic saying i'll start out with the monolith or i'll start out
with the microservice architecture there's no such thing as a microservice architecture that works
for all software all people all teams all business all environments around the world it's just it's just
a loose name it's a vague name for a loose set of concepts right you may end up writing many
services you may end up with just one service or software but you don't know that entirely
depends on so many factors that are so private and intimate you know to a certain business so
there are no universal architectures that just work great i think thanks for answering all the
questions the last question one of the answers that take away i think really great where you say
that you know let's not think about writing microservices let's write software i think yeah i hope
that that becomes a very important takeaway uh from this uh but once again you know thanks for
coming here spending the time and this conversation i really really hope it will spark some
motivation to build things for people build software right software absolutely thank you thank you
so much it was a fun chat thank you and i think i've entered quite a bit yeah thanks for providing
me with an avenue to end thank you thank you so much thanks
ff
ff