Episode 31: Combatting tech debt in war rooms

In this episode, I talk to Tomasz Łakomy, a senior frontend engineer at OLX Group. Tomasz is fascinated about teaching everything he knows and has over 170 video tutorials.  

We talk about:

  • how they develop, test, and reviews software at OLX group,  
  • what war rooms are and how they help to combat technical debt,
  • how he managed to create over 170 video tutorials about software engineering,
  • why he is AWS certified as a front-end engineer, and
  • how skydiving helped him to be a better software developer.

Today’s episode is sponsored by CodeSubmit – the best take-home assignments for your tech hiring!

Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.

Transcript: Combatting Tech Debt In War Rooms

[If you want, you can help make the transcript better, and improve the podcast’s accessibility via Github. I’m happy to lend a hand to help you get started with pull requests, and open source work.]

Michaela: [00:00:00] Hello, and welcome did a software engineering unlocked podcast. I’m your host, dr. McKayla. And today I have the pleasure to talk to Thomasz Łakomy.

But before I start, let me share something fantastic news. The podcast has gotten its first sponsor. I’m so happy about this because it means I can focus even more on producing episodes for you. And it’s not any sponsor. It’s an amazing match. Actually, two founders, Tracy and Dom reached out to me. They are building CodeSubmit, a take home assignment platform to streamline your tech recruiting. They’re already profitable and they are part of the TinySeed Accelerator. The reason for them to build CodeSubmit is because they strongly believe that take home challenges are the most candidate friendly way of assessing developer talent. And they could not find a dedicated tool for them. So they set out to build the best experience for take home assignments for hiring managers and developers. It’s built on Git and they support 64 different languages and frameworks, even though it’s a young startup, and it’s built the Indy Way, they already worked with hundreds of companies. Well, last weekend to show me the whole experience and it’s fantastic. So I really hope you go and check out CodeSubmit. You can find it at https://codesubmit.io. And they also offer a free trial. Well, if you like it, please give them some love and social media for sponsoring this episode.

But now, back to Thomasz. Thomasz is a senior front end engineer at the Alix group, which is a fast-growing platform for trading businesses. Commercial is also an ad hack instructor. He’s certified for AWS and he’s a speaker and blogger. So I’m really happy to have Thomasz here with me, Thomasz, welcome to the show.

Tomasz: [00:01:46] Hello, everyone. I’m very happy to be here.

Michaela: [00:01:48] So, Thomas, maybe as a start, can you tell me a little bit about your role at Alix group on the website? It says it’s a platform for buying and selling cars, finding housing, getting jobs, buying, and selling household goods. But what are your team’s responsibilities? What are your tasks at this company?

Tomasz: [00:02:05] Sure. So, as you’ve mentioned, like basically what we do at Olin’s group is, but we did a huge number of different websites for like buying stuff, selling stuff. So as you mentioned, we have cars, we have real estate, we have goods, we have services. So there’s obviously a lot of things going on. And obviously, you know, my team in particular, like we cannot be responsible for everything. The way we work at all X group is about each team is focused on a certain area of the business and they own it competently. So my team is focused on all the jobs because not only you can bounce stuff, but you can also find a better hopefully job at all X. So what we are building is what we are building solutions. That has people find a, you know, a newer better job in particular, we are working on something that is called a candidate profile, because the idea that we have in mind is about, you know, CVS are kind of outdated because this concept of a CV has been around for, for ages and when we need something better. So not only people can create basically are four fires at all X, but we also are going to use the data in the profile. In order to find people. I bet a job automatically because we send them recommendations based on their profile and also the face on the job ads that were actually, they were going through on the other side. So we are kind of, kind of trying to find a better job for them.

Michaela: [00:03:34] Okay. So can I imagine it as like LinkedIn, but a little bit different or is it very different?

Tomasz: [00:03:41] Is this somewhat different than LinkedIn? I think LinkedIn has this very, very focused on like white collar jobs. So, you know, white collar, basically what I mean by that is that, you know, you work in the office, you probably have a product to probably have a, you know, a title that is in English and you probably spend your time in front of a computer. And this is not the reality of like, I suppose like majority of people, because people have different careers, people have different skill sets and whatnot. So what we are trying to build is to have a product that is somewhat similar to LinkedIn as a new, create a profile. And you can use it to find a better job, but with a much broader focus. So we are wanting to target basically everyone who is looking for a job in Poland. And also help them find a better job because like not everybody is used to, you know, searching for a job, offer online, not everybody’s student negotiating. So one of the experiments that we’ve had a couple of times, I go, there’s also building a platform in which the employer would have to provide a salary because we also would like to in ideal a scenario, avoid this process of, you know, Whenever you have to negotiate a salary, how much do you want? How much are you willing to give me? How much do you want? And so bucket and so forth.

Michaela: [00:05:02] Yeah, for me, it’s always mind blowing that, you know, I, to be honest, I haven’t known about all ex before. Right. And so for this podcast, I researched it a little bit and I went on the website and I see like this large numbers of employees that you have. And then I went to the career side and I see, wow. There, I think if I, on the top of my head, I think there were like 16 open positions in data analysis or data engineering, something like this. Right. Then there were like 80 positions for engineers. Right. And I was like, Wow, because I worked as a data scientist or like a researcher before. Right. And sometimes struggling, like where are the companies that actually hiring, you know, people with these skillsets and then you’re stumbling across a company that you never heard of anything like, well, this is not a small company. It’s a large corporation, right. That you’re actually working for. And so, yeah, maybe what would be interesting for me is like, well, you said my team, right? So my team, and then you’re working with data scientists. What are other engineers that you’re working with? Right. You’re a front-end engineer. So who is on your team? You know, do you have like testers on your team? Do you have like designers on your team and, and then you’re working with data scientists. How does the communication work like this? Can you tell me a little bit about the structure and you know, how, how are teams collaborating at all X.

Tomasz: [00:06:13] Sure. So the way we kind of work at all X or X group is, but each team is a park. So we are defined the divided into something that is called a park and a park is this like self-contained unit of the organization that can ship their staff to the production. So each park has, you know, If you need front-end engineers, you have a front end engineer, you have buckets, engineers you’ll have product managers. There’s usually an engineering manager. If there are no engineers on the team, that’s kind of all, it is also useful. Some teams have a dedicated designer, some teams are working closely with, you know, with the designers, but they’re not necessarily in that team because some teams have like different needs when it comes to things like design. We also have a business analyst in our team. So again, like this is a very kind of self contained unit. What I like about this setup is because I used to work in the companies where we have, we had a front-end department and we had a backend and not only was communication tricky, but also working in an actual AI way was some somewhat difficult because as a front end engineer, if I wanted to get, by the way, I would like to get this one more piece of data from the backend. Then you had to go do the backend team, talk to them, but they apparently have the authority for this, for this space. I have to wait for the next bit and whatnot. Whereas in our current setup, we’ve worked very closely together. So we are not working in a silo, but quite the contrary, we are working very closely together with backend engineers, front end engineers. All of those skill sets that are required to build amazing products. Everything is included in that team. And I are very proud as a front end engineer of our backend engineers, because there are actually submitting a feedback when it comes to design and when it comes to UX solution that we build it. So this is honestly, this is something that I haven’t seen before then. Just the level of commitment to building. Uh, great products and not only, you know, juggling Jason data, as some of buckets engineers are used to doing.

Michaela: [00:08:23] Okay. Yeah. And so how many front end engineers are, for example, in your team, but

Tomasz: [00:08:29] those themes, they don’t have to be very large. So in my thing currently, we have two trumpet engineers. There’s two backend engineers. We have a dedicated contact in the data science team. So he’s not technically in our team, but we are working very closely together. We also have a dedicated designer, a product manager, business analyst, and my engineer manager. So there’s less than 10 people in total. I like this role that each team should be large enough that a one pizza can fit the entire theme. And I think this is not a good metric for how large the teams should be. Yeah, I like that.

Michaela: [00:09:07] But with 10 people and one pizza, I mean, everybody gets a little slice. Really?

Tomasz: [00:09:14] Yeah.

Michaela: [00:09:15] Yeah. And so one of the things that I love is code reviews. And so if you have like two front end engineers, do you do code reviews for each other? Or do you have like the back end engineers also looking at your code? And are you looking at the code off the back end engineers and visa versa? Or is that like very dedicated, like for the roles?

Tomasz: [00:09:35] So there there’s a couple of things here. First stop. We it’s one of us. Tries to grow. So I am trying my best to kind of review infrastructure changes. We are using several of the framework, something bucket the engineers are eager to take a look into what’s happening on front and side, but. The the way it’s usually happens is, but my team is only a smart, small part of a way larger organization. So we have lots of front-end engineers, backend engineers and whatnot. And so, because those teams are self-contained, you may have this impression that we are working completely alone in a silo. We don’t look at what we are doing. Give us a lot. This is not the case. So for instance, engineers from other teams, There are even with my staff, I am doing my best to review their code and whatnot. So I think this is quite useful because first of all, we do require two approvals on each request. So by definition, if there are two of us, I cannot approve my own stuff. I have to get somebody else from another team to also approve my changes, but it also builds this culture of at least having this vague idea of what the other teams are doing. And if should they be uneasy, they can also contribute to the other codebases and visa versa.

Michaela: [00:10:51] Okay. Yeah, that makes sense. And so now I imagine you write you like this one pack, and now this is a large corporation or a large organization. So I’m thinking, well, there’s your pack. And then you’re probably. Maybe 20 other banks or even more. Right. So how do you, how do you select the pegs that would review your code and would it be obviously the same, you know, like have you, do you have like two other bags that you are like, you know, working together or do you randomly allocate people from different packs to look at your code?

Tomasz: [00:11:21] I would say it depends on the, on the scope of the changes, because I am working in a pocket that is, like I said, we are building products for four jobs. So we are helping people find a better job. There are also other parks that are also in this kind of like job ecosystem. So there are other solutions for instance, for recruiters. So if something, if it might change, is. Or actually in this domain of looking for a job. So this is like in this part of the code base, or there’s this context of, you know, the stuff that we are actually currently building if necessary. I am probably going to ask for code review some of the members of that team, but if I’m doing something that is more like platform related, so I’m making kind of like core changes. I don’t know, I’m updating a very major dependency in our code base. I am probably going to reach out to somebody from our platform team, because a lot of things that I especially hate as a front end engineer is Bheki for direction. And my goal is as a developer. And the question about testing in general is I don’t want the big production.

Michaela: [00:12:29] So I actually read through one of your articles that you also have mentioned on LinkedIn is one of the Africans that you are most proud of. That’s most popular, something like this, it’s called a seven years as a software developer, right? The lessons that you have learned there, and you were talking about culture base again, right? And so one of the things that you were saying, and I’m just, I’m now quoting you robot him more or less, right. USA. I’ve personally seen people submitting code reviews when X, right, the person wasn’t in the office, or why was it a business trip? X was a brilliant programmer, but enduring through his code reviews process was a chore. If you leave 15, eight pigs and comments, and there are PR of someone who is a junior programmer, you’re not proving your superiority as a developer, you are proving that you’re not a good human being. Right. And so. How do you handle that? Like how, how do you, how do you handle unkind commons and how do you surface that at, as a company, as a team? You know, how do you deal with that?

Tomasz: [00:13:33] So, at the beginning, I w I would like to add, but if I were to write this part again, I would probably add some more new ones with. But that was the, a bit of a, of a hot steak. And, you know, there were lots of comments on Reddit, uh, regarding that part, because it seems to kind of cause a little bit of attention, which I don’t think it’s necessarily for the book, because the main point is silver. You should be kind to other people when it comes to kind of like dealing with that. I. I think it’s not easy and you are, you are probably the best person in the world to having better cultural views. But nevertheless, I guess my personal idea is that you should always try to reach out to somebody when there are, for instance, like kind of comments in photos, because there are two things that maybe happen. First of all, they may be, are not aware that their comments are on time. Maybe they’re just trying to be direct. Maybe they didn’t have the time to kind of, I don’t know, use the word please in a sentence, which I think it should happen anyways, but it could also be that something is actually happening in their personal lives and there are not, or the feeling, you know, like doing code for this today. So that’s why I’m, that could happen. But nevertheless, I would always reach out to them and say, by the way, those are kind of like review guidelines. We are reviewing the code. We are not agreeing with the person. So, you know, please try to be kind and regarding like bad code, because you know, when you leave like 50 comments on the cultural cultural view and you are very nitpicky publishing that this code is terrible. I like to think that everybody tries to do the job as fast as they possibly can. Nobody is a developer. Nobody is going to go to work in the morning and says, I’m going to write some terrible codes today. Nobody does that. So when you are seeing something in coating you, that you are shocked, that you think is terrible, consider that you are maybe not aware of their constraints, maybe there’s some context that you are not aware of. Maybe there’s something that should be improved. Maybe you should talk to them. Maybe if you see a culture of yours, doesn’t have any tests whatsoever, maybe propose to fire off. And those tests together.

Michaela: [00:15:59] Yeah, I like, and you also had that actually in your, in your blog post, right? You were saying, well, go and change the channel, the communication channel. Right. So instead of leaving all those comments in the culture view, why not reaching out to the person directly and asking, you know, if you can be, as you said, Of help in a different way. Right. And I think that’s really important. So, and maybe I want to come back to one of the things that you said at the beginning is like, well, I will definitely reach out, but do you see yourself reaching out as the person that gets this critique? Or is it like you’re a senior engineer, right. So would you also reach out to the person if you see they are leaving unkind comments from somebody else?

Tomasz: [00:16:36] I wouldn’t be much more quicker to your child if it was, if it was somebody else for the code, because I have a feeling that. As a, as a senior in the organization, that your job is not to only write code, but your job is also make others more productive and also builds an environment in which people are feeling okay to kind of express their ideas, express their concerns and whatnot. So if it doesn’t happen for their cause like this, this thing that I’ve written about in the article, it happened years ago. Uh, and it doesn’t do the, have them in my current company, which is something that I’m very happy to see. But nevertheless, if I were to see a situation in which somebody more senior is kind of attacking a more junior engineer in the cultural view, I would different. You reach out to, to that reviewer saying this is not okay. This is not something that we do, because think about it. Some people are not used to culture. This culture is, are very public. And it doesn’t make people excuse necessarily the good that I am. You know, I’ve just started at this company two weeks ago and now I have a bunch of quests with like 50 comments in it. Maybe I’m a fraud. Maybe I shouldn’t be hired through the first place. Like this is not the kind of environment that you want to build in a software organization.

Michaela: [00:17:56] Yeah, I think you’re talking about a lot of different things here. And one is for example, that the context that you have when you’re doing code reviews, right? So this person you were talking about, the person that’s just starting, so this person probably needs something very different in a code review than a person that’s, you know, at the stable at this company already, or have found their place in this company and the team, for example. And, and so, yeah, you’re, you’re totally right. There are so many different things that influence that. And so when I work with, with engineers on code reviews and they are telling me those, or, you know, sometimes people are afraid even to, to tell that, but somehow it surfaces, right? And they say, well, coffee views is the problem. But I really think it’s not the country is that other problems that the team culture. So if things like this happen in contributors, then it’s not the culture base. It’s the culture is surfacing that. And I think on one hand, this is even. Good because now you can see it, right. You can see things that are happening in a more subtle way in meetings and, you know, in work coordinations or collaborations, you know, who reaches out to whom and how do you give, you know, orders or things like this. So in hierarchical organizations, Well, so I know something else that I wanted to talk with you about and that’s technical deck. And so I noted your organization is doing something a specific year. Can you tell me a little bit, how are you tackling technical dev and you know, how you’re working on it? Do you say well happens and we never look at it and close our eyes? Or what are the strategies that you, that you have here?

Tomasz: [00:19:24] Okay. So first of all, if any of that software organization is saying that they don’t have technical depth, they’re absolutely lying. Everybody has technical that including, including us for record. So from my own perspective, I’m very happy to be in a somewhat Greenfield project. So we don’t have a lot of tech depth. Well, mostly because we are building, you know, completely new features and functionality on top of existing stack. Bob. Nevertheless, we are also integrating with something that was certain, that some of it is definitely technical debt. So there are a couple of things that we have been doing so far. You know, the two are just because we have to continue, we have to continue to develop and we have to continue building, you know, experiences for our users. We have to be able to do some of the fast and when technical debt is high enough, you cannot do it anymore. So we having this concept of a wall. And this is something that we did a bunch of times, and we basically about two types of worms. So first up we have those forums where you get together a group of engineers who are interested in a certain area. So for instance, I don’t know, we have problems with our, this, or we have problems in our front end performance. We’ve been together, a group of engineers who are interested in that, and they will be able to help. So they would be not like full-time visit on new features and experiences about some part of the work versus like 50% will it be spent, you know, focusing on fixing technical debt in order to unlock everybody. But we also had a case in which we are functioned as the heads just stopped. And we had a, basically like a company, maybe not necessarily a company wide, but department wide, a worm. By this, we were not working on anything new for if I remember correctly two weeks and we did manage to combat in massive portion of our tech debt. And my takeaway from all of that is you have the activity plan for six executives for my money. This is not something that happens in the meantime. This is not because I, I work in on some teams and there was this idea about. Each sprint, we’re going to spend 20% of our time on Tecademics. This are the, are the words, what I think works so much better is to have dedicated time and dedicated people who are passionate about, you know, fixing technical depth in my, in my humble opinion, the best way to address, for instance, like performance issues is together. For engineers who are passionate about performance and leave them alone for two weeks, he will be very much surprised with the results.

Michaela: [00:22:08] Yeah. Yeah, definitely. Then it becomes, suddenly becomes a project, right? It’s not like something that you have to fix on the side, which is, you know, in your way and actually distracting you from something. And it’s also an achievement. Like if you give them, this is a project then, and it’s achievement that you can achieve and it not something like, Oh, you haven’t worked on that feature. Well, I did something, you know, but because you’re always like, it like drops that you’re putting, right. So you don’t see them, they are dropping and you know, like the, the fondant on a stone and it’s so hot that you don’t see the drop. Right. So you really have to have a drain that the stone somehow pulls down, which also reminds me on automatic for examples. I had like likes the singer on my show. And he was talking about automatic and they, what they do is they stop feature work for, I forgot the timing, but it’s, it’s impressive. And they just do technical death, right. Just to just do everything that they didn’t do before. And they also get so much done. And it’s the whole company. Everybody does this now, and this is our number one priority. And yet he also said that it’s really helping a lot because you know, you have this focus, you have this dedication and it’s not like a distraction on the side that nobody was ready to take on. So when I looked at your LinkedIn profile, I not only saw, you know, where you’re working at right now, but I also saw a list of things that you’re doing. Outside of work or, you know, partially at work or whatnot. Right. So you are also an egghead instructor. And I think I remember correctly, you said like you have 150 videos or something, is that

Tomasz: [00:23:39] correct? More than 170 at this point?

Michaela: [00:23:41] Wow. 170. So how are you doing that? Like, this is something that fascinates me and I just have to get more time and get better at all of those, you know, recordings. Staffing things like this, but this is definitely something that I aspire to do as well. How do you do this videos? You know, what, what motivates you to do them? How did you become a head instructor? And yeah. Can you tell me a little bit about that?

Tomasz: [00:24:05] So, first of all, I was not aware they’re recording videos before I started in a bit as an insect or I was doing, I was trying to think on my blog, I was doing contract talks. And that is basically how I got noticed, because people have basically noted that I have a way of kind of teaching people what I know and I’m passionate about, you know, teaching basically everything that I know that that was kind of my, one of my personal goals is just sharing as much as, as from what I know with others, when it comes to recording over while I have that 70 videos, I recorded one video, then I did it again. Then I did it again. And I did that again, because this is how you get to, to this kind of level. I was absolutely not planning on the coding. So many videos when I started two years ago, nearly to the day two years ago. I remember at the very beginning I had a F I had this feeling, but what am I going to record? I have nothing to teach. Um, this is not exactly true. I think that if you have non trigger experience as a developer with defense, they have something to teach others. And if you are, if you have this feeling that you have definitely nothing more to teach, well, this is a good time for you to learn something new. And I found with myself that I learned the best by teaching. So the best way to, for me to solidify something that I’ve learned related to the recency is to write a blog post about this.

Michaela: [00:25:38] And so you do it from a, from a work from, yeah. From a book process perspective. Do you write a blog post first and then you make the video or do you make a video first or you just make videos for things that you think that are better covered in a video and you write a blog post for things that you think better are covered in a blog post.

Tomasz: [00:25:59] That’s a good question. What I basically do when I want to share something with others. I mostly tried to think, what would it be useful to me? Because some concepts of amazingly well explained as a blog post, because, because you can search through it and whatnot, some topics are better when it comes to, to a video. So for instance, if I were to, I have a book post on my, on my screen right now, uh, I was watching this amazing talk about coconut cookies, tokens, and API is kind of this in depth, dive into, into those topics. And that was doing some notes and basically turned them into blog posts that I published yesterday. So this is, this is good. This works great as a blog post, because I have video of me doing this content is no better than the conference topic that I’ve just watched. But if I were to try to explain something that is a bit more visual. So how do you do something in AWS console? Then the video works somewhat better than this.

Michaela: [00:26:56] Yeah. Yeah. And so you just said AWS, so I noted your are AWS certified. What do you do there? How did you know, was it a requirement from your job, or why did you set out to do that certification? And I also started, you’re going to the next level from AWS certified and yeah. What motivates you to do that?

Tomasz: [00:27:18] So there are two things here. So first of all, all ex has been. Largely. I mean, all it’s basically on the books, we have migrated everything to AWS. I think like two years ago, my team we are working with , which is based in AWS. So we have API gateways, we have Lambda functions. We are using dynamo DB, a storage SQS. So there’s lots of different diverse services. And I’ve joined today, a company as a front end engineer, and I am still a front-end engineer, but when I joined, I had. No idea about data. I, it was completely agreed in that area. So after a while, my manager and encouraged me to learn more about this, because the idea was, if you want to be able to contribute more, if you want to be able to contribute to the technical discussions that you have to act detector decisions, you should probably know what is going on. And getting certified is a. It’s a good way to accomplish that for two reasons, because there’s this texture system over there. And in order to become a certified, because there are, there’s basically a list of topics that you have to be knowledgeable in, in order to pass the exam. Right? So we have the sector idea of what do I need to learn as opposed to, I’m going to learn everything, because this is not viable with AWS and psycho. You have some sort of a proof that you have at least vaguely. Vague idea of what you are talking about when it comes to us. And like I said, in 10 days from now, I am going to pass my another example. So this is the AWS developer and I sure hope I’m going to pass it because this episode is going to be live.

Michaela: [00:29:03] Yeah, it could be. Yeah. So yeah. And well, one of the, the, the question that comes to my mind, you said, well, when I joined Alex, I was a front end engineer. I’m still a front end engineer, but at that point, I didn’t know, AWS. I guess in their job posting, I don’t know. Maybe you reacted to that or I don’t know how you were hired or how you were, you know, getting, getting the information that there is this description. Maybe they, they said you should know AWS, or it’s preferred that, you know, it’s something like this. And how do you, you know, how do you communicate that? Can you tell me a little bit about your hiring experience? You know, and you know, what questions were you asked? How was that process going? And, yeah, that would be interesting. So

Tomasz: [00:29:48] the fun thing is that I’ve joined two and a half years ago. And I haven’t been in that I’ve joined a somewhat different company because we are, you know, changing and growing quite rapidly. So, I mean, I can talk about the process that we have today because I am also kind of involved in the hiring process because I’m interviewing somebody basically every week. But nevertheless, when it comes back to AWS for us plus Fanta, We absolutely do not expect trans engineers to have AWS experience. I wanted to do. There was something new I wanted to grow. This is why I am interested in investing in that area. Nevertheless, I do a command to keep your eyes open. Like we don’t explicitly expect, expect the best experience, but I’ve never done that because it is useful. But when it comes to hiring process itself, we have a bunch of interviews. And our hiring process. So from my kind of technical perspective, we have two types of interviews. So there was a strictly technical interview in which we are talking about somebodies experiences. We are also kind of diving into some topics when it comes to JavaScript to react and whatnot. And we also have a second interview, which is a system design interview. So the idea is that we give you a problem. And architectural problem. And B basically have this conversation about how would you solve that problem? What kind of technologies would you use? How would you use them? How would you test that? How would you monitor monitor VAT? And then so it’s actually one of my favorites because he had get to learn how other people are thinking about building software and, you know, Charlotte architectures and this just, I learned as much as, as they do on those interviews.

Michaela: [00:31:36] And so now you are at the company. Do you have like a career ladder there? Do you have like some, you know, when I was working at Microsoft, there was like this really set in stone, things that you have to accomplish to get to the next level, you know, what should be your, you know, skills technically, you know, professionally and so on. How does that work at all X.

Tomasz: [00:31:57] So we do have a, we have a career lover that is by I’m Ching at the end into somewhat like a tree. So there’s junior there’s mid-level slash Aguilar engineer there, senior engineer and after a senior engineer. So basically where I am there’s this change is going to branch out. So there’s a manager stuff and there’s an individual contributor path. So in the manual, just powerful can become an engineering manager afterwards. You can become a head or director of engineering after work, probably a CTO or something. I’m not even thinking about this level right now on the individual contributor path. We have fleet engineers and principal engineers, and. Chief engineers if I remember correctly. So basically what we want to do is to avoid this problem that I saw at my very first company where you had senior developers who are promoted to engineer managers, not only not because they had, they had manager skills. But you had to promote the subway. That that was the UNBC option. And some engineers are terrible managers because managers managing people. It’s a completely different job than, you know, being a casino software engineer.

Michaela: [00:33:18] And so where do you want to go? Like you’re now in this, you know, one step before, so when you’re branching out, which direction will you go, where are you going to the management route? Or will you go into the lead engineer?

Tomasz: [00:33:29] I would have to go into the lead engineer out because I’m the kind of person who likes to make, make an impact in the organization, but mostly from like a technical perspective and mostly from the perspective of. How do we that software, how do we think about fountain? How do we think about, you know, quality and whatnot? Because like all the components we have more than once to do as, as all companies we would like to improve and having, you know, people and having more people in those kinds of like leadership, technical leadership roles helps us can kind of drill the picture of where we would actually be in, I dunno, two years in charge of this and whatnot. I am not entirely sure whether I would be the best manager alive. Definitely not a remote manager. Maybe if this wasn’t no, the year of 2020, where everybody’s working remotely, that would be probably a different story. But as of as welfare right now, I am gearing towards the reef engineers

Michaela: [00:34:29] posh. And so one of the things that when I hear you talking, right, it feels like you’re very involved in the decisions that are made about, you know, for example, well, how do we tackle technical debt? Right. Do we do this war rooms? Are people involved in those discussions about, you know, how do we actually. Build our culture internally. How do we, and especially obviously also, uh, engineering, right? What role does caudry we have for us? Is that something that you feel that you can actively change or is it something that others are thinking about and your are adopting it?

Tomasz: [00:35:03] So we have, we have a couple of confining values and two of them are my favorites. So the first one is be open. And the second one is to take ownership. And I imagined the thing that the, because most kind of like senior engineers in our organization, like we have this strong sense of ownership. So we are not building something in a bad way because I don’t know somebody from higher above telling us, do we want to build the best experiences that we, that we possibly can. And if we feel like we should improve in some area, So for instance, well, I don’t know, imagine that we were not doing cultivars at all. And I thought we have a group of engineers who are saying, we want to do code reviews and we get to kind of influence our, you know, technical directors are very open to communication too, to discussion. So it’s not like there are no them all kinds of people. There are very, you know, kind of eager and to not only do discuss, but also to listen to our feedback. And to improve and also grow, grow on each other. We also have this process of kind of like a request for comments documents. So if you, as an engineer, if you feel like somebody, something is not 100%, okay. Like there are some processes that could be improved. You can always, I document ask other for feedback. And maybe like this document has become basically the, the way we do bad things from now on at all life.

Michaela: [00:36:40] Yeah. So one of the things that I know is your area is somehow testing. And I know that you, I mean, I asked that question today on Twitter. You know, what people want me to ask you? And testing was one of the things and they said, well, yeah, you’re doing testing. If your skills are not really good. Yeah, exactly. Yeah. Can you tell me a little bit more about your philosophy here and.

Tomasz: [00:37:05] So my philosophy when it comes to testing is that I want to sleep better at night. I don’t want to worry about my changes back in production. I am not brave enough to push major features to productions that they don’t have pets basically. So when it comes to that, I struggled with believe that something that is not tested, it’s not done. And this tweet that you are referring to is from my colleague of mine. Right. And we have this internal job that’s tests. So down development, because if you build a feature and you guys did the test, it is twice the work. Right. But imagine that you are building a house. You could probably, you know, build it’s pasta, which, you know, having cheaper materials, maybe those were wait, maybe you shouldn’t wait this long for the concrete in order to, to finish like whatever the concrete is doing. If you know what I mean, maybe it is a better idea to have solid foundations on how we build software and then to kind of improve upon them. Because my own impression after working here for two and half year is about. We are building websites and experiences, fall shoots. Number of people, all that’s in Poland is in top 10, most visited websites in this country. My mom is using goal X. I do the gets the break production. Um, some like, you know, obvious mistakes because production incidents will happen always. But I have a feeling that as engineers, we kind of get to choose what kind of productions incidents are not going to happen at all, because we’ve managed to. Test and make sure that I don’t know, it is not possible for our login page to be empty.

Michaela: [00:38:51] Yeah. And I also think, I mean, Slowing down. I think it’s a, it’s a little bit a wrong perception because you’re not only writing code. Right. So there’s this task that you’re writing code, but an actually code lives on. Right. So, and you wanted to have it live on for a long time. And so if you think like this is the first investment that you’re making, and then based on this investment, you’re profiting from it. Right. But by your profit thing, you actually have to maintain. The code. And so if you’re, as you said, if you’re building a better foundation and if you are adding tasks right in, you know, your foundation is actually good in the long run, you will have less iteration on, you know, maintaining that thing to improve it, to fix things that are broken or wrong. And so I think in the end, it amortize it itself over time. Very, very quickly. Yeah. So yeah, I definitely think that’s true. So one of the things that you also mentioned was product driven mindset. What is a product driven mindset and you know, how can we get that?

Tomasz: [00:39:53] Sure. So the way I think about it is my job is not to push tickets in JIRA for ’em to do to them. My job is to build products, assault. The way I think about it is as an engineer, I think that the best part of our ability by people who have this great understanding of what exactly are they building, and this is sometimes referred to as business context. So I don’t know, I am not adding this form to make my manager happy. I am adding this form so that our users can either know their bank accounts number to the account. But when you go one level above and think about what kinds of problems am I trying to solve then actually you are building better products because it’s not about the form. The form is the way we address an actual problem that our users have their actual needs. So as an engineer in my team, okay, why are we adding this form in the first place? Maybe we could do it in some other way. Maybe we could get this data from this other, I know microservice that already has this data. Maybe we’ll go to talk to that people. And this product driven mindset means that you don’t necessarily think about the structure of building in terms of, again, JIRA tickets you think about, okay, this is the problem that we are trying to solve. How can we do that with maybe without even writing any code at all? Because some problems can be solved. By, I dunno, an email. I have a, I have a, this example that I often give, that we had this idea that we wanted to ask our users feedback on a certain feature. This feature was not used by many people, so we want them to kind of have a survey inside of this page, but then we decided that we are going to send an email to them because it took us 10 minutes and we get the, exactly the same kind of feedback that we had. If we were to build a form or survey.

Michaela: [00:41:48] Yeah. And so what came to my mind when you were talking about this, is that I think. I mean, they’re definitely engineers that don’t want, or don’t care so much about the product. And I, again, think it’s not the engineer themselves. I think it’s the culture in the company, right? That at one point you give it up maybe and just say, well, yeah, it doesn’t actually met him. What I think. So we just do what we are asked to because that’s what we are incentivized for that, you know, that’s what our incentive structure is all about. And, and I don’t, I cannot change anything. Right. Even if I think this is not. The right step for the product. But I also think that sometimes there’s like this business driven mindset, right? So there are like those two things that are a little bit competing with each other, right? So there’s this product driven mindset, which I think is maybe easier to adopt as an engineer because we like to create, and we maybe are even taught about, you know, how to think about the users and how, but then what’s a little bit, even further away from an engineer. Is this business driven mindset, right? So. Let’s say a large corporation, right. And they wanted, they have like a tool and it’s for code reviews. And so you have all these great ideas as engineers, how to improve this cult review tool. But there’s this business aspect, which says, well, we are much bigger than contributes, right? We are doing so much more. So right now we don’t have to make the best product for code reviews. And so somehow this idea about, you know, making the best product com becomes a little bit diluted by, you know, the business goals that you have as well, which are not always the product goals. I don’t know if this has makes sense to you if you feel that as well, but this is something that I feel it’s. Very often, very challenging and very de-motivating can also be very demotivating because I think, you know, there’s, it’s easy to fall in love with your product, right? It’s a little bit harder to fall in love with business goal.

Tomasz: [00:43:43] Exactly. I know, I know definitively what you mean, uh, because I, I can give you an example. So we are on running apps on all X. Every large website is running ads. We are no exception and. Engineers are, you know, we, we don’t like that. We don’t like, you know, having other Sonos creeps that are loaded on our beautiful, beautifully crafted pages with Google ads or whatever. And then we get, you know, get informed that by the way, this is paying X percent of your salary guide because, you know, we are not putting those apps for, because we want to, right. We are putting those ads because they help us, you know, our business and, you know, earn more money for the business. And I completely agree with you, but sometimes it is difficult to kind of figure it out. Why we should do a certain thing. And I think it’s always important both in programming product and business, to try to figure out what do we optimize for a given moment, right? So are we optimizing for growth in our user base? Are we optimizing for the best possible product or are we optimizing for the greatest revenue? Because doing all of those at the same time is actually impossible.

Michaela: [00:44:59] Yeah. Yeah, yeah, definitely. Yeah. I find it always quite challenging, especially like all those, even though, you know, it, it’s not pleasant. Right. So even though, you know, okay. To add some now paying part of my salary, it’s still not a pleasant feeling like, Oh, the performance goes down. That’s horrible. Can we block it? Where’s the ad blocker, right? Yeah, exactly. Right. Yeah. Yeah. Very cool. So, well, I think we actually reached the end of our session today of the interview. Is this something that you want to share with my listeners that we haven’t touched on that you think would be important or something that you want to tell them? Some advice that you want to give them on their way?

Tomasz: [00:45:43] Um, okay. So I had this, I had this fault like yesterday, because I’m not sure whether you are listening. You know, you listen, if you’re a student or if you’re younger than me, apologies, I’ve thrown them the 30 this year. And this is a major moment for me. But I was thinking today about when I was studying at the university, I have a master’s degree in electronics and telecommunications. How somewhat this degree is to my career. If you are studying for, in a computer science degree, you were probably going to become a developer and some of those skills are going to be useful. But nevertheless, I w I wanted to kind of express this idea that if you are in college, if you are, if you basically should have chosen our own pager for, for a set and you have ended up. I have this strong feeling that as you know, your university is basically not kind of like a defining point of your life. I am standing to name like most of the names of my professors from the university, not to mention the, kind of the content of the class that they taught. I am a JavaScript developer and I didn’t write a single line of Java script doing my inner negativity. So this was something that I would love to hear.

Michaela: [00:47:03] Yeah. And I also think that there’s always a point to change, right? I mean, if you look at my, if you look at my path, there was a big. A big turning point that people would probably say, well, that’s the big turning point, right? There’s when I finished art school and I went on to do computer science. Right. And I didn’t have an idea about computers. And so maybe that was, it seems like this is a turning point, a huge turning point, but actually it’s not, it wasn’t really like this huge turning point. When I started from computer science to software engineering, right. When I made this switch was again, It was probably the same turning point, right. When I then went to, you know, do for my first job was again, a very different, you know, experience when I worked as a researcher and actually over the years, you know, things really. They get less, less important and still, you know, every time you do something new, it’s again, it feels like, Oh my God, can I do that? Right. It feels like, Oh, this is what I, so when I stopped my research position and people were telling me, you’re completely crazy that you do that, right. Who would give up this position? And it felt crazy. And it felt like, Oh my God, you know, like what now? And now it’s. One year later. Right. And I feel like, well, it completely changed again. And so I think it’s always, when we are in this situation, we feel like, Oh, this is now so important, right. This is such a defining moment for my life. But actually we can always change. I mean, even if you don’t have a computer. Science degree or no university degree, you can actually really change. And it’s, it’s a lot about imposter syndrome. Also, maybe getting over, you know, yourself and you know, your, your feelings or your thoughts in your head that tell you you’re not good at that, or because you don’t know it. Right. You don’t know it. And I started my business. My first intention was I have to do an MBA, right. To be prepared. Let’s do an MBA because somehow, you know, this gives you some security that you know what you’re doing, but I felt like, well, this takes way too long and too much money. Right. I don’t have it. So I have to just figure it out myself. And I think every step that you’re doing, even if you’re not, let’s say you are, you know, in the fast food industry. And now you think I want to become also a JavaScript engineer or developer. It feels really unreal and impossible right now, but really this small steps that I think maybe just brings me back to what you said about your videos. Right. I made one video and another video and another video. Right. And then you look back and it’s like it’s two years later. It’s probably another overnight success, right? You’re not waking up, you know, watching one YouTube video, writing your first website, and then the next day you are, you know, you accomplished your dream, but if you, every day, you know, work on that, I think. Yeah. And don’t let you know whatever happens right now. Define you. I think we are giving too much, much, too much weight to what’s in the now. Right. Which is important on one hand. But. You know it. Yeah. It, it, it becomes less and less important over the years. So I totally agree.

Tomasz: [00:50:08] Yeah. Uh, also, I was still supposed to tell this story because this was requested on Twitter. And I think it plays very nicely to what we just talked about. I went skydiving for the very first time this year, because as I mentioned, I’ve done 30, my wife decided to, to attempt, you know, connect me, therefore she booked out a skydiving session. Luckily I did get the parachute. So that was actually excellent. But the reason why I’m mentioning this is that it was absolutely scary, but the scariest moment was the night before. I was unable to see if I was in the lane, in my bed. I was going through the sky dive over and over in my head, even though I had absolutely no idea wasn’t going to do. I, you know, I watched a video on YouTube. So I have this vague idea of, you know, I’m going to get into an airplane. We’re going to fly up and then they’re not going to jump out of a freaking moving airplane. But when I actually got there to the airport, Then I realized that, you know, some other people are also doing this and there are not dying, therefore I am going to be okay. So I think this is a huge, important life lesson for me is about this curious moment. When you are trying to make a huge impact, a huge change is a guide before you make them. Because as soon as you get to work, as soon as you actually get started, it becomes. So much easier. It doesn’t mean that it is going to be easy, but it is going to be easier. And with each kind of like additional challenge that you overcome, like those things have a good chance of getting easier. But going back to my access videos, I struggled a lot because they, my very first like five or 10 videos, that was a hustle. And honestly it took me, I don’t know, the next three hours to record a two minute video. That was a disaster. I thought I am so much better than this, but it took me, it took me awhile. So you have to, basically, I would recommend that, you know, you should always try to kind of keep him put away and go out of your comfort zone. And every once in a while, if you feel it feels like it, uh, I think, you know, it is a good idea.

Michaela: [00:52:21] Yeah, I think so too. Yeah. That’s, that’s definitely, that’s definitely true. So, well, I think that’s a perfect ending. Thank you so much, Thomas, for being on my show and spending the time with me and telling me so much about, you know, how it is to be a software engineer at your company. And yeah. Thank you so much.

Tomasz: [00:52:40] Thank you very much for having me.

Michaela: [00:52:42] Yeah, it was my pleasure. Okay. Bye-bye

I hope you enjoyed another episode of the software engineering unlocked podcast, but before I let you go, let me tell you that this week black Friday, I have some special, really amazing discounts on my code review workshops. So if you ever think of the idea of booking one. I think now is the time. So hop over to https://awesomecodereviews.com. And I hope to see you in two weeks for another episode of the software engineering unlocked podcast. Bye.



Episode 30: How I got into FAANG companies without a CS degree

In this episode, I talk to Ben Lesh. Ben is a Senior Software engineer at Citadel Securities. Before that, Ben worked amongst other companies, at Google and Netflix. Ben is also the Project Lead for RxJS. RxJS is a library for composing asynchronous and event-based programs by using observable sequences.

We talk about:

  • how he got into several FAANG companies without a CS degree, 
  • the importance of building relationships, and an online brand,
  • the benefits of being helpful and kind to others,
  • the differences in engineering practices at Google, Netflix, and Citadel Securities, and
  • what RX.js is and why you might need it. 

Book your awesomecodereview.com workshop!


Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.

Transcript: How I got into FAANG companies without CS degree.

[If you want, you can help make the transcript better, and improve the podcast’s accessibility via Github. I’m happy to lend a hand to help you get started with pull requests, and open source work.]

Michaela: [00:00:00] 

Hello and Welcome to the Software Engineering unlocked podcast. I’m your host, Dr. Mcayla. And today I have the pleasure to talk to Ben Lesh. But before we start, let me tell you a bit about what happened recently. Maybe you remember when I told you I’m building a code review analytics tool. Well, actually I spend the whole of October working hard on this tool, and I’m happy to announce the MVP is ready. I actually streamed everyday on Twitch about the so-called October Ship It Challenge.
Now, I am uploading my very raw and honest videos on my YouTube channel.
I’m not gonna stream every day anymore – that was quite too much and meant I had no actual evenings with my family, but I plan on streaming approximately once a week to keep you updated on my product building progress.
So, if you want to follow my raw, unedited, and live journey, the best is to follow me on Twitch, or on YouTube. Or both, which is obviously the best. I link both in the description. But now, back to Ben.

Ben is a senior software engineer at Citadel Securities, Citadel Securities, a FinTech company in the market maker. They provide seamless trading experiences and tools for asset management, bankers, brokers, and many more. Before that Ben worked amongst other companies at Google and Netflix, but it’s also the project lead for our RXJS. And RXJs is a library for composing and event-based programs by using observable sequences in general, Ben is active on Twitter and in the tech community and the big Edward kind of reactive programming and observables. Well, I could go on and on, but let me just say to them Ben is on the show. So welcome Ben.

Ben: [00:01:05] Thanks for having me.

Michaela: [00:01:07] Yeah, I’m really glad you’re here. So Ben, you have been working for some pretty large and precision corporation. There’s a lot of folks want to work as well. Do you want to share a little bit with us, how you kickstart your career? So can you walk me through how you started, , and how, hi, you got the first job in, in

Ben: [00:01:26] engineering. Okay. Okay. So, I’ve been doing this now for a long time. It’s been almost 23 years. And, when I started the, the environment was quite a bit different. It was during the first.com boom. and I was, I was actually a print designer, so I had dropped out of art school and I got a job as like a graphic designer doing like brochures and pamphlets and that sort of thing. And I helped out a little bit with a website that they had not very much just a little bit. And I thought, well, this is kind of fun. And I had somebody teach me a little bit about it. and I applied for a job. It was a, it was a part-time job doing updates to a, very ancient e-commerce site. and it was, it was supposed to be four hours a day for one month was the contract. And it had been sitting there for awhile and there weren’t a lot of takers because it’s such a short contract. I think at the time they wanted it, they wanted to pay a lot of money at the time for where I was, which was like $80 an hour or something like that. And I applied and I, of course, was not qualified on paper at all. not even close. And so I called every single day until finally someone asked me what they could, what they could do to get me to stop calling them. And I said, well, if you get me in for an interview and they don’t like me, then I’ll, you know, I’ll never call it’s fine. And. They said fine. So they brought me in for an interview and, you know, they asked me questions and I maybe got half of them. Right. I didn’t get all of the questions. Right. And I said, so, you know, we’re going to ask you, I said, you’re going to ask me, you know, why someone that’s not qualified on paper as is applying for this job. And I told them that, you know, it’s, it’s something that I really enjoy doing and I wanted to learn and do more. And I also told them that. I felt that it was going to be hard for them to find somebody that wanted to only work four hours a day for a month. And that I would work for $10 an hour instead of 80, just because I wanted the experience. And, they, they said that sounded pretty logical. And so they decided to, and I even said that you could, even at that rate, you could even hire somebody else for the same money and like, keep me too. And they kept me for like three months or whatever, and they gave me a nice recommendation. And then after that, there was such a demand at the time. But having some experience under your belt really helps you find another job. So that’s kind of how I got my first, job in tech. And from there I worked through like a lot of consulting jobs and doing different types of, mostly front end back end sort of web development. And at some point years into I was a dotnet developer. I did some, angular development and in order to learn angular because the documents weren’t documentation, wasn’t very good. At the time, I answered a lot of questions on stack overflow, because I felt like I was helping other people. And I also felt like I was learning. I’d find questions. I didn’t know the answer to, and I’d try to figure out the answer. So that way I learned things. And I got into just the right time. And like a lot of my answers tended to be more popular answers in stack overflow on that subject. And some folks that were working at Netflix, started building an angular app, which they ended up not making an angular app at all, but, they saw my name repeatedly and they thought, well, maybe we should, we should, try to get this guy to come in and. I got an email and I thought it was one of my friends spoofing an email, right. Like why would Netflix be trying to recruit me? and so I said, Oh, you know, I’ll talk to him on the phone. And then they said, Oh, we’ll bring you out. And I thought, okay, well, I’ll free trip to California at the very least I’ll go out and do that. And at the time I hadn’t really traveled to California. So I went out and did that. And, then, you know, next thing you know, you’ve got somebody important walking you to like a VP walking to the door and you’re like, okay. So it sounds like there’s going to be a job offer, but there’s no way it’s going to be enough to move my family to the most expensive city in America. And then, and then it was, so, but the, the real point is like the way that I got into like this Fang companies like Google and Netflix and those sorts of things really. a lot of my career has hinged on helping other people. Like if you are doing things to help other people in stack overflow, I did stuff to contribute on, get hub, and I, you know, tried to be as positive as I could. getting a foothold contributing and get hub on like large projects is very hard. you have to be willing to, you’re going to get, you’re going to send something in. It’s going to get rejected. You’re going to have to state your case as clearly and plainly as possible and accept rejection. If it, if your PR doesn’t land or whatever, and then not give up and try again. And, but like people will see and remember positive interactions with you. and then, you know, when you get a chance to network with some of these people, You know, they, they remember that stuff. So a lot of like contributing to open source and answering people’s questions online and trying to be a good citizen, you know, outside of just my office, like in the web community, has done things like it. It’s the reason I work in an RX. Yes. Right now, like I was asked to work on a rewrite of arcs. Yes. It’s not something I just took upon myself. And I even told them that I wasn’t, wasn’t qualified to do it. When they asked me to do that. So, yeah, I would, I mean, people that want to get in at a company like that first and foremost, the easiest way to get into the car Google is to go to school, get a CS degree, and then, you know, study up on your algorithms and go through their whole recruitment channels. but like, I don’t have a CS degree, but I have a lot of experience. and. The route that I took to get in there. It was probably, it’s probably more that I’m lucky. I’m lucky. That’s probably a little bit more difficult, but like is, open source contribution and community interaction and, you know, trying to be a positive person and on the web, And those things can get you a long way, even, even in just to like a smaller community too. Like if in a smaller city or a less tech centric city than, like say the Silicon Valley area or something like that. So I know I rambled there for quite a bit, but,

Michaela: [00:07:31] , I think there are so many good things there because I know for example, the time that, so when I, for example, started working at Microsoft and we moved to the U S . So I wanted to take my husband with me and, Well, he didn’t get a visa in this year. So because they like had the lottery or something. and then, so he tried to find an apply for jobs that would sponsor visas. This means also that you have to get known by these larger corporations, right. Because the smaller ones are not that likely to actually sponsor a research ships and things like that. And it was really hard to just be noticed. So even though, you know, he has a CS degree, for example, or, he knows algorithms and he studied a lot of algorithm because he wanted to make those, you know, yeah. Make those interviews. it was just really, really difficult to get your foot into the door. Right. The people, even that, I mean, you’re a, one of those thousand CVS that they are getting daily and, and, they did just go through, right. So he didn’t even, he wasn’t even, invited to make the first interview round. So there was this, there was this first step that was just so difficult to get in. that there was no, there was not even the chance to prove that, you know, your stuff or something. So I think that what you’re saying, being. Online being not as well, having people remember you and know you, right, showing up in a different way is really something that compliments your chances

Ben: [00:08:57] to,

Michaela: [00:08:57] to be seen, right. And also to kickstart your career. And it doesn’t have to be like four days, but for many other things, also smaller corporations, smaller companies, consulting, gigs, everything I think will be, will be easier. If you are, if you’re a little bit known, right? It’s easier. You’re trusting people more as well. If you’re seeing their work already out, out there, right. You can follow them. You see what they’re talking about? It seems that you know them, even though you don’t. Actually know them,

Ben: [00:09:26] right? Yeah. So I mean, the way I got into both Google and Netflix were through recommendations. Right. and, Google in particular was from a recommendation from a Googler. and you know, I wouldn’t have that if I wasn’t interacting with other people externally, th the truth of the matter is there are millions of people in this world that are smarter than I am, are better developers than I am. Like. I’m sure of it. I’m totally sure of it. the difference is in some cases that, you know, if, if I put my resume next to somebody else’s, and there’s a higher probability that they’ve, if they use ArcGIS or anger or something, like there’s a higher probability, they’ve seen my name before. and that, but that doesn’t mean I’m better than the other person. That’s just, it’s just something that helps you out. But like that goes on a smaller scale. If you, If you’re like again in a smaller community, you’re active in meetups. That was I’ve, I’ve gotten jobs through meetups and like Pittsburgh and Columbus and those areas where, you know, I had a contract come up and I thought, well, you know, and now I’ve got to find. Something else. And like immediately found something else because I had a network of other people. I knew they knew who I was that I had spoken at the meetups and, you know, they, they knew I kinda knew my stuff. So, you get those recommendations and, in my, in my personal opinion, Recommendations to get a job at a company hold more weight than a lot of the other vectors that are involved in hiring somebody. I mean, they all, I mean, you’re not going to get a job just based off a recommendation alone at most at any large company and most even small companies, but, you know, making sure that you’re kind to other people and making sure that you speak up so people know that you’re a smart person. Those are important to get, to getting jobs, getting promotions. I, sometimes I see people are, I’ve worked with people that are brilliant, but very quiet in meetings. and it’s their prerogative. I mean, I want people to be comfortable at work. I’m not saying that they should make themselves uncomfortable, but, you know, it’s being when you’re, when you’re a smart person with things to say, being quiet in the meeting, doesn’t do you any favors because then sometimes the important people that make decisions about who gets promoted or who gets. You know, who they want to move to, what position have no idea how smart you are, because you know, you, you have to wait for someone else to advocate on your behalf, which I’m happy to, to, but, you know, that’s, it’s not the same as them seeing it for themselves. Right. So, the, the point is, is to try to be put yourself out there a little bit. It’s not without risk. You know, like I didn’t really ever want so many Twitter followers for example, but, you know, it attracts some bad attention sometimes, and it attracts scrutiny that you might not always want. And that happens at a smaller scale too. The more you put yourself out there, you know, the more you end up it’s possible, you could interact with someone who’s a jerk. It’s possible that you can, you know, stumble over your own words and get called out for it or whatever. But, The important bit is if you, if you hide in one spot and you’re complacent, then that’s where you’ll stay. If, if you put yourself out there, you increase your chances, a bit. And I mean, put yourself out there socially in particular, like that’s.

Michaela: [00:12:37] I think our humans are really just incredible social creatures. Right? So we, we like to relate to others who like to talk to others, we need to trust. Right. And we feel more, more willing to work with somebody that we know already what we get ourselves into. Right. So having a network and getting a recommendation is definitely extremely powerful. I totally agree. so. Now you’ve worked with a lot of different corporations, right? So you’re Netflix, Google now, Citadel securities. when you look at how the software engineering, practices are, right, the methodologies that companies are following, do you see that there’s a big difference or is it all very similar? Are people working in a very similar capacity at Google as they are doing it? Netflix or the company that you work right now? Or, yeah, where there are large differences.

Ben: [00:13:28] Sure. I mean, there’s, there’s different camps. for all of these things, I have worked at like very small companies too. the, it depends a little bit on what you’re working on and it depends from company to company. So like for example, at Netflix, Netflix only hire senior developers. There’s no junior developers there, which is it’s, it’s both good and bad. But like, so you have to have that in, everybody’s kind of got one specialty and they, you know, you’re, you’re kind of tasked with coming up with a little bit, coming up with your own work. Like there might be some direction that you’re given as far as like, what way you want to go, but you’re left, you know, to work amongst yourselves to figure out how you’re all going to work together to solve problems. and, at Google, for example, it’s, it’s. There’s a lot of junior developers, there’s interns, there’s, people at different levels, and you know, direction on what you need to do. And this probably varies from team to team because it’s a huge company, kind of comes down from the top and direction, how you need to do it, depending on the position you’re in, can come down from the top. But sometimes you’re in a position where you’re a tech lead and that’s your job to kind of do those things. And some teams are more collaborative than others. But like there, I would say Google, they’ve got like internal tooling and everybody does things kind of one way. And it’s this one it’s like, internally I don’t want to monoculture is a bad word, but like they’ve got a monitor repository. They’ve got like, everything is done in exactly the same way. Even if various teams are working on different projects in different ways, there’s style guides, and there’s all sorts of very strict things. Netflix was. Every team had did things, whatever way, made them most productive. so they, they are different. Now. Citadel is, again, more of the environment of every team works in a way that makes them most productive. it’s like as far as testing and things go like it, Netflix, I worked on internal tooling that the idea was to kind of pivot it very quickly. And so. some of the tools or some of the stuff we worked on worked on that needed that were kind of rapidly developed. Didn’t have a lot of tests, but again, they’re internal facing only. And then there were other tools that we worked on and developed, that had a lot of tests, that were, more production focused, pointing towards, you know, customer facing things. So, it all kind of just dependent on what team you’re on and Citadel, again, like, right now I’m working on internal tooling. So the focus is on, you know, rapid development and that sort of thing. So there’s fewer tests than say, there might be for like, like Google would have for Gmail or something like that. Like there’s not like a massive battery of thousands of tests. and of course there’s like RSGS to which arcs. Yes. It’s used by millions of Delilah developers. So we have thousands of tests that we run against that. And as a utility library. So like it’s the testing thing. It just depends like environment to environment, but the actual. Like what the cultural is, is like, I think kind of varies from company to company. I feel like there’s some similarities between say like Facebook and Google, maybe because they’re large, companies at the same sort of structure internally, but, Netflix is much smaller, much, much smaller company. So they’re run quite a bit different.

Michaela: [00:16:41] And also the software and dam developing is quite specific. Right? So you have real time on demand media streaming, right? I think it’s very different. Like if you have like an email program or, I don’t know what exactly now I introduced Citadel securities as a banking software, so like FinTech. but I was wondering what, what does this company actually do and what are some of the. The programs and the software that you develop and what are you doing for the internal things, right?

Ben: [00:17:09] They have, they have everything from, they have like quantitative researchers trying to like analyze markets and come up with algorithms for trading, to more like what I do, which is I work on internal tooling that can, in real time kind of show what’s happening on all of the other services and stuff that the other teams have built and that are running in production. So they have alerts that. Well, you know, the CPU load load gets too high or too low or too low or whatever. Like there’s, there’s different alerts that can set up and run through the system. And it’s actually very similar to stuff. I worked on it at Netflix, but they’re so Citadel, Citadel and Netflix have some parallels in that. Said it all. they’re dealing with, with, trading and securities and these sorts of like stock market focused sort of things. So they’ve got like, laser-focus on a product, like they’re a set of products really, but they have all of this other infrastructure built around it. And Netflix was the same way where. You know, they have there’s Netflix, right? Like it’s, it’s a known product, but there’s like, there’s a breadth of stuff around Netflix. Like you would be walking through a floor and there’d be TVs torn apart there because there’s someone working on, you know, interfacing with some hardware and some like specialized smart TV or, you know, there’s people working on a windows thing or phone stuff for, you know, there’s tons and tons and tons of metrics that they collect. So all of the stuff around that, or maybe it’s about importing assets for, you know, what. Cover art that you’re showing to people in that sort of thing. So, but again, like there’s, so there’s all sorts of different jobs that people have, but they’re all, you know, kind of focused towards one product where, you know, at a Google, like they have, I don’t even know how many, probably like hundreds of products, thousands of products, something, and. it’s kind of just it’s like there there’s there’s how do I put it? There’s large groups of people working on a product probably, but they’re, they’re in a smaller silo than say the size of a Netflix and they’re all kind of going one direction. but yeah, so different company to company.

Michaela: [00:19:13] Yeah, true. So one of the things that strike me, where, when you said, well, you have all seniors at Netflix, right? So, and there comes a different set of challenges. Can you go into that a little bit? What are the challenges? If you have like many senior developers and, you know, you said also, well, global, you have different levels. I still imagine even Netflix, if you have like senior developers, they will be like the senior and then they will be the senior senior, like maybe it’s the principal or the staff engineer or whatnot. Right. So you might have their a levels as well, or was it like really, if you’re senior year equal altogether.

Ben: [00:19:46] So at Netflix, everything was equal. everybody’s sr. to the point where it’s almost an internal joke about how everybody was senior, this senior, that, and. There are people that fall into like tech leadership roles, but like, so on the, on the upside, all of the people that are senior very experienced and you have a high degree of confidence. If you say, if someone says I’m going to get X, Y, Z, done. They’re going to get it done. Like there’s, there’s very little chance. Cause if they couldn’t, they’d be like, I don’t know how to do that because they’re senior developers. They’ll just tell you, and then they’ll tell you who they think can do that or how long it will take them to learn. the downside though, the challenge to a flat or like that is when it gets large enough. Since everybody’s vote is equal, it becomes easy for someone who is. Senior enough that comes in from the outside, that lacks context to downvote or, you know, put the kibosh on an effort that, they don’t fully understand the history around or the context around. and, and that was, that was something that I had seen and heard people complain about. and because it’s like a growing pain for. For Netflix. So, so like when the smaller, they were the easier that, that wasn’t as big of an issue because it’s easy to come to consensus with a small group of people. But as the group of people gets larger and larger, especially if all of them feel as though, you know, I’m experienced, I know what I’m talking about here, inevitably, you know, everyone’s wrong sometimes, but like, it’s, it’s a little bit more painful when, you know, it’s like, It’s you have, you have somebody with an equal voice that can kind of be like, Nope, sorry. Cause you have no, there’s not like one person kind of bring everybody one direction. Everybody can kind of go their own direction or make up, make a case and convince somebody that like the direction you’re going is wrong or whatever. So it’s, it’s a, I think people, when you get a large enough group, there needs to be some sort of structure and leadership. And I don’t know, it’s, it’s been, it’s been years since I’ve been there. So maybe that stuff has, has changed, but that was the only complaint and it was a very minor complaint, but it was the only complaint I had ever heard about the flat structure at Netflix.

Michaela: [00:22:02] Okay. Okay. Yeah. And so is it more like, was it more collaborative or was it more competing like,

Ben: [00:22:08] Oh no, it wasn’t competing. it was definitely collaborative, but. You know, sometimes people just straight up disagree. And when you both have the, when, when people, when, when two people disagree and neither one of them has authority over the other one, then you’re at a, you’re at a stalemate, right? Like then that’s a problem where if two people disagree and one of them is the tech lead, then. You know exactly wins. Like it’s just how it is, whether it’s right or wrong. It’s helpful in keeping things going in a particular direction

Michaela: [00:22:42] in, in one direction. Yeah. Yeah. Yeah. Well, so, one of the things that, that came to my mind. As well is what about peer programming, for example, are you familiar with that? Has that been, practice at Google at Netflix, at the company that you are right now at smaller companies? How do you think about it? How does it fit your style, your programming style, your work style, and, and. Yes, very often. I’m, I’m asked. So I’m, I’m mainly working with engineers to make their quality is better. And I get this question really often, like, should we have like, and I just got that yesterday again. Right? So, when, when client and their whole organization wants to get rid of code reviews in favor of peer programming. Right. I have a lot of things to say about that, but I don’t want to talk about it. I want to know what you think about is, have you experienced pair programming? What’s your take on it and, what’s your take on. Code reviews. And how can we combine that? Or, you know, compliment, or I

Ben: [00:23:42] think that pair programming and code reviews serve different purposes. so pair programming, I have taken part in it. I’ve been, but usually it’s, it’s almost like a mentorship thing when it happens. Right? Like, so I’ve, I’ve been the mentee and I’ve been the mentor. and, so for example, when I joined the angular team, And this is, there’s some interesting side effects of this is like I joined the angular team. I was working on some internal stuff and they’re rendering engine Ivy. And I was coming across things that I was like, man, this is really difficult. And my manager at the time, I think just couldn’t understand why it was so difficult. And part of it, part of the difficulty was. you know, I wasn’t particularly familiar with the internals of the Ivy rendering engine yet, but the other part of it was, there were things that were legitimately difficult and kind of there. And, there was some back and forth on it. And finally we did some pair programming and he, he explained a lot of the stuff that was confusing to me, but then it was revealed that the stuff that I found difficult actually was very difficult. and we, we ended up kind of like after working, working, working on certain things, kind of walking away from the stuff that I was originally tasked with doing and working on other things, but like, it was, it was important for a few reasons. One is, you know, it helped us understand each other a lot better too. It definitely it’s, it’s very high bandwidth to be sitting, talking to someone face to face while you’re. Trying to figure something out. Like it’s much higher bandwidth than sending a Slack and then getting a Slack back and then sending another one with a screenshot I’m getting on back. Like you’re, you’re able to kind of solve problems very, very quickly. you know, and the downside to pair programming is if your personalities are incompatible or, You know, like maybe you’ve got, mental health issues that make you uncomfortable to have to sit next to somebody for a long period of time or anything like that. Then, there’s there can be some discomfort to having somebody sitting right next to you looking over your shoulder the whole time that you’re doing something. you know, so if people do it, I do recommend not doing it like marathon sessions of it, but, as opposed to code reviews, code reviews are different. Code reviews are something that, where you take a fresh set of eyes that have not looked at the code yet. I ideally, in my opinion, they’re familiar with the code hopefully, but they haven’t looked at the code that’s already been written, so they have to go through and have to figure out, okay, so what is this doing? And that provides opportunity to be like, okay, so I don’t understand why this was written this way. Can you maybe add a comment or, you know, why aren’t we doing it this way or whatever. it provides a lot of opportunities to spot things that you just, you know, we’ve all sat at a messy desk before and lost track of how messy it was. Right. Because it just becomes part of the scenery. And so if you’re working in code, you get the same thing where you work in some code and there’s something there that’s kind of crap and you don’t really, really, you don’t really think about it too much, but there it is. and, it’s not really noticed until someone that never looks at that stuff. It looks through and says, Oh, this looks weird here. So, you know, I, I just think they just serve different purposes. Now that said, I think that, code reviews are generally less thorough than paraprogramming because usually code reviews, people just will do it like on get hub or in Bitbucket or whatever, like on the web. And they don’t actually pull the code down and run it. And. Step through it and look at the diff and like try to figure out like, most people won’t go through the effort to do that with a code review. which is unfortunate. They should. But, I dunno, the pair programming is probably got more value, but the fatigue, it puts on both developers involved in that process. I don’t think is worth making it. The only thing that you can do, like everyone pair programs, because we’re not doing code reviews anymore or whatever like that. To me personally, if someone suggested that I’d be like, you’re crazy. That’s the craziest thing. Should we do more pair programming? Yes. Should we do, should we not do code reason now? Like we should still do code reviews.

Michaela: [00:27:46] Yeah. I also think that it’s very complimentary. Right. And, as you said, I mean, the fatigue is real, right. I think in general, I can’t imagine many people that would say they enjoy having another person like that clothes all over day and, and even the energy to do that. Right. Even a very extroverted person. I don’t think this is really what’s happening here. and, and, you know, there’s like the code improvement and, you know, working through. Two problems, but there’s for example, just the bareness weed contribution, you have different purposes that you could have as well. Right? The awareness, for example, that is much easier for pair program. If you’re not doing more programming, there’s one person that knows the staff as well for contributes, you could have like a little bit lighter version of this knowledge sharing, but a little bit more spread as well. but yeah, so yeah, it was really interesting to hear, how you think about this. I would love maybe also to talk a little bit about testing with you. and so you had touched a little bit on, is that testing really depends on, you know, where you are. If you’re doing rapid programming, you’re not testing that much , in depth, but if you’re having like customer facing software, there are much more tests that you, that you’re running. so one of the things that I always want to know, and, maybe you can, we can talk about this for the different companies that you have worked on, but, Did you have like, they’re like, like automated tests. I think as developers, the first thing that come to our mind is like, you need to test automated tests. and then maybe we were thinking about integrating tests and UI tests. And the very last thing is like manual testing. Except for the manual testing that we do while we are developing the software. Right. but so how was that in Netflix? How is that a T two Dell? how is that? Is, at Google, are people still testing the software manually or, is that, you know, old school and not really done anymore?

Ben: [00:29:31] No. I mean, people definitely are. All right. If all you do is automated tests, then. I roughly guarantee you that you’re missing stuff. Like you have to manually test your stuff either by dogfooding it yourself like using the latest version constantly or, but yeah, all that stuff, like actually a Google, there’s a huge dog food program for like everything. So if you’re a Googler, you like every Google property that you’re using, you have like this little dog pop in the corner and like you’re, you’re using. Some latest and greatest version, even if it’s Android or whatever, before the public sees it, because they want to get, all the feedback on it. But like, it’s so important to do manual testing. Like you have to, you absolutely have to, now that the automated testing, the tolerance for like how much automated testing should be in place is going to vary wildly on a lot of different things. Right. if you, if you’ve got something like. A Netflix app that you’re going to deploy to a smart TV that is never going to be updated or rarely going to be updated. Then you better be sure that there’s not any bugs in it, which means you’re going to have to make sure there’s a lot of automated tests and some manual testing, obviously before it goes out. because once it goes out the ship sail, most of these things can be updated now. but like, You know, if, if you just, if you just have apps that are very long lived, they go out any like, deployed like Android app or whatever they go out. And they they’re there for a very long time. you know, maybe people never update their Android app or something, then you need to be very, very sure that it’s really well tested. If you have an app that’s used by tons and tons and tons of users, and it’s your number one source of, of revenue, then? You need to make sure it’s extremely well tested in every possible way because it’s, it’s the important front, you know, that’s funneling money into your company. Now, if you’ve got internal tooling, you know, in my, this is my opinion, but like the more tests you have, the slower development can be depending on the, on the type of tests. They can save you a lot in cases where you need to rewrite things or something like that, because you can, you can rely on your test to make sure that your functionality is still the same after the rewrite, but the, the, you don’t want to slow yourself down too much. I’d say for internal tooling and other things, and this is true for most web apps, but the ability to deploy redeploy or roll back. Your software is like another level because testing is about safety, right? Like you’re, you’re trying to ensure that you don’t break behaviors. You’re trying to ensure good behavior with, testing. And it’s the same thing with TypeScript and, you know, type checks. Those are just, you know, safety checks at build time. And then you have safety checks at testing time, safety checks from Lindt and all sorts of other things. safety checks for manual testing and your ability to detect problems and, read of like deploy a new version or roll back to a previous version is another thing for safety. So it’s kind of like, you know, how well are you hitting on all of those meters, as long as those things meet your tolerance for those things, depending on the app that you’re deploying, that’s probably what’s most important. So some people get really into like unit testing and stuff like that. and that’s, I think most people now know that unit testing, like everything, you can get a hundred percent code coverage and nothing can be tied together. you know, most people know that that’s not great, but like, you know, you have to have some tests regardless of what you’re working on, but your tolerance for how many tests that you need. Are going to very unlike, you know, what you can afford to do part of it, like, you know, are you a big wealthy company? great. You can afford to test everything, or are you a small company that needs to work really fast? Well, then you need to in with you test what’s important and, you know, try not to worry too much about minutia.

Michaela: [00:33:29] Yeah, well, in general it’s, I mean, the risks are always a really an important part, right. That you have to consider, like, we want to be really sure that the payment functionality works very well. Right. And we don’t care so much if maybe, you know, something visual on the website doesn’t look that slick or something like this.

Ben: [00:33:48] Right, right.

Michaela: [00:33:49] yeah. Yeah, very well. So, maybe the last thing that I want to, you know, get some input from you because you’re really the expert here is, maybe a little bit, let’s talk a little bit about . RX JS. And I have to admit that, well, the framework name is already complicated, right? So a lot of consultants and I always feel like this is really hard. Right. You just look at the name of it. And I was like, Oh my God, this is hard. I’m not going to learn this right. If it’s called ponder or something, like, I don’t know, a Bunda framework or something. I’m like, Oh yeah, this is cozy. I can do it. so, and then I actually, announced it by saying something that it, how itself describes itself. Right. So as soon Kronos, you know, sequences with observables or something like this. Right. And so in general, so. How can we understand as entrepreneurs, even based programs? Right. it sounds complicated, but what is it really? And what does it enable us to who should look into that? And I mean, it’s not that new right. It’s been around for a long time, but it’s still, there’s still, people have maybe heard about it, but maybe are like me like saying like our exchange sounds really complicated. but we should actually look into that and, yeah. Well

Ben: [00:35:00] there’s so there’s two concepts it’s inside of our stress. And the most important one is, this type called an observable. it’s a lot like a promise, but a promise gives you one value, pasting asynchronously, and it’s done. and a promise is eager. Like you don’t have to do anything to get that, to make the promise start doing work or anything like that. Something else is doing work and it’s delivering the value through the promise. So that’s, that’s what a promise is. And I think a lot of people are familiar with that concept, but, and observable on the other hand is this type that is, it’s a lot like a function it’s it’s, it doesn’t do anything until you subscribed to it. And then it gives you three callbacks, one for each one for when you get a value. And that’s like the most important one. The second one for if there’s an error, delivering values and telling you that it’s done with an error and the third one for when it’s complete, when it’s, when it’s done giving you values and it’s was successful, there were no problems. and it’s just, it’s just this really primitive type. And it exists all over the place in many different shapes. Like it’s not just our X that has this concept of an observable. but the, I doesn’t matter, I mean, many different shapes. They’re all roughly the same shape, but like the same concept. and the idea is that if you have this, function that gets called with your values, whenever they happen and they can happen anytime, asynchronously, then what you have is, and you also know when it’s done giving you this values. Then, what you have is a set of events. So when you first subscribed to it, that’s when the event set starts, and then it gives you events as it goes along. And then eventually it says I’m complete. And you know that you’re done getting events. So you have events as a collection, as a, as a set or a collection of things. And the thing that’s interesting about it gets us to the second part of RCS, which is different operators and the operators are what I would tell most people not to worry about too much like observable itself. The type is what I most think everybody should understand. But the operators come from the fact that if you have a set of events or if you have a set of things, like say, I would say, give you a set of apples. If I was to give you a basket of apples, You could count them and you could tell me how many apples there were. You could take all of the bad apples out you could, so you could effectively filter them down to the good apples. You could take them and combine it with a set of sugar and flour and whatever else I gave you and make it into a set of Apple pies. Right? So the thing about a set is it can be transformed. It can be, it can be filtered. It can be joined with other sets. and all sets, arrays are this way, baskets of apples or this way, the universe just works like this with sets. And so if you have a set of events, you can do the same thing. So you can take a set of events, say mouse clicks, and you can filter them down to the mouse, clicks that happen on a certain spot, or the mouse clicks that happen when you right. Clicked or whatever. you can take. A set of events from a WebSocket and filter it down to just the ones you care about, or you could count them all or aggregate them over time or what, what, whatever. So that’s what these operators are. The operators are these operations, you can perform on an observable, which is a set of events and it results in a different observable, which is a different set of events. So it’s the same thing with the basket analogy. So if I was give you the basket of apples and you filtered it down to the good apples, now you have a basket of good apples, but you still have a basket that was the operation performed. So it’s, it’s, that’s the fundamental concept with our, yes, you have these observables, which are the most important thing to understand. And then there’s all of these operators that can transform one observable into another one.

Michaela: [00:38:44] so we were talking about mouse clicks, but the first thing that I had in mind when you were talking about observable is data pipelines.

Ben: [00:38:51] So this

Michaela: [00:38:52] comes, you know, right. but so how can we use it? Like, do we use it only in the front end or can we use it in the backend, do we have like data pipelines that we can use? Like these observables, this is how we build, for example, our data pipeline, right. In, at Microsoft also with like, Observable. And event-based things where we have like these, these events that are happening, if you’re getting data right. And you’re getting it real time and things like this, but, Our XJS. Do you use it only on the front end or yeah, on the backend as well, or which languages can be combined it, I read on the website with a lot of languages, but I’m just thinking, because it says GS it’s like JavaScript only.

Ben: [00:39:26] So our XJS is the JavaScript version of reactive extensions. and actually it was born at Microsoft, from, kind of as a clone of Microsoft, our Microsoft’s rx.net. So, And arcs JS can be used anywhere. JavaScript runs. when I originally worked on it at Netflix, it was being used in smart TVs and weird, weird JavaScript run times that, you know, were not V8 based. They’re not Chrome based or anything like that. They were like their own little custom JavaScript runtime. So it can be used in node. It can be used and it is used in node quite a bit. It can be used in, browsers and electronic, like it’s used all over the place and it’s very, very primitive. The observable observable type itself is extremely primitive. you could use it to develop a promise, for example, it’s like lower level than that. So, it can be run anywhere. Okay.

Michaela: [00:40:21] What are some of the, what are some of the use cases where you say it’s not a good option? You shouldn’t use it.

Ben: [00:40:28] Oh, no. There’s there’s. I mean, yes and no. So the thing about observable itself is it can re represent zero events or, you know, many events, that are either totally synchronous or happen asynchronously. So you can use it to represent anything. Now that said, I recommend people ex exercise, restraint and judgment when it comes to doing these things because, our XJS as a library has all of these operators and they have operators named things like switch map, and merge map and concat map and all these things. And I don’t know, I don’t expect just any random person to walk up and know what those things mean. And they’re almost like a domain specific language on top of a JavaScript. So for, for dealing with these things, they’re very, very powerful. you can accomplish a lot, in a very concise way, but you know, with that, you’ve got some abstractions. So there’s going to be a little bit of overhead for that. And we do the best we can on the team to make things as fast as possible and as small as possible. but also there’s a burden on other people around you that have to know these things in order to interact with this, you’ll have to add a lot of comments, that sort of thing. do you need arcs, Jess for loading an Ajax request after you hit a button? No, probably not. That’s silly. You don’t even need a framework for that. That’s just a button in a fetch, right? So, there’s, there’s a lot of places where I would say you probably didn’t need it. Could you use it? Sure. but is it really helping you in certain cases? Probably not. Where it’s most helpful is where you have to do complicated event coordination. Or combining of different data streams, or maybe you have a data stream and you’re filtering it and processing it in some way and coming out, like in the streaming case, if someone’s doing like a lot of streaming data coming into like a node service or, like a it’s, especially if it’s push-based streams or they’re just getting, here’s a new, here’s a new one, here’s a new one. or they’re doing that in the web with like web sockets or whatever, server sends events, you know, if they’re not using RX and. Especially, if they’re combining streams, then I would be like, Oh, here’s this other tool you might want to look into? Because I know firsthand from writing the library and writing other code that wasn’t in our, that, you know, trying to write, event coordination between different streams, yourself, particularly trying to tear them down and stand them back up. And all this other stuff is it’s complicated business, and there’s a lot of places where you can shoot yourself in the foot. So. that use it where it belongs, when possible, but it’s not going to hurt you to use another place. Yeah.

Michaela: [00:42:59] Yeah. So I have a couple of, so the question I actually asked you already were from Twitter, from some of the people that I asked or what they want me to ask you? And there are a couple of others. one question was what, what is your best advice for new developers? I get it very often and I think it’s really interesting to see different answers from very accomplished developers. So what do you think is the best advice for new developers?

Ben: [00:43:22] I would say, you know, people that are new, I think a lot of times when I get people that ask that, like, I’ll have someone message me and be like, Hey, how do I become a great developer? And I think they’re expecting me to pull out, you know, a magic wand and be like, boom, you’re a great developer. But like the truth of the matter is it’s just about consistency and patience. And, the best thing you can do is learn how to teach yourself stuff. I mean, that’s true for anything. Like, if you can learn how to teach yourself things, then you are going to do much better than someone that has to have somebody else teach them something. because you’re always available to yourself. Right? So, so learning how to teach yourself things is super duper important, to being a software engineer and being a human being in general, I think, and, and also being consistent, you know, consistency is something I think people struggle with. that’s why people have a hard time with a lot of different things. Like. Exercise without consistency is just moving around a lot. Like there’s, it’s the same thing with any sort of mental exercise or anything else. Like you have to be consistent. And again, you have to learn about yourself. You have to learn what your limitations are. You have to learn how to teach yourself things, and lightweight where we were talking about earlier with, being like putting yourself out there a little bit, interacting with other people. It helps you learn, right? Like interacting with somebody else. You’re going to learn new things. So, I would make sure to, to try to get out there and network and meet similar minded people. And, you know, it’s risky though, because there’s some jerks out there for sure. but, you know, it’s, it’s worth the risk, in my opinion.

Michaela: [00:45:00] Yeah. Yeah, I think so. I mean, you can already start with, asking questions, right? You don’t have to provide answers. You can network and ask people like I’m now. I recently started my own business and so right now, I mainly, participate in founder meetings by asking questions because I don’t know. Right. How do you do sales? How do you contact people? Right. And you can do the same as a developer, right? Asking questions. And I think asking questions, even if you’re a very senior developer is the right thing to do, because there’s so much we can learn, right. on a daily basis that there are new staff and new concepts and new frameworks and technologies and things like that.

Ben: [00:45:36] Yeah, I was going to say there’s the software engineers in particular very much like to be asked questions because they like to feel smart. So you can’t go wrong in this group of people asking questions.

Michaela: [00:45:52] Yeah. So, maybe the, the last question that I asked you just to wrap up this, this episode is what do you w where do you see the future of our exchange? And I actually combine it with another question, which how does that actually, how does it integrate with the no-code movement? Right. So on one hand, you are the person, you know, that the driver is actually real. Hardcore libraries for developers, right. That are very, very technical. So you have to understand a lot of concepts. And I mean, we are not talking about like, you know, web design per se, but we’re really going into, well, we have to understand a little bit more and really algorithms and things like this, which I think is the opposite of this no-code movement, where you have like lower building blocks that you put together. So, how do you see, how does, does this actually fit together? Because I think there is a relation between those two, but, what do you think about this?

Ben: [00:46:46] Oh, sure. so there’s two questions there. The first was about the future of RCS. feature of RCS is primarily just focused on making the library smaller, more efficient and kind of keeping up with changes and modern platform. So for example, abort controller is now going to become ubiquitous. So maybe we don’t need subscriptions anymore. We can use the abort controller and these sorts of things. so that’s the future of RCS and it’s it’s, it is what it is. It’s a utility library. Now, as far as its relation to the no-code movement. I think that RCS is a solid fit for some of the internals of things that might be, tools that might be used in no-code. and the reason I say this, or not even just RCS, but reactive programming in general, the reason I say this is because reactive programming is based off the principle that, you can kind of piece things together like Legos. So you can say, okay, well, I’ve got a stream of data of this shape. you don’t know where it came from and you don’t care, but the next piece is going to react to when that next bit comes in and do something with it and send it off. And then the next piece down the way, reacts to whatever that thing is that when it comes in, it doesn’t know where it came from and it doesn’t care. So the thing about RX is it’s, it’s very, It’s very composable in a way that, that like building blocks. So you can, you could in theory, make something where you could literally drag and drop shapes together. That declared how you’re going to transform some streaming data. And then under the hood, it would build an array of operators in RX and just kind of apply them. and so reactive programming as it stands. Like I actually don’t even know. How you could go about developing something no-code without some form of reactive programming, not necessarily arcs Jess, but, just some form of, I don’t know where this piece came from. My job is to transform it in this way. cause I’m a blue Lego or whatever, and then I sent it onto the red Lego or whatever I do. so I think that it’s got a strong future in the back of that sort of thing. And I actually liked that idea because one of the. Struggles that people have with RCS is just learning all of these operators. and if I could find a way to just abstract them stuff away from everybody, I absolutely would do that because, they’re the most, they’re the single most powerful piece of, of RCS. not the most important observable, still the most important, but the most powerful pieces, these operators, but they’re also the thing that confuses everybody. Because it is a bit mind bending to deal with this multidimensional problem of time and, and values. And, you know, when things happen here and here and here, and like, you know, even though you’ve broken it down into individual steps with reactive programming, you have to know like what a switch map is and so on and so forth and how it behaves. So I think that, you know, building some sort of no-code thing on top of it is, is a fantastic idea. I don’t really know that anyone’s doing that, but. Or, or even anything like it, there’s plenty of other, reactive programming paradigms or, or libraries and things that people can build no code on top of it’s the same concept. And in my mind, it’s a win whether it’s RX yes or not, like it’s, it’s reactive for a programming is important for this sort of thing. It

Michaela: [00:50:03] could be very powerful. I think like just flexibility that no coder had with, you know, having that under the hood, just

Ben: [00:50:12] that right. Yeah.

Michaela: [00:50:14] Well, thank you so much, Ben, for being on my show, we talked about a lot of things and, I’m really happy that you took the time to be here with me today. Is there something that you want my listeners to know? I will definitely link to your Twitter profile. Is there something else that I should put in the show notes or that you wanted to yeah. To say before we wrapping up this

Ben: [00:50:33] episode? No. No, but I’m, I’m happy to hear that you’re starting your own company. Good luck with that, dude. I don’t know what your, your company is though. What is your, can you tell us about your company really quick,

Michaela: [00:50:42] but my company, yeah, I actually started it already. so I started, a year ago. so I left Microsoft in December, 2019 a little bit before the pandemic. and yeah, I’m, I’m giving quadruple workshops. And I’m consulting with, with organizations that want to improve their processes. And right now I’m actually writing a code reviewing tool. It’s not for code reviews, but it’s for code review analytics. Right? So when I was at Microsoft, I was helping all the different teams. I was also for internal staff, right. So I was responsible. I was in the tool tools, the software engineers. Team. and so we were responsible for the 40,000 engineers and that they are, you know, having a good experience for build test and code reviews. but everything that I did was data driven, right? So we had like all the events that we had from like, I’m doing a committed, I’m chatting here with another person. And so we could use this data to inform actually transformation. So like for example, office would come and say, Oh, we have a problem over there. Can you help us? Right. And so I had all these data to help them, whatever the, the, the question was like, can we. split up the built graph to make the build faster, right. Or can we make the tests more rebel liable because we have some problems here or can we make code review less painful for many reasons. Right. And so, um, so I’m doing the same thing now outside of Microsoft for different corporations, for different organizations, mainly focused on contribution. and yeah, and now I’m building my own tool to get that data. because now I don’t have the data anymore, like at my fingertips. And so yeah, this is what I’m, I’m doing. That

Ben: [00:52:10] sounds really cool.

Michaela: [00:52:11] Yeah. Thank you. Yeah. Okay. So thank you, Ben, for taking the time. Thank you so much for being here and have a good day.

Ben: [00:52:19] All right. Thanks for having me. Yeah.

Michaela: [00:52:21] Thank you.

Ben: [00:53:12] Oh, okay.



Episode 27: How I got a job at Spotify during a pandemic – Emma Bostian

In this episode, I talk to Emma Bostian, who recently started as a software engineer at Spotify. And Emma is the kind of person, that not only applies and interviews for jobs, but at the same time writes a complete book about her interviewing experience hunting for this dream job. This book sold so well, that she could pay back all her medical debt. Before joining Spotify, she worked for LogMeIn, and IBM. She won competitions and moved countries several times.

We talk about:

  • her interview experience with Spotify and Google,
  • her experience moving countries during a global pandemic,
  • what makes for a great onboarding experience and
  • how we can take action to make sure workplaces are friendly and welcoming.
Continue reading

Special Episode 25: From art school to Microsoft Research

In this episode, I talk to myself. Yeah, to celebrate the one year anniversary of the podcast, I tell you about my own journey into tech, and my experiences working at Microsoft and Microsoft Research. I share with you the turning points in my career and also how and why I started my own business.

I talk about:

  • how I got into tech without any previous computer knowledge, 
  • how my dream of becoming a researcher in the industry became true,
  • and why I transitioned to remote work.
  • Finally, I talk about starting my own business because of the need for more flexibility to combine family and work.
Continue reading

Episode 23: Wearing many hats – From Sysadmin to Developer to Solution Architect at Red Hat

In this episode, I talk to Angela Andrews, a solution architect at Red Hat. Angela is a curious learner who has worn many hats over the last +20 years in the tech industry. 

We talk about:

  • her experiences as a sysadmin,
  • how she learned to program,
  • and how she transitioned into becoming a solution architect at Red Hat.
  • She also shares why she has a wall of different certifications,
  • and started a bunch of different learning circles and communities that help people learn to program and reach their goals.
Continue reading

Episode 21: Inside Doist – The Bootstrapped Market Leader

In this episode, I talk to  Amir Salihefendić, CEO and Founder of Doist,  the company behind the widely successful productivity app ToDoist. Amir shares with me his entrepreneurial journey and talks with me about the company and engineering values lived at Doist.

We talk about:

  • bootstrapping from idea to market leader, 
  • how asynchronous communication helps create better products,
  • why he believes in the vitality of recharging,
  • and how to get a job at the remote-first company Doist.
Continue reading

Episode 19: Checking the Disability Box at Apple Changed My Life

This episode is part 2 of my interview with Cher. In this part, we deep-dive into her interview experience at Apple and how she worked her way up to a Staff engineering position.

We talk about:

  • the hiring process at Apple
  • the tasks and responsibilities of a Staff engineer
  • mental health, and bipolar disorder
  • and how the “disability” box can be a life-changer when it comes to getting accommodations for your special needs.
Check-out also part 1 of this interview, in which Cher talks about how she overcame poverty and hardship. 
Continue reading

Episode 18: From Hardship to a Staff Engineer at Apple

In this special episode, I talk to Cher. Cher shares her inspirational story about she overcame hardship and poverty, and worked her way up to now be a staff engineer at Apple. 

Cher has incredible strength in her, and bravely shares her struggles dealing with mental health issues publicly. 

She also regularly reminds people that they belong in tech independent of their education or background. 

I am impressed by how she openly shares her vulnerabilities and encourages and lifts up others. 

Continue reading

Episode 17: Why we hate to read code

In this episode, I talk to Trisha Gee, who is the Lead of the Java Developer Advocacy Team at JetBrain. She is an expert for Java high-performance systems, and developed software for a variety of industries, such as finance or manufacturing.

We talk about:

  • how she got started in tech, 
  • why it’s harder to read than write code,
  • how it is to work at JetBrains,
  • her hiring experiences,
  • and how she overcame imposter syndrome and started to feel confident with her competences.
Continue reading

Episode 13: Bad Tests Are Worse Than Product Issues with Dan Abramov

In this episode, I talk to Dan Abramov. Dan is a developer at Facebook, working on the popular JavaScript framework React. Dan is also one of the most well-known person in the whole front-end developer scene and recently started working on his new side-project JustJavaScript.

We talk about:

  • how he got a job at Facebook,
  • his interview tips for getting into Facebook
  • the development mentality and the development practices at Facebook,
  • and his new project JustJavaScript that helps intermediate developers to become JavaScript experts. 
Continue reading