like throwing myself into this weirdness of like, I don't know what the heck this syntax is. I don't know how to think of thing through this, but the more you do it, the faster you become and the better you become at it. I think the really interesting place to start will be when we talked about talking, you mentioned growth and despair in careers. Let's start with that. What do you mean by that? What's this despair in your career?
So I've been a software engineer professionally for 21 years and a few years before that, like, I guess, unprofessionally, if you will, back in college and stuff like hacking on stuff. But I've been pretty lucky throughout my career. Like I landed in good places, had good mentors, managers and all that and kept growing and growing.
I want to say maybe about 14, 15 years into my career, sort of after the senior engineer spot, right? Like I... graduated or became a principal engineer at amazon okay we can if you are interested we can talk later about the whole other parts leading up to that but we're going to just start from there at this point right so principal engineer in amazon
I think at that point, there was maybe less than 1% of the engineers at Amazon, so a pretty senior role. It's almost like a technical as well as a leadership role. although you're not a man manager. It's kind of like staff engineers or senior staff engineers that you see at other places, right? And... So leading up to that, for the last four or five years, I was kind of like, you know.
really aspiring and excited to get to that level and work across like big initiatives across many multiple teams and all that. So it was a pretty big like moment for me personally. And it's not like an easy step to get to. Like there's a lot of peer review and interview and all that, that kind of.
There's like a committee. Well, not a committee anymore in Amazon. There used to be. But at least a couple of other established principal engineers looking at your portfolio of work across the last like six, seven years and kind of deciding. are you up to that bar or not and all sorts of things, right? So it was a pretty intense process of like two, three years leading up to it to get to that level. So I was really excited.
And I think the first few months were really like exciting for me because... Another thing in Amazon, as well as other like bigger companies is you have to be performing in a role already to be promoted. right that's pretty typical in big companies is to become a senior engineer you have to be doing the work of a senior engineer pretty much immediately
So in a way, I was probably already working as a principal engineer. I was working with about three, four teams at that time. But the transition, I sort of started seeing after the first. four to six months is a lot of my work became Very, very distanced from like actually what we were building immediately in the moment. And I started feeling that I was starting to get frustrated with that. Right. It was very strategic kind of long term kind of work.
and very complex kind of work. As an example, I was in AWS at that time and one of the products we wanted to build. was for basically how people would use that is you would get notifications when anything across any of your like 200 AWS services happen. And you could customize it like very specifically using rules. And as probably people know, AWS is a very...
high availability and region isolated kind of structure, right? Like your data will never cross the boundaries of a region and that sort of thing. Those are like set in stone. Whereas for this kind of thing, what we needed is no matter where the notification is, it needs to... end up in your email inbox or slack or things like that and so there were like organizational principles and barriers that i had to kind of uh
rewrite or kind of convince leadership of that this is the right thing to do. And this is how we are going to honor the high availability and region isolation things, even though we're delivering kind of like a single page. of glass kind of product right that's bringing you information from all your products all your services and all your regions into one single place And that ended up being maybe like a six to eight month journey to write various forms of documents because...
You can't expect like a CEO or an SVP at a AWS level organization with like, I don't know. tens of thousands of engineers, right? Maybe at this point to understand each and every nitty gritty detail, right? So you have to like kind of write for the leadership and Amazon, it's a very writing driven culture. We don't go do presentations and all that.
So I think what I realize is what I'm doing is really important, really strategic work. This will open up a lot of doors. But at the same time, I have no connection with what we're building right now anymore. just that begs the question immediately because a lot of people in this did you like any code at all during that six to eight months there or is it all the documentation No, I mean I did write code, but that was more or less because...
I wouldn't survive like a month if I don't write code. I think it was, I could have easily gone by without writing code. I think the best principal engineers at Amazon actually do. do it really well where they are able to balance all of those aspects um another thing i did it's not super common at amazon is i didn't get out of the uh like the on-call rotation right because
I felt like the on-call rotation is a really good way, even though it's stressful, it's a good way for me to keep up to date with what are the things that are wrong, right? And the kind of... opinion within the Amazon principal community is divided. Like some principal engineers are, some aren't in it. And for good reasons, both ways. But yeah, I tried to keep my hands dirty, but I think there was definitely a sense of like, this is not what I'm going to be rewarded for.
Right. What I'm going to be rewarded for are these big kind of organization wide. framework changer or things like that that i influence and come to uh come they come to fruition maybe in four years five years down the line And I think at my heart, I was struggling with that because I just see myself as a builder more than anything else. And I was getting really, really frustrated.
That's kind of like what led to the growth story and then the despair part of it. Yeah. But it's true of so many things, isn't it? Once you get to that certain level. You move away from the code, you move away from being a builder and you have to build for other people. You have to build fire that aligning the resources of the organization, whether that's your computing resources, your financial resources.
Your development resources, you start spending less and less time actually building and more and more time trying to create that alignment. And whether you're doing that as a manager, trying to align people and vision and so on, or whether you're doing that.
for the technical side, trying to align the technical vision. You just find you like less and less code. I think that's something that a lot of us find difficult to accept because I think both of us, I'm guessing, quite like being hands-on, quite like still building stuff. I'm coding interpreters and compilers right now for fun. Right. And there's nothing bad about either of these paths.
Right. Like you discover for your own what you like to do. There are people who I like. They're my mentors that are still there. I talk to them once in a while. Right. They're extremely good at the principle or somewhere like. senior principal level. That's like maybe 0.01% of Amazon engineering community, right? That sort of level. And they're doing an extremely good job, both kind of influencing the long-term direction of what they're doing and keeping up to date with things.
And some of them are like into the prototyping, maybe the early stage of it, but it's very rare. And I think personally, what hit me is it's very hard to balance those things. at the expectation levels of like being a principal engineer or a staff engineer at a company like that. Cool. So in the last five minutes, you mentioned good mentors several times.
So what's a good mentor to you? What's been a good example of someone that's really stood out and why they've been a good mentor and how that's helped you? Yeah. I wouldn't name names, but I think people who are my mentors would probably know me. I would take examples of three mentors that I have had over the last 15-ish years. First one I would say is work pretty closely with me was within kind of the purview of the organization. And so they knew.
sort of the in and out of the technical stuff that i was working on okay so what i could discuss with them is when there were really complex kind of decisions to make i could bounce around with them get their opinions on it, and also get a different perspective usually on these things. So from a technical perspective, I love that person. The other two mentors were from completely different parts of Amazon. Okay. One was from Audible.
I was in AWS and this person was in Audible, which is the like audio books and podcasts and that space, right? Nothing to do with AWS. And what that person... always had me think was whenever I would go and discuss kind of like, hey, I'm thinking about building this kind of a thing. What do you think? He would go back to the first principles about like.
Who is exactly because he doesn't understand our like AWS customers as much as we do. But he would ask those very basic questions like, why would I do this? Why would I use this versus that other thing? Or why would I need? configure all these things to use this product. Because when you're building for, like, enterprise in AWS, for example, Most of your products tend to be very, very configurable, like lots of different ways people are going to use it. And it's more lower level kind of.
infrastructure as a service i was more in the product as a service side but it's very configurable versus what they're building in the consumer side is for like Everybody, it's the same product for everybody, like Audible, the app, right? So he would ask a very different perspective of questions. And then the third mentor, I would say he was in South Africa and then Ireland now. And this person had a very, you know, like.
down to the earth kind of he even though he was a senior principal engineer he was always open to it doesn't matter whether i want to talk about tech or some personal struggles or this whole growth and despair part i talked to him for months on end about like hey how did you go across this did you ever feel like this what do you want to do he is actually the one that echoed and maybe convinced me that maybe i should take a pause and like
figure out if what i want to do long term and it it's not always bad to like you know you're familiar with the concept of golden handcuffs i guess right yeah these big companies so so at like a senior level you do get paid a lot of money there's a lot of stocks coming every year so it's not always easy to say like
Maybe you should take a pause and stop that. And maybe even if you don't like doing whatever you think you will end up like doing, maybe there is a path back into this if you want to. So that sort of stuff. And I think all three kinds of aspects of mentors are very, very valuable. And then I would say one more, and this is actually, she was my mentee.
So I was her mentor. But for the most part, what happened is this person was a teacher for the longest term time. And then she changed her career and became a software engineer through a boot camp. uh happened to join like our team in amazon and this was maybe about 10 years back and i sort of like uh brought her into our team from a different team and became her mentor
And I feel like in the beginning, she was learning a lot from me. But towards the end, I started learning a lot more about how she thinks through because... She has been teaching like kindergarten students and like smaller kids all her life. And the way she kind of goes into a... Maybe a hard, conflicting kind of team situation where there's multiple different opinions and people are having a hard time kind of.
getting their point across, the way she would come in and solve, resolve those situations, I started learning a lot more from her. So that was, I think I would say I started as a mentor, but eventually I became a mentee of her. So, yeah. Those are some of the best relationships and the great benefit of mentoring, isn't it? Is that you can learn as much from the person you're mentoring as they can learn from you. So apart from that last one that you said you bought into your team.
The other three sounders over there are very culturally, geographically, and even organizationally quite diverse. AWS and Audible, fairly different companies to my mind. AWS built in-house by Amazon with your infrastructure. Audible was an acquisition, I believe, going back quite a while. You say one is infrastructure as code and a whole bunch of enterprise services.
there was a consumer app to sell us audible books. So how did you end up with finding these diverse mentors? That's a great question. So I think, first of all, inside these big companies, There are channels built in already for like finding mentors and stuff like that. But I take this question as like, I think let's, let's take it to the next level. Whether there are organizational.
channels and mechanisms available to find such mentors or not. I think as a software engineer, maybe in any career actually, it's important to find such mentors with diverse perspectives.
and it doesn't you don't have to immediately commit to somebody right like it's a long-term relationship but it's not you can kind of like go for a coffee chat with them or meet them virtually whatever it is see if you like each other's vibe if you get like positive from that relationship if you like it it can be very fulfilling but i would say date around i guess or to find the right mentor or mentors for you within your organization so in big companies
Like in Amazon, we had like a whole internal tool dedicated to finding mentors and kind of checking in with them and communicating with them and all that. And I didn't use any of the rest of that, like the communication or check-in. and all that, but I did use it to find such mentors. And so that's the first part. As a junior engineer, I was able to find some of them.
I think in most companies also at that staff or principal or sometimes even senior, depending on the size of the company, there are communities of those engineers built in. So in Amazon, we had like a principal, I forget what it was called, but a community. So every Wednesday, there would be a lunch and learn all the principal engineers across Amazon. Well, not all, but almost all of them would come in. And there's a very vibrant kind of stimulating conversation.
And through there, you would also find people that you feel like, okay, I really resonate with that person. Let me send them an email and see if they're up for a chat. But I think the main point is it is important to find... such different perspectives. I would say maybe even, and like I said in my case,
Some of them were, most of them were really senior to me, but one of them was junior to me and I ended up learning a lot from her as well. So it's kind of important to, I think, have those relationships. Yeah. Yeah. You mentioned just meet people and reach out and ask and inquire. I think people forget that you can just do that. What's the worst that can happen? They say no. Yeah.
I've had plenty of, you know, I've had, I mean, these people are busy, right? Especially the senior people. So I've had times where I sent an email saying, hey, I'm looking for a mentor. Are you up for a chat? Some of them outright said like, no, I can't do it right now. Like my hands are full, right? Some of them had said.
you know what i don't have time for like a recurring monthly kind of thing but if you have a specific problem i'm happy to talk about that and i met a couple of people like that that ended up, I think after meeting a couple of times, like I went to them with a very specific problem, technical problem. We talked about it.
Then we ended the engagement. Six months later, I said, hey, you know what? We talked about that thing. We launched this and now we are thinking about like a V2 of this thing. Do you want to have a chat? We had that chat. So those are also valuable, but more I think. targeted, very very specific.
Generally, probably in a more technical sense than as a life mentor or life coach or that sort of perspective. Yeah. And I like the way you put it earlier as well, like date around, go and try different mentors. Yeah. Yeah. Like you said, worst thing they can say is no, and you're no better or worse off than you were like 10 minutes before. So yeah. Yeah. And I'm now mentioning it. If anybody stuck for a startup idea, yeah. Tinder for mentors.
Yeah. Actually, somebody, you know, a principal engineer from Amazon, they actually also started a podcast about a few months back. So he actually said that he's having a lot of success with a thing called Mentor Cruise. I don't know if you have heard about it, if you have used it. Yeah, so he said that he has met a lot of great people through Mentor Cruise. He's an ex-principal engineer. He also kind of got burnt out and left Amazon and is kind of doing this as his full-time thing now.
Yeah. Cool. So talking of startup ideas, then let's pivot to this quickly. Then you are now doing a startup. How did that come about? Part of the despair. or the results of the dispatch? A little bit. So let's go back a few years. So I actually spent about 14 years at Amazon, but that was in two stints. Okay, so I landed in Amazon as a pretty fresh like SDE1, pretty green.
And then I did, I worked across Amazon, like three different parts of Amazon. And then there was always an itch in me to like go and work at a very small company, very early on, early stage company. So I left and did that. I actually tried once before to work at a startup. I moved to India, moved back to India, I would say, from Seattle and joined a very small stage company.
We had fun. I think we built something pretty interesting, but it was not... We were not seeing... good like growth signals and all that and at the same time i kind of felt like okay i need to actually go back to north america because of my daughter she loved her life there she was very young at that time but we could see that she loved her life there and she's not like really getting into it there so we decided to move back so I joined Amazon back
But there was always a part of me that was like, I want to work in a very small environment and do something. I have the ownership as well as the burden of... taking the right or wrong decisions actually ilia and i ilia is my co-founder um we talk about this quite a lot internally too we'll maybe touch upon it today later on but the the key difference of like working as a
very high level senior employee in a company versus as a startup like kind of co-founder what what are the differences in there right so we were talking about it and so like i always wanted to do that and As I was going through this despair period, around like 2021-ish, I would say, Ilya and I had lots of chats. Ilya and I used to work together in Seattle. For about five years, we worked together. Then he moved to Google. I continued on AWS.
We actually kind of at the same time arrived at this thing that we both love podcasts. We want to do something together. And none of the podcast apps out there are like doing what we wanted out of it. So we were like, why don't we take a bet on it? We did some analysis about what could be the possibility in this space.
decided to build it so that that's how we kind of ended up there yeah cool so what did you decide is a kind of killer feature for a podcast app that was missing yeah so this is about 2021 right so Ilya and I both listen to kind of knowledge heavy podcasts sort of like I listen to a lot of science as well as a lot of history Growing up, I never, I don't know if it was me or the schooling system or whatever, I learned a lot of factual kinds of history, especially region-specific in India.
but a lot of the like politics or the personal side of history all across the world. And I really got intrigued by it later on as an adult, learning about the personal stories of history. I do listen to a lot of history podcasts. I do listen to a lot of science podcasts. And the thing that kept bugging me and... Ilya and I talked, it was exactly the same thing as we would hear something and it's kind of like a flow of information coming towards you. If you retain it, great.
but it's very hard to go back and find that specific thing. Like if you remember, so I'll give you a specific example. Okay. So there is a episode of Neil deGrasse Tyson. talking about the Gregorian calendar, right? The calendar that we use right now. Why are there 28 days in February and why is there a leap day every four years and every...
100 years, there's like a change to that as well. Where did we end? How did we ended up on all of this? And he has a beautiful story talking about all of this, right? And I know the podcast that I heard this in. I don't remember the episode and I don't remember especially the specific segment in there.
I think we are not there yet with Metacast as a podcast app we're building. Ultimately, I'll kind of tell you what I want to do is I just want to type in Neil deGrasse Tyson, Gregorian calendar, and find that specific segment. Okay. Where we are at right now is if you know the podcast, there is a pretty... decent-ish search inside the episodes already. Like for example, for coding chats, if you go to the coding chats in the Metacast app and search for like a topic or a guest name.
Based on some metadata, this is not great yet, but you can find that episode. Once you open up that episode, the whole transcript is there for you to search and bookmark and all that. we are adding more and more this is still like two two person project uh so it progresses a little bit slower i would say it's pretty complex uh because we're building uh apps as well as the website at the same time But we have made decent progress on that already. But the idea, eventually the idea is that...
you can find things like this. You don't have to remember the podcast name or maybe even the person who said it and things like that. Like if you search for a Gregorian calendar origin, you should be able to find this piece of beautiful information. And the second part, why podcast is there is something about the audio medium. that Ilya and I both captivate towards. I know different people learn different ways. Some people love YouTube videos. Some people love blog posts and reading and...
kind of reading books like that. I have always been into like audio books and podcasts and something about the creator's voice talking to me kind of has a deeper connection than I think just.
as I get from reading or, and I don't usually have the time to like go through video. Like when I'm doing dishes or going for a dog walk, I don't actually be wanting to watch a YouTube video at the same time. So. That kind of juxtaposition of the audio medium, finding all this rich information that's already in there, but kind of the ability to...
quickly find or go back to that piece of interesting thing I heard or bookmark it, share it with others. Those are the things that we felt were lacking. And so we built that part. That's very cool because I do have a number of podcast episodes I've never finished because I've been listening to my walking the dog and I go, oh, that's a brilliant idea. I need to take that and use that. So I'll pause the episode.
so i can rewind 30 seconds listen to it right and then i'll finish my dog walk and then sometimes when i get back to the office or home i'll remember and i listen to it and take a note other times i forget about it and i i'll lose that little stroke of genius i'll remember it a little bit later on some of them the podcast episode has been so good
I've done this five or six times and I never actually get past the first 10 minutes of the podcast because I keep pausing it and never listening to it all. So that, that would be a very useful feature. Right. Um, that'd be great. So the interesting thing that you mentioned though, is audio and podcasts and I've got a mixed feelings about this. So for decades, I think myself, like a number of people had viewed podcasters dying.
Why would anyone listen to podcasts anymore? I've now got audible. I listened to audio books when I'm driving or walking when I'm not, when I'm at home, I've got YouTube. So I might watch videos on there. So, and again, I'm kind of guilty of this and it's more. not being aware of what's going on outside our own bubble. So until I joined the podcast company in 2022, I thought podcasts were dead and gone. So when I joined the podcast company, I found it's still a massively growing market. Right.
Yeah. And it's why subsequently I've created my own podcast now. And here we are talking. I did see a thing in some of the industry press a couple of days ago saying that YouTube was now kind of dominating the podcast. YouTube has captured a lot of the market. It zoomed past Spotify and this, and it's pushed video podcasts. Video podcasts are now the thing and the most popular.
How do you feel about that? How do you see that fitting in the industry as you're building a podcast app? Yeah. So I think, do you know Justin Jackson? Yep. He runs Transistor FM. He did a great post about it. And I mean. I'm not going to be able to do justice to what he typed it. So I would say for anybody listening to this, go read his blog post on this. But I'll give you my perspective on it, okay?
Video has a certain, definitely an appeal to it, right? For me, the appeal of video podcast is for... know-how or how-to-do-things kind of podcast, I love the video medium for that. For example, I'll give you two examples. One is, you know, Hanselman, Scott Hanselman from Microsoft. And the Microsoft Azure CTO, they have a podcast where they kind of do about 15, 20 minutes every week on how to do certain things. For example, use like Windows Power Tools kind of things.
Okay. So those podcasts, I think audio is a horrible medium for that because you need to be actually watching what they're doing while they're describing it to make any sense out of it. I have tried the audio part of it and I think some of it doesn't make sense in that way. Another example is I'm a big tennis nerd.
Right. So the tennis podcast where they talk about tournaments and results and all that, those are great in audio. I'll get to it in a second. But there are a lot of podcasts that discuss like strategies or tips and techniques for tennis. Right. And those I think are much better done in video than in audio because watching it while listening to it at the same time.
has a certain, like, more... I think you retain more of it for these kind of tips and techniques kind of things. Versus, let's say, history. Okay? or even signs, like I'm learning something about black holes or dark matter, things like that. The visuals don't really add much to that. versus I think what's starting to happen is because video podcasts and YouTube is growing, people are putting more and more effort into the video part of that rather than the content part of that.
Yeah, makes sense. And I think for me personally, like when I'm out driving or I'm walking the dog, those are the two times a day I always am listening to a podcast or an audio book. I don't have time for video at that time. I know a lot of people actually at their desk when they're working, they have YouTube up and they're watching something while working on something. My brain doesn't function like that. I can't do it. Yeah, I'm the same.
can't either yeah i i like when i'm working i can't even listen to a podcast i i need like music or something if somebody's talking my attention just goes to that so i can't function that way so i think there's a lot of people who are going to learn and get introduced into podcasts and all that via YouTube, which is actually great. But I think the use case, if you will, for different types of podcasts for video versus audio is slightly different.
Yeah, that makes sense. So pivoting topics slightly, you mentioned mentor number four was a teacher, a kindergarten teacher, I think for many years. And you learned a lot from her. That strikes me as a non-standard career path. Yeah. And as you also mentioned, I think she did a bootcamp. Yeah. So what are your feelings on bootcamps and, you know, the benefits, counter-benefits? Do you need a computer science degree to progress as you have for Amazon to a principal level?
Right. So I personally, I actually never did a CS degree myself. To be fair, I do regret it once in a while and we'll get to it in a second, but let's first talk about the bootcamp part of it. I also didn't do a boot camp and learn through that. We'll go back to my story in a little bit. But boot camps, I think...
For people who are looking to transition into software, it can be, like if you're a teacher or you're a nurse, actually this person that we are talking about, not only did she jump over, She is the mentor of that kind of a community inside or was inside Amazon. Now it's outside of Amazon. And she brought in actually another nurse into our team.
Actually, three people she brought in from complete career transitions into our team. I think overall it enriched our team quite a lot with different perspectives. But it can be very hard to jump into software if you have no background in coding at all. Right. Because it's a very different kind of the high level thinking and problem solving and all that aside. the actual mechanics of building something is pretty alien to somebody who doesn't know anything about software.
Right? And then you put in all the kind of architectural blocks that you have to be aware of to build something good, like...
Starting from the basics, like a database, which maybe makes sense to a lay person, right? A database is where you store and retrieve information. But then the best way to store and retrieve, the scaling-wise efficient way to store and retrieve, caching on top of... that how do you have communicate like different parts of the system do you want to build it as a monolith or like distributed architectures different pieces communicating to each other via messages
serverless functions like Kubernetes. There's so many things to think through. right? And we're just thinking about the system side of it. There's also the whole, like, web. If you're building a web or an app, there's an entire different world of things you need to learn. And I think it can be pretty daunting for somebody to come in and not just learn the syntax of programming, which is alien.
enough already, although it's much better than it was like 20 or 30 years ago. But also all of these other things on their own very quickly. My transition was kind of like made by myself because I found this world exciting. We'll get to it maybe in a little bit why I did that. But for somebody who's looking to transition, let's say from being a teacher to a nurse, and they're earning money, but they want to transition and do something else.
they don't have an infinite amount of like, they can't take like, okay, I'm going to take five years to learn all this and then find a job, right? They need to find a job maybe within six months, maybe within three months. And so for them, I mean,
Other than learning all these things very quickly yourself, I think bootcamps are a great way to kind of go through the process, learn with others, learn from experienced people. Yeah. I have also run kind of... I wouldn't say these are bootcamps in the traditional sense of like three to six month bootcamps, but I've run one day camps where you have people coming from a different background.
And like, let's say something basic as building a Ruby on Rails website, very basic website, right? You're not deploying it to production, but you see that, okay, I'm writing this and it's showing up in a website here. And that's kind of powerful enough to a lot of people to make that transition or start thinking that I actually want to do this. This is super fun. So, yeah. Yeah. I think that's one thing that the web has made so much easier for.
For people coming into software engineering. So I started coding when I was nine years old. And for me as a kid, it was like, hey, I can get this graphics to move. I can create a simple computer game. Right. Which was, you know, hard back in those days. It wasn't very easy to get to that stage. But nowadays, you could do that in Python, PyGame very, very quickly and easy. You could do it in the web or you can get just a web page out and see something. It's so much easier.
And that's much more exciting than building a terminal app, much more satisfying. Yeah. I mean, I also kind of landed up here. in a similar way i was actually a civil engineer i was going through my undergraduate in civil engineering and um one of the things i built was a software for like estimating the cost of a project, right? So you would take in all the like building materials, you kind of estimate, I want to build this house, let's say, right? So...
It has these many floors. These are the rooms. These are the dimensions. Based on this, how much raw material am I going to need? How much labor is it going to need? And what is the entire cost of this project, right? Software estimation. This is, we're talking about like maybe 25 years ago. There's, I'm sure there are like 200 different great software doing this. But as a student project, this is the first thing I built. And I did this in Visual Basic.
Okay. So it was more or less like plug and play kind of components. But I was mesmerized by the process of building something that others can use and they don't have to go through all these calculations and do it themselves. So then the next year, the project that I picked up was in Visual C++, kind of a traffic signal design.
So the data collection was still manual, like you would collect manually how many vehicles are coming through which intersection from which side manually, but then you feed it into the system and it would... You can say it's linear programming, but this is before I knew what linear programming was. It would kind of do some math and come up with like, this is the most optimized way to arrange the timings for the signal.
Right. And there was just something fascinating about having a computer do this rather than a person kind of go through these calculations and do it. And so that got me started and I picked up.
c plus plus or something like that after that and then when i got to the web i was like wow this is super cool like i can build things uh that others can use and i think maybe that's a part of me that to this day i love building consumer or things that like people can touch and feel very quickly rather than enterprise backend kind of, even though I spent a lot of my career in AWS in the API and backend side of it.
And I love that part of it too. There's just something about bringing something to life that other people, hundreds of other people can use it. And that just is gratifying to me. So, yeah. Yeah, definitely. I can agree with that. I've built a few bits of software that were millions of dollars worth of software, but three people in the world ever saw it and used it and nobody did.
Massive impact, but when you realize that Hardin actually uses it and you can count your users on one hand, it's quite different from then going, oh, one of my first things is I built a bot for Quake. Over a million people downloaded that bot. That was quite like, hey, and I was still at university at the time as a student. It's like, hey, this is amazing. A million people can download some software I've learned over the internet. And they're using it. It's mind-blowing at the time.
So you've listed quite a layer of technologies there. You mentioned Luby, C++, Visual Basic. You weren't kidding when you said you've tried different things when we talked earlier. So what else have you been trying? Whatever technology stacks have you played with?
So I think aside from the, if you were to take out whoever is listening to this, if you were to take out two things from this episode, I would say the first one is finding the mentors, trying out different mentors, the chat that we had maybe about half an hour back. The second thing I would say is try out different technologies because we'll get to the because later, but try out different things.
just so you get exposed to the different perspectives. And I think in some ways, this is the same thing as having different mentors with different perspectives is you're going to enrich the way you build software. very differently every time you come across a new paradigm of building software in, right? So I started with, like I said, Visual Basic, Visual C++, then C++ and all that.
For a while after that, I worked in like Pearl. This was the early Amazon days. So Pearl and Mason, those kinds of technologies. It was very complex to build anything in it, I would say. And then I think the first wave of, I don't know if you were part of it, but the Ruby and the Rails community back in about 2009, 2010-ish. maybe a few thousand developers across the world, but that community was like amazing to me. The amount of support and the open source kind of ethos of it.
Right? Like everything is open. You can read the source code of anything you want, and then you use it to build your own things. You can ask questions. If you have a problem, you can report it. You can go fix it yourself, or you can help kind of document why it's not working.
the way you're and somebody somewhere sitting across the world is going to help you out without you paying anything to them right and just because they everybody believed in the open culture of it and that was amazing to me So that kind of, I think, kept me going.
throughout as i get more and more invested in like the software world so then um one of my mentors i don't remember who but said you should try out like lisp style of programming too because that's a very different way so and that's when i started getting into the closure i also tried all those other like kind of lists for a good four or five years emacs was my editor And so I completely was into Elisp. Emacs is an editor built with the Lisp itself, right? So I was heavily into that.
And then I think over the last few years, what have I tried? Kotlin. pretty much built a lot of backend things in Kotlin and JVM. And then recently with Metacast, our app is in Flutter. So that's for the Android and iOS apps.
And then our website is Next.js with React deployed on Vercel. So I think last two, three years, I'm learning quite a lot. And I've come to realize that I love this experience of... learning something from a new framework or from a new programming language and bringing it like kind of... kind of uh ingraining it in myself that this is the right way to like build software for for example um closure or lisp i don't use it
And at all apart from like maybe two, three years where I used it a lot. I have not touched it since then. But the way it has completely shaped the way I think about software building in a way that everything should be small, composable functions. and the functional style of programming, right, where you pass data along to things, and then they modify it and send back.
Actually, they don't modify it. Everything is immutable. But basically, you pass along thread data along various things. Each one is a small unit of capability, and they'll do something with it and give you a different piece of data that you thread along. This is something that I live and die by even now, right? Like all the software I build is sort of like that, where it's small modules of like capabilities that come together to build this whole app that you're experiencing.
So for a while in there, I also, I got so much into programming languages and you are probably more of a programming language nut than I am because you said you're building like interpreters and stuff like that. But I got really into programming languages. And so I took like a course in programming language design, played around with building my own programming language. There were, I don't know if you have read those, but there were.
two really beautiful books called Seven Programming Languages in Seven Weeks and then Seven Databases in Seven Weeks. And actually databases, again, they're not languages, but they also completely reshape the way you think about how you store and manage data. I love those things. So I would like constantly go around maybe every six months, find something else and do it in. And then last thing I would mention is every year, I didn't do it last year, actually.
Thanks for being in a startup. But till then last four or five years, I've been doing the advent of code that happens in December. And one of my goals was always to pick a new language to do it in. Because my goal and my capability.
to be honest, I'm not going to end up on the leaderboard, right? Like there are people around the world who you post the question, get posted at like midnight Eastern US time or something like that. And within three, four minutes, there are like 15 solutions out there. I'm not one of them, right? My goal is to actually learn and craft something beautiful, taking maybe four or five hours of that day.
and then learn from the process of building it so for every year four or five years i picked a different language to build it in and i think i enjoy it and i think it does enrich the way you Maybe you pick up something and then you leave that world. You go write software in another language, but it...
fundamentally changes the way you think about building software in that new length. Yeah, absolutely. I'm actually very curious to learn from you on this too. What's your experience? What's your process of picking up new things? I'm just curious. And I love learning new things. So I have tried to stay away from seven databases in seven weeks and seven languages in seven weeks because I'll just lose 14 weeks of my life. I'm, I can, I can lose all that time.
That's just the title of the book, yeah. It probably took me like a month to go over them. I would end up speed winning them. Right, right. It's not unknown for me to get through a 300 or 400-page book in a day. So if I pick up a book like that, I will end up working for it as fast as I possibly can. Everything else gets dropped for a bit. So I don't want to do that because I'm trying to do my own startup. But I'm totally with you. I have...
I have learned 30 or 40 programming languages at various different levels over the years. Right. Maybe even more than that. Every time I try and list some, I realize I've forgotten some. And some of those I've learned... enough to do the tasks that I had because that was the job. Some of them I've gone into intense detail. You know, I was passionate about C++ for a while, got involved in the standards process and was.
involved in the Standards Committee. I'm less involved in that now. More recently, I've done quite a lot of list and go, and I've been interested in those. But every single one, as you say, I've learned something new from it. I've got a different perspective.
And that's very, very powerful. I think it makes you a far better software engineer because you realise that programming knowledge is just a tool. You don't have to get wedded to it. And they've all got their strengths and weaknesses. They've all got something to take from it. And you say...
When you then also look at, you know, imperative language versus a functional language versus an OO language, you can look at all of these and go, well, actually, I really liked that part. You know? Yeah, that's great. I like the idea of objects. I don't like the idea of inheritance and all the complex mess that you get with that. Or like dependency injection, for example. One of the things Ilya and I had a beef over last week was my TypeScript code.
tends to have objects and classes and all that and he was asking me like why why why don't we just do functions and um Maybe this is because I'm pretty new to TypeScript and JavaScript and all that, even though I use it in the web sense for a backend part of it. I haven't used it much. a lot of it is also dependency injection. And I found that the best way over time to kind of write unit tests for...
In a startup, we don't want to write a unit test for everything in there. Maybe even in real world, you don't want to. That's maybe not the best use of your time to code up every possible interaction in the system. But in... in in our place it is pretty important to be able to systematically test various inputs and outputs for some complex like let's say regular expression related things or something involving a dependency you do need to know
what is the expected input and output, not just to learn it in today's time, but maybe a year down the line, has anything changed if I change that dependency or upgrade that dependency? Does anything break? Right. So that's kind of important enough. And the best way I found to do those kind of things is to build a decorator or a wrapper around it and have that be a dependency injected so that you have a very.
isolated, abstracted layer around that piece of software that is a third party, and the rest of your system doesn't need to know anything about it. But at the same time, you can test that very easily and know that whether it's working or not if you upgrade or change that dependency or something like that. And whether that's in TypeScript or Clojure or whatever, I'm not going to go away from that concept.
Right. So, yeah. And that sort of harks back to what you said before about the functional style, where your function is going to take in some data, which is immutable, or you treat as immutable if you're not using language as that.
And you're going to apply an operation to it, and you're going to return that data back. So again, you're not changing the input, and you have no side effects in a functional style, but you're going to change this data back. Again, that makes your code a lot easier to test. Avoid side effects in your phone. You treat all the data that comes in as immutable. Again, a good style to pick up and you can apply that whether you're working in a functional language.
language or anything. So the exposure to these different things is really good. And you mentioned Ruby and rails, you know, that was one of the earlier frameworks that applied MVC and some of those design patterns. in a reasonable way and introduce some people to that. So it's quite useful. Before that, I was in some really crazy PHP and Perl kind of website code where there was no separation between the website and the database and all that was a nightmare with some SQL thrown in as well.
be right into that website yeah yeah yeah in 2009 i was more exposed to wordpress so we won't talk about open source and wordpress we'll avoid that whole mess yeah Yeah. Cool. But I'd love to do more of a Lisp-like language. So I'm quite interested in playing with Clojure sometime again. Yeah. I've had a very brief play with Lisp when I go at a coding challenge around it. But apart from that, I haven't dug into it too much.
Yeah. One of the things actually right after Clojure I picked up is Elixir. And I know recently Phoenix, the web framework for Elixir has gotten pretty big. Lots of people are using it. I haven't tried Phoenix. So that's one of my goals maybe over the next year or so. I'll learn that. Cool. Yeah. There's so many fun things to go and learn and try out. Yeah. Cool.
I said this would be about half an hour, but as usual, I've gone way past that. So we're 55 minutes in. Any last thoughts or points that you'd like to share now? I didn't actually think through this in terms of like points, but I would say you actually brought up the two most important things. We are maybe the third time I'm reiterating them, but...
Finding the right people, maybe even generalizing mentor, right? That you like working with, but also learning from and making learning a continuous process, whether it's... from people or from new technologies, new software. That is, I think, the best way to grow in your software engineering career.
right is different perspectives always being open to those perspectives try out new things and i think the more you do it the easier it becomes From my personal perspective, and I've seen it in a lot of other developers later on, is if somebody has been coding in, let's say Java their entire life, right? if you throw them into Dart or into TypeScript, they're going to hate it. And they're going to look for the same ways of doing the same thing before.
And maybe that struggle will last for a while but eventually they'll start to learn from the new thing. and do idiomatic things in that new language. And it'll actually enrich their own programmer, like programming style in the long run. But it is hard in the beginning if you are just used to doing things or you love, let's say, I don't know, Kotlin. I love Kotlin. Even to this day, I love Kotlin. But I'm never going to go and say I'm only going to code in Kotlin. It depends on...
Maybe it's a systems piece of software and I need to pick up Rust for it or go for it. So be it, right? The more you transition through these languages and processes, the faster you get at doing that. Yeah. And I'm sure right now when you said you're going to go pick up Clojure or I'm going to go pick up Elixir. I have a confidence that like within about three, four days, I can be reasonably good in Elixir or Closer, even if I've never been exposed to like that style of programming before.
And that is only because I've tried it so many times before, like throwing myself into this weirdness of like... I don't know what the heck this syntax is. I don't know how to think of thing through this, but the more you do it, the faster you become and the better you become. Yeah, absolutely. And to believe your point, I've had a few customers where I've gone in as a consultant.
And they've said, we've got this problem. Everything's broken. Building's burning down. We need this code fixed ASAP. Great. Where's the code? Look at the code. And it could be in a language that I've not dealt with before. So I've had to... sit there, figure out how do you build it? How do you deploy it? What is it? What the hell does this code do? So I've done plenty of times where I've had to come in and review code in a language I've not seen before. I then start fixing it.
And as you say, the more exposure you have to different languages, different styles of languages, the easier that becomes. And I think that's important to like on your path to become a senior engineer. And also... You never know, right? Like you may not be working in the company that you're in love with right now, five years down the line. You want to look for a different or the industry overall changes, maybe.
Right. Like we went from C++ to Java in a matter of maybe five, six years and everybody was building everything in Java. Right now it's all like web apps. Like you wouldn't think beyond like JavaScript. There's like 15 different ways of building a JavaScript, but you wouldn't think usually beyond JavaScript to like build a web app. So if you have to make those kind of career transitions,
Make it easy on yourself and like kind of be used to switching tracks and learning from different ways. Yeah, absolutely. A hundred percent. So thank you very much, Adam. So where can people learn more about yourself, mentoring? And Metacast, most importantly. So Ilya and I, my co-founder Ilya and I, we do our own podcast where we talk about Metacast. We launched like six months ago, the app in iOS and Android.
It's a linear growth, slow growth, but it is growing. We're getting more and more people using it every week. Like I said, I get a lot of joy of people using software that I've built. And so that's growing. And that sense is growing that it is actually meaningful. But we do document all of our ups and downs. kind of struggles that we go through as well as the positives. I want to say monthly two to three times, sometimes more, sometimes less. That's called our Metacast Behind the Scenes podcast.
And then we have another more, I think... uh infrequent podcast called builders gonna build where you were john you were there last year that actually since last year we haven't launched anything but we just recorded uh one last week that's going to come out soon So on that podcast, like you are doing in this podcast, we bring on people who are building things
Whether it's like you said, you're like running a coding challenges or somebody's building like a product of their own. We try to bring on those people and learn from their journeys. So it's kind of like a founder's journey kind of podcast. So those are the two of our podcasts where you can listen to more if you like what.
we are talking about here. Aside from that, metacast.app has all the information about the app and Ilya and me in the about page of that where you can find our entire history and how things led to what. Yeah. Awesome. Thank you very much. It's been a pleasure talking to you. Thank you.