P2P Podcast Series: Priya Patil from Hobby to Trustee

During the day, Priya Patil (LinkedIn, Email) helps companies of all sizes solve their problems as a polyglot engineer for 8th Light, a consultancy based out of London and Chicago.

At night, people like Priya are building a more diverse future for the tech industry. She was one of the first students of Codebar, a non-profit inspired by taking Rails Girls workshops. She continued by becoming a coach, and now is one of 6 trustees that steer the vision and execution. You can also be the change for diversity by joining Codebar.io as a student or coach.

In our chat, we talk about hands-on learning, taking breaks, the history of Codebar, growth patterns, and successful software without test-driven development.

This episode is packed with insights about:

• (00:01:44) Take a sabbatical when you can (and be intentional)
• (00:08:39) Rails Girls starts with connection and empowerment
• (00:12:07) "I owe my career to Codebar,... but it's not unusual."
• (00:27:50) A great environment is where everyone is humble and willing to learn
• (00:31:01) Tech expectations are immature compared to other industries
• (00:33:58) Success starts with engaged communication
• (00:42:19) Balance humility with taking healthy credit
• (00:50:20) Effort + Practice = Expertise
• (00:51:48) Helping people grow needs many different hats
• (01:02:23) Code-based systems are more predictable than human-based systems
• (01:03:38) Big companies don't have panaceas to "big" problems
• (01:11:35) Sometimes success is just throwing more talent at the problem

Listen and subscribe on Apple Podcasts, Spotify, Google Podcasts, Overcast, or your favorite platform.

Zeke Arany-Lucas is a developer, coach, and consultant from Seattle, living and working in Berlin since 2014. He has been in tech industry for more than 25 years, starting with web browser development in the 90s, including long stints at both Microsoft and Amazon in multiple leadership roles. You can also follow him on LinkedIn, Twitter, and Instagram.

Artwork by Emre Aydogan & Laura Diezler — ©️2022 Zeke Arany-Lucas

Read the full transcript

Zeke: Hi, welcome to The Introspective Developer. My name is Zeke Arany-Lucas, and I am talking to software developers who started their career without a computer science degree. Um, today I have Priya Patil on the show. Hello, Priya. Um,

Priya: Hi, I'm excited to see you today.

Zeke: Awesome, awesome. I'm really excited to have you on the show. Um, can you introduce yourself, tell me a little bit about, uh, what you're doing right now, where you're living, um, where you started out?

Priya: Yeah, of course. Um, so slightly different answer to the two questions. So I started, um, I'm a currently a software consultant at 8th Light. It's a small software consultancy based in London. Um, the head office is in Chicago. So, uh, the state side of things is much bigger, but for like a small office of around 30 people, um, and get put onto different clients, uh, to kind of help them write good clean code.

And I've been doing that for about seven years now. So a long time I'm a career changer. So previously was working towards a career in law, um, and then made the switch through kind of attending evening workshops and kind of making a hobby into a career. And right now I'm actually, just started my sabbatical.

So I have a mini three month sabbatical. Unfortunately, I got sick at the very beginning of it. So I've just recovered today. But, um, yeah, pretty much started that at the beginning of the month of July. And yeah, so taking a nice little break, it. But, uh, this is it's good to meeting this podcast in that time as well.

Just chatting and reflecting on what I've done so far. Yeah. Hmm.

[00:01:44] Take a sabbatical when you can (and be intentional)

Zeke: You know, sabbatical is a really powerful experience. My first sabbatical, I didn't waste, but I did not take advantage of it to its full extent. I took the sabbatical at Amazon, which is cool, cuz it's a perk in Germany that doesn't exist in the US.

So you could take a sabbatical it's unpaid, but three months was, you know, maintain all your benefits and stuff. But the, the, the fact that you are not do not have to think about work, um, opens up things in very surprising ways.

Priya: Oh, for sure. I think it, I, I think in tech, it's almost like, because it's just such a good idea. I've only spoken to a few people now who I've noticed have, like, I've noticed more and more people are doing it basically. Or I'm just talking to people at a stage of their career where they feel they need a break.

more so I'm not sure whether that's the case, but. Yeah, I think it's probably good in every industry, but I feel in tech, like, cuz you're so detail focused, just looking at code all the time. It's good to take a step back sometimes probably as well. Um, and yeah, so I mean, I'm, like I said, I've just started, I have some ideas of what I wanna do in that time, but yeah.

Um, I think I would definitely recommend it or yeah, I think it's definitely a good idea if you're UN tech to do this and take a bit of a break.

Zeke: What, what are you thinking about doing during your sabbatical?

Priya: So , I'm traveling a little bit, uh, because since coronavirus, I kind of have missed that. Um, but I also am at that stage of my career where I'm kind of thinking about if I wanna specialize in something a little more, because I work in, in like consultancy, we get put on lots of different clients and get a bit of a breadth of experience.

So now I'm starting to think about if I want to. Look into an area more, and there's a lot of talk around machine learning and all the, this aspect of things. So I'm kind of looking into that and seeing what I would need to do if I wanna move in that direction. Um, it's like a lot of theoretical stuff at the moment, but yeah.

Talking to people in the industry to see if it's something that I'd be interested in doing, um, and kind of where to start as well. So yeah, that's kind of my idea.

Zeke: I spent my sabbatical, my pre last one, my first and last sabbatical official, pretty much thinking, making, try to make the decision between whether I should jump back into management or stay, you know, as an IC. So I was working as an IC and I was having this debate and I spent the entire three months, kind of looking at jobs in the surrounding environment, um, and interviewing and even getting, you know, having, having, having, getting accepted, getting offers, and then in the end, deciding to stay at Amazon and switch to a manager position on a new team.

Priya: Yeah.

Zeke: but my, my wife was like, you do this for every vacation, you know, like you, we start the vacation and then you spend the whole time thinking about what you're gonna do next at work.

And I was all

Priya: Yeah, I

Zeke: Ooh,

Priya: No, it's not great.

Zeke: smart.

Priya: but it's true. I know. I like, I was, before I went from my sabbatical, I was talking to my manager and stuff and saying what I wanted to do. And they were like, just take an actual break. Like, don't think about work for a while. Like, it'll be good to take an actual break, but I don't, I think I actually do really like coding, so I kind of, it used, I mean, it used to be kind of something I enjoyed just doing in my spare time.

Um, so I'm starting to get back to that feeling again, I think at developer people go through this a lot, like you work on a project or a client and you feel like you come up against like some of the bureaucracy and the, the stuff that kind of slows you down a little bit. And then when you don't have those constraints, it's really fun.

So like side projects and things are a bit more interesting and what you can do with it is quite fun. Um, but then yeah, it's

Zeke: I'm thinking about being a consultant, but I have not actually done it.

Priya: Yeah. I mean, to be honest, it's, they're real, like, there are things I really like about it. The fact that you're kind of trying to solve. People problems ultimately is what I think I've seen in like being at different clients. It's always about like communication and the tech is the easiest part. Like the coding is not the, not really the tough part.

Like if you have good people around you who wanna like write good code, that's not really the constraint. Usually it's just communication and like trying to, um, communicate with all the people that you need to, especially if it's remote right now, that was quite a challenge. But, um, but yeah, so that part is quite fun and you get to talk to a lot of different people and different industries and yeah.

Feel like you're solving some good problems, I think.

Zeke: I'm pretty sure that this is for almost any project in any domain. That's important in the end, it's working with people that's the real challenge.

Priya: Yep. Yep. Yep.

Zeke: Well, let's, let's rewind cuz I think the, one of the things I'm most curious about here is, um, how you decided to become a developer. Tell me about this, this early decision.

Priya: Yeah. So I guess I have an older brother, so I've always been like aware of tech. And as I was growing up, he was like always taking care of like the computer side of things. And like, we got a Packard Bell and he was the one setting it up and kind of, he took the lead there and it all, I used to look up to him a lot.

So I always used to think that was very cool. But then in our schools and everything, like, it just, wasn't an industry that we had any exposure to. So I never considered becoming a software developer. Our IT classes were just, filling in Excel spreadsheets with this number. That was pretty much it. Um, and then as I was studying and like going towards becoming a lawyer, that's what I wanted to do.

It seemed like sensible and well paid job and a very clear progression. Um, I was just like reading more and more about tech and coding and kind of how it's shaping our world. And at that time it really was, um, it was

Zeke: What

Priya: Probably that must have been around like 2010, 2011, 2012, like those years

Zeke: time is that? Hmm.

Priya: I CA yeah.

And I started reading like Wired magazine, cuz I was like more interested in like seeing what was going on there. And they had, I saw a page in it which had an advert for Rails Girls. I dunno if you've heard of, um, that organization. Um, I think it started in Scandinavia and it was a weekend workshop where, um, if you attend, they'll show you how to spin up a Rails app basically, and show you what you can do.

[00:08:39] Rails Girls starts with connection and empowerment

Priya: Um, it started in Scandinavia and then they started in different cities, um, across the world. I don't, I'm not sure if it's still going on, but at that time it was like one of the few coding, like workshop, weekends that you could attend, and it was very female friendly. The marketing was clearly targeted at females as well.

And, um, and yeah, so I, I looked it up and I saw that they had one in London, which I couldn't attend, cuz I had plans that day. And they also had one in Bristol, so I went all the way to Bristol just to attend this. And I think one of the best things that it showed was like, how. how you could do something.

So like, obviously now that I've worked a bit longer, I see like, it's clearly a lot more complex than if you just start up, uh, a Rails app. Um, and then just kind of have the default configuration. But at that time it seemed like, oh, wow, this is something that is possible to do. And that was really empowering.

And then the people who started Rails Girls in London kept it going. So they kept weekly workshops running that turned into Codebar. So like the, the founder or the person who volunteered at Rails Girls kept it going and kept wanting to like, keep the momentum up. Like one weekend was good. But then if you actually want to teach somebody how to, you know, learn a bit more about what's involved, they kept these workshops going in different offices in London, and then that turned slowly into Codebar.

Um, and I kept going. Cause I was thinking I was, there were people volunteering their time. There were all developers working professionally. And I was like, wow, this is incredible that people are willing to teach, teach me. I have no excuse not to go. If people who are like good at what they do are giving, you know, education for free.

Like it's, I felt very grateful and I just kept going and I kept learning. And then I, yeah. And then I met people, um, at my current company who were also volunteering at Codebar and they were starting an apprenticeship. Um, and so it was a student apprenticeship for the first time they had apprenticeships where, uh, if you did a boot camp, you could attend.

So after having learned a little bit, but for the first time they were doing one where you didn't have to have any previous, uh, experience. And so I applied, I started doing that. It was an unpaid position initially, and then it was a paid position as an apprentice as well. And yeah. And I'm still at that company now.

um,

Zeke: Wow. So, so you were at Codebar before there was a Codebar. You know, full dis full disclosure, um, uh, I, I got a hold of you, of course, through, um, Kimberly, who is the director of Codebar. And ran into Codebar basically indirectly when I was looking for, um, you know, I was just searching for people who, you know, have non-traditional tech backgrounds.

This is just, I was just kind of looking for, you know, how do people learn to code these days? And I stumble on Codebar and then I volunteered as a coach myself Codebar. And then, um, you know, I've done some coaching sessions and stuff like that, and it it's been interesting, but one of the things I was curious about was, you know, what's, you know, who uses Codebar and how much of an impact does it matter?

Does it make, and it sounds like in your case it was hugely impactful

[00:12:07] "I owe my career to Codebar,... but it's not unusual."

Priya: Yeah, I mean, I owe my career to Codebar pretty much. So definitely

Zeke: And it sounds like you're act, you're actually part of why Codebar was even created. I mean, you're part of.

Priya: I mean, at that time there were other people as well, and you know, I think there's actually, the thing is, so now I'm also a trustee of Codebar. I started as a student started coaching and I'm now a trustee, it's officially a charity as well. So we've got charity status, I think maybe a few years ago.

And, um, and so I think I'm not actually that unusual story. Maybe I was first. So like I started a long time ago, but I think a lot of people have actually got jobs through Codebar and from just attending regularly, going through interview processes, maybe they're also doing a boot camp, for example, but, um, yeah, I guess.

My story is quite cool, but it's not unusual. I don't think, I think maybe I was, yeah, I've been doing it for a long time, longer time than most, but

Zeke: I was just more thinking that you were part of the, the momentum, right? So the, the energy that, you know, makes these things work, when you say, oh, why are you volunteering? You're volunteering because there are people that are worth volunteering for. Right. And, and then, I mean, like, and you're actually even better example because the energy that you brought actually then allowed you to, you know, carry on forward into networking, which then got you into your apprenticeship, which then now has your career, but then it kind of comes full circle back in, and then you're coaching and you're keeping the momentum going for another generation.

Priya: Yeah, for sure. Yeah. I think that, that's kind of what I noticed at Codebar. Just that energy, when you even go to a workshop, like people are generally there for a good intention, so it is just, a good atmosphere. People clearly like what they do, if they wanna give up their evenings to teach it even more, or like, you know, are passionate about making it more diverse.

So, yeah, definitely. I like feel that energy. And I remember when we had in person workshops, which we have now, again, like you end the day real in a really nice note and it's just because of the energy that people have in those workshops and the hosts themselves as well. Like yeah. It's been really, really good.

It's funny looking back on that time. Like, I, I also think that time, like 20, I think, guess it was 2012 actually, if I, if I try to think back exactly when it started initially, um, maybe 2012, 2013, it was like early days. It felt like I don't, I mean, tech had already been around for a long time apps, like, you know, programming, in general.

But it felt like it was just starting to get into like public consciousness a bit more. And I, I felt like I was just ahead of when everyone was gonna start coming over into, into the industry as well. Um,

Zeke: I think you might be onto something there there's inflection points where the, the growth curve accelerates. Um, you know, so, you know, people talk right now, they talk a lot about the.com bust because of the, the, the downturn this year with, uh, stock prices. But. Dot com boom. That immediately preceded it totally transformed the university pipeline. So what was happening was there was all this hype and excitement and the schools realized they needed to change their curriculum to feed into the ecosystem, right.

So there, what did go from, Hey comp sci was mostly academic computer science. It was like Knuth books and stuff like that. And then, and then they, oh, now they're teaching Java.

Priya: Right.

Zeke: And I was, I was already, you know, working at Microsoft at the time and I actually got to watch the candidates change, right. So you're interviewing people and then suddenly they start coming in with Java programming experience. And, um, and I think that there's inflection points like that where like suddenly the, the, the environment changes.

And I think like 10 years ago there were, there's almost no boot camps, you know, like there are here some here, one or two here and there type of thing. And I think it's like 10 times as many boot camps now, as there were 10 years ago, like they've just been growing like crazy. And, and you even talked about Ruby on Rails.

I remember the first time I heard about Ruby on Rails and it was absolutely in the context of which you just described it, meaning that the, the thing that people loved about Ruby on Rails is that it was so easy to kick off an app.

Priya: yeah,

Zeke: To build a website of your own was almost effortless. You didn't have to learn hardly any programming, um, in order to, you know, get up and running.

Um, whereas, you know, writing it in C or something like this is just like, okay,

Priya: yeah,

Zeke: you'll be a few weeks. Just try to get the thing to compile.

Priya: Yeah, for sure.

Zeke: Uh, did you have to interview when you were

Priya: I did, I had to go into the office to, for my apprenticeship. You mean?

Zeke: Hmm.

Priya: Yeah. So yeah, I had to go into the office and kind of just chat through kind of why I wanted to do it, why I wanted to do the apprenticeship and it felt like the initial apprenticeship kind of is a very prolonged interview. Um, and then you basically go through a student apprenticeship, uh, it's changed format now at the company, but when I was doing it, it was a student apprenticeship. Which you then, uh, after about three, four months, you do another assessment and it's kind of, then it's decided whether you become a resident apprentice.

So like the initial student apprenticeship was kind of felt like a very prolonged interview. We are doing like code challenges, PMs, like, um, iterative planning meetings. And, um, uh, I'm trying to remember because the first two have blurred into one. So my student at resident apprentice, I think it was four months.

I think my student apprenticeship, if I remember correctly. So it was longer than the boot camps. I remember thinking that like, um,

Zeke: And you did a bootcamp too. Ah Hmm.

Priya: no, I didn't do a boot camp, so that was my boot camp equivalent almost. So I started like writing just one function in Ruby, I remember. And then writing a test for it and then doing like really fundamentals.

My mentor, um, had like a very strong computer science background. He went to Oxford, did computer science and he wanted to teach me the fundamentals. Um, and so we were like doing all those things and like sorting algorithms and doing a little bit of theory, I guess, as well. And, uh, and then yeah, working towards, um, some more complex apps.

And I did, I made like a contact management system , which was no, no UI, no user interface, just, um, just Ruby and kind of feeling the pain points of how you can write bad code.

Zeke: Mm,

Priya: Being allowed to write bad codes. So then when you need to make changes, understanding the pain of why you don't want to be writing code like that basically.

And yeah. Through experience, just like writing as much as possible and learning how to be better, I guess, was the apprenticeship aim.

Zeke: but it sounds like, uh, almost all of your training then is very hands on, right? Like

Priya: Yeah.

Zeke: you're you were going to workshops with the, the Rails Girls and then, you know, then as it evolved into Codebar, you're still going to workshops and you're, you know, as a side project. And then when you do your student apprenticeship you're then like working on projects with a mentor.

Priya: Yeah. Definitely very hands on. And I think, I think that was really good in just getting comfortable, like getting more confident in writing code. Like it's okay. You can always change it. And like, you know, you get reviews working in a team, getting feedback, taking that feedback. Well, um, a lot of that was, uh, focus, like just being humble and you know, if you, if you wanna.

Talk about why you had a certain approach. Don't take it personally. If you have to rewrite the whole app from scratch, that's fine. Like, you know, don't get too tied to your code basically, which is hard but it's also important because yeah. Ultimately it's just, yeah, you can redo it. It's not, it's not that big a deal.

Um, yeah,

Zeke: is like a crucial skill in being successful as a developer. I I'll just, you know, what, what platform are you mostly targeting these days? Is it still Ruby on Rails? Mishmash.

Priya: Oh no. So I actually, I didn't really ever do much Ruby on rails. After that workshop jumping with me, it was more just doing basic Ruby. And then, um, the apprenticeship takes you through, well, it used to take you through different types of languages. So you do a dynamic language. So I did Ruby for that.

Static, so you do some Java. And then a functional. So I kind of, what did I do? Clojure a little bit of Clojure. So then you understand the paradigm. Um, and then on different clients kind of get placed and learn what you need to learn. So, right recently I've been doing a lot of React, um, kind of liking frontend coding a little bit more, um, but pretty much fullstack.

So Go and, uh, basic like little bit of Go, not too much. Um, did some Python like lots of different languages. Really? Yeah. Yeah. Which me is a good word.

Zeke: I got the polyglot. I'm also, you know, polyglot, you just use the language that makes sense for the

Priya: yeah.

Zeke: to solve. Right. Um, but I was more than wondering, do you continue to learn the same way, which is just kind of project based learning or do you, what, how do you learn best?

Priya: Um, I think project based learning is good. Um, if like first introduction to a new language, there's usually, a problem that language is good at solving. So like looking at a pro like a simplified version of that problem. So like React. I remember when I had to figure out how to, uh, build a basic app, just looking at a to-do list, cuz that seemed like quite a use, like a good use case of that with all the components of state changes and yeah, so kind of asking people who already know more than I do about it and taking their advice on what's a good small project to understand, you know, the basics of that language basically.

So yeah. And then reading as, and when reading in depth of a specific problem or area of that as a project goes on, um, yeah, that's kind of the general approach I'd say at the moment. And then yeah. Side projects are always fun. Uh, it feels less constraints and yeah. Usually approach.

Zeke: Yeah. Um, I, I also, I mean, I, I think people who are self taught mostly do a lot of on, you know, in, in processor, in the flow kind of learning. Um, but I tend to do a lot of reading in advance, just trying to cover as much of things as possible. But for example, I never watch YouTube videos. You know, some people are really big into watching YouTube videos and, and partially that might be just, I grew up reading books as the way that I got information, so.

Priya: I do do like YouTube videos. I do watch some, if I wanna learn a new thing as well. Yeah. And I find some people are very good. That's a, like, that's an impressive skill to be able to talk through a video in a, in like half an hour, an hour, even of like one concept of a language. It's very impressive.

Zeke: Um, does, what, what role do you're a, you said you were a trustee at Codebar. What role does Codebar currently play in terms of how do you spend your time or is

Priya: Um, so yeah, so as a trustee, you're basically responsible for ensuring that the charity is running legally and well. Um, and yeah, like hiring some, some of the hiring decisions. So I think a lot of the trustees are also directors, so we have like a combination role. But I'm at the moment, uh, kind of, we have weekly meetings for any trust important trustee business, but I'm also trying to reestablish like help the London team start in person workshops again.

And we have a really good team there who are doing a great job at that. So I feel like they've kind of got it down now, but recently I was attending some of the workshops again and kind of helping with my experience. Having attended them a long time ago and regularly kind of knowing the format, just like helping them out with that.

So that's kind of the role at the moment, making sure, um, any documents are submitted that we need to, um, Kim, who does a lot of the day to day running, um, who is now an employee of Codebar as well. She, if she has any questions, helping her answer those and yeah. Um, it's generally the day to day stuff.

Zeke: So, uh, Codebar has some people who are not just volunteers, but they're, they're full employees.

Priya: Yeah. Yeah. Uh, just Kim , uh, it sound like

Zeke: Just Kim

Priya: it's a big organization, but just recent. I like, that's a relatively recent thing, I guess the past year or so. I'm I, my timelines now since coronavirus are all over the place, but, um, it's not, she had like, yeah, she's our first employee. And it was just because it's getting to that size now where we have so much to do that in order to keep it running, we really needed to have somebody focused on it, um, more than we ever have.

So that's why we decided, made the decision as trustees, as like six of us to hire Kim as an employee. And she has a lot of context is really good at it. And yeah, it's been a very good decision for us, I think. Um, yeah,

Zeke: Was was Kim there before you, or were you there before

Priya: I was there before Kim. Yeah. um, yeah, I, I think Kim was already working as a developer when she started attending Codebar though. So came at it from different, um, points. Yeah.

Zeke: Yeah, I saw the Codebar website is in, is in Ruby.

Priya: Yeah. So that's, that's still from that time. I think , um,

Zeke: Yeah. And it's, it's an old version of Ruby.

Priya: exactly. And that's kind of like show, like we always have these ideas of what we wanna do, but because we just are still like, at the point where we have one employee, we're like trying to formalize everything a lot more. And so that's kind of that shows on the website, but we are in talks of how to like update the website and, you know, have a separate jobs board, which we have now, which is good.

And yeah. Um,

Zeke: I, I, I thought it would be kind of cool to just have your students join. Uh, the refactoring, I said, you know, somebody was one of the coaching sessions they were asking like, you know, how do I really learn? You know, what's important. And I was all like, try and upgrade the Codebar website from Ruby four. I think it's on Ruby 4.2 to Ruby six, you'll learn a.

Priya: Yeah, that's true. Uh, it is all open source. So like, I think some people do look at the issues and if they're students who have enough experience, they contribute that way. Um, a few of our students are at an earlier point, so that would be quite a big ask, I think. Um, but

Zeke: Yeah. Yeah.

Priya: yeah, with coaches help, that would be a good, yeah.

Good idea. Uh,

[00:27:50] A great environment is where everyone is humble and willing to learn

Zeke: Um, in, in this whole trajectory, is there somebody in particular who's, you know, made a really big difference for you?

Priya: yeah, I guess like, uh, the people who founded Codebar obviously Despo, and then the people who are helping right now, Kim, Christa, like, uh, Jarin, Kara and, uh, and all of, all of the trustees really, um, really have helped, uh, a lot.

And then in the apprenticeship, I had a mentor, Danny, who is no longer with the same company anymore, but you basically taught me initially, most of like what I known was like molding my learning by telling me, like setting the tasks for the next week and guiding yeah. Mentoring basically. So he definitely made a big impact. And then also at that time, the company I was working for was a very small, I think there were eight of us, um, in London.

So every, and everyone was more senior than I was. So I was just learning from everyone around me at like a sponge, just trying to like ask questions when I could. And they were, they were all very good at what they did. So they were able to explain it well as well, and yeah, teach me a lot. So pretty much everyone in the London office at that time was super helpful.

Um, yeah. Yeah. I think, I think the company itself, one of the most important things is that you're humble. They kind of wanna make sure you're willing to learn and humble. And I think that just makes it such a good learning environment.

Zeke: Do your current teams ha uh, still hire, um, people who are not don't have a CS background.

Priya: um, yeah, I think, I think at the moment there are definitely people coming in who don't have the CS background. Now it's more of a mix. Um, I think initially, because it was such a small company in London anyway, um, the hiring was slower and I think there were more juniors coming in previously and now it's become like one company across the States and London.

So, um, it's kind of more of a global effort for hiring and stuff. So I have less visibility on that, but I think, um, there definitely still people coming in, um, at experience levels.

Zeke: Because one of the things that I've noticed over my career is that it can be challenging to, to, for teams to figure out how to hire people who are kind of from an well, first of all, many companies seem to have a hard time hiring junior developers and they also have a hard time hi, hiring really experienced people

Priya: Yeah,

Zeke: like the two, like they, everybody's pretty good at hiring.

I'm gonna say the bread and butter developers, you know, the people who are, you know, five years in, and so they know most of the, you know, some sort of tech and they can, you know, do the work. But, um, junior developers require a different sort of intuition. Like you, you can't say, oh, you must have all these skills because junior developers don't have them.

[00:31:01] Tech expections are immature compared to other industries

Priya: Exactly. Yeah. I found that's that's quite hard. Like tech has hap like evolved as an industry quite organically. So it doesn't have all this regulation around it. Like I remember coming into it from law where it's very structured, you know exactly what role you're going into and what your experience level is expected to be at that time.

And as a train, it's basically at a trainee level, you, they know you're, you don't know that much, and you're there purely to learn and observe mainly, and then you get hired to go in onto clients and, um, and then there's like a very clear progression and what steps you need to do to get to the next step, basically.

Whereas that's quite, that's a, one of the good things about tech, I guess, where it's like that doesn't exist. And it's why, you know, you learn what you're interested in. There are fewer constraints that way and what you learn, but then that leads to a point where if you're a junior, you don't really know what to do next.

It's like a huge ecosystem and you don't necessarily have the experience or know the people. To talk to, to know what you want to do next. So you're kind of just are figuring it out as you go. I think, I don't know if that's still the same, but I remember thinking at that time, like, it's, I, I think I was lucky that I met people who kind of had that experience that I could kind of observe and learn from, but if you're kind of self taught and looking at what to do next, it's quite difficult, um,

Zeke: Yeah, that's definitely the same.

Um, I mean, if anything, there's just a lot more structure than when I got started. I mean, there really was, uh, um, I mean, both in the structure from the standpoint of, they have specific roles with titles, in some sense of what the levels mean, they, and they're, they're still pretty fuzzy, but they, you know, frontend developer means something different from backend developer.

You know, when I got started. There was software developer. That was

Priya: Wow.

Zeke: there wasn't another, there was no variation

Priya: all right. Yeah.

Zeke: Um,

Priya: it's like, that's, it's probably cuz like business is generally, it's still quite, I think tech is not fully understood from a business it's difficult to understand and I don't think we're generally very good at explaining to a business what exactly is entailed in what, what needs to get done.

Um, dunno how to articulate that better, but yeah, I guess how would a business know the difference between a frontend developer and a backend developer? I think a lot of people in business probably still don't fully really understand that separation. They probably have a general idea, but they don't know exactly what that means or breaks down into in reality.

And like, yeah, whether that separation, how you need the teams to talk to each other, if they do need to, um, and all that type of thing, probably isn't that clear. Right.

[00:33:58] Success starts with engaged communication

Zeke: That springs up an interesting question, which is how do you you're as a, as a consultant, how do you, um, present your value? How do you prove value to your clients and how is that different than proving value to the company that you work? Or you're employed by technically the consultancy, but you have to make the clients happy.

Priya: Yeah. Well, I guess, yeah, so a lot of it is like, we get very good feedback from our clients and they talk to our managers about how happy they are and the managers then tell us, oh, we've been told to keep up the good work. Or it's just like, if we get positive feedback, basically. Yeah. I guess, I don't know if that's what you're asking.

Exactly. Like how

Zeke: I, I don't know. I'm like, I assume that you would have some way of saying, like, this is the kind of value that our clients expect, and this is, so I then know what to focus on in my own personal development, because these are, you know, we talked a little bit earlier about like, oh, the, the technical problems are usually the easier problems and the organizational ones are more challenging.

Um, and that implies to me that really, you know, part of you being successful is then communicating what success means in a way where they're gonna say, yeah, I see that. I agree with that. And I, I appreciate that.

Priya: Definitely. I think having those meetings with the business side, so the product side, and being able to clearly communicate what we're doing, they value that so much and kind of being more engaged and proactive. I think that's what I've noticed is like how surprised a lot of our clients are at how we do that.

Um, which I can, I guess isn't always the case. It's easy to be disengaged. I think if you are, especially if you're remote and asked to be doing something quite small and difficult if there's a lot of dependencies on other teams, for example, to like slow down. But if you are engaged and communicate, I think they really appreciate that and kind of take initiative.

Basically. I think it doesn't sound like a lot , but I've noticed that clients generally are very happy, um, in that, and it can be tiring because it's not, it's like another job almost, right. Like it's not writing just the code, it's like communication part. So you're almost doing two different roles, I'd say.

Um, but that's a lot of the feedback we get for sure is how we communicate that. And then also communicating with other developers about the code, like, you know, discussing it in like nonconfrontational way and just being open to ideas, um, then people, yeah. Just feel, it just makes it a much nicer environment to work in.

We had good feedback that, uh, from the QA team, the last project that I was on just before the sabbatical, they were saying. , I didn't know. It was possible for developers to be this nice.

And felt really, which is like that, this felt really nice. Cause that means, you know, just change their perception of what it means to just work in a nice team and how, yeah, how that can make a difference to somebody's day.

This will coming into work and knowing that it's not gonna be hostile. And, you know, people are trying to explain like, you know, explain the tech, explain what we're doing to a QA. It's fine. Um, yeah, that felt really good. So just that type of feedback we get is really rewarding, I think. And it gets back to our consultancy and our, um, our yeah.

Our managers as well.

So that's the value I think. And I think then that ultimately gets like the, the client that's hiring us is aware of that. Like somehow they get news of that because people are happy, I guess. And that, that gets communicated as well. Good.

Zeke: It's interesting, cuz I mean, in all of these characteristics you're describing here are, are the very social characteristics, meaning, you know, like the value we bring is that, or how do I know that we're doing the right work is actually because people feel like they wanna work with me. Um, I, I actually, you know, personally I've always liked this, you know, like when you do performance reviews type of thing, I think that they, you have lots of criteria and they create all these rubrics and you know, you know, competencies and all the stuff.

But at the end of the day, I'll tell you the, the, the key metric for me is do I want to be on the same team with them? and, and, if I do that's because not only are they, are they good at being, you know, working like in the concrete part, delivering things that I need, but like, they're, they're actually also good at working with me in particular, mean that like, I like the interactions and it's often hard to quantify this. Meaning, like, it just looks like favoritism, but it's not just favoritism.

Priya: No, I think it, uh, like it's that humility, like if you work with people who kind of, you know, don't bring their ego to work too much then it, you can feel it in a team. It's that it's those metrics. I think that Google put out a while ago about like having a safe environment. So like, you feel comfortable making a mistake or like discussing an idea in that your team won't be hostile towards you.

If you do that. And that's important because that's. Like challenging everyone's assumptions all the time. You feel comfortable, challenging assumptions or, uh, ideas out there. And yeah. So I think that's, that's probably ultimately what it might be the, just being a bit more humble at work and, you know, discussing ideas as opposed to thinking your, your one is always right.

You know, I mean, and sometimes if you wanna discuss it and you do think that that's also okay, but like yeah, not getting too upset about it, I guess, or yeah.

Zeke: At Amazon, they have a leadership principle called Are Right a Lot

Priya: Right.

Zeke: And you can easily see how that might be abused. But part of being right a lot is actually being aware that you're also wrong a lot.

Priya: yeah, exactly.

Zeke: Do you know what I mean? Um, there's ano there's another thing which is for the, um, In the principal space.

So in the leadership, uh, higher levels of tech that they talk about respect what comes before.

Priya: Right.

Zeke: So a lot of times people come in and they're like, oh, this code sucks. They're like, "It's totally messy. They didn't know what they were doing."

Assume that the people who were here before you were at least as smart as you and that they have information and pressures that you don't have.

So when you're looking at this code, you're looking at it free from the, the truth that they were living.

Priya: Yeah. And especially, you can even look at your own code like that. Right. So if that's possible, then surely somebody else could be doing the same thing you were doing. It's very likely, you know.

Zeke: in fact, usually if you come back to your own code a few years later, you're like, who wrote

Priya: Yeah, exactly. And you do a git blame and then it's like, oh, that's me.

Zeke: oh, that was, that was me. Why did I write it like this? What was I thinking?

Priya: Exactly. So, I mean, if that, if you, if it's possible to think that of yourself, surely somebody else could also be, you know, writing something under pressure or just having a bad day even, and you know, that's inevitable. I've, I've not seen a code base grow in size and not grow in complexity. And it just be partly, you have to get some context and understand and navigate it a bit initially it's not gonna be, you know, always that intuitive and stuff like this as it gets bigger. So

Zeke: Hmm. Yeah. Um, accretion, accretion, and osification, this is, you know, where it becomes brittle over time because the complexity makes it hard to change.

Priya: it's inevitable. Yeah. Yeah. Yeah,

Zeke: Um, the humble thing also, I, I think. So I agree that being humble in the face of what you don't know is, you know, super valuable and increases your chances of learning and also building trust with others.

[00:42:19] Balance humility with taking healthy credit

Zeke: Um, there's also, there's a, a risk here. I think that sometimes people go too far and they don't take credit for their own successes. Right? Like you can be humble. It's different to say I am humble. Meaning I respect others around me for having their success and their own trajectory. And I am open to that, but that doesn't mean, oh, I'm, I'm not valuable or I'm not worthy.

Priya: Right. Yeah. That's a difficult balance. And I've been told I should be more confident, a lot um, in that regard. So yeah, I understand that that's a double edged sword, right? Like, but I always find like, this is a lot of people say, if you. if you have a strength, like the other side of that is inevitably a weakness.

So you're always gonna have that feedback. If, if you are humble, that is something that almost inevitably will sometimes go along with it. You can learn from it and try not to have it in every circumstance, but, you know, it's, if it's like, yeah.

Zeke: Okay. So I'm gonna give you a chance here to not be humble. I want you to brag. I want you to say here is something that, what, what is something that you're super proud of? An accomplishment that it just, um, you know, runs, sparkles up your spine every time you think of it.

Priya: I guess like being, having stuck at it for this long, which doesn't sound that great, but like being quite determined and taking, taking time when you need it to kind of just keep pushing through, like, there are some really hard moments. In, um, in software development in general, and almost everyone I've spoken to has experienced that hard, like hard week or like a project deadline or something where you're like, I don't know if I wanna do this.

Like you question, whether you wanna be in the industry and stuff like this. And just like having that grit to keep at it. I'm quite proud that I managed to do that. Even during the student apprenticeship, it was great that people were very helpful, but that learning curve is steep and there's always other easier options.

So you're like, oh, I could do something that, you know, something else. I don't have to do this, but I think partly because I really still enjoy it and like coding and still did at that time, I knew I wanted to push through. And also because other people have done it, you know, like, oh, if any, if somebody else could do it, you can do it too.

You know? Like, um,

Zeke: can you share a specific one? Is there one where that you remember back where you were like, maybe even on the precipice of giving. The, was there a

Priya: Yeah, I guess. I remember one point, like I'm talking to somebody else about it and being like, I don't know if I'm, I can do this. I don't know if I'm learning at the right speed. And they, they told me like, as long as you're learning, you know, more today than you knew yesterday, you're fine. And that made me feel so much more relaxed.

So I was like, okay. Um, that, that day I remember in the apprenticeship and then other times yeah. Being put on a new client and not really feeling capable and then just like educating myself, like, like you said, getting a book, I got a book and kind of read through it and felt way more confident just through, just through reading it and just, yeah.

Just taking the initiative to feel more confident and knowing that I was capable of doing it. That was, that was another moment, I guess it was like, yeah. I dunno if that's.

Zeke: you said. Where you realize like, Hey, I'm actually a software developer. It's real. This is what I do.

Priya: Um, a specific moment. That's interesting. I don't know if there was a specific moment where I think, oh, that's, this is what I do. I, and during the apprenticeship you do it. Well, you used to have to, um, like at the end do a mini challenge. Um, and I, when I completed that successfully, it is definitely something I was proud of, like having accomplished it and then thinking, and then looking back, I think it's only when you kind of look back is when you realize, oh, I've got so much further and I don't do that a lot of the time.

So like, yeah, looking back maybe after the first year of working on clients and then thinking, oh, okay, now I know how to do. X Y and Z. So there's different, different checkpoints. The first client, it was kind of like being able to write and feel confident and kind of communicate that code to a client just, and a lot of that was through observing other people how they do it.

Um, but then kind of taking the initiative and doing it yourself and like speaking up more at meetings. I remember being like, oh, I understand exactly what I need to say and how to say it to these people that they understand what I'm doing. Um, and being able to see that they understand it. Like that was a moment, I guess that was maybe six months to a year again, I can't remember the specific time into, into being on clients.

I I, mean six months in, at that time, I mean, just like communicating one small piece of, of at that point, no way like infrastructure, all that stuff.

I did not, I could not talk about to clients. I was like kind of more talking about just specific tasks that I had been set and how they went and, you know, my role within the team.

Um, I feel like on the last couple of projects, I've got to a point where I can start feeling what you were saying, where you're like, oh, I understand these systems at a higher level.

I might not know exactly each of the languages or each of the parts and how to write them from scratch immediately, but I'll be able to figure it out. Like how these, I guess that's architecture. Right? That's what I'm talking about. Like, I can start thinking about how systems are architected a bit better now.

Um, but there's still a lot there's always more to learn though, right?

Zeke: Mm-hmm

Priya: So, yeah. So I guess I'm constantly looking back like that. I don't think I, yeah, I think I probably still have a bit of imposter syndrome where I'm like every so often, like, oh my gosh, I don't know what I'm doing anymore because things change so fast. Right? Like if you, I try to write something and it doesn't work the way you expected it to you kind of question your whole career.

Whereas actually it's just one small update or something like this. And, um, I think that's probably normal. Yeah. But

Zeke: I mean, in, in child development, they talk about the zone of proximal development. This is, uh, a place where you are both being challenged enough that, you know, you have to push, um, um, but not so challenged that, you know, you're feeling frustrated and you wanna give up. Right. So it turns out that people thrive in this, you know, like challenge enough that there's reason to put energy into it, but not so challenging that it, you know, you don't think you're gonna ever succeed.

Priya: Yeah.

Zeke: And, and I think that for me, this aligns closely with the imposter syndrome. So like, I never want to feel like. I couldn't be this person. Like, I don't wanna be the kind of imposter where like, I'm pretending to be king of the world. That's not what I'm talking about, but the next level up where I'm just, you know, kind of a little bit outside of my comfort zone and I'm trying to push on my own boundaries.

That's usually where I get my best results.

Priya: yeah. Yeah. That's a good place to be. It's difficult place to be, to find

Zeke: Hmm. Well, I mean, it's why I'm doing the podcast,

Priya: cool. Okay. Yeah. Yeah.

Zeke: right? I mean, I'll, I'll, you know, listening to my own voice recorded. I'll tell you, not always easy.

Priya: Yeah, I can imagine I would not be good at that. Um,

but

Zeke: Practice takes

Priya: yeah, yeah, exactly. Actually, no, that's one thing I remember when I was studying out in like learning to code was just thinking it's just a case of practice.

[00:50:20] Effort + Practice = Expertise

Priya: I think it was around the time of the Olympics section and I was looking at all these athletes, I was like, wow, they're so good. But they've just put the time and effort into it. And I was like, that's pretty much what you have to do. If you wanna do anything, put the time, effort and energy into it. And even if you don't necessarily get the result you want, you'll get a result. Like you'll see improvement in my level.

Thinking that at that time, I think that drove me a little bit actually. Like it was a lot of lyrics and I remember every, I was like, so inspired by all these athletes. I was like, yes. And yeah, that's kind of also the time

Zeke: the, the creator economy, uh, influencers like to, um, pound this one in. They're just like, you know, come back consistently every day and over time you will get there.

Priya: Yeah. I mean, yeah, definitely.

Zeke: But it's also, the fitness is the same way, right? Like if you want to get stronger and fitter, then it's just like, basically just have to work out every day.

You can't work out once a year.

Priya: Very easy. it's very simple, but not easy.

Zeke: Exactly. Very simple to say, little more challenging to execute on.

Um, earlier you said that you might have some questions for me. Do you wanna kind of

Priya: Yeah. You, yeah. Sure. So you mentioned you are a coach and coach people who are going into tech or like in, in, already in their careers are other people. Yeah.

[00:51:48] Helping people grow needs many different hats

Zeke: yeah, so I just, I mean, like in my career, coaching is part of the role that I play, you know? So over time, coaching people, whether it's people who are just starting interns or whatever, or coaching people who have been, in the business for quite some time, or just coaching people who are getting into, um, different domains.

So coaching is different than mentorship, right? Because you don't have to know what they're doing in order to help them figure out how to do it.

Priya: yeah, right.

Zeke: I did a lot of coaching of Amazon with people who were managers, even though I wasn't being a manager, right. Cause I could help them understand what their role was at Amazon be just by, well, just by coaching.

Priya: yeah. yeah. Okay. Yeah. That makes sense.

Zeke: I, I, I could say here I, I separate coaching from training, from, uh, mentorship, from, you know, uh, counseling. And, you know, I, I've also been a manager and from managing and from leading, these are all different hats to wear. Um, and you know, mentorship, I tend to think of is like, where you, you, two people are on a similar track and they exchange stories, right?

Or is coaching is two people. They're not on the same track, but one of them, you know, can help UN uncover or, uh, can help the other person get to their next level through their, by UN revealing their internal abilities, right.

As opposed to training, which is actually where you're trying to transfer some, usually fairly concrete skills over, right. So you'd say a, a trainer would say, I can train you. You could, you could train me about Ruby, right? I couldn't train you on Ruby, but I actually can coach a Ruby developer about how to become a better software developer.

Priya: It's

Zeke: Right. Because I can talk about a lot of conceptual stuff that applies to any language

Priya: yeah. Got it.

Zeke: um, find out where they are and stuff like this,

um,

Priya: How long have you been doing it for

Zeke: Coaching? 20 years.

Priya: Yeah. Oh, wow.

Zeke: But like I said, it's just, it's just part of the job responsibilities as you kind of,

Priya: yeah. Yeah. I've become up more of a managerial. That makes sense. Do you, have you noticed like, um, common patterns or like common things that people have always asked about? And you're like, I've seen this before many, many times.

Or is it usually quite different from individual to individual? Right?

Zeke: No, I think, you know, most of the time it's the it's fairly similar things. It's even in my own self where I need help, coaching. And it's, it goes back to some of this imposter syndrome, which is how do you, you know, put yourself far enough outside your comfort zone to really challenge yourself. Um, that's one of the things without getting overwhelmed.

I think this is a lot of times where coaches can help figure out that zone.

You know, you know, you're like, you're the one who has to set it. The coach can't tell you where the zone is. You as the person who's being coached has to come to the conclusion on your own, but a coach can say, you know, how did that make you feel?

Or where is it you're going next? Or, or what are the, how do you prioritize or is this, is this an intention or is this an actual goal? You know what I mean? Like, there's ask these kinds of questions that, um, help people figure out for themselves what they're gonna do next, right? Like that's a lot of times what coaching is, um, I don't know.

I think a quintessential example of where a coach is often very helpful is for deciding about, uh, forks in the path, right? So when somebody is like, do I wanna become a manager or do I wanna be an IC? And there's, there's no rules for this. There's no, there's not a, Hey, just answer these four questions and you're done.

You actually need to have a dialogue with yourself and with a few other people to find out whether or not this is the right juncture and whether it's a good fit for you and what, um, what kind of support you'll need for it. Um, what does success look for you? Because it may not be the same, you know.

When I became a manager at Microsoft, um, I knew at the time, for example, that I did not wanna stay a manager. But I also knew that I was, there's like a hidden part of decision making, you know, behind the manager curtain.

So I was, you know, a superstar developer and I was, you know, coding like crazy. And then I would hit these blocks and the blocks would be political, social kind of organizational. I didn't really understand what they were. And, and it was clear to me at some point that there was almost like a secret language, not really secret, but for me secret, because I didn't understand the incentives, motivations, and drives of the managers.

So I became a manager volunteer to be a manager so that I could learn what that meant. Yeah. But, uh, but, and so I had my own personal drive here, but I actually didn't have a good coach.

Priya: Right. Interesting.

Zeke: So it took it really, I really struggled to be a manager in the beginning, even though I knew what I was, what I, what I wanted to get out of it.

Priya: Yeah, yeah.

Zeke: um, yeah, the, the hardest part was faring out how to recognize my own success.

Priya: right.

Zeke: I get this way.

Priya: Yeah.

Zeke: Does that, does that help you and, and

Priya: definitely.

Zeke: and mentorship is, um, very, very different from this. I find, um, cuz mentorship is usually you have to be relatively close in, uh, abilities and also in the trajectories, right?

So you don't look for a mentorship in a completely different discipline. You're kind of, and the other thing is that some mentorships are very close and high touch feedback loops. Usually with people growing together like that they're really growing together. And other mentorships are actually, um, just a modeling kind of thing being,

Priya: So, yeah, that's how I look at it usually is like mentors usually like somebody's their career. That's what you want your career to look like in however many years time.

Uh, but yeah, no, it's super interesting about the manager, I think, and not wanting to stay a manager. I've never thought of it that way before.

There's definitely like, I think in software, in the roles that I've seen, it almost feels like when you reach a certain level that manage being a manager is the next step, but it feels like you're further away from writing code, but I don't has it doesn't have to be that way. But that's what the perception is, I guess like maybe that maybe it does.

I don't know. I don't know enough about it yet, but,

Zeke: Well, you have to look to your own organization to find out what's the truth here, right? Like, um, whether or not they have career paths on the IC track that reflect the kind of, um, I don't know, the kind of career you want to have, right? So there's some things which are just options within your organization.

Um, definitely in the big tech, they're very clear that you can get to the top pretty much the top level of the, the compensation ladder as an IC these days, you know, technical fellow, which is same as, you know, executive vice president kind of thing, senior vice president.

Um, um, but there's a lot of infrastructure that has to go into understanding what those people contribute that makes them equivalent contributor to, um, you know, the senior vice president, right? So when you run an organization of, you know, say a thousand people, you're managing that large of an organization, what does an individual contributor that's of kind of the equivalent impact. And it's as a manager, it's just kind of easier to see what your impact is by the scope of your organization.

It's not, it's not the best measure to be honest, because people can be effective with smaller organizations, but it is a pro good proxy for this is your level of influence, right? This is your level of impact.

Priya: Yeah, definitely. And I think you're right. Like you get insight into the business more than you would if you were in a non managerial position. So even if you don't necessarily want to become a full-time manager, having some exposure to knowing what's involved at that business decision level side of things, Like helps you make decisions as a developer as well, or understand.

Sometimes it can be frustrating where you're like, oh, why don't they understand? Or as actually you don't know what the incentives are, or you don't have visibility of them maybe, and having some experience. And

Zeke: Hmm.

Priya: will probably make your life easier or less stressful or sadness if you know.

Zeke: Well, I mean, at, at some level, the most basic thing to manage is just people, right? And if you're responsible for other people, you, you, you pretty soon realize how much work it is

Priya: Yeah.

Zeke: to manage. I, I mean that dynamic, that company to person relationship, um.

Priya: For sure.

Zeke: Yeah. And you know, to maintain cohesion, to, you know, get alignment, you know, even within a small team can sometimes be quite challenging.

Priya: Yeah. Definitely. It's energy, right? Like you're fitting energy into communication. Like writing code probably takes different type of energy than like talking to people and, yeah.

Zeke: The thing that, that most developers, or really personally, this is why, you know, why code is so satisfying is if you write the, if you write good code, then it actually does what you expect. And it turns out that even when you do the right thing in an organization, people might not do what you expect, meaning that you can say, I, I actually went through the steps.

I followed, you know, the protocol or the best practices. And my team still did something completely different.

Priya: Yep.

[01:02:23] Code based systems are more predictable than human based systems

Zeke: Right. You know, human beings are not as predictable as machines, but it, it. In my experience, it's actually pretty good model to think about organizations, more like complex systems, you know, code systems, um, than to pretend that they're just chaos, right?

Like it's, it's not just chaos, little bit of black box debugging. You have to say, what does this part of the system, how does it really work? Not just as, how does it say it works? You know what I mean? Like you can read the code and like, oh, this is what's supposed to happen, but then you run it in production.

It's like, that's not what happens.

Priya: Exactly. Yeah. I kind of think of stuff like that too. Sometimes. Like, oh my gosh, I'm thinking of everything like code, but it definitely, there's so many analogies for it. I think like, yeah. A company as a, it kind of is a system. Right. So it

Zeke: Oh, it is. It absolutely is.

Priya: makes total sense to think of it that way. Yeah. And there's lots of variables.

Like you were saying, you don't, you can't predict what an individual or like people are gonna do because you have no idea how many variables are affecting, you know, an individual on a day to day. Sometimes somebody's just having a bad day and outside of work, you have no idea what's going on. So yeah, it's very roughly.

[01:03:38] Big companies don't have panaceas to "big" problems

Priya: Um, interesting, like to talk to somebody who's been working for a long time in tech to kind of see what they think of it. I, I actually have more questions. Like what

Zeke: ask your questions.

Priya: do you think have like you've. Working for like big companies, a long time. Have you seen changes in approach to like general problems? So let me be more specific. I've started working at bigger clients and there seems to be like the same patterns emerging across them. And people haven't really figured out yet a good way of tackling those problems and they're the same problems.

So like, um, does this book accelerate? I dunno whether you've come across it, um, it's kind of like in big organizations, what are the patterns and anti patterns and how to tackle them basically. So like, I can't think of right. One right now on the spot off the top of my head, but a lot of it is like, if you know, like writing tests, I guess I haven't, I can't remember this is a specific one, but people know that that's a way to increase, uh, code quality or like more predictable behavior, um, on an application or program that you write.

They have metrics, basically that show that that's the case in this book. So, so it's more for businesses to understand that these are measurable approaches to software that have proven results showing these metrics. Like if you do this, your code will be better because of this. Um, have you seen things or like, I guess in Amazon as well, are there approaches that you've seen that are trying to tackle these problems or kind of, is there like a conversation happening right now in how to yeah.

How to kind of fix these common patterns across large organizations that everyone kind of knows is the case like, oh yeah, we know that that's gonna happen. If you have a bunch of different teams and dependencies will like, you'll slow right down. How do you approach that? What types of things like those are just very specific examples.

They don't have to be that. But yeah.

Zeke: Scaling is hard. And, and it happens in multiple dimensions at multiple times for each team, you know, so you a team of six and it goes to a team of 20, then there's like a scaling problem there. And a team of 20 that goes to a team of hundred, it's a scaling, you know, new kinds of scaling problems, crop up and so on and so forth that you keep on going up and, and similar to the way that like you have a class, you know, that you're writing and then it has three methods and it's fine.

And then it goes up to 12 methods and it's still fine, but then it goes up to 30 methods and you're kind of like, this feels awkward, right. But is it okay to refactor because other people have dependency on it as 30 methods and, and this, this dynamic it's the same for organizations. Um, and the specific needs of the Sy, the, the system around it to actually determine a lot of the other behavior.

I, I think the anti-pattern when you really talk about, deep set anti-patterns that I've seen over and over again is the, the Panacea Answer. Meaning books will always tell you that they have a good answer for this and they don't. They have an answer. And that doesn't mean it applies to you.

And I'll, I'll give you two, one, an one kind of example, or I'll give you two examples.

One is parenting. There are lots of parenting books out there. Does it guarantee that parents are good parents? No. Does it even guarantee a single parent will get their answers for their child? No. Right.

So I have three kids. My kids are all different. I was different for each one of my kids, meaning that I was at a different spot in my life with each one, the dynamic between having one kid and having two kids and having three kids is also different.

Right? So a book is. Or, or any system is necessarily, you know, tremendously simplified, right? So you can't go to a book and say, now I know how to a parent and every book is actually gonna try in most books and who you're gonna try and sell you that they are the solution to parenting, right?

The another example, which is in the tech industry is when, you know, I joined, you know, Forto, of course they they're, they're in the middle of scaling and they have a lot of, they're doing a lot of interviews and they had some struggle trying to have consistently.

And, and I, I identified right away that I can help here. But you know, what they're kind of hoping is that I can just take the Amazon interview and just kind of plop it in.

Priya: Yeah. That.

Zeke: But the Amazon interview is really for Amazon. You can't just take this system that works good for what Amazon cares about, and just move it into another company.

Um, because the things that support it working well at Amazon are completely different than the things that this company really wants to solve. So even though it's a working system with a lot of skills and thinking, and tools and success behind it, um, that doesn't mean it's portable.

Priya: me

Zeke: So, uh, I, I think, you know, scaling the first thing is just to plan for pain at every scale point and to really look towards, um, what's important here, right?

Like why is like this? And don't look outside to determine what's important. Look inside for what's important. Does that make sense?

Priya: Does make sense. I. I, I was asking with a motive of trying to find out, like, if there's a way when you talk to. If you're a developer, maybe not fully at the managerial level, how to make sure that the bus, or maybe it's fine if it's at the managerial level, but how does the decide it's okay, to take a little bit more time for the right approach that will serve them better in the long term than just getting something working immediately and them understanding the difference between those two things.

Does that,

Zeke: Sure, but it's actually the other way around. You as a developer, need to understand what the priorities of the business are, so that you can understand what approach you need in order to, you know, make sure the business is successful. Um, and I, I think that this is the, you know, like the, the tension, you know, like.

Good engineering could be what the business needs and, um, but crappy engineering can also be what the business needs.

Priya: no, that's fair. I I've seen that before. Like start the needs of a startup are different from an established giant organization that has, uh,

Zeke: That's right. I mean, uh, I, you know, like if you're looking at something like S3, and you know, a single change, you know, two line change may take a month or two months to go through the propagation process, right. Because getting it wrong means the internet goes down.

Priya: Yeah.

Zeke: So they have, you know, they need to have at least five nines of reliability. And, and on the other hand, you know, you're, I'm spinning up my own website here to run my blog. And if I screw something up, I mean, nobody's even gonna notice it for a couple of days, right. Or they, they, if they do notice it, like nobody really cares. I mean, I may lose a couple of people who are like, it's not there.

I guess it wasn't a real website, but this is like, so these are, it's very different context.

Priya: Yeah. So it's, I guess again, it comes down to communication, ultimately, I guess like

[01:11:35] Sometimes success is just throwing more talent at the problem

Zeke: You, you did, you did ask a question about tests and I'll tell you that, you know, like Microsoft, when I joined, there was no code testing culture, right. So there was not a culture, like you had runtime testers. I was one, I was a runtime tester to begin with. So you had developers, they developed things. You had testers, testers, you know, manual testers just tested things.

And then they had development testers, which were not actually what we kind of think of today as automation testers, as much as they were, uh, system developer, testers, meaning that they were, um, they were code testers, meaning that they were like testing APIs and testing functionality of the operating system, but not really kind of, they still didn't replace the manual testers at all.

The manual testers were still the manual testers. And so this is, you know, back in the nineties. And I remember there was a, during the dot com boom, a bunch of developers left, a bunch of testers left, and there was headcount constraints. And he started thinking like, what we need to do is have the developers write like code that's can be tested without having a bunch of people to test it.

And this created some, you know, new pressure. It's a different kind of thing. And then, um, and then also as you started moving to shorter release cycles. So if you have a couple of years, that gives you a long time to, you know, have testing, be part of the cycle, but if you get shorter and shorter, then you need to have, you know, um, you know, faster iterations and the tests have to get, so testing became more and more part of the, the process.

Um, the, and, and inside of Microsoft, one of the first places that had a super aggressive testing architecture was actually the Trident team, which was the HTML engine of internet Explorer. And they had something called gauntlet, which you could kind of think is a CI tool, um, where every single developer would run their things.

And it would through automation, um, because tried and was completely automatable, which is actually where D HTML got all of its dynamicism is so that you could really test all of your changes quite quickly. And they would have this big pipeline, all the changes of, you know, a couple hundred developers were going to that pipeline and then being collapsed together and then, um, tested together.

Cuz there are a lot of tests, you know, like over time you became, you know, a lot of

Priya: That's super interesting how it evolved basically. Cause when I said it was already, well, the company that I worked for, already had this idea that you test code before you write it, and then you kind of drive it from like test driven development, basically how you kind of that way or

Zeke: tests. Yeah. Hmm. Yeah. Yeah. And, and

Priya: started.

Zeke: I I'll, I'll also, you know, Amazon, when I started in 2011, the frontend, the retail website had also almost no tests. So when I left Microsoft, you know, in 2011, The, the code was extremely well tested. I mean, all different kinds of tests. But when I went to Amazon, it was suddenly like, I felt like I was in the dark ages again.

And the retail website, which was essentially a monolith written in Perl.

Priya: All

Zeke: And, and had no good tools. So they didn't have continuous integration. They didn't have, uh, test systems. They, I mean, they didn't have a debugger, so everybody wrote their own logging, debugging tools for the frontend. Um, and anyway, and that was when I joined, it was, you know, $40 billion a year of, of traffic that are going through the, the one page.

And I'm like, not even all this stuff, just the one page, the detail page, which is what I started on. And they had no tests. And, um,

Priya: how does this, like, I've seen some legacy and stuff like that. I'm like, wow, this is like still working. It's super impressive. Like how it functions still without,

Zeke: and, and, um, In both of these cases, both Microsoft and Amazon, part of what it is is hiring the kind of caliber of people and really being, you know, willing to kind of, I'm gonna say, throw manpower at keeping things going,

Priya: Definitely.

Zeke: right. So, um, you know, where there was a lot of manual testers at Microsoft in the early days, Amazon was never super big on manual testing, but they, what my, what Amazon was really good at was detecting problems in their business.

So if a bad change went up within, they extremely high fidelity metrics for telling you that we're losing money. So within 15 minutes or something like that, there'd be like, you know, like there's an alert you like, like if there was a problem on the website, they would notice that the revenue was going down.

Right. And then you say then, and then they had a quite advanced system for undeploying things, right? So you could say, pull that stuff back off of production, Reno, redeploy, Reno, fold out changes so that no longer are we losing money. Um, but it, they, they have moved to, uh, Pipelines, which is a CICD internal solution.

Um, that allows for many different stages and lots of different tests and, uh, a lot of, um, quite, quite rich,

Priya: Yeah. Now they have like, it's available why I not use it, but I guess at the time, yeah, it must have been

Zeke: Yeah, exactly. They, they, I mean, Jenkins was like, you know, for weird teams. You know, like, and Jenkins was pretty terrible in 2011, 2012. So it wasn't like, you know, advanced pipelining stuff.

And I remember some team coming to, to me and there's a Pipelines team, that's what it's called. And they were exploring like, how hard would it be to test the retail website? And I, and I remember telling them like, it's just not possible. I said, really, you have to refactor everything to become testable. Like there's just, it's not in a state where, you know, like there's an answer of how to test it.

Priya: I always think you need in those, you need like two teams. You can't like two, one, like somebody maintaining it and other people are like trying to change it at the same time. Like,

Zeke: Well, Just for, for scale, just kind of give you a little perspective. I worked on the Detail Page. The detail page, you know, is the, the spot where you're looking at the product where you see a buy button and you know, all of the details, the reviews, everything else like that. But each box on that page is really provided by a different team.

Priya: yeah. All

Zeke: Right? So if you think about it, like the top box, which is the nav bar is provided by one team, and then there's another one, which is like the, you know, the primary display. And then the, you know, like the, the buy box is a different box. The reviews box, the, you know, the, uh, the, the Sims carousel, each one of those carousel is by a different team, different data provider, different UX provider.

And they all go to go on the same machine. So on a, on any particular page with a set of products, there's a pretty good chance that there's at least 60 teams that have contributed code to that, to that page, right. And are keeping it running.

Priya: Do you,

Zeke: and then, and then the Detail Page, the team, I was only like, so like 10 people.

Priya: Okay. Right. So depended on what

Zeke: Yeah. And technically we weren't even the Detail Page team. We were the detail page latency team. So there was no true team that owned this page. It was, uh, an aggregate by all of is co-owned by all these different teams who have completely different schedules, contemporary different priorities, you know?

Yeah. Very rough stuff.

Priya: think it would've been possible to have one team do it

Zeke: Um, no,

Priya: No.

Zeke: no. Um, and still isn't

Priya: the, the requirements like no team

Zeke: No. And in fact, the whole structure of Amazon is based on this. It's very federated. So to have one team would be to, you know, to pull everybody into the same org in a way that Amazon is allergic to.

Priya: Right. I see. Yeah. I always wondered like, yeah. Microservices and all this stuff,

Zeke: Yeah, well, they, they had microservices. So, um, yeah, the, the Retail Website, you know, like on the Detail Page, I think it was about 200 service calls that are made on every, uh, render

Priya: how much, right? Yeah. It's a lot of.

Zeke: six 60 teams contributing with 200 different services and, and they had, you know, this is before GraphQL, but they had their own, uh, service framework BSF, which would actually do graph style traversal. So from your, you kind of put all the services in a graph so that you don't call the same service twice from two different places in the UX.

So of course the catalog, which is the, the main data store for ASINs, you'd say, oh, I wanna get the title, or I wanna get the price, or I wanna get the X of this product. Right. And lots of PA places on the page want to ask for the same piece of information that goes into the graph so that you only call once for that piece of data.

And everybody has a dependency on it gets the same chunk, right? So it wasn't, we're talking about that kind of, it wasn't stupid. I mean, it wasn't like they'd built a system that had no intelligence. They quite, uh, spent a lot of time and energy and very smart people had been working on it. Um, but at each level of the, the growth, like the systems that had worked great before were not necessarily gonna work great again.

Priya: Yeah. Makes sense.

Zeke: Yeah.

Priya: Interesting stuff. Yeah, no, I, I mean, cuz I said, I came into the industry like 2010 ish, 20 and 12, I guess. It's interesting to hear having worked on legacy systems. Like at that time the, these were the constraints. So like this is what was going on.

Zeke: But what my kind of the interesting part is that it happens again and again. So you're asking, oh, has this happened before? And I'm like, not only has it happened before, but it's gonna happen again and again. Um, and the tools at your disposal are it's, you know, like they, they change, but they're fundamentally not that different, right?

Like,

Priya: What you just explained. Yeah. It sounds like. they just had a custom version,

Zeke: well, what I mean is of course what they were trying to solve for building this webpage had never been solved before exactly the way they were doing it. And nowadays there's a bunch of, problems that there's a bunch of solutions out there that make some of these things much faster to get to, but you always get to a point where what you're trying to solve is not trivially solved by the things that are available to you.

And so you build things for solving that, and now you're in your own space,

Priya: yeah.

Zeke: right? And as you scale up in your own space, you find out that like, Hey, nobody, there's no good way to solve this. If it was solved, you just used the solution, right. Then you'd be like done. I I'm outta here. I don't need to do this anymore.

Um, but uh, most of the time it's, you know, it's a composition thing. You have lots of different, um, it's like baking a cake or something, right? Like you change one ingredient in the cake. And the rest of the recipe also has to change. You know, if you add more sugar, it might just make it sweeter, but it also make, it might make it so it doesn't cook.

Priya: Yeah. It's that feeling when you think you found the, the solution you need, but it's like just ever so slightly doesn't apply to your use case and then you're like, oh no, I have to do it. So

Zeke: Or you, or you bring in way more than you thought you were gonna bring in. You're like, Hey, it solves my problem. But then it re requires me to commit to, you know, all these other things that I would, they weren't problems I had before now, they're my problem too.

Priya: Yeah. True. True, true.

Zeke: Yeah. Um, but this is why we get paid the big bucks, right.

Priya: Yeah. Yeah.

Zeke: sure. Um,

Priya: Yeah. Oh, I'm gonna have more time to think about all the stuff in the next few months, I guess. So

Zeke: If you, if you have any kind of follow up questions, you wanna have another chat, then go ahead and shoot me an email and, and we can set up some time and, and talk about stuff again.

Priya: that's good.

Zeke: Uh, do you have, um, do you have places where people should reach out to you or find you if they wanna follow up?

Priya: Yeah. I guess, uh, LinkedIn. And then the Codebar email might be a good one to give out like our general Codebar one, if they're interested in attending. Um, and like all the trustees get this email basically. So I'll get it as well individually. Um, it's like London at Codebar.io.

I think you might know that one potentially talking to Kim already, but, um, that's probably a really good one to reach out on and I will check that. And if, if I miss it, one of the other trustees or, um, Kim will see it. So that's probably a really good one to give out and yeah.

Zeke: Okay.

Priya: Yeah.

Zeke: Um, well, great. Thank you so much for, for joining me and having this conversation.

Priya: No worries. Thank you. Thanks, bye.