Episode Archives

Content creation as a career path for developers

In this episode, I talk to Florin Pop. Florin is a web developer that started building websites in 2013 and worked many years as a successful freelancer. I know Florin from his super-popular YouTube channel and his funny and inspiring Twitter stream. In this episode, he explains how content creation became a lucrative career path for him. 

We talk about:

  • how he turned from developing software as a freelancer to a successful content creator
  • his recipe of success through failure and smart goals (e.g. specific and measurable goals)
  • his journey to more than 100K YouTube followers.

Book your awesomecodereview.com workshop!

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

Transcript: 

[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.]

[00:00:00] Michaela: Hello and welcome to the software engineering unlocked podcast. I’m your host, dr. mackalya and today I have to pleasure to talk to Florin Pop.

But before I start, let us talk about this extremly long, and very unexpected break. You must have believed that I might never come back. But thankfully, that’s not the case.

In fact, I actually came back bigger and multiplied… Yeah, from today on, I’m not doing those interviews alone anymore, but I have a little intern for the next couple of months – which is sitting right in my belly. So far, the intern has not been very helpful I have to say – instead, I got horrible morning sickness, which is also called hyperemesis. Well, that’s also the reason why there was this long, unannounced and unexpected break. But I had a good talk with the intern and put it right on a performance improvement plan, and yeah, it seems we are slowly getting better.

So, we both started working on new episodes for you again. During this break, I also decided that it is time to shake things up a little bit. I will start to experiment with the format and content of the podcast.

I have a couple of ideas that I will try out and see how you like them. So, stay tuned for new episodes! But now back to Florin and his insight into content creation.

Florin is a web developer that started building websites in 2013 and worked many years as a successful freelancer. I know Florin from his super popular YouTube channel, and he’s funny and inspiring on the stream. He’s dedicated to grow and learn in public. And what fascinates me the most is this Florin always is humble, honest, and very, very kind. So I can’t be happier to have Florin here with me. Florin, welcome to the show.

[00:00:34]

Florin: Thank you very much. And thank you very much for the kind words that oh [00:00:39]

Michaela: yeah. I’ve been following for, for quite some time and I’m really always impressed , . It feels very authentic. If you do a YouTube channel, if you do your challenges and how you share what you’re learning. And also sometimes you’re vulnerable, right? If people, you know, online can be a rough place, you probably know that. And, and I think it’s really important to also show that, you know, words can harm and can. Yeah, you can feel it. And I like that, that you shared that. Like, if, if you are deep down, you’re sharing it. If you have like success, you’re sharing it. And I always feel like you’re very, very honest with your journey and not everything is like super fine. And, you know, I’m writing three blog posts and now I’m famous and make the most money or something. Right. So yeah, I always say, give and take, [00:01:29]

Florin: right? Yeah, exactly. So this is how life works. You have successes and failures and some days you’re doing great and other days it’s not so great. And I like to share that and to, because. I always, I’m thinking of people who are following me. I want them to learn the most after my experience. This is one of my values to share what I’m learning and alongside my journey. There are also failures and I’m messed up a lot of things. Usually people are kind of afraid to share that because you have to be vulnerable about those. But if you don’t do that, especially as a influencer quote it just sends the wrong message that everything’s perfect, but in reality, not everything is perfect all the time. It’s just a continue grind of doing your best every day. And sometimes you mess up things and that’s okay because that’s how we learn by messing things up and. [00:02:34]

Michaela: Yeah, it’s true. Like, it’s really easy to say for others always. Oh, it’s, it’s totally fine. It, I think they are. They’re also forgiving for artists very much, but not so much for ourselves if you’re messing up. Right. And you’re afraid to, to show that things are not. Not going as well, or, you know, we made this big goal. You make this big goal, right? You said like 100 K you didn’t say many how many days. Right. But you said 100 K so it’s a list, but you know, like, can you fail with that? How would you say it? Would you say, oh, it didn’t work out or, you know, and actually. [00:03:09]

Florin: I like to create big goals for myself. This is probably the first challenge where I didn’t have a deadline for, for it. For example, 365 years days of running everyday, I did 100 projects in 100 days. I did, when I started my YouTube journey, the first challenge was 31 videos in 31 days. Then I did the frequent camp curriculum in a month. So everything kind of was kind of had a deadline because. Those are called smart goals. They have that deadline aspect of it. The reason why I didn’t add the deadline to this new challenge, which I’m currently working on going from zero to 100 K I mean revenue is because I wanted, I, I just feel that there are so many variables. I don’t know. And I didn’t want to put a lot of pressure on myself, although I kind of have a deadline of one year, 1.5 years, roughly, I don’t want to go 10 years with it. And I’m sure that I, so I have kind of a hidden deadline for myself. Oh, I don’t make it public. Although in some of the streams, we talked about it when we kind of decided, okay, how many projects I should work on? What should they do? And what are kind of the deadlines just to see, just to keep track of what’s happening. And I think that’s, for me, that’s highly motivating because this is how I worked in the past couple of years. I just. These kinds of challenges got me out of my comfort zone. Also the public aspect where I share on, in public, what I’m doing is what makes me kind of have to do it because now people watch me and, you know, I, I it’s okay to fail. But like, The challenges, which I’m doing. I try not to make them super, super hard. Like, I don’t know, make 10,000 pushups in a day for 100 days, you know? But rather make 10 pushups every day. For one of the days, it’s more about the consistency aspect than having crazy, crazy, crazy goals. I might do that, but like with shorter, like 10 days or something, Yeah. So it’s going [00:05:31]

Michaela: into the building. I have it building thing, right? So I say tiny habits are actually better for, in the long run. [00:05:37]

Florin: Right? Exactly. So it’s not about doing super, extremely hard things, but then just doing something which is relatively easy to do, it’s just a matter of being consistent with it. And it will over time change. Change an area of your life. Like when it was for running, I lost weight that period, then I felt much energized and yeah, building the projects have learned stuff along the way. So it’s just being the consistency. Yeah. [00:06:08]

Michaela: Yeah. And so, for example, we’re coming back to the running because I also follow that one. I’m following a lot of things, but so you lost weight and then after the challenge, do you keep up with the things, do you still run daily or several times a week? And did you know, did the, the way you go up again or, and you share that as well? Like if it’s setbacks, for example, [00:06:31]

Florin: Yeah. So when it comes to weight, my weight journey II, it’s kind of rough because I did this like several times in my life so far, I would lost the way doing a challenge. Then when I kind of gave up on being public about it, I started to go back to my old habits and I got some of it back. So right now I’m. Doing on tick-tock I’m doing this weight loss challenge again and I’m sharing what exercises I’m doing, what I meeting everyday, just to, again, hold myself accountable. And what I’m trying is to, which is really tough. This is one part of my love with my life, which is tough for me is to not only lose the weight because that’s relatively. it’s just the map. If you have ambition, you can get it done. You just said, okay, for the next three months, I want eat and healthy. I will do these exercises. And it’s that the most challenging part is afterwards, like keeping the weight off and keeping the habits. So that’s where I’m a. Kind of going now is to build a healthy lifestyle, which can continue after I lose the weight. So I want to keep it off for good. And it’s still a challenge for me. It’s been going on for a couple of years now. But yeah. Yeah, I think a little learning and [00:07:55]

Michaela: yeah, I think having a healthy lifestyle is a challenge for, for many, many, many people. Right. Be it sleeping enough, eating healthy, you know, don’t not gaining weight. I think also sport, like sport is something. I have a lot of friends that don’t do any sport and I’m like always, I’m always amazed. I also have two. Struggled quite a bit to make enough place and space in my life to do sport, but I always do some kind. I mean, there are always like weeks you know, where I didn’t do it or sickness, for example, I was very sick at that time. I didn’t do sport for a really long time or what I wouldn’t consider sport that the, you know, the doctor would consider it even sport like walking and things like this. But in general, I try really to make sure. You know, I also needed, it’s also for my health, for example, for mental health. I always feel much better if I, if I do, if I do sport, but yeah, it’s, there are people that don’t do any sport and I’m always amazed. Like how, how are you doing it? Like, I really feel completely. And ease and very unhappy. So yeah, maybe everybody is different. Right. But I think a lot of, yeah, [00:09:06]

Florin: yeah. He’s like, so we are different and some people can just have a great body and all of that without doing any exercises. With eating like junk food and all that. For me, you can quickly see that. So if I don’t take care of myself for a couple of weeks and I start eating junk food and stuff, it just, you can clearly say not only that my mood is going down, I don’t have energy. And part of my reason why I’m doing I’m working out and all that is because of that energy, I need a. What I’m doing now as a content creator, making videos, live streams and all of that, I need energy and I need a clear mind to be able to do that. And for that, I need to take care of my health. I need to go to sleep early. I need to eat healthy exercise and follow the. I mean, I guess everyone knows what are the good habits to do in this area. It’s just sometimes we, we mess up and it’s okay. So if we mess up once it’s okay. It’s not the end of the world. It’s just, the problem is when we do it through Peter Lee for weeks, that’s one, that’s when sort of say that our lives. Yeah. [00:10:24]

Michaela: Yeah. I think can even, you know, mess up for several years and still start today and say, well, today’s a different day. Right. So yeah, exactly. Yeah. I have two little kids and I have to say it’s so much more challenging to do all those nice things with little kids, because like, for example, sleep. I mean, you can, it actually messes you up. If you have like this goal of having a healthy sleep habits and you have like a newborn, I mean, it’s just two competing goals that are not, you know, you can’t, you can’t do them at the same time. And I think it took. It took almost three years that, you know, each of my kids, you know, we’re able to slip through. And so until that time, there is no healthy sleep you know, balance, for example, for yourself and with the sleep thing, you know, a lot of other things deteriorate because you don’t sleep, you don’t eat healthy because you’re like just not, you know, really awake and not clearly thinking and so on. Right. So that’s, I think, and the same for sickness or other things, right. Just struggles in your life. And I think that’s okay. Yeah. Whenever you wake up and you can try again and maybe you fail and you know, don’t give up. I think this is probably the most. [00:11:32]

Florin: Yeah. Yeah. This is something I like about what I’m doing now is that I’m okay with failing for me every day is a new day to do things. If I mess up, for example, last week for a couple of days, I felt unproductive and that and that for me was okay. I accepted that, that it was okay for me to be unproductive because now it’s a new week. It’s a new day and I can pick up things which were not done last week. So it’s okay to always like, give yourself this. Boost of all right. I messed up, but it’s okay. I can start over and I can do it right to this time. [00:12:19]

Michaela: Yeah. And so content creation, this is really the big thing now in your life, right. It’s also where you build your business around and how did that come about and how do you, how does the monitorization work? Can you live from it or, you know, how long did it take you to live from it? I think content creation. A dream of, from many people. And then the question is, you know, is it really working out or is it not working out? Do you think that you can sustainably do that for a long time? [00:12:50]

Florin: Yeah, so I expected as a content creator on my blog writing articles. This was in 2019, I think in February or March, I posted my, I restarted blogging because I had like seven articles. But they at least started logging in. I did it sort of consistently three blog posts, two or three blog posts per week. I had a job back then. And it just said, okay, after my day job, I’ll just write something because it felt like something fun to do. And they always wanted to get down this path of blogging and creating content. So I started blogging and at the same time I picked up a Twitter and I started sharing on Twitter. I started to be active on Twitter, really. I think I spent hours and hours per day on Twitter, interacting with people, with people, replying to them and all that. And it took like six months. Well, the, the plan was actually to leave my job. Next year. So in 2020 January, that was the plan they need for plan. So I’ll just try these for 10 months and see how it works. And then if it’s all good, I’ll just quit my job and do this full time. But then on June in 2019, so six months prior to my actual deadline, I was like, I told my wife, you know what I just, I want to do this now. I mean, we had some money saved up from the job. And I was like, you know, let’s, let’s do it earlier. I mean, if it failed, I failed in six months, I’ll get the new job and it should be okay. We use the savings and it was an interesting journey. I can say that it was tough because my focus wasn’t. Monetization. So just imagine, like in the first month I gave up my job, I made 150 bucks. So yeah, it went down for several K two to 150 bucks. But for me, that was okay because I never. I didn’t chase money in the first year or so of concentration. Right. I liked what I was doing. I wanted to grow my reach to grow my audience, to get in front of multiple people. And I knew that it will pay off one day. And they did that for, so basically I was blogging for six months or so. And then in November, that year I started my YouTube channel. And in 2020, my main goal for the year was to get 100,000 subscribers in a year. And they started working really, really hard on that, I think in six months or so I published over 200 videos and livestreams on my channel. Yeah. I was in the crazy, crazy mode where I was putting out content like crazy. Of course it wasn’t like. Highest quality and all that. But for me it was a great practice. I, I know people say quality over quantity, but for me it was quantity brings quality. So I was pushing out a lot of content and see what works and then doubled down on that and made it better and better. And I got monetized in February 18th or March. No, it was in March. 2030. I was monetized. Quickly compared to other YouTubers. And probably because I also had an audience on Twitter, so that helped. And then the amount of content I was putting off out was was a lot. So that helped as well. But from the YouTube revenue side, it wasn’t a lot, it was like probably $400 a month or so. Yeah. After two months or so, I don’t, I don’t remember now exactly the numbers, but the peak on my YouTube channel. Was it September where, when I did a live stream, another challenge, 10 pro 10 JavaScript projects in 10 hours. I just got the idea that morning and it was like, okay, I’m going to go home prepared. These inches go live for 10 hours to do 10 projects. Wow. And that turned out to be great. That video now has over a million views. Wow. And brought in like three or four K sense. But like when it comes to YouTube, the trick is that YouTube revenue from ads is oh, okay. It really depends from which, what, which part you’re saying now is roughly seven, $800 per month. So it’s okay. It’s probably not lots of people can live off of that, but the, the main source of income from YouTube is that the audience, where if you create a digital product, you can sell that digital product and you can also have sponsors. So those two combined will bring in more revenue. Yeah. That combined with some, I think I had a couple of projects for someone I managed to get past to that period of low-income and now the digital products are making good income. Roughly 3, 4, 5 came depends on the month just from digital products, which is mostly passive. So there, the products are out there. And they’re just selling on their own, I guess that’s your book, for example. Yeah, so I have my ebook and I have a course on you than me, and they’re both both doing this. Like [00:18:27]

Michaela: that’s not counting them for the zero to 100 K. No that’s so exactly. [00:18:35]

Florin: Exactly. So those projects I bead last week last year, and I’m not comping for challenge for, for this challenge, which has started. Two months ago or one and a half months ago. I started from zero. So everything I’m monetizing in, the challenge is built during the live streams. I go live every day from Monday to Friday and I build something and the things I’m monetizing then are the things which come for the challenge. Because right now I also have some sponsors on my YouTube channel. And they can’t add that too. I don’t feel like it will be okay to add that to the challenge because it kind of uses my audience before the challenge. Right. There’s just some extra income which I have. And it’s not for the challenge. The challenge is something else in it. [00:19:26]

Michaela: Yeah. And so today I went on YouTube and to your profile, and then I saw that now you can not only subscribe, but it seems like there’s a membership thing on YouTube. Now, is that something that you offer and you see that it’s working already? Or how does that work? Yeah. [00:19:42]

Florin: Yeah. I offered this for quite, I think over a year now. And it’s. It worked out well at the beginning, when I started to promote that I had, I mean, well, I had several people who subscribed who became members, but it’s. I don’t know if people can rely that maybe if you offer something valuable, it can work out. Well, it’s sort of like a Patrion, but it’s built into YouTube. So if you have something to offer you might get more people to become members. For me, it was just like, Hey, if you want to support, become a member. So that’s not like a high incentive to people. To become a member. Yeah. I still get one. She remembers every now and then, but it’s not something you can at least not for me because probably I haven’t laboratories date to the maximum. [00:20:35]

Michaela: And so what do you do members get? Do they get something else or is it just really that, you know, they, they get the same public videos and it’s just like, they support you and they want to be. [00:20:46]

Florin: Yeah, so you can do like sky’s the limit through that? For me right now is you get the special badge and you get your name collar to the live streams. You get some special emotes who can use. A lot, a lot of value there. That’s why probably I don’t have a lot of members, but you can do that. So you can have specialty videos for those members. You can offer them a one-on-one consulting or coaching, or you can send them a discounts on your products and like the sky’s the limit to. What you can use it for. I’m just yeah. I even forgot. I have that enabled. And now you also have a button, a YouTube. They added it recently where people can thank you. So they click the button and they can donate you. If they liked your video, they can donate a, I’m not sure if anyone used that button so far on. I’m not sure if where I can see that. So, and people also can donate through the livestreams. And I got a couple of those along the year or so I’ve been streaming probably for streaming. I’m still debating, which is best YouTube or Twitch, because I noticed that on Twitch people are more likely to support creating. And like donate more become members and all that. It’s just the communities built around, you know, supporting creators on YouTube is more like people come to watch polished videos, which are edited and all that it’s nicely placed. So they’re not that popular right now with streaming. So probably that’s why. People, at least in my niche, people are not. Likely to donate, [00:22:36]

Michaela: but how many people do have on your life? Coding streams onto it? [00:22:40]

Florin: It depends on if I like, for example, last week I had a special livestream where I announced it two days prior to the event and I had over a hundred people joining me, but in the day day by day-by-day stream, I gets 30, 40. Tomorrow or less that [00:22:59]

Michaela: are, that are following you and your [00:23:02]

Florin: staff. Yeah, but I mean maybe some of them leave and others join, but like an average of 30, 40 people tuning date. I mean, that’s the number I see of viewers at the moment, but who knows how many people show tonight? [00:23:20]

Michaela: And so you, do you use restream Dan too, or something like that, the platform stream your Stritch video also on YouTube and the other way around or? [00:23:28]

Florin: No. So right now I’m only streaming on YouTube. So I’m using just OBS to stream directly to YouTube last year I streamed. So I started streaming on YouTube last year, then I moved to Twitch and now I’m back on YouTube because I just felt like I have a big audience here. And I don’t know. I was thinking that I’ll get more viewers over time. I still don’t know. I might have to test multiple times to see all right, which is best Twitch or a year to maybe just keep Twitch for streaming and a YouTube for videos. But I found myself that that was too lazy to just take the videos from Twitch and upload them again on YouTube. So I I’m just dreaming now because. Easier for an hour. The goal is not necessarily to have the streams go out to thousands and thousands of people because I only see them after a day or so. They’re not very polished. So the goal is to have a place where those who are interested to follow. Day by day didn’t know that, okay. Flooring is life this hour everyday. Let me check what is day. And I’m also doing recap videos every week. Now I messed up a couple of weeks, but the goal of the recap videos is shorter videos, which kind of describe what I did in the past week. And those should like push out the challenge idea to more people and get more people. To eventually join me. [00:24:56]

Michaela: Yeah. So I have been streaming on Twitch for, I was 2019 a long time ago. I actually almost said, no, it wasn’t. 2010 days, sorry, 2020 last year for a month. And also for like my challenge of building, you know, building a tool within 30 days. And I also went live every day was very, very nice. I was a little bit exhausted to be honest, after 30 days with like, oh my God. And it was fun, but I also feel like it’s really hard to do something meaningful in an hour. Without really preparing for it. Right. So this was also always like great, just jumping in and doing it on the spot. And, and then even talking with people, like if people are coming you’re a little bit chit-chatting and then really getting something done, I feel it’s very, very challenging is it’s something that you felt you grew into and you just got some more, you know, some muscle memory to do it better. Or do you prepare before the stream or how, how do you. [00:25:58]

Florin: Yeah. So I have to agree, like it’s very exhausting. For me, I just, I kind of noticed that after two hours of going live, building, researching, brainstorming, chatting with the people from the chat for two hours, I’m just dead. Like it just can’t function anymore. I need an app very bad. It’s just, that’s how it is. I mean, I can think on my head hurts from after two hours, because I think. Too much going on because I’m also coding and thinking at the same time, because it’s not something I know by heart. So I have to research it. I have to think about the things I’m doing. And at the same time, people from the chat are talking with me. I have to interact with them. So it it’s, it’s tiring. But I liked the, I liked the fact that I do this every, every day and the, it just. To be honest, some of some days, this is the highlight of the productive part of the day for me. So if I didn’t have this, I wouldn’t do anything that they, so for me, it’s. Motivating to keep doing something, even if it’s just for 30 minutes or an hour, it’s doing something towards the goal of what are a cake. And like the money aspect is nice. It’s kind of intriguing for people to join and see, let’s see how much money flooring made. But for me, the real goal is not necessarily the 100 K in revenue. I could make that it don’t have to make it public. I almost did that in a year, so it’s not the, I it’s it’s possible, but for me, it’s just who I have to become, what skills they have to learn and develop and what knowledge I need to learn along the way to be able to do this. And I also do it publicly. So it’s, it’s more about my personal growth than it is the money aspect. That’s what motivates me. So the money goal is nice. We could public people like to chase those things. But yeah, it’s more about, because I’m also going out my comfort zone because I’m building projects to monetize them. So I need to maybe learn new skills of how to develop a proper database and how to get that education and how to design well and market and all that. So there are new skills I have to learn along the way. And that’s, that’s motivating for me and hopefully inspiring for others to get out of your comfort zone and money is just a return of the value you bring and grow to have. So it’s just a matter of time afterwards. [00:28:35]

Michaela: So it seems like you never suffer from analysis paralysis, right. Where you’re like, oh, what should I do? Oh, this or that? Or they say that, how do you do, do you just do all of that? Or do you feel that [00:28:47]

Florin: something. I feel that probably all the time is just the chat helps. So whenever I don’t know what to do, usually what I try to do is to set the side tasks for tomorrow. So whenever I’m live and I have inspiration of how to develop the project to bring it to the next level, I just write down a series of tasks. So then tomorrow, when I’m not that inspired of knowing what to do. I just have the tasks and another thing which really helps is the chat. So I have a couple of people who are joining every day and just having people to bounce off ideas and they give you feedback and their critique, your work is it’s a great way to have something to do. But I, yeah, sorry, [00:29:38]

Michaela: man. Do you know how, how old. Audience is, or the background or the new developers or the senior people are they’ve maybe indie hackers as well, or, [00:29:54]

Florin: yeah, probably those who follow me along everyday are indie hackers or at least want to be in the hackers. The reason why, like I have 115,000 subscribers, but. Dan’s joined the live streams and there isn’t why is that? Because most people who subscribe to my channel, they subscribed for my tutorial. So like probably they want to learn to code, but what I’m doing now in this challenge, basically it’s not necessarily beginner friendly, although I kind of try to make it beginner, flan friendly, where we build a project from scratch, but there are. Some things which go out of that comfort zone is some things which are more of a business related thinking. And not a lot of people are interested in it right now. You know? So most people who follow me day by day they are interested in this like building projects, monetizing them and work for themselves kind of. Entrepreneurial stuff. [00:30:57]

Michaela: So you have actually two, two sort of niches. One is the indie hacker niche where you have, you’re building a following and then you have that mixed in with the, I want to be a developer niche. Right? So teaching niche, do you want to have them separated more? Do you feel like. You started off it, for example, teaching development. And now you want to be more in the D you know, indie hacker space, or is that both that represents you? How do you think about that? [00:31:27]

Florin: So throughout my journey, as a content creator, I mostly shared what I was doing. So I started off as a blog. Right. I was posting articles. Then I moved on to YouTube creating YouTube tutorials, and now I’m moving on to being an indie hacker. So I’m kind of doing my own journey and. People who follow some people follow me for me. But then I have separate audiences for those separate stages. As I said, most of the people I most of the subscribers I gathered along the past year or so were those who are interested in learning how to code, but now as I’m approaching like a new direction, some of them will be interested in this too. But I’m also now targeting another audience for me most, most about my own growth. And I know that if I learn stuff and share stuff, people who also want to do the same. The same things they will follow along. I know that with this new indie hacker kind of journey, I’m not targeting my older or my old audience. But that, that’s fine because it’s, it’s a progress in my own life. I’m just, I want to be I feel like I would be starting. In a place if I just don’t grow, you know, and I will continue to address that audience as well with tutorials, but my life goes on and I learn your stuff and I, it. Move on, on a, on a new, because at the same time, there are so many YouTube stars out there doing tutorials for beginners and much less of those who just use the skills you’re learning. And building stuff, monetizing them, be your own boss. Yeah. Yeah. Kind of thing. I think that [00:33:23]

Michaela: that thinking and those fears around those thinking are very, very similar to those fears that you have. Oh, I studied computer science and now I want to be a writer. Oh my God. You know, my life will end. I’m even allowed to do that. Right. So these growing aspects, I think of people and, you know, whatever you set out to do, and then you grow and you realize actually something else. It’s happening in my life. I think this is very important that we acknowledge that and that it’s really normal and it’s okay. Right. You, I don’t know, you studied history and now you want to be a developer, go do it. Right. And now you did those videos and you want to be, you know, want to do other videos that are following along your life. I think that’s a super important and we shouldn’t be afraid. I think it will work out wonderful. You’re very charismatic. So I, I was really happy that you have been on my podcast today and to talk with me about all of those things, content creation, monitorization, building an audience, and I will definitely follow you. I will link everything down in the show notes and yeah, with those words, thank you so much, Lauren, for being on. [00:34:31]

Florin: Thank you very much for having me was very nice step. Yeah. Thank you, [00:34:35]

Michaela: flooring. Bye-bye [00:34:36] Florin: thanks. [00:34:38]

Michaela: I hope you enjoyed another episode of the sup engineering unlocked podcast. Don’t forget to subscribe and I’d talk to you again in two weeks. Bye.

Driving innovation and engineering practices with Dr. Holly Cummins

In this episode, I talk to Dr. Holly Cummins. Holly was the development practice lead for IBM Garage for Cloud, before becoming an innovation leader in IBM’s corporate strategy team. She drives innovation for companies in various industries, such as banking, catering, retail, or even nonprofit organization. She is also a Java Champion, a JavaOne Rockstar, a published author, and a regular and vivid speaker. 

We talk about:

  • What it takes to drive innovation in an organization
  • Test-driven development (TDD)
  • Ensuring a healthy and welcoming company culture
  • The benefits of Pair programming

This episode is sponsored by IBM – where innovation and transformation come together.

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

Transcript: 

[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: Hello and welcome to the software engineering unlocked podcast. I’m your host, Dr. Mckayla and today I have the pleasure to talk to Dr. Holly Cummins. This episode is sponsored by IBM. IBM not only produces and sells hardware, middleware and software, but also offers hosting and consulting services. The part that is the most interesting to me, is that IBM is also an active research organization, and an enabler for innovation and transformation. One interesting business area is called the IBM garage – which focuses on accelerating digital transformation, by helping people generate innovative ideas while it also equips them with the practices, technologies and expertise needed to rapidly turn those ideas into business value.

Dr. Cummins was the development practice lead for IBM Garage for Cloud, before becoming an innovation leader in IBM’s corporate strategy team. She drives innovation for companies in various industries, such as banking, catering, retail or even nonprofit organization. She is also a Java Champion, a JavaOne Rockstar, a published author and a regular and vivid speaker. So what should I say? I’m super thrilled to have Dr. Holly Collins here with me today. Holly, welcome to the show. 

[00:00:56] Holly: Thank you so much. It’s yeah, I’m really looking forward to our chat. 

[00:01:00]
Michaela: Yeah, me too. I mean, my introduction was really, really long because yeah. You have so many accomplishments. It’s really cool to talk with you. So how does that work? Driving innovations for organizations? Can even one person drive an innovation for a whole organization? Or do you need like, that everybody is on board. How do you. 

[00:01:21] Holly: I think one person can make a whole organization innovate, but one person can help create an environment where innovation flourishes. I think we’ve certainly all seen the opposite as well. One person, if they do it wrong, can really best innovation across the whole organization. And I think. With innovation. It’s about making this sorts of environments where ideas can grow and where there’s the second, the logical safety for people to express ideas, but then also the organizational tolerance for risk too, to be able to invest in those ideas. But then also I think you need some methodology or, or some rigor to try and. Manage your innovations, because I think a lot of us have as well have seen innovation labs where there’s all these amazing ideas and then none of them actually make it out the door of the innovation lab. And that’s fun for everybody, but it’s not really moving things forward. And really what you need is innovation that matters. 

[00:02:29]
Michaela: Yeah. . I’m currently working on a research project where we look at cultures, especially for development teams. How do they have their cultures? What makes them happy? What makes them productive? What makes them innovative and psychological safety and, you know, being able to speak your mind. This is also important. And I conducted a couple of interviews. I also have worked in different organizations and it’s just really tricky, right? I mean, it’s really tricky to be in a work environment and being able to voice your opinion. And some people get really lucky, but a lot of people really struggle with that, I think. And I don’t know if it’s, if it’s bigger organization, I can’t, can’t even say like a bigger organization. It’s more tricky than in, in smaller. I’ve been in startups. So you think, well, innovation should really flourish down. There were like brilliant people on the team, but they’re are also. They take all the space, right. They’re very dominant people. So then all the others conferee so much, then there are like larger organization where you can strive. Is there some recipe that you can recommend for people to, you know, follow to get more psychological safety or do you know, be, be more self-aware if others even can speak their mind or, you know, like, how does that work? 

[00:03:40] Holly: Yeah, that, that that’s yeah. Super interesting about the startups. I I sometimes feel at a disadvantage talking about culture cause I’ve worked for IBM, my whole career. And IBM clearly is not a startup. It’s about as opposite a startup as, as you can get in terms of its history. But one of the things that I. Like to talk about, which I think is probably quite related to your, to your research is the importance of fun in the workplace. And I deliberately talk about fun because it’s a little bit provocative because we all have this sort of instinctive reaction that says work is a place for work. It’s not a place to have fun. And so then. I think by sort of choosing something that seems counter-intuitive and then peeling away the layers to talk about why actually that fun environment is really closely correlated to a productive work environment. And I think as well, it’s, it’s quite closely correlated to psychological safety. And I think, you know, the psychological safety manual, certainly doesn’t say let’s have achieved psychological safety by, you know, installing. Ping-pong or, you know, that kind of thing, but, and it’s, you know, and I think what I mean by fun as well, it’s not those sort of that superficial layer of fun. It’s that, that deeper thing where you feel the connection to your colleagues and you feel the work gives you joy. 

[00:04:55]
Michaela: Yeah. I also saw that coming up in my own research, but also related research, right. That satisfaction, happiness and productivity. They are really concepts that are very intermingled. ? So engineers also having fun if they are feeling productive and productivity also means connectiveness. ? So a lot of developers that are interviewed, they talk about supportiveness and how they have to know that there is another person that I can. Call or no call before we could walk up to them, but now we call them and they are there and they’re helping us. If you’re stuck, we don’t see the siloed. Right. There’s a friendship coming up as a concept. Right. People want friendship in their workplace. Yeah. I can totally relate to that. I felt really lonely last year working as a solopreneur. And so that’s also why I stepped a little bit away and was taking on more customer work again, because now I’m in teams and I’m feeling, you know, I’m talking to people more and this is really, I mean, it’s also joy and yeah, so I can totally relate to that. How, how do you engage with organizations? So you are at IBM, but you got into different other organizations or is that all internally where you have like little labs that you, you know, that you try to get to flourish? 

[00:06:09] Holly: So my role at the moment it’s somewhat internal and somewhat external. We’re always working with clients, but sometimes I’m working with an IBM team who is working with a client, but in, in the garage we were, we were very outward facing client facing. And, and I think there’s, there’s lots of different answers for how do you engage with an organization? How do you change an organization? Right. The, the answer that we chose in the garage is really sort of support at the top and then making the change bottom up. So we would try and get buy-in from the senior stakeholder. And the organization wanted to try working in a new way that it wanted to try bringing some of these, the psychological safety in the innovation. But then also some of the other things that we talk about a lot, like, I mean, agility is an overused word, but that, you know, that ability to respond to change that, that tolerance for risk. But I think sometimes know. If if we try and make that change only at the top level, then it just ends up being as a lot of words on slides and so in. And, and there’s a lot of resistance to these ideas as well because people work in the way they work for a good reason. It’s not like everybody’s sort of set out and said, I know we’re going to make our organizational cut culture so that it, you know, crushes the spirit and destroys productivity. You know, the intention was always to, you know, to try and achieve something good. It’s just that the side effects. Yeah. We’re not good. So then what we do is we work with a particular team on a particular project, and we say, we’re going to, we’re going to do this particular thing and we’re gonna get a result and we’re going to do it in this new way. And you can see that while we work in this way. Actually good things are happening, not bad things. And bringing in dev ops, for example, hasn’t increased the, the odds of something bad happening. Look, we can show you it’s reduced the odds of something bad happening, and look, it’s actually made the process more rigorous, even though the process is also more seamless. And so if we can do it on this one project, that’s maybe not super business critical, let’s try and now expand it to the next project that maybe is a bit more business critical. That, that ripple I would affect because I mean, I think success is the best evidence. And so when you can do something and show the results, then that makes people much more keen to try it for themselves. 

[00:08:32]
Michaela: Yeah. So you are coming in and then you’re working with one team. And is it only you, or is it you and the team that’s working with that other team with that project? How does that work? 

[00:08:41] Holly: Usually we’d have a team. And I think the, sort of the, at that teamwork aspect is, is so important. I think going back a bit to what you were saying about the lockdown that even the most introverted developer, I think, you know, we, we get something. Team and the, the effects are much better as well. So we try and have really diverse teams in terms of the skills and the disciplines of the people. So normally what we would have is we’d have a handful of developers. We’d have maybe some, some architecture support. But then we’d also have designers who are really making sure that we’re focusing on. The humans using the technology rather than just look, it’s a thing and it’s shiny and I can install it and I can write code on it. And so I’m happy, you know, trying to sort of reel it back, but I’m glad you’re having fun Holly, but how are we making life better for someone else? And, you know, what’s good. You know, cause success for any software project. It’s not just, I did code success is something is better somewhere either at a business level or, you know, at a user level or that kind of thing. So on, on our side, we try and have this really diverse team, but then we also want to make sure that we’re co-creating with the client. So our ideal is that they’re bringing their developers along. They’re bringing their architects along. They’re bringing their designers along as well. And then they’re bringing a product owner because they’re the one who owns the vision for what we’re trying to do. And then that means that as well as making the thing we’re doing a skills transfer. And so I when I was first working in the garage, one of our, the the IBM sellers who we were working with got a bit grumpy because the, the sort of model that they had done was that we would do a thing and then they would sell training for the thing. And because we were. Co-creating that training just sort of happened on, on the job and it didn’t slow anything down. So we would be pair programming and that knowledge transfer would happen. And it would happen in both ways as well. So we, we know things about the carriage method that we can share. We know things about test-driven development dev ops, but then, you know, they’re going to know things. Or organizational context to say, ah, yes. When you want to do this, you need to tell, talk to Bob on the second floor. And so having the person who knows that pairing with you means that you don’t sort of have to go through this elaborate process of I’m stuck. Who do I talk to you? And then, you know, try and figure it out. And they know things about their, their business domain as well. And you know, the sort of the, some of these problems are really quite specific and niche. And, you know, you couldn’t have just a general consultant go in and solve it without doing that. Co-creation. Yeah. 

[00:11:24]
Michaela: And how long are those engagements normally until there is some transformation and some knowledge transfer, how long does it take 

[00:11:31] Holly: for the license? I don’t think the sweet spot is about six weeks, so that’s, that’s long enough to do something that’s really meaningful to get an MVP, but it’s short enough. That an organization will feel okay with the risk. Cause, you know, if we, if we sort of say, and, and, and as well, you want to make sure that at the end of it, those results are going out and are really visible. So having that short cycle and then say, okay, and if we’ve done it once and you like it now, let’s do it again because. You saw that result and it wasn’t this sort of really protracted process where it took 12 months to see any change. Yeah. 

[00:12:10]
Michaela: So you are mentioning already a couple of development practices, like Def ops test driven development, and you have, I mean, the development practice lead for IBM garage. So. Do you think, what are some of the development practices that you recommend that really everybody should do? Is it like peer programming? You also mentioned that or code reviews. What about testing? Do you think this is crucial? Do they have to do it? Can we just do it a little bit? Or can we just skip some of those things?

[00:12:40] Holly: Yeah. We sometimes have conversations about testing because. The there’s a trade-off I think between doing something quickly and failing fast and getting that rapid feedback and not over-engineering while you’re doing that and the enormous benefits of testing. So sometimes if we’re doing something that we know is going to be throw away, and I think there’s a lot of value in doing something that you know, is going to be thrown away. That is that, you know, sort of lean startup , methodology, maybe testing doesn’t make sense. But I think in general, The, the benefits of testing are so great in terms of the quality of the code, but also automated testing is absolutely necessary to support dev ops and dev ops is really. Necessary now in order to support any kind of automation and efficiency and any, you know, that, that ability to do those repeated deployments and the ability to respond, to change and to manage risk. Sometimes, you know, you sort of hear these stories of something that goes wrong and then an organization doesn’t have any way to make a change to fix the problem, except either to go through. Lengthy process or to completely short circuit and bypass the process and, you know, have someone secure shell into the effective machine. And then they change the things by hand, which is obviously not going to be particularly robust in terms of the repeatability or the safety or anything. So you sort of get this chain where you. Do dev ops, because I know it gives so much better results in order to do DevOps. I need to have automated testing. If I’m going to do automated testing, I want to do it with test driven development, because that gives so much better quality for the tests and it. ensures the testability of the code and as well, I think one of the biggest benefits of test driven development is really to refine our understanding of the problem as well. Some people call it tested and design rather than test driven development because of that effect that when I sit down, I think we’ll see, what am I really trying to do? How will I really know what I’m successful? Let me write a test for that. And usually what we look for with a test is something that we would have been looking for manually. Anyway, you know, I go to a web page and I see this, or it prints this. It’s always, you know, we’re always looking for some evidence. We just try and encode that, looking for the evidence in, code, which is efficient. Usually. 

[00:15:09]
Michaela: Yeah. So test driven development often is I see it a little bit synonym to also unit tests instead of integration tests. But now you also mentioned something like a UI test, for example. So do you have, like, do you make some distinction here and do you think one is better than the other? Do you see that there’s a shift nowadays in industry? I see a shift and a little bit that, what is your perspective on that? 

[00:15:33] Holly: Yeah. I mean, I like to do test driven development at, at all levels. So I like to do test driven development for my integration tests. I like to do test driven development for my unit tests. I think sometimes you do get a little bit tangled where you can’t have, you know, you sort of, you, you do your, you write your unit test and then it passes. And then in doing that, you’ve done enough that actually your integration tests is already passing. So then you’re. Catching up with your integration test a bit, but sometimes we do it the other way and we say, okay, I’m going to start with my integration tests. I’m going to get those integration test passing. And then I’m going to fill in a bit with the unit tests. But I think like, I don’t think it’s something that is just for one level. I think if it’s an outcome that you care about and that you don’t want to regress, then there should be an automated test on it. I mean, I, I. I’m a huge fan of contract tests as sort of an intermediate layer between the integration tests and the unit tests. Cause I think sometimes with unit tests, well, integration tests are really expensive to run in any kind of complex environment, especially once you’ve got 60 microservices. Good luck running the integration tests in any kind of regular way. But then with the unit tests, I think you can sometimes get the sort of abdication of responsibility where everybody owns their microservice and they run their unit tests and everything works great. And the system as a whole doesn’t work. And so somebody has to care about that at some point, but then you sort of end up playing this sort of. Sort of pass the parcel of responsibility, where everybody goes more, my services working as designed. And so then an on all the problems happened at the seams. 

[00:17:13]
Michaela: Yeah. , my PhD thesis was about playing in testing our plugging systems and how you test them. It was more or less also services, service oriented architectures at that point. Right. And it was pretty new. People were just jumping on that vegan and so on. And I said, well, you know, you were going to get a little bit into travel if you’re, if it stayed the same with how we are doing testing and nowadays but you’re also an expert for cloud computing. Would you say that in the cloud world, somehow testing or in general engineering practices change, is there, do we have an impact we should we or can be developed in a different way, test, deploy everything. Why is said the same? 

[00:17:54] Holly: Yeah, I think it has to be different in order to take advantage of the cloud. So one of the things that you’re almost certainly going to want to be doing on the cloud is, is that DevOps it’s that more rapid deployment. And then if you. Deploying rapidly. And you don’t actually know if your code works, then either you’re going to have an enormous issue in production, or actually you’re not going to be deploying rapidly, you know? So we still sometimes see these cycles where something is getting deployed to the cloud, but then there’s a three week UAT phase before anything can be deployed. And so then. You know, that just doesn’t work. It’s a waste of the cloudiness. It almost may as well be on-prem. So, so you sort of get this ripple back from, again from the dev ops, which you want to be doing to the testing to the TDD. 

[00:18:42]
Michaela: I also think like we had, we had very strict roles back then. Right. So whatever, like operations. Yeah. The engineers, the software engineers or developers. And we had like the testers, then there was like a time. Now we have this dev ops for, you know, at one point for dev ops, I feel like every engineer was supposed to be a dev ops engineer. And and then we had like the full stack. So you’re not a front end or back end, your full stack, your full stack from front end to back into dev ops to everything. And now I feel people start to struggle with that concept again. No everything because there’s so much to know that there’s not a single person that can be like this end to end dev ops engineer to front end you know, genius. You see dad, like is there, is there again do you see that there are more roles that are forming itself or a person is bringing more Def of engineer and then more of backend, more front end, you know, cloud maybe, you know, even more concepts that we have here.

[00:19:43] Holly: Yeah, that one’s a really tough one. And I, yeah, I sometimes sort of, and I think I sometimes talk to people who ha, who say exactly the same as you, that, that there are too many expectations on me and actually trying to do all of these things means that not only will I not be quite as good in all of them, actually, I’m going to be pretty inadequate in all of them. And are you sure that’s what you want? And so. I think there probably is, is a space for having those specialist roles. But I think part of the issue as well, sort of is there’s an organizational decision about where do you, where do you put the boundaries? Because I think we probably still do want to be saying. That if you are too specialized, it creates organizational friction because it means that you risk becoming a bottleneck or, or the opposite as well that it, you know, it means that you risk not being deployed because all of a sudden, none of the projects our organization is working on, have a need for your skills. And since you only do this one thing really well. You’re just going to be sat around and that’s not great for us cause we’re paying you and it’s probably not great for you either because you’re really bored. So let’s try and have everybody at least be able to do a few things and let’s have people really comfortable sharing their skills as well. Cause I think that comes back a bit to the pair programming and the multidisciplinary teams that maybe I’m pretty sure. Pretty bad at front end, but I know just enough front end that if I’m collaborating with a front end developer, I can bring my something else. And we’re still going to do a better job than if that front end developer was on their own. And we’re going to do a way better job than if I was trying to be a front end developer on my own. And so then you get these sort of complimentary skills in, in the pairs. 

[00:21:37]
Michaela: I think we are coming back again to the teams as well, or to the concept of a team. And that people are really strong as a team. Maybe they are. And there was like, I did an interview with it, very senior engineer. And what he said is like, , if you want to go fast, go alone. But if you want to go far, go with the team or with people. Right. And so this was indeed in one of the interviews about productivity and happiness and so on. And I think. I was also talking to Alex from FedEx and she was on my podcast. He’s a testing expert. And she was also talking about these teams where you have like a person that has a strong expertise, but then this expertise somehow overlaps. Right? So you want to expand your expertise to other roles. Let’s say you are a testing expert, but then you want also to understand development a little bit, then you want to understand maybe dev ops a little bit. Right? And so you’re having this. These shapes that are overlapping. And then in the same team, you have a person that is very similar to what you said, right? They are front end expert. And so you’re overlapping in your understanding each other quite a bit. Right. It’s good. If you don’t, if you’re not solely responsible for everything and you can learn from each other, I think learning is also such an important concept for happiness. Do you see that, that people want to learn? 

[00:22:47] Holly: Yeah. A a hundred percent, I think it’s, it is one of those things that motivates you at work. Isn’t it is, is that desire to learn and, and, you know, if you just do the same thing every day, it, I mean, it’s, it’s awful. Isn’t it? There needs to be something coming in. And I think you’re right. That, that does come back to that teaming that if you’re working in a team and people have different skills than you, then you’re, you’re automatically going to be learning. And one of the things that I always said about pairing in particular is, you know, there’s sometimes we put sort of a hierarchy on pairing doughy and we say, okay, so we’ve got the senior developer pairing with the junior developer and they’re teaching everything they know to. It always, it always goes in both ways. So as a senior developer, if I’m pairing with a junior developer, often they’ll know a framework I’ve never heard of. And so then they’ll teach me about that and they’ll know keyboard shortcuts. I’ve never heard of. So they’ll teach me about that. And so it’s always that, that two way knowledge transfer in, you know, independent of your position in the hierarchy or how long you’ve been anywhere. Yeah. 

[00:23:50]
Michaela: So I hear you talk a lot about pair programming, so. I don’t hear you talk about code reviews. What do you think about them? Do you do them, are they not that important? Do they compliment or do you don’t need them, if you do poor programming, how do you see 

[00:24:03] Holly: that? So my, my, my personal take is that one of the great advantages of pair programming is that it eliminates the need for code reviews. And we sometimes talk about You know wait, isn’t pair programming, more expensive. I’ve got two people doing the work of one person and, and, you know, there’s all sorts of reasons why that’s not true, but I think one of them is that otherwise you have, usually you will have a para-pro code review process at the end, otherwise, and that can be really expensive, so it can be expensive in terms of people’s time, but then it can also be expensive in terms of the sort of thing. Bottleneck and the blocker that it creates, and it can be expensive as well in terms of the, sort of the patterns that it encourages. Because if people know that when you put something in for code review, it takes three days to get it back and get it approved. You know, that’s maybe a pathological case, but it’s not that pathological people. Aren’t going to be putting things in every 10 minutes. You wait until you’re finished something and then you send it over and then you get this. Spiral where the person who’s doing the code review gets a mountain of code and they go, Ooh, I’m not, I’m not looking at that until I’ve got a bit of room in my schedule, which is three days later. And then as well, when they look at it, usually. I see a couple of things happen. One is that because it’s so much work, if there’s a really fundamental design problem, either it’s sort of too late and they can’t see it, or they do see it, but they think, oh man, you know, they’ve been working on this for three days. I can’t go back and tell them they should have done something completely different or that they shouldn’t even written any of this code. And so then the sort of the big problems don’t get fixed and. But then you think, well, but I’ve got to show that I did the review. I’ve got to show that I’ve got some value in this process rather than just annoying them by waiting for three days. Let me find the position of the semi-colon line 36. Let me comment on that. Then everybody knows I’m contributing. So you get this sort of bike shedding. And as you can tell, if I find the whole, the process for us one of the patterns that I really encouraged with the pair programming is that you rotate the pairs every day. So that gives you a much deeper code review. Cause I think otherwise you only, you get like one person’s code review, but then you sort of end up where two people can be wrong just as easily as one person or two. Certainly, you know, two people can be wrong. So then on the second day, A third person comes in and then there’s already sort of another built-in code review where they, in order to be able to contribute, they get walked through what was done the day before. And then they’re able to say things like, oh, well, but why did we do this? And here, why don’t we just try this? And it it’s, you know, it’s not a formal review. It’s an interactive sort of getting them up to speed teaching experience, but then it means that there’s this second chance to catch errors before. Developed too much, but I think, I mean, I think you probably are. You’re asking the question cause you, you probably have quite a lot of expertise on code reviews and you’re gonna tell me all the patterns where it does work, which of course it can, then it can work 

[00:27:07]
Michaela: with no, no, but I definitely did the recall and realize all the things that you said, because this are definitely really common problems that I also see that teams have. Right. So this is also one of the things by in my view, Teams come and they bring all really everything that you said, right? Like, and this whole chain of how it just doesn’t work. Great. How to process doesn’t work and where you, where you have this waiting time, where then the code reviews are too big, right. Or you’re done, cannot understand them. You still have to do them. What do you do? Right. So this, there is definitely this, this loop that you are describing. Totally recall, because this is, you know, this is the, the problems that all the people are bringing on the table when they’re coming in, when I’m working with it. Maybe what I see, I actually really liked code reviews because of this synchronicity. Right. So you can have them in a very lightweight way. I also see them complimentary a little bit to peer programming, but you definitely have to do them in a different way. Right. And I think what many organizations don’t understand and why we are creating this loop of yeah. Troublesome problems that we have, how we doing is that we don’t understand the goal of why I’m doing this. Right. What do we want to get out of that? And then also, okay, what do I want to get out of that? And how can I shape the process in a way that I’m getting this out of that? Because I really see that they have all these painful drawbacks. Definitely. But they also have like really wonderful benefits. So I think the most important is that you really understand. The pain points that you said very, very deeply, but then also, what can you, you know, what can you do to counteract them? How can you change your practice but, but I see, I see all the things that you say, and I’m actually a big fan of pairing as well. For me personally it’s very draining to do it. Like I love it from time to time, right? Like it’s the best where I feel like. You have your mentor there, or, you know, you have just this connection and the supportiveness with the people. So I totally enjoy it from time to time, but not too often. How often do you do pairing? 

[00:29:17] Holly: So what, what we used to do. In the, in the garage is, is we would do it pretty much all day, every day. And there was, there was a few advantages to that because I think one of the, sort of the hardest things of pairing is the logistics. And so then going back to the PA to the code reviews, you know, there’s some circumstances under which pairing just will not work and makes no sense because it’s, it’s so synchronous and asynchronous doesn’t scale. So, you know, you need to have that kind of asynchronous process as well. And if you’ve got Particularly, you know, if it’s something like open source where people are in different times zones and they’re working different schedules and some of them are doing it in their own time, you know, something like pairing it, it, you know, it’s almost off the table to, to begin with. But what we found is if we tried to be. Ad talk with our pairing, which of course works quite well for a lot of teams. We sort of, we never ended up doing it because it would be well let yes, let’s pair today. Yeah. We definitely want a pair today. Okay. So, so maybe after lunch. Oh, I can’t after lunch, I’ve got, you know, I’ve got a thing. Okay. Well we’ll maybe, maybe at two o’clock. Oh, I can’t. And then, you know, we, we settled that we’re going to start pairing at three o’clock, but then something would come up and then somebody would be unavailable. So by sort of defaulting to pairing, we’d keep our calendars free. And it was great actually, because if we got invited to. I’m afraid I can’t attend this meeting. I’m pairing. So if you interrupt me, you’re interrupting my hair as well as it was sort of, it was like this sort of intro we could block your time. 

[00:30:43]
Michaela: a couple of organizations that are working with and That we try something out and it looks really, really nice is that you’re doing code reviews on a particular time. And then it’s done by one engineer. Right. But they’re doing all the others can go in and now everything is via suit, right. As are our teams and whatnot. Right. So by that video conference, and so they’re doing this cultural view, right? Everybody that’s interested can join. Right. And those sessions really, really particularly work well. I’m very surprised by that, but I really have good feedback from, from different organizations where you know, you have this casual thing where people know this is happening, right. One person really drives the review and the errors can watch ask questions, clarification questions, or, you know, other things maybe learn just have their fairness. Have you tried something like that? Is that 

[00:31:36] Holly: we’ve tried some similar things? Not, not exactly like that, but that, yeah, that seems, seems really good. So we did I mean, one pattern of course is the sort of the mobbing pattern where we say We don’t just want to do it with two people. We actually particularly for knowledge sharing, you know, we want to do it with six people. So let’s all gather around the keyboard or let’s all gather on the zoom, but as well, what we used to find was, again, it’s that scaling that the pattern I described, where you rotate the pairs every day in a big code base. With a big team is still gonna be quite a while before you rotate round. And so then you do need something else. So what we’d sometimes do is on a Friday, we’d do a show and tell session. So it was, it was very similar to what you described actually, but we’d sort of someone would say, okay, well, I’ve just done this particularly evil thing in this part of the code base. And nobody’s sure. Yeah, understand what I’ve done unless I talk them through it, or I’ve just discovered this really counter-intuitive behavior in this library. Let me show you all what it does. So you don’t get called out the same way I did. So it was sort of partly a code review and then partly a, an education session, but it would just be really informal and just whoever had interesting code. Would show it and talk it through the rest of the team and then they’d ask questions and that kind of thing. 

[00:32:46]
Michaela: So maybe one last thing that I would like to talk a little bit with you about is because you. You actually transitioned a way, right? From, from being this development lead at the IBM garage. And now you’re an innovation leader in the corporate strategy team. What does that mean? And what, what’s your role there? What do you have to do? 

[00:33:05] Holly: So our, our, my role in corporate strategy, it’s really interesting. It’s because I’m sort of in the, you know, we’re sort of a headquarters role, so I’m sort of in the, in the heart of IBM in, in the center of IBM and I sort of get to see a lot of what’s going on and what we’re trying to do is we’re trying to. Really just be the, sort of like a free resource, both people and financial to try. And when we see something amazing that can’t quite happen because there’s some sort of blocker or there’s just, you know, it just needs a little bit of money to, to get over a starting line that we can sort of give it that, that push. And then hopefully. Make something amazing happen so often it’s where if we have a client team and you know, the client really wants to do something and we really want to do something, but just somehow it just needs a little bit of money just to demonstrate to the people who have the large amounts of money that this is really worth doing. And, and one of the things that we do as well, because I think as an industry, we’ve, we’ve moved a lot now, too. Every, you know, we always want to be trying to do things by actually trying them out rather than doing slides. So that that’s not, it was new when the team I’m part of was started. It’s not, it’s not new anymore, but still in a larger organization, you still sometimes get things that fall between the cracks where it doesn’t quite fit in, in anybody’s mission. But that means it’s actually extra important. So then, because, because we’re sort of central, we can bridge those, those internal barriers. 

[00:34:39]
Michaela: And do you still have a lot to do with engineering? Do you still develop software or is it more really strategic and leading that you’re doing right now? 

[00:34:49] Holly: It’s a little bit of a mix, which I think going back to what you were talking about with the learning and the, and the variety, I think it is good. So it means that whatever, whatever seems most necessary. We’ll do that. So sometimes it’s actually let me go in and architect this, let me, let me go in and out a bit of code. Let me, you know, I’m not a data scientist, but some of my colleagues are data scientists and they’ll okay. Let me fix your model for you. And then sometimes it’s more strategic and more making those connections to say, actually, I can see that this is going on in one part of our organization and something complimentary is going on in another part of my, let me connect those two, and then we’re going to get a better outcome. 

[00:35:31]
Michaela: Oh, that sounds like you’re really having a lot of hats. I really liked that when I was at Microsoft, also driving bit innovation there and having all these different hats, like you’re, you’re driving projects, but you’re also doing the implementation. I was mainly prototyping at that time. But it also means that you, as you said, you have to learn a lot. Did it take it a little bit to get used to that role and know what you have to do? Do you have like mentors that help you or is it. Structure around some, formal mentorship program at IBM. How does that work? 

[00:36:03] Holly: I think. With that kind of role where, where you have a lot of hats. I think it comes back to, to the team again and the sort of the resiliency and the team. So what we tend to do, because we’re doing challenging things and we don’t know in advanced necessarily what skills will be required is we, we do sort of go around in groups where there’s more than one of us. And then that means that whatever hat ends up being needed, there’s someone who has that hat and then someone else who can sort of shadow the hat. 

[00:36:34]
Michaela: Yeah. Yeah. That sounds really a great team to be in. Maybe the last thing really last thing. And then I’ll let you go. Or that I want to talk with you about is there’s the same culture eats strategy for breakfast, right? So, and what it means is that. The culture is of utmost importance. But also it’s a very vicious cycle that, you know, how do you get your culture to apply and how do you get your team members to, you know, like each other or at least respect each other, right. Especially if you have, so sometimes people have I also have that in my workshops when we are, you know, when we are working on these problems, that code reviews create right where we have, for example, very strong personalities in a team with very strong opinions. So it have problems, you know, like giving into, what did you hear? Do you have like do you have like some strategies for that? Do people do something to do, do some coaching or can you help can the team help itself? What’s your experience with that? 

[00:37:34] Holly: It’s. It’s tricky culture, because in some ways, some things about culture, you, you can change because you can, you know, sort of start with your small changes and then success is the best evidence. And then you can roll it forward and you can make those little changes to encourage psychological safety. And you can have, if, if the leaders are bought in, then they can make some of those changes as well. But part of it then does still come down to the people in the team. And that is often the thing that is. Most challenging to, to change, but, but even, even people I think are, are changeable. And I think sometimes characteristics that we assume are just this person actually are the context in which we put them as an organization or habits that they’d learned that with the right environment can be unlearned 

[00:38:27]
Michaela: or teamed up that makes maybe right or one person creates or reacts, but only two, right. Person, but to really the whole team dynamics. Are you are you a fan of like bonding sessions and you know, we’re people, what a team really can, you know, get to know each other, do you think that’s 

[00:38:45] Holly: I really like them, but I think they, they need to be done sensitively because they do end up sometimes not being very inclusive if we. If, if we choose something that half the team love, and then some people are sort of stood there going, well, this isn’t really what I wanted. So I think there sort of needs to be some, some pre-thought to, well, there’s everybody in the team going to like going out to a noisy bar or. Does that actually not work. And I’ve seen I’ve had some good conversations with people actually, when I talk about fun, because sometimes we get these sort of bonding sessions that get put into a team and we say, right, we’re going to have fun. Now we’re going to, you know, do our bonding and we’re going to go out to a bar and some people are going to know this, this isn’t fun for me at all. But then there can be alternative. So some teams, for example, they’ll play a board game at lunch. And so it means that people who need to rush home after school, you know, are after work to get kids from school or that kind of thing. You know, they’re, they’re included and people who don’t drink are included and it’s in sort of at work. So then it feels like an extra nice treat. It doesn’t feel like you’re sort of being required as part of your job to go out and do things out of hours, which some people really object to. And so then, you know, and there’s other things like, like that, or. This is a really old example because w w one of the other things that happened when I started talking about fun is lots of people told me about their workplaces and that the terrible unfun things that had happened. And there was a team and they were sort of there were a support organization, so they would work quite long hours and shifts. And it was a distributed team. So what they would do is AF after five 30, they would all play quake or doom or something like that together. And it was sort of back in the day when broadband at home was a luxury. So you would take advantage of your office network and they were, you know, they were, it was completely you know, a bonding thing. And they were told by management, if you’re in the office after five 30, you have to be doing work, which I just thought was. Incredibly short-sighted on the, on the part of the, that management to say, you know, your, your people are not on your time making the effort to get to know each other better and to work better as a team. And not only have you not, you know, encouraged this and, you know, put in money for cakes or something, you’ve actually told them they’re not allowed to do it. Yeah. Yeah. That’s very, 

[00:41:08]
Michaela: very shortsighted. Yeah. Terrible mistake. But sometimes I really like for management, sometimes I really ask myself. How can you make this decision, but you know, different story. Okay. Well, Holly I know we are on time, so thank you so much. I could have, you know, like talked with you another hour, but thank you so much that I could pick your brain about everything, about all your experience and you know, your knowledge that you have. Yeah. It was really wonderful that you have been on my show. Is there something that you want to share with my listeners? Did you think it’s important for them maybe around culture, happiness, fun productivity, maybe a little thing that they can start doing today? 

[00:41:49] Holly: I mean, I th I think, yeah, just to sort of think about those, those, those aspects of fun and, and think about how can I have more fun at work? How can I bring more joy, joy, and delight at work, but also how can I make. Those around me are also having more, more joy into life at work because otherwise it becomes a bit one-sided. Yeah, I 

[00:42:09]
Michaela: think in general, after Corona, I call it now after COVID right. I just say after, because it’s just nicer to say that I think we really have to come back to thinking more about others. I think we haven’t been thinking. Enough about others before, but I think, I don’t know how it’s in, in, you know, in the UK, but it, at least here, I feel people are more distance because of it. Right. And I really think we should think more about each other and you know, what brings us joy? How can we help others? How can we be nice to others? Right. Yeah. And I think this can bring joy again to yourself, right? If you maybe should think about how can I make the day, a little bit better for my colleague today? Or help somebody? I think this can be a cycle of positivity. I dunno. Like, yeah. 

[00:43:00] Holly: Yeah, absolutely. I think we realized one of the things that we realized with, with COVID is how, how much we need others and how it’s, you know, it’s not much fun without others. Yeah. Yeah, 

[00:43:12]
Michaela: exactly. I think so, too. So I hope you all can come back together and then really be nice to each other and care for each other. Yeah. Okay. So Holly, thank you so much for being on my show. Have a wonderful. In them. Yeah. I hope I talk to you soon again. 

[00:43:29] Holly: Yeah. Thank you so much. It was, it was great fun. 

[00:43:32]  Michaela:  Yeah. It was really fun.

Better collaboration & performance through diversity and inclusion

In this episode, I talk to Trier Bryant and Kim Scott who co-founded the company Just Work which helps organizations and individuals create more equitable workplaces.

Trier Bryant is a strategic executive leader with distinctive Tech, Wall Street, and military experience spanning over 15 years and the CEO of Just Work. She’s previously worked at Astra, Twitter, Goldman Sachs, and led engineering teams in the United States Air Force, where she already also drove diversity, equity, and inclusion (DEI) initiatives.

Kim Scott is the author of both successful books: Just Work and Radical Candor. Kim was a CEO coach at Dropbox, Qualtrics, Twitter, and other tech companies. She was a member of the faculty at Apple University and before that led AdSense, YouTube, and DoubleClick teams at Google. 

We talk about:

  • how they both landed in tech
  • their diverse and exciting background
  • how to counter bias, prejudice and bullying in the workplace
  • the framework for diversity and inclusion they developed
  • and how engineering teams can be more inclusive.

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: 

[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.]

 

Falling in love with the JavaScript community

In this episode, I talk to Tracy Lee. Tracy is the CEO and co-founder of This Dot Labs, a widely successful dev shop. She is also a speaker, conference organizer, and blogger.

We talk about:

  • how she dared to start her first start-up as soon as right out of college,
  • how she learned to program and fall in love with JavaScript and the community,
  • how she founded a successful development shop,
  • her advice in terms of a marketing-driven versus product-driven startup launch.
Continue reading

Bootstrapping Netlify to a multi-million-dollar company

In this episode, I talk to Matt Biilmann. Matt Matt is the CEO and co-founder of Netlify – the modern platform for high-performance websites and apps. Netlify has around 150 employees and an estimate of over 20 million dollar of annual revenue. Matt also coined the term Jamstack, which stands for JavaScript, APIs, and Markup. 

We talk about:

  • his journey bootstrapping Netlify to a million-dollar company
  • how he got the vision for the JAM-stack,
  • how it feels to grow a company from a two-person adventure to over 150 employees,
  • how he envisions the collaborative software development of the future,
  • and the acquisition of  FeaturePeek.

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: 

[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. McKayla, and today I have the pleasure to talk to Matt Billman.

But before I start, I want to tell you more about CodeSubmit – the best takehome assignment platform to streamline your tech recruiting! Yes, exactly, this amazing start-up is back sponsoring the podcast. And over the last months, they introduced a lot of exciting new features such as live coding – within a full working IDE running directly in your browser. Beginning of the year, when I was hiring engineers for a startup I work with, I used their tool during the interview process for all the candidates and was extremely satisfied. CodeSubmit made it really easy to create custom tasks that reflect the actual work candidates would be assigned to on the job. Their missing: real tasks, not brainteasers, resonance a lot with me. So, I cannot recommend CodeSubmit enough. Please check them out at CodeSubmit.io. That is Codesubmit.io.

But now, back to Matt. Matt is the CEO and co-founder of Netlify, the modern platform for high-performance websites and apps that defy has around 150 employees. But that’s not all: Matt also coined the term JAMstack, which stands for JavaScript, API APIs and markup. Today, JAMstack is even more. It stands for collection of technologies and languages, including web oriented databases, frameworks, like Nuxt and NextJS, and even framework less approaches. So I’m super, super thrilled to have Matt here with me today to talk about his experience founding and running Netlify and also JAMstack and
software engineering practices at Netlify fly. So yeah, I’m super thriller that you’re here. Thank you so much for joining us.

Matt: [00:00:57] Thank you for having me. Yeah,

Michaela: [00:01:00] really, really excited. So how is that? I looked a little bit like a research you obviously a little bit. And so I started it’s around, you know, seven, eight years ago that you, you for aided or you found that and Netlify how, how was that? Is that. Or you have an idea and you do it, or what was the process like?

Matt: [00:01:23] It was a long, it was a long process that, that, that started way before Netlify itself. So. I I’m originally from Denmark, but spent seven years living in, in Spain, in Madrid, where I worked a CTO for a company that built websites for small to medium businesses, but at a very large scale. So we would build something like a hundred websites a week, tens of thousands of sites in total. Right. And in. And I let the whole product and engineering or built the platform that all the designers would do the design with it, all the clients with useful content management that, that powered every single website from brief to production in. And then, then I actually started a CMS startup in, in Madrid together with the founders of that Spanish. Is that up because we had just tried building sort of several iterations of this. Develop a platform in-house and we thought, okay, we can build a cloud hosted multi-tenant version that, that other agencies and other professionals can, can use to get a lot of the same efficiencies when they are building websites for their clients. Anyway, that was sort of the first take on, like, how do you really remove all of that? The friction for web developers in, building deploying operators. With properties, but, but it was built as Hess as a traditional, like monolithic application. Multitenancy Amisu with database and template engine and all of that. And I came to the, to the bay area and the whole tech scene here, working on that. But while working on that, I started getting this sense. But even if it, if it was a product that was, I was very proud of building. It had a lot of like early innovations in it that had serverless functions before. That was the thing you could write, like service side Java script to running in, in this case, within the JVM in isolates and so on. But I got the sense that the fundamental architecture of this. This monolithic approach where data business, logic template language, front end code is all closely tied to gala was just not going to be long-term the real, like the few charts I could take chunks the way. Yeah. I was looking at lot at, at, in, at what was happening in the, in, in, in two different areas. One was like the space of static site generators. Jake hill and middleman were at the time in the other ones, the whole no JSPs ecosystem and Beaufort was having what was happening there in terms of the early built tools and task runners like grunt and gulp, but also. The first sort of real full race into the, in, into the whole world of single page application with originality tools like sprout Cole or Andy and Leyda in birth in angular react to all of that. Right. And I got this sense that. Pretty soon as browsers really started maturing, it would make much more sense to have an architecture where you try to decouple the front end web UI layer completely from the backend business logic, Leah, and the best back in business logic layer would likely Kelly split into all these different API APIs and services where someone to them, of course I, your own in Europe. But a lot of them are other people’s services, like Stripe oil, goldeo Twilio, and the like, and I also saw that if, if you could do that, you could sort of map that whole web UI there. You could map the workflow around that pretty tightly into the get centric workflow that developers were already working on, where in pull request and merchants and so on. Right? Like it was much more straightforward to. Map that whole process on twist StatePlus, UI Leah, then mapping it onto both the UI layer and the whole business logic data layer that tends to require all these kind of migrations and the settings and so on. So I got, I got the sense that that architectural approach would win out, but I could also see that there was just too many too, too much friction. Standing in front of developers that wanted to go that direction and then actually building, deploying and operating with properties like that. So I built a small in VP of like, what’s the smallest thing I can build that that’s sort of. Aims at edit dressing the workflow for those kinds of web developers. And the first MVP was this was a small service called bit balloon, where in the very first version, you could drag a folder with your friend dot com and it would immediately go live on a, on a, on a URL. And then I edited some CLI tooling and some in API tooling around that. And, and quickly saw that it, that it resonated with the right kind of early adopters in the front end space and, and got very validated in the idea that this architectural shift was going to happen. So at that point, I started to talking to one of my best friends back from Denmark, who Chris was my was my co-founder today. Him. He. We we’ve known each other all the way back from, from high school, which is sadly a long, long time ago by now. But while I, I spent seven years in Spain, he had built his own production company back in Denmark is specializing in like in very interactive, often video power websites typically built in flash for some of the largest brands in the world. They won a bunch of international awards for its work there. And then sold that to a full ed foot, to a full service agency where he became the partner and the chief digital officer. And I started talking a lot to him about this architectural shift and what it would mean if you could sort of pre compile the whole UI and put it on a globally distributed network. And then just talk to these different APS and services. How we could really fundamentally solve a lot of the problems around global performance, around scalability, around reliability, around security, in an, and even in the process, potentially really address to develop a practice city. And all of these areas were where areas that, that. Like he, he knew from, from operating across like web properties from, from tons of different companies and running digital strategy for the sort of Walmarts of Scandinavia and the, like how, how big these problems were and how enhanced they were. Like how, how much worse the problems got as, as, as we also started having more and more people using mobile devices for the web and, and expecting a different kind of, of both pace and use experience. But we could also just see again, how much friction there was. If a team wanted to adopt this architecture, suddenly they had to stitch together like CIC CD with object storage, with CDNs. They had to figure out cash perching rules and it’s caching. They had to figure out how to connect to all these different API APIs and services, and typically had to pick out triggering, rebuild swings. Content that data changed and so on. And there was just no viable tool chain for saying like, okay, we’re going to do this. What do we do it with? So that became the core idea. We, we, we sat down and discussed and came up with from fo for Netlify and still the mission we’re we’re still working on, right? Like how can we create a. At cloud platform for the collaborative work, where teams can really operate efficiently, where we can remove all the friction involved in going from pull requests to live code running in, in, in front of a real uses in. And yeah, we, we, we started out just bootstrapping the two of us. Build on top of the, of the product I had already built and turned it into Netlify launched on air show. Heck a news post the in, in March, 2015. In, and by the end of 2015, we were still just two people bootstrapping a company, but we are serving around a quarter billion web requests a month out of our homegrown CDN for customers. Like we work in Sequoia capital and the Molalla foundation and, and was realizing at that point that, okay, now, now we need to raise capital, build a whole team around this and, and really accelerate. Hmm. Ray cell first round of venture capital in the start of 2016 and hired the first engineers in March, 2016. And then, and then it, of course, it’s been a really fast paced growth since then by now we’ve raised about $107 million. From top tier find slack, Andreessen and Kleiner Perkins, Menlo ventures, EQT M we have for you onboarded more than 1.5 million developers onto our platform and, and, and sites are now like just, just the sites and web apps on our platform are reaching the close to 700 million unique visitors every month. It so. So, yeah, it’s, it’s been quite the ride so far. Yeah. Mine’s lowing.

Michaela: [00:11:26] Wow. Yeah. It’s mind blowing. Yeah. And so for me, You were really very, very involved with the technology. And you had like this vision where it’s going to go and it also went there. Right. So it was spot on. Do you feel like that you’re still very connected to that? Like, do you still feel like that you’re so connected to technology or are you now more involved in, you know, you have to see overall. I am now a little bit more away from this technology side. And how is that for you? You, for me now, how you explained it and how much passion I could really see that. Right. I can imagine that you have also like this passion for the role that you have right now. So you’re probably extremely. Business oriented and you know, all these funds and you know, like where to raise money and how to acquire a company and all of that. Are you still very technical? Do you feel like you’re as technical as you have been before?

Matt: [00:12:24] I I’m obviously not as involved in building Nipsey five from writing code perspective at Southwest, right? Like the first version of I built a CDN from there, from the ground up and the CSTD platform and the react UI that powered it and everything. Right. Like, and now I typically don’t like by my working space, now it doesn’t involve writing code file product eight. Like. But in a curious thing about my background is that that while I’ve been programming as a hobby, since I was 10 years old, I studied the musicology and cultural studies in and was always more interested in how humans adopt ideas and make sense of the world and understand things. So, so I think some people are, need to feel very hands-on with the coach to feel that they are doing something. I, I, I get a lot of joy also out of building the culture and the organization and the, and the engine that can build things without me. Right. And trying to understand both how, when we talk about something like the gem stake emerging, for example, and the shifts in technology. There’s always a mixture happening of like the actual sets of technologies involved and, and the specific program languages and API APIs and infrastructure evolutions that we’re seeing. But in the end, technology is adopted by humans, learning about things and building things, right. And you can understand where technology is going, what will happen in an ecosystem? If you don’t understand how humans adopt technology and why developers built with certain technologies at certain points in time and why you’ll sometimes see technologies that are technically better loose out in the marketplace because their adoption path is harder. Right? So for me, it I’ve always been a very curious person and, and, and, and like to understand. Both sides of that spectrum, both the lower details of, of how does technology, like how does that technology work behind the scenes, but also the details of like, how does human beings approach it and understand it and build with it. And of course, as I been building this company and it’s, I am building it right. The layer of where I operate them, we’ll have to keep shifting. Right? Like in the beginning I had to be the one who just sat down and wrote the code. And then I had to be part of a team that wrote the code. And then I had to be more warfare at it, take lead for that team and guide them in the right direction. And so. And now I have to build the right kind of organization and the right kind of organizational structure to allow our company to build the kind of product that. That we think we need to build. And that’s that, that in some cases also requires finding the right partners to build it with in terms of fee investors or, or ecosystem partners in, or finding the right people to join our team and, and help build it.

Michaela: [00:16:01] So, this is really, really super interesting. Is it, is it for you all about the people or is it also about the structures and how people are working together? Do you see it as a system? Or, you know, like, or is it self forming, like is a company self forming or do you give it some structure?

Matt: [00:16:20] No. No, we, you, I believe in, in trying to, to, to. Bring some structure along the way. I think both me and Chris have always fought that did that, that intentionally building structure and organization is really, it’s really important for building a company that can, that, that can scale to, to become a really large company. Right. Like I think. If you, if you try to ignore the structure, you, you will hit a point where, where everything’s that’s is that’s falling apart. And it’s very easy to hit points along the way that feels like that’s happening. Of course, you’re always a bit riding on a rocket that’s slightly out of control. Right. But I think culture and structure and And value is a really important for how a company functions. And then of course, like you can never replace the, like, it’s in the end, it comes down to actual people doing stuff. Right. But the structure is important and it’s important to be intentional about it. I think we’ve seen some companies that tries to build completely like say they built completely flat structures with. In any kind of structure to it. And that, that just means that as a leader, you’re not taking any intentional decisions and route the structure, because your team is still going to have people that have more offices than other people. And they’re still going to have, it’s just going to happen by politics and, and, and sort of maneuvering rather than by any intentional process of like how strict the structure. Do you see

Michaela: [00:17:51] like a parallel between like I texture, like software, I attacked her and technical debt and structures of companies. Like where you say, well, we try to build the best system with the information that we have right now. Obviously also looking into the future, but then, you know, things evolve, things change. So we actually have to go back and change the architecture or change, reverse some decisions, you know? Remove some technical debt. Do you see the same happens in company in your company structure? Or do you feel like, oh, this is for what we have foreseen, but now we actually have to restructure and re refined or redefine ourselves.

Matt: [00:18:31] Yeah. You absolutely see that happening. And of course it could be a useful metaphor too, to compare like your company through to the machine, building the thing and, and, and think of it as an architecture and that point. Just also have to remember that Indian, the pieces of the machine. So not lines of codes that, that are predictable. They are people with goals and dreams and carry ambitions and interpersonal. Characteristics in. So you have to be aware of both, both sides of it.

Michaela: [00:19:07] So you’re what you’re saying is that technical debt is sort of peanuts, right?

Matt: [00:19:12] Complicated. I just, it to deal with, with, with technology. It’s a lot more predictable Indians than people are, but it, yeah, in the same way, it can also be a lot more fun. To deal with, with human beings. Yeah, obviously.

Michaela: [00:19:30] Yeah. Yeah. I’m, I’m super impressed. Like I can’t imagine how much personal growth has to happen on a way from, you know, like bootstrapping something, then getting investors, you know, scaling probably if you get investors, you normally scale really fast really quickly. And yeah. So th that’s.

Matt: [00:19:53] Yeah. And it’s also, I mean, it’s also a choice you take when you go and raise venture capital that, that raising venture capital is only one way of building a business, right? Like the many other approaches to build a business. In, in our case, we felt that there was also the kind of market opportunity, right. Because we really, from the get go belief. That there was a real opportunity to shape how the future of the web is, is going to be built and how it’s going to function. But we could also see that, that making that big of an impact and getting there in time. And so. There was not something we could, we could have done if we had grown just organically based on our revenue. Right? Like, so that’s, that’s why we, we went out and, and, and raised funds to be able to, to scale and grow much faster than we would be able to do organically. Right. And that, of course always didn’t happen. Half the trade-off of like all the older challenges you get when you are trying to scale an organization very fast. And it has like, you have to know what you’re going into as a founder also, right? Like, as you say, of course, it’s a, it’s a learning curve and you have to be very okay with continuously taking things that, that you saw as quarter your role, like writing the code, building the technology. And then have other people come in and do them instead of you and step away from it. Right. But if you do that, you’ll also learn very quickly along the way. The more like that, no matter how much of your job you seem to delegate it at way, you only get more busy somehow.

Michaela: [00:21:39] Yeah. So one thing that that would really interest in me is like you said, you wrote this little first version MVP of, of Netlify and. A lot of people adopted it. So it seems like you didn’t really have to convince people about this solution or that there is a problem because sometimes like founders it’s, it’s hard. Right. You think like, oh, I have this idea. And then is it too early? Do I have to convince people to have to explain it better? Do you have like to, do you think that this is, this is the right mindset or should people step away from something like where we have. Tweak one sentence to be really powerful and express like the pitch. Right. Is that really too important? Or should we read our focus, our energy on finding the thing that people actually want? Even if you write a sloppy sentence about it, you know what I mean?

Matt: [00:22:34] Yeah. I think, I think it it’s never completely one or the Euler in, I think. You have to in like initially for example, the mental model we had around adoption was that for these kinds of technology products, if you’re trying to build something that’s in that the future of how things will be built, you would expect it to sort of grow in concentric circles where you sort of have these very early adopter technologies that are constantly. Joking too, to broaden their horizon, then find new things that work and so on. Right. And, and, and you want this kind of product to resonate with them first, right? Like in the initial stages of this product, you wouldn’t expect someone who was like aids. Are they working in a law long enterprise company? Very focused on solving. Big picture of business problems, insight that for which assisting technologies to even be interested in your product, right? Like it’s just not time, but you would expect like for a product like ours and, and early adopter of JavaScript frameworks or, or site generators to, to get interested in. And then ideally like there’s, there’s two is essentially two different paths to building. Product companies, right? Like one of them is product led growth and the other is sales or marketing led growth. And not, there’s not like one way is the right way for some products. If you have a product that requires in a whole organization to adopted horizontally before it really adds value. Right. Build a product lead motion around that. You have to go build a sales lit motion where you first go and talk to executives and companies and pick out the needs and then solve their needs with a product. But if you have a product that can both be really useful to an individual engineer, into a small teams with engineer to a larger team of engineers into a whole organization, then you have the opportunity of building like a product led growth moment. Motion. Where, the way you get into businesses is by individual users first adopting the product, and then, then it spreads from there. Right? And we saw the opportunity to build that kind of company. And when you built that, then it can’t be like the cost sale doesn’t depend that much. At first, unlike nailing there, the phrase on your marketing site or something like that, it comes on nailing the onboarding experience for how fast. Can you get someone to land on your website and then be inside the product, doing something where they having a hard moment of why? Like, why is this product going to be useful to us? And for us, there was really about like landing on netlify.com and then having a web property running on a custom domain in a shorter time as possible. Right? Like that was sort of the first iteration of, of, of that hard moment. And then knowing that maybe in, in, in 30 seconds, so minutes or something, right. You had gone from nothing to having a globally distributed website, running on a custom domain with a CSED pipeline plug directly into get right. If we could just make that motion, like something you could do in, in, in 30 seconds or minutes at something like. Then then we would drive that, that, that feeling of like, wow, this is, this is another generation of tooling. This, this is, this is just so different from how the world looked before and, and, and then build excitement with developers. But then in parallel with that, we will also positioning ourselves Hindu in, in the midst of like an architectural change of how are we going to build the web in the future. And at the time when we started, there was just a lot of difference. Technologies that was making that happen. There was, as I mentioned, static site generators that were single page applications. There was a lot of talk of the API economy, some talk around like the programmable weapons, but there was no name for this architecture. And that was something that, that, that, that Chris Sue, my co-founder immediately saw from his background. Like we need, if this is going to have him, we need a name for this category and this architecture, because otherwise, again, all of this happens because humans adopt the technology and humans goes in the direction and, and. If you can’t give people the vocabulary to talk about what they’re doing, it becomes very hard for that idea to spread between groups and teams and people. Right? So that’s why we ended up coining the term game stack. And it happened sort of in a very collaborative process with different people in the, in the industry. And so on in an and the term started taking off because it was needed, right. Because it gave me. And nomenclature to start talking about things that before were seen as just separate movements, right? Like, okay. This, something happening about the architecture we use for cell phones, talking to API APIs, there’s something happening or how this whole world of web API is exploding. There’s something happening around single page applications and something else happening around CDNs and site generators and stuff. And suddenly we had a nomenclature to say, oh, it’s an architectural shift. It’s a shift to watch the games deck. And that, that was really important to, to, to build the other part of like on the one hand, the individual product story and the developer story of like finding this product and instantly getting into ha moment and then connect them. To a broader story around like a new architecture for the web emerging and, and the possibilities that that would entail and how not just individual developers, but large organizations could benefit from that change. So both sides are important, but in the end, if you’re building a product led growth company, you have to be really obsessed is obsessive about the product itself and how. That product that attracts Andy and convinces juices to, to, to work with it.

Michaela: [00:29:17] Yeah. The funny thing is that when you described the story off, you know, how a developer, you know, sees your side and tries it out. This is exactly how I felt when I tried it out. I was not an early adopter dough. Right. I try it out somewhere last year, but. It wasn’t exactly like this. I was like, oh, I have to reply this website. And I want to do it quick. And you know, like, let’s, let’s try that out. Right. Everybody is already on it. I’m like the late, late person too late for everything, but I went to it. Right. And obviously at that point it was fully baked fully in, but, you know, I was there and was like, wow. Well, it’s running, right? Like I was like, and as you said, right, this, like you push and then it’s there. I exactly felt what you were saying, but it was like last year. How was Natalie fly when you say, well, let’s go five years back. How was the experience? Was it similar? Like at that point, would you say.

Matt: [00:30:18] Yeah. So, so the expense involved in, and it will continue to evolve it as, as we also go for, broadening the experience and, and telling it different, like as a large and larger story through the product. Right. So the very first story you would see was, was, was in bit balloon the predecessor to Netlify. Land on a website that just immediately on the front page, head like a drop soon in saying drag your web folder here. And there would also be a little download link where if you didn’t have a website handy, you could download one and drop it there. Right. And then you could just drop aside onto bit ballooned at com without even signing up or anything. And it, you didn’t need to sip the files first, anything you just drag the actual folder onto a bit, little.com and boom. Now you would be live. We still have that done. If you go to app.netlify.com/drop, you’ll get the same kind of experience that mimics, like what, what the very first version was like, of course, in the signed by me and not by actual designers. Like it looks like today. So that was like the first simplest motion we could do right in. And then the next step was really to, to start, like after we had, after I had built out that initial version of just getting a site live and, and, and getting a custom domain connected to it, getting SSL set up and so on, then, then it was really the question of okay. This is fine. If you’re really just one developer by yourself, manually deploying, and we added a CLI where you could do the same from like writing it at for spit and native later, just Netlify deploy and immediately from the command line, deploy fault. That’s fine. If you’re really just one individual working, as soon as you’re at team of people, that’s not very useful. Like you, you can’t just random. You have people deployed manually at different time without structure and people get their structure from, from GitHub or GitLab or bit bucket. That’s where developers collaborate on opening new pull requests and building new features. So. The next iteration of that on Netlify was really saying, instead of focusing on you deploying manually from a folder that solves the whole problem of you working in a good provider and getting that live. So the next moment really became that flow of like calming. Tell us you’ll get repository and we’ll try to even guess what tool you have a framework you’re using. And just say, okay, and now you’re done, right? Like now you have something you live in. And, and now of course, with, without acquisition of a feature peak and that whole journey, we are going even deeper into that space of like, this is not just for single developer building. On their own, like real projects, always built by teams with lots of different stakeholders and with several developers and one part of the processes it’s writing the code. But another part of that whole process is that for every release, you have some feedback cycle where you have back and forth with product managers or designers or other developers or other stakeholders. Before you take something live and now we’re really sort of expanding that whole experience to drink fluid, that process and to sure how, how frictionless we can, we can make. The process of a team actually building releases together and taking them to the world.

Michaela: [00:34:21] So with, with this acquisition, somehow you have like this deploy previews feature. Yeah. You know, my, my favorite thing are code reviews. Is that something that you think is part of the programming part or is it part of deploy? Is it, is it part of something that should be, should code reviews be somewhere in that picture or how do you see it?

Matt: [00:34:45] I mean, code code reviews are really important, but then there’s also the, the step ahead that’s like viewing their outcome of, of, of your current code. Right? Like being able to just open a pull request and having that pull request running in the full production environment. Exactly. As it would look like if you were. That’s that’s really like, it doesn’t replace the code review. Right? Like the developers should still work on the code review tools to make sure that the quality of the code behind that it’s up to scratch and so on. Right. But it does make the, the review, especially from. It QA testers, product managers to designers and marketeers to content editors or anyone else that’s involved that will want to review what the output looks like. Hmm. It makes that process in much simpler. Right. And what we were seeing, like w w like we launched deploy previews in 2016, a long time ago, and we’ve of course been very big consumers of that whole workflow internally, ever since then. netlify.com runs. And Netlify Natalie find that conference and identify all of our web properties up easily run on Netlify. And in that process of deployment, Completely essential to how our web teams work. We’re constantly sharing URLs and so on. But the one thing we saw also when talking to clients and so on, was that when you share that URL, then. The feedback cycle spec to the developers that happens all over the place. Some of it happens you’re shared in slack and there’s feedback in slack and more people open issues and get up or in JIRA, or they will piece two screenshots into documents and sent them back and forward for, at the mess attachments. And, and for developers like the, the process. The process of, of that is as fragmented as the process of code reviews was before tools like get help and get lab integrated into the workflow. Right? Like before that happened, like there was no. You, you would sometimes have specific tools for code review, but mostly it would be processes of sending back and forth emails around the code, or simply just having to sit down at a laptop together or at, at this top bank at the time, and look at the code and talk through it. Right. And get up with the pull request. Functionality really gave her home. For court reviews, right? Like in the game of place where, where now you no longer have to wonder, like where is it happening? And people commenting in all kinds of places and so on. Right. So what we’re trying to do with collaborative deploy previews is in a similar way to give it a form for the, feedback, not on the, on the input, which is the code, but on the output, which is the reason. And make sure also that since every deployed review, it’s a different URL. We don’t, we didn’t want to have a system where every deploy preview now has its own. Like you have to know it exists and go there and look at the feedback in order to take part in that process. Because like we had some initial prototypes integrating with tools like that, and it just attracted from the process because now. Apart from checking the pull request to end a slack messages and the emails also I had to continuously try to figure out is people, are people now also commenting on the deployed from you? Yeah. So it’s really important to make each deploy from URL. Okay. At checkpoint that that makes information flow into the original places. So feedback that stakeholders make on the deployment of the will, will flow back into the poll requests. They’ll take part in the comments there, or they can open tickets in whatever project tracking software you’re using related to get Harper linear clubhouse for the like, and now it’s really important for us. Right. But again, it was this sense of like, Now when a developer, she is that deployed preview URL, the Isles are sharing how to give feedback and how that whole process operates. And we hope that can really, as I said, do do for this process, what, what pull requests themselves fit for them? For the code review process

Michaela: [00:39:23] feature peak, which basically is part of what you’re just describing right. Of the functionality that you’re describing. As I understand it. Is it a company that you acquired? So I would like to understand the process around that a little bit. So you have this vision, obviously you seem very vision driven, right? So you have this vision and then you see that there is no place for that. But how does that work? Like, and then you find a company or, you know, like it, because you’re, you’re obviously. Yeah. Having your eyes out on the space and under companies, and then you see a company that works in that space and you think, oh, they’re going to the right direction. And then you contact them. Or how does that, like how, how can it be such a good match and why not do that? In-house and you know, like how does this whole process wig? And what’s your, what’s your mental model behind it?

Matt: [00:40:12] Yeah, let me, let me tell them, so let me take a step first bank and just to the listeners shit like yesterday, we announced a big feature for us called collaborative deploy previews that allow other stakeholders to give feedback in the process of, of, of reusing and going from pull requests to release. And behind that feature launch was an acquisition of. Affair venture funded company called feature peak that was backed by Y Combinator and matrix venture in that joint Netlify and integrated that product into the core of our product. And the whole, the whole process started in a way back into, in our all hands meeting at the very start of 2020, where in memory. So was a UX researcher on, on, on our team. Yeah. Brought up the, it like brought up the initial idea that take it. It would really add so much value to the other stakeholders. If there was a way of bringing feedback and commenting to to deploy previews. And based on that, we started at first in prototyping with a couple of different tools that already existed in the space for. Full commenting and annotating on websites. So we integrated one of those tools through it, built, pluck in and started testing it out internally. And we learned there that if the commenting was something external to the current process, our developers cut more frustrated than helped by it. Like they quickly felt like, okay, now, now I’m just getting. At pod from all the meals and slack messages in this year’s I get, I’m also now getting comments in a different place. Right. So after testing that for a while, we found out that, okay, that’s that’s not going to be the right approach. It’s the right idea. It’s the right problem with tackling, but it’s not the right solution in. So we think it, that, that we would have to do something that tied into the process that developers will already working in. And that tied into the pull request process. And we did start in building our own. We built first, a quick prototype that I went to celebrate experienced team built in. To be able to take that to our user researcher and then put it in front of a bunch of our clients talk through like, what would this do for their workflow? What are they currently doing for their workflow? And started all to really understanding like the set of tools that, that our customers were working with and how they were already solving this problem. Because obviously like, It’s not like this is something that everybody already doing in some way. No, no one are building software just by having developers write the code and then launch it. Right? Like there’s always a process of write the code, show the output, talk through it, do testing, validate the result, give feedback, iterate on it. And then you launch it. Right. But often that process is just a lot of screenshots and PowerPoints and emails and slack messages and stuff. And we could see that, that, that if we could make that flow back into the poll requests, that would help. But it wouldn’t be enough. Like when we tried just that with our first prototype, we saw like just full requests, comments. It’s not enough. Like people are also using is your track or some project management software. And we had to figure out how can we integrate into those pieces as well? So this was a long process and we built several internal prototypes and did some. Kicked off some real development. And in the process we kept looking at, in any, any company, they was trying to take a listen to the market. The end, the one of them that started to really stand out was, was west feature peak. So we reached out to them and, and asked to meet. And they came to us and, and had at the time actually started working on it on a nearly fight integration through our built plugins layer and. Yeah. I was in Nicole together with a, with, Jessica, one of product managers with the two founders of feature peak. They gave us a demo of, of what they had been working on in the integration. And as the demo progressed, I would say like our jobs got closer and closer to the, to the flow of because yeah, it, was really far ahead of anything else within this space. And more than that, It, it was as if they had been reading all of our use of research, like building exactly the kind of product that, that I wanted to build in that we were dreaming about. Right. So we very quickly figured out that, that, between us and, and the, and the Fiji peak founders, we really shed a vision of like, what can you do in this space? And what can you build in? They had already built a product that, gets a lot of things. But we could also like, just, just talking through food, future potential. We could see that we were so aligned in like, what could this turn into? And as we started to talk more, it was also pretty obvious that they could build a great integration on top of Netlify and here’s how our integration layer for that. But it would still just be an add-on. It would still just feel. Like something you could add and that would be bolted on, right. It would have its own like separate sort of dashboard and lock in. And the integrations would be only on there and not on our end and so on. That would not really be a good way to integrate the whole feedback cycle as a first-class citizen throughout our whole product journey. It would be feeling like it just, to pluck in just an add on, right. And we felt. Between all of us that if we really wanted to do this, integration had to be much deeper. It heads to be much tighter. And we would only really be able to do that if we were one company. So then we started talking about what if we joined forces? What if we, what if we built something together, then build something in, in two different silos ended and ended up agreeing that, that that was the right way to go.

Michaela: [00:46:35] And so now, You acquired them this week. And are you going to develop something now or is it already developed or, you know, like how does that person?

Matt: [00:46:46] So, , we did the acquisition in about three months echo and behind the scenes that their whole team and our team have been. Working really hard on, on, on integrating their technology really deeply into Netlify. So Netflix too. So yesterday we didn’t just announce the acquisition. We also announced the full product launch with with all of these collaborative features now available to all Netlify users from Friday.

Michaela: [00:47:19] Yeah, very cool. So you took the D the code base that they had, and then it w it’s not a complete rewrite, it’s just that you blacked in what they had, you know, got rid of some, you know, functionality because it was a plugin first and now it’s, you know, it’s part of Natalie fly. So you, part of the code base and integrate the data. How does

Matt: [00:47:40] that. The team that has like they both whom re rewrote parts of their code base to integrate it into our code base directly for, for the whole coy API functionality. I think our team together with their team built the. Three new microservices to power, like identity for cross integrations, for uploads and so on in. And and they updated the whole UI to be in line with how we built Netlify UI and to feel integrated into, into that process. Eh, But if, but I have to say an incredible job from, the whole team, executing that in just three months in and taking it to them.

Michaela: [00:48:29] Yeah, I can imagine. Yeah. Yeah. Well, it did. So I have 1000 more questions, but we are on time. So I will just, I would just say thank you so much for sharing everything with me and Medalla, you know, with the listeners and with, with, with us, it’s like, yeah. As I said, I just have so many more questions. I could talk for hours, but you maybe I’m inviting you again. Maybe you have time to spend a little bit more talking with me about all of those things. Yeah. Can you have more questions, but yeah, it’s, it’s, I’m really impressed. It’s a, it sounds really fascinating and really cool. Is there something from your side that you want to share, like with my listeners that you want to give them on the way I will obviously link everything in the show notes, but is there something that you want, especially for people that are, you know, like love technology, software engineering, and also maybe want to become founders or, you know, do their own thing.

Matt: [00:49:28] In. Yeah. I mean the first thing I would say, if you think all of this sound sounds, sound interesting and, and you would like to read the part of it. We are very actively hiring. So check out our careers page and if you don’t find anyone, anything there. Think you could be a great part, then we always have at your dream job position that you can write in for in. So that would be the first part. And do the other part, I would say is that it S this whole sheet. From big monolithic applications having to to, to modern architecture with it, decoupled front end and all these different APIs and services. There’s also a lot of opportunity for founders to, to build new, interesting, newer, interesting pieces that, that fits into that developer workflow. And I’m always happy to. To, to, to spend time with founders in that space that are building something new or interesting. So it feel free to reach out or Twitter or email or the like,

Michaela: [00:50:36] wow. That sounds really nice. Cool. Thank you so much, Matt. For, for being on my show. It was really a pleasure.

Matt: [00:50:43] Thank you for having me. Bye.

 

 

Responsibilities of a Chief Data Officer

In this episode, I talk to Patrick Wagstrom. Patrick is the Chief Data Officer at Brightcove. Before that Patrick was the director of emerging technology at Verizon, meaning that he leveraged AI/ML, augmented reality, blockchain, IoT, quantum computing, and even 5G.  Before that, he was a senior director of data science at Capital One. Even before that, he was a “research nerd”(his own term) at IBM working on the Watson project.

We talk about:

  • his role and responsibilities as a chief data officer,
  • the difference between building systems that support machine learning and systems that don’t,
  • distributed software engineering,
  • data governance and GDPR,
  • and how to make sure your AI model is unbiased.

Book your awesomecodereview.com workshop!

Links:

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

Transcript:

 Coming soon…

Using Entrepreneurship 101 to Build a New Profitable Business

In this episode, I talk to Karls Hughes. Karl is a software engineer who turned into an entrepreneur in the midst of the pandemic last year. His start-up draft.dev creates content that reaches software engineers – which means he combined his two passions, development and content creation.

We talk about:

  • his transition from developer to CTO, and then to the business owner,
  • value-based pricing and how to focus on the customer segment that gets the most value out of your product,
  • how to scale as a bootstrapped business,
  •  why blogging is such a career changer for developers.

Book your awesomecodereview.com workshop!

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

The Secret To High-Quality Code with Dr. Michaela Greiler and Liran Haimovitch

In this episode, I talk to Liran Haimovitch, CTO of Rookout – an effortless debugging tool, about how to get to high-quality code.

We talk about:

  • what are the challenges of moving fast
  • what does productivity mean
  • a lot about code reviews
  • and I also give you a glimpse of the research I’m currently doing.

Book your awesomecodereview.com workshop!

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

Transcript:

[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: Hello and welcome to the software engineering unlocked podcast. I’m your host dr. Michaela and today I have a special episode for you. Two weeks ago I talked with Liran haimovitch,the CTO of Rookout – an effortless debugging tool. Our conversation was so much fun and somebody on Twitter asked me if I could make it an episode on, and i thought, that’s a brilliant idea. So, today I’m sharing my talk with Liran on the challenges and strategies for getting to high-quality software. Enjoy.

maror:[00:00:00] Um, hi everyone. And welcome to our webinar today on the secret to high quality code. We’re really excited to have you all here with us. Uh, so let me introduce you to Dr. McKayla and the stars of today’s webinar. Dr. McKayla has been helping software teams build high quality software in an efficient and effective way for 10 years. And her mission is to lead teams. So I’m up there full potential through company workshops and team coaching sessions. Leanne is the co-founder and CTO of workout, which is a live data collection and debugging platform. He’s an advocate of modern software methodologies like agile lean and DevOps, and his passion is to understand how software actually works. So when he’s not thinking of code, which is rarely usually diving, hiking, or writing a new workout blog. Um, and so before we get started, I just want to remind you all that we do have time for questions at the end of the webinar. So please don’t hesitate to leave questions in the question box and this will be recorded and we will be sending you the recording at the end. So. You’re on and McKayla, please take it away.

michaela: [00:01:02] Thank you so much for your really nice and kind introduction. I’m really excited to talk with Liren today about, um, high quality code and get his whole perspective on this topic and pick his brain. So yeah, I’m really thrilled to be here. It’s

liran:[00:01:19] great to be here with you discuss so many interesting topics.

michaela:[00:01:24] Yeah, really cool. So in, in the beginning we discussed a little bit, like what should this webinar be about? And we thought like, let’s come up with this idea that we are asking each other a little bit questions that, you know, are burning questions for ourselves or that we very often, you know, encounter. And, um, so I want to start with that theme and I want to ask you about. The challenge that you see, or the challenges that you see that, uh, engineering teams face nowadays, but really moving fast. Right? So there’s like this accelerate the book, for example, there, the Durham metrics are many other metrics around code velocity. So it’s apparently something that we want to do, right. We want to move fast. We want to be productive, but what are the challenges and how can we actually achieve that? So

liran:[00:02:12] I can say from my personal experience as well from pretty much everything I read on the topic, the best way to move faster is to work in smaller units. You mentioned Dora, the Dora metrics and accelerate, and they’re constantly about, you know, roundtrip time for new features and the amount of new features that are being released. And how can we build in it? How can we work in smaller unit to Falk? And the reason for that is because smaller units of work allow for much faster Predix cycles that allow you to learn much more. You get more feedback, you get, you learn every step of the way you learn more often, and you also get delivered more value to the cost, to the end customer on a more frequent basis. And in a way that’s actually driving a lot more value. I guess the biggest challenge is actually, how, how do you do that? How can you keep moving ever faster? How can you deliver in smaller units while still keeping delivery efficient? And I found that one of the best way, the best way to start is quite often culture. And we talked a bit about you, eh, doing some rich recent research for that. So I would love to hear about. What do you think about how best to build a better culture and how to promote a culture that deliver faster and deliver in smaller units folk?

michaela:[00:03:34] Um, I’m a big advocate for, for great, uh, culture, right? Who isn’t somehow everybody wants to work at the company that has a great culture, but unfortunately not everybody is I’m currently actually doing a research project that I that’s. The one that I talked with you about a little bit is on productivity and work culture and the experiences of developers at their companies. And so I’m, I’m doing right now, a qualitative study, a grounded theory study where I’m really. Trying to deeply understand how are people experiencing their work place and what factors are influencing their satisfaction, their happiness, their productivity, and what, what enables them to move fast, as you said, to be productive, to be the best selves. And, you know, there are some factors around obviously release, for example, is one that’s also covered by the Dora metric. Um, how has the release experience? And here I’m not only talking about metrics because. I think on one hand, I’m extremely data-driven. Um, whenever I was working with teams or am working with teams, um, also at Microsoft, we did a lot of the research was very data-driven, but it was also, and this was very, very important for me, always. Um, Kwon qualitative as well. Right? So not only you’re looking at the data, which gives you a very include complete picture, but you’re understanding, trying to understand the whole experience. And so this research study is really looking at the whole lift experience of developers. So on one hand we have like metrics like, um, you know, release cadence or from time to commit or from time to merge and so on. So what what’s very quantitative quantifiable, but on the other hand, you have. Um, the impressions and the perceptions of people around that. Right? So are you feeling better with it are, um, are they feeling worse and the same is true for code reviews and so. A lot of the things can really back to culture and culture is somehow enabler here, right? So we have like this practices around those areas, let’s say release. These feedback loops that we have released is actually a feedback loop. Code reviews are a feedback loop, right? Talking with product management is a feedback loop. How, how seamless, how smooth can we make them? And culture is really an enabler for that. Why is it an enabler? Because if I’m allowed to say, if something is wrong or if I’m allowed to experiment, even experimented with some failures, right? Like I try something out, I try to work different with product management. It doesn’t work out what happens, right? What are the consequences of that? And. And that’s why culture is so important because if people feel that they can experiment, if they feel that they can also express their opinion on it, they will drive more improvement. Right. Um, the research is really a lot about improvement. How, how much improvement can people. Um, drive and they normally know what’s good. Right. They know what’s going bad. Um, or what’s good. And so it’s really about enabling them to act upon that. And that has a lot to do in here. The funny thing here is that metrics are really important to want on one hand, to enable people that we see and that we make it visible that there are problems. But on the other hand, metrics often also hold people back. Because if I’m, if I measured. By one metric. Right? Um, it means that if I’m trying something else, something new, that’s not covered by this metric. It very well, it could very well be that I’m actually slowing down or I’m. The metrics outcomes going down while I’m trying something out. Right. And so the question is really about culture here. Again, how are people handling that? Right? Do I always have to perform to my OKR or KPIs or whatnot, right. The metrics and the goals that set around, or am I actually allowed to experie experiment here with things that might slow us down for a short time when I’m doing the improvements, because improvements are really hard to do without. Short term slowing down, right? Technical debt. How are you going to work on technical debt and still keep the features going? Right? Yeah. So this is what I am seeing here

liran:[00:07:41] that actually brings to mind the analogy from lean production, where you stop the line. When you see something is wrong and you say you have the, you give a individual engineers or individual employees, the. The permission to call it, to stop the line and spend the time and efforts to improve things, even at the cost of lost productivity in the short term, because it allows for continuous improvement.

michaela:[00:08:09] Yeah, exactly. It’s a really good analogy. Yeah. I

liran:[00:08:13] think it’s so important to create. Um, I remember I talked a lot about feedback, but you’re right. It’s critical that it’s not just enough to have feedback, but it’s super critical that the feedback experience is going to be positive. Even if this feedback is negative, it’s important for people to be able to experience. Getting feedback, something positive and in a way that if they’re changing something or developing something, or if it’s a bad product idea that the negative feedback should be, you know, about the, the, the feature about the, the task that this feature was bad, but the person who came up with it wasn’t bad and they didn’t necessarily make a bad choice by, uh, you know, going after this feature. And. People should be glad about getting those so-called negative feedbacks and not attribute them personally. And that’s super important to the culture, to the experience, kind of, how do you go about creating that? How do you go about building that environment where you get continuous feedback and experience is good.

michaela:[00:09:23] Yeah. I mean, I’m, I’m, I’m thinking a lot about culture nowadays and, you know, to. The common sense is always all countries so hard, right? It’s so hard to change. And if I’m in a, in a bad place, you know, it’s a bad place. Um, and I think on one hand, that’s probably true, but I don’t hand now that I’m confronted. So, so a lot with that, and I’m really working a lot with organizations and that they in displaced, I’m thinking about the small things that you can do. And culture really begins now really coming back to something very concrete. Um, I’m all about code review. So culture begins already in cultural views and for example, code root feedback. And to, in my workshop, what I do, I work with people on how to give respectful feedback. And very often everybody thinks like, Oh, but I’m doing this right? Like we are not fighting in the code reviews or whatnot, or, you know, or it’s only instances of that where we are mean, but it’s more, it’s about the collective awareness of not only do I fight with somebody or, you know, is it an unrespectful, but really. Uh, is my mind about value? The value that I can provide to others is the, is my mind about how can I actually, you know, improve the experience of my peers here. And I think this is something that’s often not done, and this is something very small where a team can really. Start actively being more aware of that, more deliberate, more conscious about this. Um, and it starts already by understanding code is really, really hard and everybody has, um, everybody has a time pressure and you know, wants to deliver the features. And a lot of engineers say, well, you know, code review is good, but, uh, I actually have to deliver feature. So what’s about the time that I have to spend on the code review. Somehow it’s missing from my feature work and so on. And so having really empathy around that and the experience of myself, but also off my, off my team, that’s already creating culture, um, and being extremely, um, it bear that feedback, even if it comes from a good colleague that you think like, we are all, you know, good friends and we are really on the same page that we still really take. And this is now again, you know, slowing down, right. It’s slowing down to make sure that I’m phrasing this feedback in a very respectful way, because we know that feedback can sting. Right. Um, and it can be misinterpreted. A lot of the feedback comes through a tool, which means it’s an automated tool. I’m not directly talking to a person. So sometimes I forget it. And we are in this automated way of. Um, you know, looking through the algorithms, finding, you know, let’s say edge cases or whatnot, finding problems. And so if you are in a very technical state of mind, and then we are hammering in our feedback and say, Oh, Variable name is wrong or, you know, or should be different. And then going, you know, taking one step back and thinking, is that creating a good culture? Or can I take this, you know, two more minutes and say, Oh, you know, what about, um, renaming this and even giving an explanation, you know, w really expressing your, your mind. I think. Driving cultural change is definitely hard and, um, comes often also from the top, but there is a lot that teams can do for themselves. And even engineers themselves can ask themselves every day, like, what did I do positive today? Like I’m not only going somewhere in and they’re expecting that culture would be great, but am I actually contributing to, to making a good culture here? Hmm.

liran:[00:12:49] I think it’s so much more critical today as well, working remotely, because as you mentioned, we’re often in that technical state of mind, whether it’s on GitHub doing code review or on Slack or wherever, but behind what’s actually happening is we’re communicating with other human beings. We’re not just no analyzing code and the testing stuff we’re communicating to other human beings. And as we were, many of us are working remotely quite often, or most of the time. We can often forget there is a person on the other, on the other side of it. And sometimes we kind of forget to act with empathy, with compassion, and while we may be factually, correct. We’re not creating a good experience for the person on the other side of that communication.

michaela:[00:13:35] Yeah. And actually about the factually correct thing. I have learned over my, you know, my time in the industry that at seldom leader, Kate seldom Livia are very, very active, you know? And I think sometimes you forget about that and, and this is two perspectives. Cultural views are a place where two perspectives really are, you know, they are, they are the benefit of it. And there are also the problem, right? That you are constantly having somebody that looks at the same thing and say, well, but I’m seeing something else, right? Like I’m seeing technical debt and you say, but it’s fine. You know,

liran:[00:14:15] the thing is engineers so often feel like they’re factually correct. Even whether it’s or not, it’s the case. I just, and quite often we’re not actually factually correct. There is some degree of, eh, you know, afraid. Of common sense and various options. And w there is not one single truth out there, but even if there is even if you there is, and you’re convinced that there is in your, on that single spruce, it’s still communication. And you must not forget that there are other things beyond fact, too, and more often than not, there are actually no facts. And it’s just your opinion, which might be very good and professional, but it’s just an opinion.

michaela:[00:14:59] Yeah, very true. And a lot of the time it’s about strategies. And about the unknowns that you know, that the unknowns unknowns that we actually make guesses and decision and B we don’t know if they are the best ones. And we even in hindsight, we cannot decide like if we could have, you know, if you would have done it differently, would we have a better outcome? We don’t know. Right. So, yeah, it’s, it’s, it’s really dealing with that and, and embracing that and maybe reminding maybe something that we can do also, always over time to build this culture is reminding us of that. Right. It’s a little bit like we have to remind ourselves of the central things. We have to remind also ourselves that we are dealing with so many unknowns and that on one hand, you know, we are, I think at, at one point we have to go and say, Well, we don’t know better. And maybe some people disagree here, but now is the time that we are, you know, buying in and going this way together. And I think this is also important for engineering teams, right? So in one of my country workshops last week, for example, I give them a code base and it was, um, it seeded with errors, right? So it has issues and they asked the team to, to find those issues. And there are, you know, they are. Issues about readability, maintainability of the code, but there are also security issues. And so then we had a discussion about, you know, um, so there are a lot of issues. So how are you going to communicate to the person that wrote that code about those issues? Are you going to tell them all of them at once? You know, do we make like a plan around what should be, um, worked on first? And there was, for example, this discussion then between two senior engineers and they were saying, well, once by saying. Yeah. Um, so everybody agreed that, you know, sending them 300, 300 problems at one point is not the right thing to work with this junior. So, um, they were thinking, well, let’s do it in, in phases, but it didn’t, they couldn’t agree. Like if security issues are more important than readability issues or not only readability, but making the code work. Right. So there was this discussion that, well, this is early stage, so it’s, it’s probably a prototype, so we should have to, you know, show. So let’s do it. Make it correct first that it works and then work on the security issues that they had, like they had, there were injection box and cross site scripting products and so on. Right. But in the end, you know, like the whole team was discussing it. They couldn’t really find a way forward. Right. There was one side that was very convinced that, well, these are really critical security packs and they were really critical. And the other was like, well, but it’s, you know, we use it internally right now. It’s a prototype. So let’s make the functionality work first. And so what, there was a back and forth, and I think this was a really nice example of, I couldn’t tell, like, I couldn’t say like they wanted me to be now the referee and say, Oh, you win. Right? Like the security team, Vince, we first do a security or we first do inability, but there is no right or wrong answer. It’s just the strategy that you’re going to do. And probably that you’re not doing, you know, again, not sending all the issues at one is a good one. Um, but then in the end, it doesn’t matter if you do one or the other, as long as the security backs are not coming out right. In, in production. Um, yeah. And, and I think here it’s really important to step back from this discussion at one point and say it’s actually a nonsense discussion. Let’s, you know, flip a coin and do one or the other. Um, yeah, this is what I think about this. So a lot of the things is really. It really depends. And then we have to make a decision and if we made the decision, this is the important thing. And then everybody has to buy in and not like, keep this resentment and say, Oh, the security or pre approach first. Right. And I think it’s stupid. And so that’s why I’m blocking here, which is culture. I think.

liran:[00:18:49] Yeah. So actually it’s not, it’s interesting that you mentioned that because it’s such a big topic. And I mean, so much effort goes into code reviews and often becoming the button neck, both for whoever has to do the code review. And, you know, spend the time and walk and provided feedback in both wherever need, wants to get, just to get this code out there. And they’re just trying to, and, you know, they’ve just finished developing the feature. They just want to check off the it’s been called of you and send it out there. So kind of what strategies should company follow to speed up their code reviews?

michaela:[00:19:27] So, um, I totally agree that code reviews can become a bottleneck and they’re coming with a lot of pain points, but I think especially this. This mindset of, you know, cultivate is just another hurdle. Um, that’s something that people have to work on. Right. So, um, we really have to understand and carve out also, what’s the benefit of the code view? Why do we do it even here? Right. And if the feeling of the engineering as well, I just wants, uh, I want to look good to me and that’s it. Um, then obviously it’s a delay and it’s a bottleneck and you know, the value. Probably isn’t that high because even if the person gets good feedback, you know, if the person that receives it, doesn’t actually want it, you know, what’s the value of that. So I think that a lot of those is really for an organization and for a team to think about what do we want to get out of contribution? And there is a lot of imperative studies also that really show that the benefits like. Um, improved code base, readability, maintainability, um, less, you know, less issues, less facts, defects in posts and pre-releases, um, all of those are happening. Culture-based, there’s a lot of mentoring and learning happening. There is advantage knowledge sharing, but it’s only if I’m open to it. And if I’m very clear about what I want to get out of here, because if I want. Let’s say if I want to find it back, it would be the best to ask a person that’s familiar with the code to be on this code review and not, you know, a junior, but if I want to have this learning expect more in, in, you know, in the center, then obviously I ask somebody that maybe hasn’t seen that code part before, so that they get familiar, that I have knowledge dissemination that I have more people that are familiar about this code base. And I think most organizations. They’re not real bear. They, they hopped on this code review bag and because the hopped on, you know, to pull request, model to development and pull requests and code reviews are not the same. And so suddenly they wrote a pull request and they felt like, Oh, before I pull it in and look at the code and because I’m looking at the code, it’s already a code review. And so now I’m doing code reviews and I want all of these benefits without actually investing I’m investing. And then here it comes back to this slow down. Right. So I have to probably slow down first. Really find out with my team, what is it that we want to get out of code reviews? How are we structuring our processes, our practices, and this has to do a lot, right? Like, depending on the risk profile of this code review, who should be on the code review would ask for feedback, how long should it take them? What issues are they looking for? All of that can actually be designed and very deliberately made. And then you’re getting really a lot of benefits out. But if you’re not doing that, yeah. Then you’re in this state where. He just wanted, it looks good to me. Right? The other person knows you just want that, but still feel a little bit pressure, um, that they have to look at it because if it goes in, they’re also responsible. And so there’s this delay, um, and you don’t want to spend time for it, but you have to, you know, and then you having an, I actually have a, if you look on my website, there’s the code through your quadrant. Um, and this means like it’s, it’s, you have to access and it’s the speed of the process and the value. And this means that you often have them. Organizations that are slowing speed. And low in value. Right? So they are low in, in speed. They’re very slow. They’re bottlenecks and they don’t get value out or that they’re fight fast because they’re just giving out. Looks good to me, but they’re not getting value out of this. Right. But even if you’re waiting for look good to me, Like say half an hour or an hour or four hours, it’s still slowing down your process. And the question is, was it worth it right? If people are not really taking the time to review. So in the end for me, it was probably a very long answer to your question, but it really comes down to what, why do you do code reviews? Right. And do you have to have an answer for that? And probably depending on the code change, the risk profile of the code change and the code change, you will have different answers to that, or this code review. I want that, you know, my junior engineer knows how that works. And so I’m sending it over or this, this code changes about how we are doing the checkout. So I definitely want, you know, two more eyes, um, to make sure that there are no, no defects going out. Right?

liran:[00:23:47] Yeah. I mean, that sounds so complex. Can’t we just automate this and install some tool and get it over with.

michaela:[00:23:55] I definitely parts of it. And I think that a lot of people are, are, are doing stuff that tools should do for them. Right? So they, they, they are mocking on, you know, style issues they are talking about, you know, some, some things that actually study analysis tools could find. Um, or automated code review tools, whatever you want to call them. Uh, in the end it’s, it’s, linters that checkers steady analysis tools. Right. And they are actually much better than, than people. To find certain, certain errors and certain problems with your code, they can actually, you know, they can walk through your code and really find out, you know, if they’re, if, if some code paths are not called and tell you, Oh, this is actually not going to call it. Or, you know, really also back study analysis backs, but they are limited. So it’s, it’s not something, you know, they are not, you cannot comply, uh, replace the, the manual review. But you can replace a lot of that, you know, nitpicking, which is very unproductive and code reviews. Um, it doesn’t matter. Like why would you have an engineer spend time on finding certain types of errors? If a tool could do it automatically? I’m I’m all for automation. I think it’s so important to automate whatever you can automate here. Yeah. Are you using, are you using some automated tools in your pipeline?

liran:[00:25:15] So yeah, we actually adopted a GitHub advanced security. A few months ago at lookout. And it was actually a pretty good tool for us. It allowed us to gain some insights, actually both brought us a lot of insights into some of the other code that broke out and kind of knowing where we might’ve pitfalls, but it also managed ha ha is helping us moving forward, knowing that it could work coder pushing through discussed meeting there. No style checks and best practices, especially when it goes to more junior engineers or engineers or working in environments that are not a strength. Let’s say, I know most of our full stack engineers spend most of their days between a, you know, react and node JS, but occasionally they dive into Golang. And then all of a sudden, they’re not as fluent in, you know, what can go wrong and how should the code views. And some of those arrows can easily be caught by those automated static analysis tools. Also, it’s a very useful tool personally, we’ve, we’ve recently developed support for Ruby and surely within that skeleton of project, we started with Robocop, which is a very, very strict, eh, who bill inter. And that’s actually provided us with a lot of insight and kind of kept us very honest as we were developing the code, keeping functions, very short, creating a very orderly and well structured code. And that’s kind of something that it’s always a dilemma for me when starting a new project. Do you go ahead and spend a lot of time building the skeleton, building the CACD building, building linting. At the beginning of the, you wait for it later on, because you know that later on, doesn’t always get by. And if you’re adding a linter to an existing project, and then all of a sudden you’re getting, you know, dozens of errors, then you might not be, get going around to fix them because it’s too much work and that’s always kind of a dilemma. But for that project, it was a very good experience for us in developing high-quality code.

michaela:[00:27:25] Yeah, that’s really nice. Yeah. There’s also my experience. Like if you, if you add that to an already existing, quite substantial code base, right. It’s just out of hands, right. You will have like all these red flags, orange, whatever, you know, depending on the tool that you have, like different severities of issues. And I always feel really bad because. I know that I’m not going to be able, like to go back and, you know, redo the past. Um, you can do it slowly by slowly, right? Like I’ll voice called removal or at five by refactoring where you say, well, if I’m touching this code, I make it nice again or make it better and you can do it ongoing. Um, but yeah, I also feel like for, for existing code, it somehow has this, you failed here. Um, um, Psychological, uh, you know, by byproduct, but you’d be like, Oh, now I’m seeing what’s all messy and you cannot really do it. Um, yeah. But yeah, it’s good that it worked out. So apparently you could, could you remove all of the issues? Could you work through all of them?

liran:[00:28:26] So we got through, and I think 95% of them ere, there were some, a few areas where we decided that. That code is not going to be the nicest code in the project. And that’s okay. This code is mostly, you know, four, it wasn’t was low maintenance, low complexity, just a lot of, you know, lung functions doing boring stuff. And we said, that’s something we can live with without spending too much engineering efforts, kind of fixing it up and making it look the best.

michaela:[00:28:59] Yeah. So in the interview and the research interviews that I’m doing right now, we talk a lot about technical debt as well, and how people deal with technical debt. And I’m asking different organizations, different teams, their strategies for technical debt. What are your strategies? We have like some, you know, some amount per sprint that you can use on that, or how do you, how do you even. Um, assess the value of working on this, uh, you know, technical, then you were talking like, Oh, we already okay with this part of the code base, but how do you assess that? And on a more strategical, systematic level, right?

liran:[00:29:34] Yeah. So I guess that’s a two part question. And on the one part, we do have a strategy and I can talk about it a bit, but I think it goes beyond that. I found that for you, you mentioned actually early on that nothing in very literal in tech is factual and most of it is opinions. And I think that’s doubly true for a tech debt. And quite often one engineer joins a project and they decide that what’s happening. Much of, many of the decisions have been taken before they joined our tech that there have been wrong. And I would wager basic statement that it’s. Probably the other way around. I mean, if the project is live, if it’s generating value, if that piece of code was walking from when it was written up until now, then chances are the decision to, to do it. That way was actually correct. Or at least descent. And engineers often jump to say to, you know, define tech that because something is not in the latest design pattern or something is using an older technology or paradigm, or maybe simply because they don’t understand something. So often the first thing you have to do when you think of tech that is actually understand what’s going on and truly think for yourself. I truly think about it. Is this truly affected? Oh, is this something you lack an understanding? And actually that’s something we were seeing within Rueckert and with our customers that shook out is quite often used for once you have a better understanding of the code, because you can see how it’s working and you can see inside of it, then you quite often realize that’s not actually that that’s the, I just didn’t understand how it was working. And once you get gain a better picture of how is it working, why is it working that way? And none of the sudden then it makes perfect sense. But obviously sometimes there is real product that there is real tech that they, for the most part, we kind of manage tech debt on a, you know, quarterly on a quarterly roadmap. We have a very. Agile flexible quarterly roadmap while we manage our roadmap, eh, usual, all the rollout. And you also kind of add, you know, a handful of tasks for each team and full of mid-level mid large tasks for each team where they can, whether they should strive for a tech that. And obviously, you know, like that usually comes last in priorities priorities. So it doesn’t always get executed a lot. Depends on the roadmap progress in general and especially on a. Eh, eh, new tasks that get pushed in from the sales team as well, working with customers. And there are always new requirements for improving performance, for a meeting new criteria for giving the best experience with possibly can for our customers. And those often override some of other stuff we have on the roadmap, but we do try to get at least some of the tech that cleared every quarter, just to get a few low hanging fruits with high impact stuff. That’s been bothering us, that’s bothering the team. And also we find that having those, you know, tasks in the queue engineers kind of find time in way to get to them, to get it out of the way.

michaela:[00:32:56] Yeah. So what, what reminds me and what I wanted to ask you in that context is that the original or one of the very early on definitions of tech dad was code that didn’t have tests right from my Confederacy would say, well, it’s tech that if you don’t have tests, because then you really have a hard time refactoring and often, you know, There’s also this new, I was actually, I did a podcast with him, uh, recently on, on, on my podcast and we were talking about it and then he, and he also sat like tech tech. That is the code that has been outlived, but a person that. Wrote it right. And that in our days in our, in our, um, very fast pace or, you know, um, take industry where people will stay two years, maybe at the company, they write code and they actually never really see it in the maintainance pace. Right. So do you see it when they’re writing it? Maybe when you’re releasing it. And so a lot of the, you know, like a lot of the, the. Code becomes tech deck, because the knowledge is actually gone from the organization that, you know, wrote that that code or, you know, can maintain or understand it. What’s your perspective on that?

liran:[00:34:07] So there’s actually a truck out we’ve kind of we’ve wrote and talked a lot about understandability. It’s exactly what you mentioned. It’s about knowledge it’s about if you’re able to understand the software, the code fairly well, then. You’re the new C you can do a lot. I mean, you can get stuff done. I mean, I think the most obvious example of that is, you know, those simple exercises you get on introduction to computer sciences file from disk, Salton array, eh, those kinds of stuff. And you know, those exercises you can usually do right now as a senior engineer in 10 minutes, 20 minutes. And you’re done, but if you were to get the same task within the context of a very large system, especially one you’re not intimately familiar with, then all of the sudden the same tasks can take you weeks. And then you’re going to start complaining about tech debt and lack of knowledge and documentation. And if at the same time, or to give that same task to the two, a person who was one of the founding team of that system, they’re still going to get it done in, I know maybe not 10 minutes, but 30 minutes. And preserving knowledge is super critical. And at the same time, we need better tooling. We need better tooling that would allow us to work with systems that are complex, that we’re not intimately familiar with. Obviously testing is there, as you mentioned, testing is a form of tech that because testing is a Godwin. That allows it to operate in a, in an area where you’re not familiar with. It allows you to easily debug the code that I, you to see it in action. Even though it’s a developing environment, you can see the code running, you could see it in action. You can make changes in a control mirror. We know what you’re changing, you know what you’re going to impact, but that’s at the same time, I think tests can be incredibly expensive. Even more so if you’re not already familiar with the code, so it’s kind of, you know, a conundrum you’re saying the code is not very good because it’s effective because it doesn’t have any tests and it doesn’t understand it, but then it’s going to be very hard for you to add tests to the code. You’re not honest. You don’t understand. I think observability tools, by the way, can provide you with some insights into how the code is walking. Right. Eh, but at the end of the day, nothing beats just debugging the code, stepping through it, see what, see the actual types and values of variables, seeing the inputs and outputs of the system and seeing it in action. That’s the best way to understand the code.

michaela:[00:36:45] Yeah. I think the too, when I was at the university of Victoria in Canada, um, I was doing a research as a bicycle there. And they, they developed a tool. I think at that point was called driver. You will not find it because it was a research tool, right. Not really popular and bad. The tool itself was really cool because it helped you understand cold. Um, my, my research area was called comprehension. And so really helping teams and engineers understand code. And so this tool was made in a way that you could Deepak and it showed, you know, the traces and the values as you just described. Right. But this is like, 15 years back pretty long time. So it was very novel at that point. Right. And so this was really used to understand coach. I think debugging is definitely one of the ways how we understand code, right. That we really go through it and try to understand what’s going on a really interesting resource maybe in that, um, in that regard is also a book that’s coming out from a friend of mine, for the Hermanns it’s called. The program has brain and it talks a lot about cognitive load and code reading. Um, there’s actually a workshop that I’m going to attend today about code reading, um, from her. And, um, yeah, and I think this is really, this is really interesting because it again goes into these different versions of cognitive load and also confusion that you have with code and confusion can come, come from different sources. One is lack. Of your own knowledge, right? So being a junior or, you know, being a senior engineer, you have a different knowledge base. So you can actually go back to your longterm memory and quickly access how to load the file, or you know, how to save a file, how to close a file and so on. And then as a junior, you have to really think actively think about this with means that you’re. Your, your processing power more or less, right? It’s reduced because you have activity after actively think about this. And we can think around four to seven things. So if you’re already thinking about those things, you know, there are only two more things that you can add. And as a senior example, you, you. You have that in your long-term memory. So you have seven things that you can think about. And the interesting aspect here is also the same with what you said about the code base. If I’m familiar with the code base, I can load parts of that from my long-term memory. And I don’t have to use my short term memory. I don’t have to use the processor for that. Right. Um, and so there’s definitely, there’s exactly what you’re seeing here. Um, maybe something else that I want to add here is you said knowledge dissemination. And code reviews are really good for that. Right? So that’s why I’m saying the organization has to understand the benefits as a whole, right? And suddenly if you understand that, well, if I can actually have, have a, a larger part of my team, be more familiar with a larger part of the code base, that’s actually extremely valuable and it will. You know, it will speed up your development process quite a bit. And there are also studies on that around code reviews where we really see that, um, it teams that have code reviews in place. They already have a Vitor understanding of the code base than teams that don’t have. Right. They’re only known only know what they’re working on. Um, and so why it’s slowing you down to do the reviews. It really speeds you up. Once you have to work in this pace, right. Or in this place off the copies, or if somebody leaves, you have other engineers that are also familiar with. With that. And so I think there are other benefits that are really, really, um, really important here. Yeah.

liran:[00:40:19] Yeah. I mean, I’m hearing here speak, it’s obvious. You’re an advocate of code reviews and you’re passionate about it and you’re making great, great arguments about why it’s so important and how the part, the value fit. But don’t people ever come to you and say, I don’t know, it’s slowing me down. It’s making stuff complex. I mean, I don’t want to do pull quest. I don’t want to do code reviews. I just want to skip the whole things and kind of what do you send them?

michaela:[00:40:50] So, honestly, I don’t, I don’t have a lot of people that have this complete mindset. I have a lot of people that would say I really would like to skip code reviews because I don’t have time to do them because my reward system around my recognition and what I’m expected to do is something completely else. And then I have to look at code reviews and, and this is not part of it. Right. So I recall one person, I was just talking with them. Like we could go around that. Right. It was part of the research again, and they were talking about it. How, how is it? It’s really difficult. They actually laugh code reviews and they learn quite a lot and they would have much more, um, much more benefit and would feel better about them. If this would be actively part of their job description and their expectations. But it’s in very many, many organization. It’s. It’s window dressing. It’s like, yeah, we want you to do code reviews and it’s really mandatory and they have to do them. But on the other hand, there is no time to actually do them. Right. And I think that’s, that’s what I see very often. I definitely see people that haven’t had good experience with code reviews that don’t maybe see the benefits out of that. But I also have, on the other hand, I think this is why I’m such a strong advocate for that. I have people, really, a lot of people that have seen the benefits and that have done code reviews in the right way. And, and, you know, with good processes around and with a good culture around that, that they say I would never, ever work anywhere else without code reviews, because it’s a, it’s a mentoring tool. It’s a learning tool. I’m learning so much more. I’m so connected to my team. Right. And not working in a silo anymore, but this needs a certain time of code reviews. You cannot like work on a feature for a month and then throw over like thousands of lines of code or whatever volunteers look at it and give me feedback, right? Like this is not gonna work, right. This is, uh, this is definitely a frustrating experience for everybody. And in this case, I say, get rid of it. You’re not getting anything out of it other than frustration. Um, but also be honest to yourself that you’re actually not really doing code reviews, right? You’re throwing pieces of understandable codes to somebody else that can spend maybe half an hour, an hour to look through thousand lines of code. What are they going to say to you? Nothing. Right. And so maybe it’s really to be about, be honest and say, if I want that, I need to slow down, understand how to design the process. Um, maybe even get help for doing that. Right. And then, and then really do it right. And have so many people that really love code reviews and so many teams that are striving through that. Um, and yeah, so definitely if you know, if they don’t bring any value, then it’s really, I think it’s very often the process that’s just completely screwed up and the culture around it.

liran:[00:43:39] Yeah. And do you find that companies struggled to understand which public was deserved called the abuse versus which, what policies did they have in place to know to solve them out? Sometimes I know sometimes just adding a log line and then you need to go through the same code of your process, or at least by definition, it’s the same workflow as if you’re adding a big feature. So kind of how the companies go around managing the different kind of pollute quests.

michaela:[00:44:08] So I think this is really a part of, I cannot generalize, um, because for some organization it’s definitely valuable to go. Through a pull request or a code review for every line of code that they’re doing, even if it’s a lock line. Right. Um, but then this is a certain type of company and they have certain goals around it and it’s beneficial. I definitely see also, um, you know, organizations that have some code review guidelines in place and it says we have to look at every line and it’s a log line. It makes no sense here. Um, very often here, people haven’t thought about again, you know, what are our goals with cultural views? And if you think about the goals and it’s a logline in, you know, Yvette Yvette site that I can update within minutes because I have a fast pipeline, why would I go through a code review here? Right? Why would I slow that down? What’s the benefit here? Um, so I think that organizations that are more vague about their contribution to practices and process, and really take the time they understand that. Um, and it has to do with risk profiles. Can engineers, do they have like guidelines to work around? Have we thought about this as an engineering team? What are our values? Um, when I was working with Microsoft, we had like, there were, there’s not one code review. Policy, right. It really depends. Office has a different policy than windows. And then even in, in office, you have like different teams that have different policies and so on. And so the teams really thought about, um, some teams would say, well, for us, every line is reviewed. And then other teams would say, uh, well, vs keeping, for example, refactorings if you do a refactoring and you can show it, it’s, uh, uh, And refactoring that has no side effects, then you can just put it in or some teams would do the review after they’ve pushed it, for example. Right. So after, after committed, after pushing and after merging, they’re doing the so. The, the policies really differ. And I’m not saying that, you know, even if the differ for some teams, they were really good for some teams do or not. Um, it really depends how, how honest and how in there and reflected people were around their cultural views. Um, but you can definitely be design and, you know, even have automatic things that help you to decide whether or not something should have a code review. Right. You could buy somebody if you think about conventional commits. Where you have certain aspects in the commit message even right? Even those systems are in place. If you, that you could do here, where it could incorporate some of the risk of something, or you have against that again, as it tools around somehow assess the risk. And that helps you to decide whether or not you need a code review or in what depth you need a code review here, how many people should be under code review. Right. So, so many questions, uh, yeah. Yeah. Touch on what you meant.

liran:[00:47:07] Uh, that’s. Exactly. Yeah. That’s that’s perfect. I think we’re almost running out of time here. So maybe Mo join us, throwing a few questions

michaela:[00:47:16] from the audience.

maror:[00:47:17] Okay. So actually, a few questions did come up. If you guys are ready for it, um, McKayla, we’ll start with you. Can peer programming, replace code

michaela:[00:47:26] reviews. Okay. Um, pair programming. So I, yeah, this is a, this is a very often, uh, asked question and my answer is no, it’s very similar to, you know, can automated contributes, replaced code reviews. I think they are very complimentary here again. So if you have peer programming, um, You’d probably have different cultural view practices again. Right. So very often we talk about code reviews and then code reviews are that thing that everybody does the same, which is completely not true, could be, it can be so many things, right. If I’m looking over the shoulder with somebody and looking at the code at the same time, it’s an over shoulder over the shoulder code review. And so peer programming could actually be one kind of code review, but then you have to ask your, you know, for yourself or your organization again, Do we need more? Do we need like some gatekeeping around that so that we have another person do we need in fairness right around that? If I have two people that are pairing very often, then you have like this knowledge silo, again, that those two people know about the code, but maybe I want other people in that, so we’ll add them. So, um, code review can be, uh, a complimentary strategy to pairing, but I definitely say it should look different, right? For team, the task pairing code review should look different than for a team that desk. Does know Perry. Yeah. Okay.

maror:[00:48:50] Very cool. Um, Leon, I think this one’s for you, what’s the relevance of code reviews for compliance.

liran:[00:48:58] So I think we found that there are a few, few key elements in that I think compliance kind of often requires that, eh, some peer reviews, every change, and I think it goes back to what said about the purpose of code reviews. And compliance for the most part would be focusing on first and foremost general security review, but even more. So it’s an often a question of trust and governance that you essentially know what code is going into the system in a way. I think it’s very different from most of America is been talking about today, about, you know, in depth review, understanding the code and. Eh, me ensuring that you have all the right pieces in place. It’s more about cursory examination that you make sure that you’re not, you’re not changing anything. You shouldn’t be changing that the person is making that commit within the assigned task is working on and within the assigned scope, if there are any changes to security, sensitive area that you go through additional scrutiny. But if those are eh, you know, It’s more about ensuring that whoever is made the task, did what he was supposed to do rather than the quality of the work he did. So that’s a very different thing. And it’s very important again, to kind of. Define the purpose of the code review. Is it just about understanding the scope of the task and the scope of the change, or is it about deeply evaluating it? Giving feedback, mentoring, sharing, knowledge and so on and so forth.

michaela:[00:50:43] Okay.

maror:[00:50:44] Um, and Mikayla, if people wanted to learn more about code reviews, where, where would they be able to

michaela:[00:50:50] go to do that? Okay. Yeah. Um, obviously I can see my website, right? I’m writing quite a bit about code reviews, which would be awesome. Code reviews.com. Or you can also go through my, my link. That’s my name, Kayla gala.com, which is a little bit more difficult for me. We can put it somewhere, but I’m awesome. Code reviews, dot com should have them work as well. And, um, yeah, I also have like a GitHub. A project that’s about code reviews, um, where I’m listing a lot of different resources that I find on the web. So it’s not only from me, but also what I started recently doing is best practices from different organizations. So there are articles where you see like how, um, You know, for example, the Google desk cultivators, or how is, you know, VMware doing code reviews and other, um, resources that I found really valuable as well. I also have like code review checklist there on my guitar profile. Um, so it it’s, uh, the guitar thing. And then my, my handle is M and then Kyla, G R E I L E R. And so, yeah, there, you can find also quite some stuff, um, that, um, that comes from everywhere that I found this valuable.

maror:[00:52:03] That is a wealth of information that everyone should definitely take advantage of. Um, and I will make sure to send out your Twitter handle for them too, so they get it. Um, and on the topic of learning more in the event, where can you learn more

michaela:[00:52:17] about lookout?

liran:[00:52:19] So you can learn more about first and foremost, that’s roka.com, which is our awesome website. We’ve just launched a new website. And so feel free to check it out. Also, you can reach out to me on Twitter at
other school last, and I’ll be happy to chat with you and share more about what

michaela:[00:52:36] we’re doing.

maror:[00:52:39] Amazing. Okay. So then we have one last question here, um, and it looks McKayla like it’s for you. The question is, do we need additional manual reviews or testing if we have a study analysis tools or is

michaela:[00:52:52] that enough? Okay. Um, I think I touched it a little bit on that. So I definitely think it’s complimentary again. Right. So if you have, like, I definitely recommend to have studying analysis, test tools, have static analysis tools, security tools, because they are much more systematic and they they’re defining more issues. They are less error prone. You’re not overlooking something, right. Especially for things that are systematic. As I said, Um, for example, security testing tools are really good or, you know, security analysis tools are really good for injection box, um, where, you know, people would have a hard time and it’s just unproductive for them to look at that. Um, you know, in, in the, in terms of what a tool could do here, but then for example, broken off, um, authentication or just the flow of things that is really beyond the scope of tools right now. Right. So if you’re, for example, sending out. Let’s say that you’re somebody is requesting a password reset, right? So the whole, uh, workflows through dat can be very, very broken and there are no tools that, right. An alpha example can check for that. So that definitely has to be done manually by, by person and very similar in the cultural sense. Right. So, um, there are really good static analysis tools, but there’s always things that just the tool cannot do for you. So they are complimentary, I would say. Okay,

maror:[00:54:18] thanks. So that’s all we have time for today, unfortunately. Um, but hopefully we can also down again cause it’s been great. Um, so thank you everyone for joining us, we will be sending a follow-up email with the recording and McKayla and Leon’s contact information for whoever wants to get in touch with them. And thank you McKayla. And thank you again.

michaela:[00:54:38] Yeah. Thank you so much. Let’s refund.

liran:[00:54:41] Thank you. Thank you.

Book your awesomecodereview.com workshop! Secure Code Review Workshops are coming soon too!

Getting ready to build a billion-dollar business

In this episode, I talk to Max Stoiber. Max is a JavaScript Engineer that is in love with React and Node, and also a fellow Austrian. He has a track record in the open-source world, worked for Gatsby, and Github, and also is a successful entrepreneur. 

We talk about:

  • what he learned about software engineering best practices at GitHub,
  • why he started his newest side-project bedrock,
  • why building an indie or small lifestyle businesses is not his thing anymore,
  • and how he prepares to build a billion-dollar business.

Book your awesomecodereview.com workshop! Secure Code Review Workshops are coming soon too!

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

Transcript: Getting ready for a billion-dollar business

[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. mckayla and today I have the pleasure to talk to Max Stoiber.

But before I start, I wanted to update you a bit on what I’ve been up to lately. Over the last few months, I have been quite heads-down with some new exciting productivity research. Mainly investigating what makes developers happy, productive and successful. I’m planning on wrapping up this research soon, so I hope I can share more about the findings in near future.

Another thing I have been up to is preparing a secure code review workshop. I plan to release this worksop this fall. It will focus on secure coding practices, and shows you what to look out for when inspecting code for security vulnerabilities. If this sounds interesting to you, hope over to https://awesomecoderviews.com and either book a workshop or hop on my waiting list. But now, back to Max.

Max is not only a JavaScript engineer that is in love with reactive note, but also a fellow Austrian. He has a track record in the open source world and worked for Gatsby and get up. And he’s also a successful entrepreneur. Max built, for example, a community platform called spectrum. It became so successful. It was a quiet, but GitHub. And now he’s again, working on a new startup idea. So I’m super excited to talk with max about all of that. I’m super thrilled that he’s here. Welcome to the show,

Max: [00:00:39] max. I am super excited to be here as well. I’m a big fan. We’ve obviously spoken before. I’m really happy that I get to be here too. Yeah, I’m

Michaela: [00:00:47] really, really excited. Thank you so much for joining. So I want to start with something that I wanted to ask you a couple of times already, and that is you build this really amazing community platform spectrum. And I recently looked on their website and I see that I’m in the forums. There are several forums where people in communities where people are talking with each other and it seems really lively. Like when I went there, they were like 50 people online in that community and 60 people in that community and so on. Right. So it really seems like a big success, but on the other hand, there is the announcement that. It will be read only, right. It will not survive for me. It looks like it’s shut down. Is that, is that true? And if it’s, so how do you feel about that?

Max: [00:01:33] It makes me very sad to be honest. Whenever I build a product that they’re sort of like my, my babies, right? I want them to be successful. I want them to succeed. I want people to like them. And the spectrum no longer existing or, or only existing in an archive format is, is quite sad, honestly. But at the same time, the spirit lives on in GitHub as gets up, discussions gets up originally bald spectrum with the intention to eventually shut down the platform itself, integrated into, gets up. And that’s what, that’s what they’ve done. And so that was part of the plan. And I’m, I’m happy that that plan is being followed so closely, but of course I would much rather spectrum stayed around and lived on as its own thing, but that’s not the way it’s going. And we’ve, we’ve actually, I talk, I’ve talked quite frequently to my other co-founders Mike’s, co-founders about doing the same thing again, because with the, with the benefit of hindsight, there’s so many things we would have done differently or we would like to do differently. We have so many ideas about how we could have built spectrum better, but of course it’s all just wishful thinking. We’re very unlikely that we’re going to do that, but it isn’t fun. A fun thing to dream about.

Michaela: [00:02:41] Yeah. I mean, community is such a interesting topic and I mean, it’s so powerful and it’s so important and communities are, I mean, people are here for communities, right. We need communities to strive. So I actually also playing a little bit with the idea of building some community, but I feel also very overwhelmed at the same time, how to do that. but it’s just a fascinating topic. Right. And just having people around and I mean, a community can be also like five people or, you know, two people, three, two people. Right. So spectrum is on the very other end, right. There are like hundreds of peoples or thousands of peoples. But so I think community is really important. So, but you were saying that when GitHub bought spectrum, you already knew that they are going to shut it down. So you, you knew that that could be one of the paths or this could be leading towards that shut down off the platform.

Max: [00:03:33] Yeah, absolutely. Spectrum itself, technically just wasn’t architected well enough to SU to sort of sustain get-ups load. And it was clear from the very beginning that it would be a lot more work to make spectrum work at Kitsap, stay at scale, rather than trying to rebuild the parts of spectrum that we liked within GitHub. And so very quickly, we just arrived at the conclusion that we’re going to have to shut spectrum down as a platform. Sort of build that integration and gets up completely from scratch and separately because GitHub has so much tooling internally. And that, that helps it handle the scale it’s at, right. We’re talking hundreds of millions of developers, which is very different from scale. That spectrum is that spectrum as a couple of hundreds of thousands monthly active users, which is a lot, but it’s not by far, not as much as schizopath. And so it was clear from the beginning that we would either need to rebuild spectrum. I mean, it was clear that we would have to rebuild spectrum. The question was rested. We rebuild it as spectrum, or do we rebuild it in GitHub? And since we were already rebuilding it, we might as well just rebuild and get up. And that’s what discussion came from eventually.

Michaela: [00:04:32] Which

Max: [00:04:32] again, makes me a little bit sad because I would like spectrum to still exist, but that’s the way it is. And discussions actually turned out really well. I’m really excited about it.

Michaela: [00:04:39] But so for our community, there are two parts to it, right? So there’s the tech around, it enables people to meet in an online space and talk and, you know, like, you know, write or have chat or whatnot. Right. So there’s the tech around, but then there are also the communities itself, which are really, really valuable, right? So that hundreds of people come together on that place, like type in that URL, for example, and then meet at that forum or, you know, that, that place, that community place. So is that my graded are people migrating or is that as easy? Because I feel like there might be people that say, well, I’m on spectrum. I’m going to this community on that. You’re out, but I’m actually not on GitHub in, you know, in that space, which I think, you know, on one hand it feels like, well, what’s the difference here, but I can imagine that it’s not that easy. Right? So there’s like the tech around the community, but then the real heart of the community is the people that choose to be there to go there every day and, you know, provide benefit or value to other members. How is that what, what, what do you think about that? Spectrum

Max: [00:05:43] was always mainly used by developers. A large percentage of our users already authenticated with Kitsap even before we were bought by Gates. And most of the communities were around open source projects, or we also had some design communities. Those are gonna have a harder time migrating somewhere else. But most of them were open source communities, definitely the most active ones. And so I think those will migrate just fine. I think get up discussions is a great fit for that since it is based on a repository and GitHub and open source projects are just repositories, don’t get up. Right. And so having that community right there will actually be huge for the vibrancy for those communities and enable a lot more open source projects to build communities around their projects. I actually think that part of our fundamental assumptions about spectrum were, or parts of our fundamental assumptions were incorrect. We wanted to build a space where large communities do the order of magnitude of tens of thousands of people could communicate and connect with each other. But actually that doesn’t work super well. When you have 10,000 people in a community, you don’t really feel connected to any person anymore, right? Connection happens at much smaller, much, much smaller scales. And which you can see by the sort of prevalence of group chats now, right? Like you have telegram, you’re signaling for WhatsApp and within those chat messaging platforms, everybody’s a part of 20 groups, right? And you feel connected to each and every single one of those groups, but they’re much smaller in scope. They’re much more specific which allows much more of a community feel to build much more of a sense of community, much more of a connection to build. And so I think actually there is probably a way where you can scale that sense of community up to a larger scale, that you can definitely have a community of thousands of people I think that’s possible. But there has to be much more of a mechanism of sub groups within that. Right. I don’t know exactly what that’s going to look like. Somebody who’s going to figure this out eventually. But if you think about, for example, football fans, right? If you look at Liverpool, they have a. Fan base of, I don’t know how many hundreds of millions probably. Right. And they’re spread all around the world, but within that massive group of fans within that massive community, there’s these tiny subgroups of the fan club in Vienna, the fan club in Istanbul, the fan club in wherever. Right. And then even within that, there could be even smaller subgroups. Right. You could have your friend group of the fan, a fan group of Vienna, right. And so then that’s the 10 to 20 people you feel directly connected to, but yet you’re still part of this bigger community. And so in real life, it kind of already works that way. The online platforms just haven’t really been able to mirror that real, real life engagement. I would say if that makes any sense. I don’t think any online community necessarily has figured out how to represent both the large groups as well as the small groups. I think actually the one that’s the very closest is Facebook groups. I actually think Facebook groups for what it’s, I mean, it’s on Facebook, which kind of limits its usefulness, but actually Facebook groups works really well. And a lot of people are in very many different groups and sort of feel connected to many different communities through Facebook, which is very fascinating. But other than that, no, one’s really figured out how to make the, how to scale online communities beyond a couple of hundred members of most.

Michaela: [00:08:40] Yeah. And so when you build spectrum, was it mainly about the task and then you were all thinking of, you know, how many people do you want to allow in a student. Group and what interactions you’re facilitating and all of that. But did you also see the community itself? So how did you get the first people using your product? What were some of the strategies that you had there? Spectrum came to

Max: [00:09:03] be because my two co-founders Brian Levin and Bryn Jackson have a podcast called design details and they actually started a podcast network around that podcast that at the end, I think contained eight or nine podcasts. And it was all design and development focused podcast. And they created a Slack community for this network and where they want it to connect to all of the listeners together. They wanted to answer questions that they want people to chat with each other, basically build a community around that network. And eventually that’s like group that Slack workspace grew to eight or 9,000 members. And then Slack came to them and said, Hey, it’s really cool what you’re doing here, but either pay us or go leave somewhere else. And I think it’s Slack costs $5 per member. So they were looking at a bill of $45,000 a month for a free community that they were running, which is obviously not something they can pay. And so they looked around and they didn’t find anything that would sort of. That fit their niche, right? They, they wanted the community to Republic. They want people to be able to read the content, even when they’re not a member, but also they wanted it to be real time chats. They wanted it to be, to feel like the multiple people were there and talking at the same time with each other. And so they started building spectrum just for their own podcast network, which is where the name actually comes from because their podcast network was called spec FM. And so spectrum was sort of perspective and community platform. And interestingly enough, they had a problem. They, they were using one of my open source projects, style components, and they reached out to me from via Twitter because they were having an issue with it. They found the bug and I knew of Brian Levin and Bryn Jackson, but I’d never met them in person. I talked to them before. So I, I was a big fan of their podcasts and their work. And so I said, look, you have a problem. Don’t worry. Just give me access to the repo. And I’ll, I’ll take a look and fix it. And they gave me access to the spectrum reap, and I looked at it and I told them, Hey, I need this. Like, this is the platform I need for my open source projects. Right. I’d been building communities around my open-source projects for a lot, for awhile, but none of the platforms for that were very nice, like get like basically there was, gets her or gets up issues, but get the issues there for problems. And it gets, there was just one massive chat room, which doesn’t scale beyond 10 members. And so I said, look, forget about whatever I’m working on. I want to work on this and I want to make it more general. And so that’s where spectrum was born. And that’s also how we seeded it. We built the initial version and then immediately onboard at the eight or 9,000 members at a time of spec of him onto the platform, and immediately had that first community there, which was huge for us because that kicked up the flywheel of people joining over time. Because those people in those old spectrums, awesome. I’m going to create my own community there. Right. And invite my own people there. And so that’s sort of how it started growing and that’s why it really grew in the design and the tech communities. And why there was so many open source projects using. Yeah.

Michaela: [00:11:39] Very, very cool. And so spectrum itself, is it open

Max: [00:11:42] source? Yes. Then we asked her about a year of working on it, but we open source the entire copays. If he goes to getup.com/with spectrum you can look at it. It’s, it’s one big Monterey pro basically that contains all of our servers, all of our clients, everything we ever built. It’s all completely open source. It’s terrible code, please. Don’t look at it too, too closely. I love product what we did cause we did a lot of shipping and not a lot of cleaning up, but it works and it’s open social people to look at. It’s a, it’s quite funny because I think spectrum is quite a messy copays personally. Like it’s not, it’s not the nicest code I’ve ever written. I didn’t have as much experience then as I do now. And, and also we were just trying to ship as much as possible. I’m trying to figure out, trying to find product market fit and then eventually the business market fit And it’s funny because sometimes I see tweets of people saying, Oh, if you want to see a really well architect, the copays, go look at spectrum. And every single time I see that I like please, please. Don’t like, that’s not, it’s not that well, I can think of, it’s kind of a pain to work with. I don’t know. Yeah,

Michaela: [00:12:37] I know you cannot respond to every tweet like that. Like

Max: [00:12:41] exactly. Yeah. I can’t really be like, ah, hello. Yeah, please. Don’t look at my work. It’s really bad. That’s not a good idea. I can’t really do that. But it is, it was very interesting. I do think spectrum helped a lot of people think about how they build apps, right. And it has a lot of people to learn and it was quite fascinating to open source it and see how many people actually cared. Because there is so few food products out there that are open source, right? Usually when something’s open source is either a toy product, the toy project that somebody builds, or it’s a library that’s very encapsulated, very small, but very few people open source, entire apps, right. Century being one of the many, many exceptions and one of the most famous ones or ghost, for example, but there’s only like a handful of those. And so adding to that list was quite interesting how much people responded to that and how much they liked it.

Michaela: [00:13:27] Yeah, because I mean, I think so I’m a, for example, I’m learning Peyton things two years now. And I’m also a little bit struggling with, how should I actually go about learning Peyton. Right. And that, that has to do that while I’m not employed as a heightened developer right now. Right. Which also limits, you know, the. The amount that I can actually spend on it or that I spend on it. It also means that I don’t have like a network of people around me that I can learn from, right. Like code reviews that you have. If I would be a Putin developer right now, I would have like my colleagues also writing Python code and I can learn from them. Right. And so open source is definitely something that I’m also sometimes doing. Right. I go and look at Ida patent application to just understand, you know, how ID architecting something, because these are the questions that I still have. Right. I don’t have the question on which type to use or how to do it area or how to do a list, sorta whatnot. Right. So I know those things already from my other programming adventures that I did, but I’m more interested in, Oh, I’m coming from the job are object oriented C-sharp world. Right. So how do you do that in Piketon and, and how would you, you know, structured applications and open source is something that sometimes helps me, but it’s very hard to find like either like a good application again, because sometimes you find application and I’m looking at it. And even though I don’t feel like I’m the expert for piping, I can say, Oh, I shouldn’t call it. What’s going on here. Right. And then it’s big enough that it’s interesting to look at and has, you know, good quality and you can learn something from it. I think it’s very, very valuable. I can totally see how people are. Yeah. Interested in, in doing that and learning more about it. So, but now you, you build spectrum and then it was actually acquired by GitHub. Right. And so you’d done because it was acquired, you worked at guitar building, you know, GitHub or spectrum into get-ups right. And get into YouTube. How did their view changed on software engineering practices on good code? Did you experience something like that that suddenly you were in a team and they are all, you know, like working together and you can learn you know, you can improve your skillset, sat there with, with the input of your peers or how, how was that for you?

Max: [00:15:36] Because we very quickly realized that spectrum just wasn’t built well enough to run a Kitsap scale. It was very fascinating to learn how Kitsap scaled itself, because obviously when they started building gets up 10 years ago or however long that was, they also didn’t build it to handle the amount of traffic that it has now, because GitHub is massive. It’s one of the, I think, 10 biggest websites on the planet, maybe 15 biggest websites on the planet. It’s, it’s massive. It, it gets absurdly much traffic. And so it was very fascinating to be at Kitsap and to see How careful they are about the code they write and how many conventions and constraints they built into their systems, particularly for the developers. So that any code that that is that is written is good enough to run at that scale because most people have never worked at that scale before, unless you’ve worked at Kitsap before, or one of the other 15 companies, that’s this big, you have no idea how to work with that scale. Right? And so a lot of the work that many teams that get to did was building tools for other developers that gets hub to guide them towards success and to avoid expensive database queries, to detect them, to warn people when they were writing them, stuff like that, where they built a lot of internal tooling to make sure that they could run at scale and that they could continue scaling into the future. And I actually think a lot of what I, what I learned there was how important constraints are with programming. You have all the options, you have all the possibilities, you can do whatever you want, but a lot of what it means to be a senior or an experienced developer is knowing which 90% of those options are actually trash. And you probably shouldn’t do them because you’re going to run into problems. Right? A lot of the choices that experience developers make are based on experience and I’m talking to other experience developers and they avoid future problems, right. By, by making good decisions. Now you avoid a lot of future problems and sort of. Avoid running into troubles down the line. And that’s something I’d never done before with spectrum. And so with spectrum, we actually had a lot of scaling problems when there’s this sort of rule of thumb that started people say where every single time you get a new order of magnitude of users, you run into new scaling problems. And for us, it happened like that, like clockwork. When we ran from zero to a thousand users at the, when we onboarded our first community, we immediately hit scaling issues. We immediately had to move away from Firebase, build our own backend because Firebase was couldn’t sustain the load anymore. Then when we went from 1000 to 10,000 people, we hit the next set of scaling problems. As soon as basically as soon as the 10,000 persons joined almost to the day we started having server issues. And so we had to resolve those, then everything went fine. We’re going, we doubled, we tripled, we quadrupled. We went from 10,000 to 9,000 people. No problem. And then as soon as we hit the a hundred thousand monthly active users, the next set up problems, they didn’t get in with them releasing our server. Our servers were crashing constantly. And it was very fascinating how these, this sort of order of magnitude step change of traffic really impacted our stability. And so get ups really focused on making sure no one that gets up some writes code that doesn’t run it, their order of line of traffic, that no one, there can even commit something to the code base, no matter how inexperienced they are or how much they fork rails, for example, that could break their systems. And then when something breaks, they have a lot of infrastructure, of course, around that, to monitor, to fix those issues, to roll back deploys so that when problems do arise, they don’t impact many users. And it was fascinating to see that and to see how many constraints. They put on people, but they were very productive constraints as a developer. They made me free to build the stuff that I wanted to build without having to worry about scaling, because I knew if I did something that was bad, there would be an Arizona. Right. See, I would throw an error. There would be a winter error. There will be a test error, right. Like somewhere, somebody somewhere would catch my stupidity and tell me to do it differently. And so that was actually really fascinating. And they learned a lot about scaling engineering and then organizations there.

Michaela: [00:19:31] Yeah. And so it seems that this is also very specific. So some of the engineering practices, some of the tools, some of the processes are really made for the scale there. But now if you’re going back and I know you’re now building a new startup, so what do you take away from that? What do you say? Well, you know, this is overkill not needed for me right now in my next startup. Right. And what are some of the, the, the practices the knowledge that you acquired your thing? Well, I’m going to build that in from the start and get go, because I don’t want to run into issues. Long-term with maintainability, readability of the code base, many things.

Max: [00:20:08] We, we made many, many mistakes, or I should say I made many of those mistakes as the main technical person, that spectrum, I made many tech choices, mistakes. And one of the main things I really learned is that. Using technology that’s widely used is a very good idea. There’s a reason people use Maya’s quail or now Postgres, right? It’s because those two databases, they run and they keep running no matter what scaling crap, right? Like it’s a famously uses my SQL and is the 15th biggest website on the planet. And I think they’re now starting to hit the limits of that. And they’re starting to have to really work around a lot of these problems. But they managed to become the 15th biggest website on the planet with my SQL. So why would you use anything else? And I’ll be like, there’s no reason to choose anything that is less battle-tested because, you know, if, because if you end up being the 15th biggest website on the planet, you can fix my SQL. If you don’t end up being the 15th biggest website on the planet, it doesn’t matter. Right. It it’ll still work. And at spectrum we chose a database that was a lot less populated. What’s called rethink to be the company behind a shutdown because they weren’t financially successful. And the database system just wasn’t as well built as my, as going reading be. And we ran into a lot of scaling troubles because of our database choice or because of the database choice I made. And so I learned to rely on battle, test that technology, even if it’s under equals boring, even if it’s something that a lot of people use, that’s a good thing, because that means it’ll scale with you. And if you have a problem, you can Google it right with rethink to be almost nobody used it. And so when we ran into problems with our careers, when we ran into problems with the database engine, we Googled them and we found nothing. There were, there was no information, which is very different if you’re using MySQL or Postgres, if you Google any problem, I guarantee you you’ll find 10 pages of Google results with people explaining different solutions to the problem, how they approached it, how they fixed it, how it held up over time, right. And that that sort of Corpus of knowledge and that Corpus of experience is incredibly valuable when evaluating technology choices. That’s really one of the main things I learned, which is obvious in hindsight and is, it’s a common thing to say. Don’t use boring technology, use things that are proven to scale. But it’s really hard to keep that in mind when you’re using technology, because you will, you’ll see something that’s fancy and new and you’re going to want to use it. And it’s, it’s cool and everybody’s using it. And you feel like everybody in Twitter is talking about it, but if nobody’s used it at scale before, you’ve no idea if it works out right. And you can only, I think there’s often these tools have upsides, but the trade off of the missing community, the missing usage, the missing scalability, isn’t worth, there’s some tools where that isn’t the case. So I would still evaluate that sort of as a trader. Right. Does this tool make me so much more productive that I can handle production problems? Is it, is it production critical at all? So there’s like, there’s, you have to think about that, but always err, on the side of choosing boring technology, that’s proven to scale.

Michaela: [00:22:52] Yeah, I think that’s a, that’s such a good advice. And I also ran into dad when I was I was choosing which, you know, static site generator to use. And like, they’re, they’re the ones that, you know, right. Like Gatsby or Jacquelyn, I think like this. And then there are a lot of others, like tiny ones. And I was like, Oh, this is one that nobody knows over there seems really promising and interesting and you know, like shine in you. And I think it was also curiosity. Right? I think that a lot of engineers are very curious. I am curious. So I went with that one. But what I forgot to calculate is how much time I’m actually spending, building my website with that acquiring knowledge, then knowing how to use that thing, but also at the same time, learning that there is not enough support information around to, to get me out of errors that I run into, or maybe it’s even, you know, like the thing itself it’s broken. Right. And it also reminds me of, I actually tweeted, I think recently about this where some tools make me cry. And it was like when we, when I was at Microsoft and I had to use some internal tooling, that was really new and we just build it until we were doc fooding it. And we were forced sort of like to use that new thing, which is it’s a good thing. Right. But on the other hand, I couldn’t just go and search for the problems that I run into because it wasn’t even existing outside. And so internally people were building it, they weren’t really like, you know, supporting others or writing blog posts. So it was really a bad experience and something that made me think a lot about so important that if you’re stuck, that you can find information that gets you out of this, that gets you unstuck, it gets you out of this, you know, stuck situation and maturity of software projects and community and livelihood. Right. It’s definitely something that’s, that’s important here.

Max: [00:24:43] Absolutely. I think this is. Even more critical in areas where you don’t have a lot of experience that the less, you know, about a problem, the more you shouldn’t rely on boring existing solutions. I know nothing about databases, so I should probably use my SQL and Postgres because I know that those are gonna work. And any problem I have, I can find a solution for, I know a lot about react. And so I can, I know I can, for example, use Preact instead of react, because I understand very deeply how react and Preact work and I can debug my own problems. Right. And so a lot of this also has to do, like you said, with familiarity, right? If I’m familiar with, with a certain problem space, if I’m familiar with the tools within the problem space, I have a lot more leeway to use cutting-edge solutions. If I’m in a problem space where I have a NOAA experience where I don’t know how anything works, if that doesn’t make sense to be on the cutting edge, because I’m not gonna be able to resolve my own problems. And so I think, like I said, that that really ties into it, that sort of familiarity that understanding of the ecosystem is really critical. If you’re using something on the cutting edge.

Michaela: [00:25:39] Yeah. Yeah, definitely. And so maybe, I mean, what me too is very often startup founders, especially ones that are new and maybe they don’t even have a tech background. Right. They’re like what tech stack should I use? Grade one? What what languages and so on, should I build up? And most of the time the answer is, well, the ones that you’re mostly familiar with, right? So if you are a Python developer, probably just stick with Python. If you’re a Perl developer, maybe it makes sense, you know, to update your texts. Most of the time you’re like, Peyton is just fine or Ruby is just fine. Right? You don’t have to have, like, you don’t have to learn JavaScript and react if that’s not where you’re coming from. But so now for your new startup, I want to talk a little bit about the app. So you’re going to do something new. How are you going to, you know, how are you going to come up with the idea? And maybe with ties in a little bit here, it’s like bedrock. So recently you released a new product called bedrock and that’s like everything you need to know or everything you need to have to build SAS apps. Right. So it would be authentication. It would be emailing a little bit community subscription payments and all of that. Right? So sort of the pilot plate code of SAS applications that people can use. And when I saw it, I mean, it, it got really viral on Twitter. So people were really like, very happy to get that. And and I think it’s one of those problems that you see people running into. And so how was that for you? I mean, it looked like super popular. Was it also from the sales perspective, was it as successful as you hoped and, and will the next product that you’re working on being that space or will you go somewhere completely Allison? How are you going to, to tackle the next problem? How did you come up with this idea?

Max: [00:27:27] Sure. So I’ll start from the beginning. I I’ve spent the past, basically all of my career building JavaScript tooling. I’m sort of, I would say mainly well known for making a bunch of open-source projects, like react polo plate and style components that are cutting edge, new ways of doing things right. And I have a very deep understanding of react and JavaScript tooling and to have a good overview of the ecosystem. And I know how things work at a very deep level. And particularly at Gatsby now over the past year, I really dove deep into that because Gatsby basically is just a bunch of open source 20 combined in a very nice way. And what I realized was that I kept building SAS products on the sides, but I kept doing the same setup every single time. And every single time, it kind of sucked. Like I have enough experience to know, like I said, to avoid 90% of the bad choices, but in the JavaScript ecosystem, it can sometimes feel like 99% of the choices are bad. And you have to just make that 1% of choices to make all of the tools that you use work really well together. And making all those choices right, is really, really, really difficult and takes a very long time. When I set up my last, my last sort of SAS product feedback Fisher, I probably spent at least a week just setting up the boilerplate code, right. Just setting up TypeScript, prettier easily in payments, authentication database, a GraphQL API, graphical client, all of those stuff, all of that stuff. So that it works well together and sort of is easily usable. And doesn’t just break down after a while. It’s actually really difficult. And even after a week, I wasn’t happy with where I was at, but we just kind of have to build our product at that point. Right. Like you can only spend so much time setting up. And so after that, I actually took what I had after a week. And I said, okay, I’m going to sit down and I’m going to make this as nice as possible. And I spent at least three weeks of evenings and weekends just building Building a boilerplate really like I just plugged together glucose, right? Like it’s basically a bunch of configuration and glucose so that everything just works really well together. And now it’s at a point where, for example, if you change, if you add a required field in the database, your seat data for your end-to-end test is going to throw an error that, that the required field doesn’t exist. And the entire thing from tobacco just works really well together from testing over client, over backend, over everything you need just works really, really well together. And I had that, I had that boiler plate and I was like, well, this is kind of nice. Like, this actually feels really fantastic to work with just yesterday. I set up a new version of change feed one of my SAS apps. Cause we were we, we kind of need to rebuild it because it takes stack. Isn’t very nice that we chose there and slowing us down a lot. And so I basically rebuild all of the core functionality in an hour. Right. I took bedrock. I added a bunch of stuff to the API. I added some fields to the client and it’s ugly as hell. Like the client, doesn’t it it’s completely front-end list. So the client looks likely to sell, but everything works. And that only took me an hour. And of course there’s a lot of stuff to make it production ready into, add to make the build the client of course, make everything nice at onboarding, whatever, but it works right. And it has everything I sort of need. And so long story short, that’s why I thought about selling it. Right. And I was like, well, if I think this is nice and it’s, if it took me, somebody who really understands this problem very deeply into really understands that ecosystem deeply. If it takes me four weeks to set up something that’s good, that that’s really good. And that, that that sort of saves people time and is better than what they could do themselves. Then maybe it’s we are selling that, that sort of knowledge and that experience to people as a boilerplate and people were kind of excited about it. Then I think by now I have about a hundred pre-orders somewhere in that order of magnitude, 105, I think, which is really exciting to see. It’s kind of funny. I, I honestly didn’t expect to get a hundred pre-orders because there, there isn’t even a demo on the landing page. It’s just a landing page to explain what I want to do. It doesn’t even show anything yet. And yet people, a hundred people pre-order, which tells me two things. One, the community really trusts me, which is fricking scary. Like that is very scary to, for me because now I have to deliver and I have to deliver something. That’s actually as good as I promised, which I think I can do, but it’s a lot of pressure. And then secondly, there’s a, there’s a need for this, right. People struggle with setting up JavaScript project very well. And they’re willing to pay for a solution to that problem. And so that’s exciting to see, I don’t think I’m going to make this, my next startup per se, but it’s a really nice product to work on. And it’s just something that I personally really care about and I really enjoy doing. And so it was just like a fun, fun project, if that makes sense. Yeah. When I

Michaela: [00:31:46] started tweet was like, wow, that’s such a great idea because I was exactly imagining something like this that you run into the problem over and over again, you have this expertise, you have the wig Dan sort of, right. So you’re there, there’s obviously more work that you probably could in now to make this even better than what we would do for yourself. But in general, there’s like this foundation. And I mean, especially if people want to start a SARS app or, you know, do their own startup, I hope that they’re smart enough to realize that, you know, I think right now you’re selling it for 150 or 149 bucks. And later it’s like 200. I mean that this is like a bargain, right? Because I mean, if I’m spending a month, I could do. And as you said, they probably spend two months. They could really think about their, their solution. They could talk to customers, they could, you know, find out which problems to solve instead of doing that work for you. So I think it’s really a fantastic idea to, to go that route and do that. And it’s also great to see that people are backing you up. I think, I mean, obviously it’s frightening, right? If you have like, you have a platform, you have like a community around, but it also see you also, I think it’s also really beautiful to see that. They are people who care about what you’re doing and who trust, you know, you and I experienced you as a very authentic, very honest person. Right. So it’s not like, Oh, I’m doing everything that I do is really cool, but like, Oh, I’m making mistakes, but I’m learning from it and I’m sharing it here. Right. And so I think this is definitely something that people can, they realize, and, and this is why they are there right beside you. Right. And so but now we’re coming, you said, this is probably not what you’re going to do for your, for your new startup. So how, how is that? No, dis tricky, first part, like we have this idea, you want to do something and now you have to start in one direction. Right. And so how are you going to tackle that problem? And, and yeah. How do you think that you can set yourself up for success in the right direction? I think,

Max: [00:33:48] Multiple, multiple things. One is being very clear about what I want to accomplish. I want to build a billion dollar startup in my life. That is sort of the thing I want to try next. I’m not right now. I don’t want to build a, a indie hacker business. Right. I don’t want to build something on my own and I I’m perfectly happy to do that. Right. But right now at the life stage, I’m at, I don’t have kids. I’m relatively young, still. I don’t have a lot of commitments. I have the opportunity to try and really build something that changes the world. And so I want to try doing that. And that immediately already tells you a lot about the problems I can tackle, right? There’s problems I can tackle with that, that are big enough. Like the, basically the promise has to be big enough to eventually be worth a billion dollars. Right. They have to be really big problems. If you’re solving something that’s a small problem. It’s never going to be a billion dollar startup. It might be a nice indie hacker product business, but it’s never going to be a billion dollar startup. And so I know that that already deletes 80% of the ideas I have probably if not even 90%. And then the other, the other fundamental assumption, or, or axial I have is that I want to build something that I use, that I need myself. And that doesn’t necessarily mean a problem that I have myself right now, but something that we’re, if it exists, I’m an, I’m a user. Right. And I can think about what I needed and talk to my customers and figure out what they need and sort of reconcile that with my own needs, for the product. I don’t, I’m not very good at building stuff for other people. I would say, like, I, I’m fine at doing that, but I’m much better and much more motivated if it’s something that I want to use myself and that I want to make better for myself, where I see, ah, This part of the app kind of sucks, right? Like I want to fix this NAF part because it’s really confusing. Right. And no one needs to tell me that. I just feel it because I use the thing every single day. And so again, that restricts the problems based on a lot, right? There’s only so many things I know so many problems I care about. And so immediately that restricts the problems I can tackle a lot. And where exactly that Venn diagram of big problems that I have sort of overlaps. And then ideally that the other part of this is that I want to solve something that businesses are willing to pay for it because we spectrum, we had, we built a product that many people found valuable in that many communities found valuable, but we never managed to get anyone to pay for it. We never made any money. And so that’s why eventually we just had to sell because we ran out of money and our server costs were exploding, but we didn’t, we that doesn’t correlate to an increase in income. And so now I want to build something that businesses are actually willing to pay for it that solves a problem for them that they’re willing to pay for. And so again, that restricts the progress based on even more. Right. And so the more of these sort of axioms, I add the more of these properties I want to have in my idea, or in the problem that I want to solve really that the smaller, the space of possible problems kits. And I have no idea what I’m going to build. I have a couple ideas that that I want to maybe explore. We’ll see. But right now I think. The main thing I’m doing is talking to people. Right. And I’m doing a lot of customer research. I’m talking to people I’m talking many to developers because I kind of want to build something for developers, not for again, I want to solve my problem. Right. And so talking to a lot of developers about what they struggled with day to day, what their work life looks like and thinking about how one could make that easier. And we’ll see where that leads. I have no idea. It’s very scary. It’s sort of a pretty scary time in my life right now because I have no idea what I’m going to do. But it’s fun. I’m looking forward to it. I’m looking forward to the challenge and I’m really excited to be back in sort of back in the trenches of trying to figure out how to leave my stamp on the world, if that makes any sense. Yeah. Yeah.

Michaela: [00:37:19] It definitely makes sense. And I mean, I think we are in very different situations, as you said, right? You’re looking at your own situation, do you think? Well, right now I’m really free and I want to tackle this 1 billion thing. And for me it was more like, well, I’m completely not free. Sorry, I’m competing. I have my two kids and I want to spend a lot of time with them. But on the other hand, I want to go. And for me the thing, he was more, how can I use the time that I have right now to set myself up for success in two, three years, right? When my kids are a little bit more grown up. And I think that I’m getting closer and closer to that clip where I feel like, well, maybe, you know, my time to build something really cool will start soon. And And so, yeah, I think this, this all, I, it really resonates with me, like thinking about, you know, what can I actually tackle? What do I want to do? Right. What is really my, my ambition to, to do here and then trying to figure out. But I still think that even if you take this Venn diagram, it’s a huge problem space still, right? So there are so many things that you could tackle. And so if you do something like, do you try to get now this idea by talking to people, or are you going to build a little bit and testing the waters? So, so what will be the next steps to really understand if there is there’s a market for it? Or, or do you say, well, I’m completely committed. This is the idea I’m completely committed. I’m going to build it. I give it a year. Or is it like tiny bats that you do? Like, Oh this week I’m trying out, you know, I’m sending a tweet and see if people respond or I’m building like this little email list about something. How do you, how do you see that? I do all of

Max: [00:38:57] those things. It sort of depends on how serious I am about an idea and how much I believe in it, myself. Right. There’s thanks to my audience. There’s a lot of things I can validate just by tweeting. Like you said, particularly if I’m building something for developers, I can tweet, does anyone else else have this problem? And then I will feel the resonance or not. Right. Maybe nobody will respond or maybe a thousand people respond. Right. And sort of in that spectrum, I can tell how much that problem resonates with people. And then I can think about how would I approach solving that? There’s a, there’s a little validation that happens that way. And then the other thing is that I. Just ping friends and colleagues that I’ve worked with before or people that I know are using certain technologies. And I talk to them about how they’re using them and what they’re struggling with. And usually I go into those calls with some sort of hypothesis, right. I think maybe there’s this problem that maybe I could solve this way. Let’s see if they have the problem. And if you ask people straight up, do you have this problem? Would you pay for a solution if they’re friends of yours? They’re probably just going to say yes. Right. Because they’re friends of yours. They’re like, they’re probably not going to pay for it, but they’re still going to say yes. And so I actually go into those conversations and don’t even talk about my idea of what I want to do. I asked them what their problems are and then I look and listen and see if they even think about that problem at all. Right. And if they sort of stumble upon it themselves, and if they, if they’re annoyed by it, if it’s grinds their dead, their gears, right. Like the sand in the gears that grinds and it’s been really fascinating. It’s helped me invalidate a lot of ideas and, and tell me that people probably wouldn’t really care about them. Which has been really fascinating to do. I learned that from a great book called the mom test. I highly, yeah, I know that one.

Michaela: [00:40:22] Yeah. When you said that, I was thinking I should have mentioned it, but

Max: [00:40:29] it’s really well, it it’s helped me invalidate a lot of ideas. I have very, very quickly by just talking to someone for five minutes and being like, Hey, you know, what are your problems? What are you struggling with right now? What do you care about? And that very simple approach would be to the tests. We do daycare about your. Problem. And then could your solution solve that problem or not? And it also helps us cover other problems, right? Like I’ve discovered other problems that people have. And now I’ve talked to, I don’t know, 10 to 20 people and I’m starting to see patterns. Right. I’m starting to see, Oh yeah. A lot of people care about this one problem. I wonder if we could maybe solve something there, maybe there’s a solution for that. Right. And so that, that process is very, it’s very fun right now.

Michaela: [00:41:02] Yeah. That’s so smart. It’s so smart because it’s not like just, Oh, I’m going to build this and then you build it. Right. And you’re spending so much time doing it. Then I think it felt, feels maybe a little bit slow. And because you’re not really building something, which I think everybody wants to fill it, rightly we want to do, and we want to make progress. And if you just, just talk to people, it doesn’t feel like progress. It feels like, Oh, I’m still, you know, even before my idea phase, but this can pay off. So I mean, tremendously, if you’re studying and you’re going the wrong direction, I actually tweeted recently about that the tiny steps actually bring you the big success and, and, and do you have to be in the right direction? And this is also what I, I try to be very patient with myself thinking, well, you know, my steps are tiny right now, but as long as they are going in the right direction that I want to go and, you know, have a go completely straight. Right. So you, you learn and you bounce back and you think well, but if you’re open enough to see, well, this is the wrong direction. Now I have to go the other way around. And you know, even six sucking your way to success. I think this is so important and I see that. Yeah. I think you will be very successful. I can can see that. And so I’m definitely going to invite you again. Yeah. In, in a couple of years, right? I know we talk about like how it went

Max: [00:42:19] there. Yeah. We should

Michaela: [00:42:22] do that. Like we do that like in a year, maybe we do it, like go on a journey. Right. So in a year we talk again and then in a year we talk again and look how it goes.

Max: [00:42:34] Exactly. Yeah. I do think one of the things you, you said is really important is, is realizing when you’re doing something that’s wrong when you’re building a company or when you’re building a product, you’re so enamored with that product that you forget to think about. Am I even building the right thing in general? Right? You’re so in the deep, in the specifics you’re showing, Oh, which button do we put? Where, what feature do we build next? What features should we not build? What is more important? What do our users care about? Then you stop to think about the higher level. Does it, is this even a problem we’re solving, right. Is this even something that people care about at all? Or should I do something else entirely? Right. And I see a lot of startup founders particularly end up with problems or solutions to problems that no one cares about. And they never stopped to sort of reflect on, am I even working on the right. Thing right now, like, am I even doing something that anyone’s going to care about? And there’s, there’s sort of different there’s different problems to solve, right? Some are more immediate, some are problems that are problems right now. And people try to solve them right now. And then you very quickly learn whether it’s something that people very much care about or don’t care about whether you have product market fit or you don’t, if you sort of want to talk in the startup lingo. But then there’s sometimes there’s founders that are working on stuff that is way in the future, right. They have an idea of how the world should look like in 10 years and they want to help people get there. And that is really, really hard because at that point right now, no, one’s going to care, but maybe in 10 years, people care and you have to have a lot of conviction to sort of stay on your path, stick true to your values and goal the 10 years to see if that’s actually the future. That’s something I’m way too scared to do, right? Like I, I don’t have time to wait 10 years. I only have very limited time on this earth. And I know a lot of funders that are doing that and I respect the hell out of it. Right. But I’m, I’m way too scared of that. I would much rather solve an immediate problem right now where I know that people care about it rather than trying to do something so big. And so future that it would take decades to realize. Does that make sense?

Michaela: [00:44:38] Yeah, I think it’s, it’s painful. I mean, it’s painful to look at what you have invested in what you have spent your time on and to say. Honestly, I have to do something else here. Right. It’s it’s like I was standing, so I was, I was studying in London and then there was this really cool discotheque where you can go in the night. Right. I think it was called February or something like that. I forgot. And so we got a ticket there and we went there probably at, I don’t know, maybe it was like one in the morning or something or 12. And there was a line around like one of these huge buildings and we really wanted to go in, first of all, the ticket was expensive. Right. And say, if we wanted to see it and experience it. And so we stand in line and we stand in line for an hour and I say, you know, we didn’t even come, you know, like sit around. So what are we going to do? But then, because you’re already standing in our, like, it feels like, Oh, any minute, anyway, we stood actually three and a half hours and it wasn’t a morning when we could enter it. Right. And so it, and it was really this problem off, you know, like you’re standing already in line, so are you going away now? Or, and you leave all this waiting time for nothing. I was really horrible. And I think that this happens also to, to pounders. I mean, it, it also happens to me that you feel like, and, and it’s, it’s a blurry line. Like it’s, Oh, is there not traction because I’m doing it wrong? You know, is there not traction because I don’t have an audience yet? Or, you know, nobody goes to, I mean, there’s also build it and they will come if it’s not true. Right. So. It’s a little bit different, I think for especially people that don’t have like a platform and an audience yet to say, well, I’m tweeting about this amazing thing. And it could be that I am getting zero likes. So one like, and it doesn’t green really mean that, that what you’re building is not interesting. And so, you know, it’s not always easy to really understand is that the wrong direction or is it not? And then to be as honest to you and take this pain to say, well, I think it’s the wrong direction. Let’s do something else. Let’s start over. Yeah. So, so what I try to do is I try to have my, my activities always have one purpose that I know it will definitely work out. Right? So I’m doing this stuff and maybe the whole idea of turns out, but at least I know that whatever happens, there are three steps that are going into the right direction, right. Is it building an audience or, you know, building a community or learning something about the tech that I know I will use. Right. So I have, I have a couple of different goals around something where I say, well, maybe it doesn’t completely work out, but I can for sure say that those three checkpoints that are on my way to success, those three are going to work out. Right. I don’t know if that’s something, how you think about things, but this is, this is really my salt pattern pattern for everything I do. And very often it’s just learning right? Learning about. You know how to blog or how to do a podcast or, you know, something like this, which brings me to the right, you know, brings me closer to where I actually want to want to go. And then I know I have it. I have control over that.

Max: [00:47:49] Absolutely. That’s one of the big reasons I joined spectrum was because I said, there’s no downside, right? I get to work with two fantastic designers that I know online that are very famous for their great work. I get to watch them close and learn about design myself. I get to be a technical co-founder, even though I had no idea how to do that, I could learn how to do that through spectrum. And then you worst case scenario, if it doesn’t work out at all in one and a half, two years, I’ve made two new friends, at least if not many more and learned a ton about how to build a startup and what that even means. Right. And so really even if the product itself had gone in a completely mood, I knew there was no, like, I wouldn’t have any regrets about it, but I knew it could only work out and any success at the proton on top of that was just a bonus. Right. There’s the fact that we got acquired, but gets up is just a bonus, right? Like that’s sort of like that happened and it’s fantastic. And it was a great experience, but it’s not something that was required for it to be a success in my mind. Right. It was always already a success just by the fact of me doing it. And I, I think very much in the same way that you do where I sort of consider the, the whole, the, the implication of everything that I do on a sort of broader scale, right. It’s not just, I’m building a startup, is it going to be a success or not? And that sort of binary, the outcome is good or bad, but it’s. How much do I learn? Who do I get to know? What do I, what do I do? Do I enjoy my life? Do I have fun? Right? Like all these things can tie into it and can make something a success. Even if maybe directly it isn’t the success. If that makes any sense.

Michaela: [00:49:14] Yeah. That’s exactly how I approach things in life. So I think I’m fairly new. I’m happy that I got some confirmation bias here.

Max: [00:49:26] yeah, maybe. Yeah. I have no idea.

Michaela: [00:49:30] Yeah. We can see, maybe people can reply to this episode on Twitter and tell us if they are the same pattern.

Max: [00:49:37] I really curious if anybody else thinks that thinks that way. Yeah, absolutely. Please let us know. I’m I’m I’m super curious. I only start

Michaela: [00:49:43] things where I know it can, can only be a success and it can be a bigger success. Right. But it’s sort of the things that I’m doing are already success, right? Independent of how it turns out. I mean, yeah. So, well, I took already much more time than we actually that I actually set out to talk with you. So I already stolen a little bit of your day-to-day, so I I’m going to end it here, but we did promise that in a year I’m going to schedule again and then in a year we are going to talk again because I really enjoy it. I could talk on and on. And so I’m really curious where your journey goes and how, you know, how you think about the things that we talked about today in a year from now and 10 years from now. So thank you so much, max, for being on my show today, talking with me about all. All these really interesting topics and getting, picking your brain and getting a little bit an idea of how you approach things. I think this was so valuable, at least for me, I hope for my listeners as well.

Max: [00:50:39] Thank you for having me. I hope it was interesting were valuable or at least the pertaining, I hope it was at least entertaining. And I can’t wait to be back in a year and see, I, I honestly can’t wait to listen to myself. Talk about what I’ve just done for the past year. Cause I’m really curious to see where I live.

Michaela: [00:50:55] Cool. Yeah. Okay. So I will link everything in the show notes like bedrock and your Twitter profile. Is there something else that you think my listeners should know or, you know, they should check out that that’s important to you?

Max: [00:51:09] No, I think that’s it. If by then I’ll have a, start-up maybe link that to but I don’t know what that is yet. So cuddly can either yet.

Michaela: [00:51:18] Thank you so much for taking the time and enjoy your Sunday and talk to you in a year on this podcast again, hopefully. Yeah.

 

Episode 39: From designer to web developer

In this episode, I talk to Annie Liew, who works as a web developer at a startup called Pastel. She transitioned from Design to Engineering, and I want to know how she experienced this.  

We talk about:

  • about her experience transitioning from Designer to Engineer, 
  • the role her Juno Web Development Bootcamp (formerly HackerYou),
  • her new role as the first engineering hire at a startup,
  • her drive to learn and level up in public,
  • and how she managed to build a large Twitter following.

Today’s episode is sponsored by Botany.io – Botany is a virtual coach for software engineers that unblocks essential teamwork and levels up careers!

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

Transcript: From designer to web developer

Michaela: [00:00:00] Hello and welcome to the software engineering unlocked podcast. I’m your host, Dr. McKayla, and today I have the pleasure to talk to Annie Liew. But before I start, let me tell you about botnay.io, yho sponsors today’s episode. Botany is a virtual assistant and personal coach for engineers. It helps you adopt better habits, improve your skills or automate your workflows. So how does that work, you ask. Well, great question. Botany connects to the tools that your team uses and crunches through the data to find opportunities for you and your team to improve your skills, strengths, and collaboration, and improve processes and automate workflows. By gently and smartly nudging or reminding you, you stay on top of open tasks and learning and growth opportunities. In this way, Botany smoothly drives your new skill and habit acquisition. I love how it makes code reviews, and giving and receiving feedback a better experience for the whole team. But I guess it’s best you try it out for yourself. For that hop over to botany.io to request access to the tool. So that is botany.io, but now back to Annie.

Annie is a designer who transitioned into software development. I want to talk with her about how she got her first engineering job and how she now build soften his startup as the first engineering hire. So I’m super excited to have any year with me Annie, like come to the show.

Annie: [00:01:27]Thank you so much so happy to be here.

Michaela: [00:01:30] Yeah. I’m really, really glad that you joined. So you have been a designer and then one day you wake up and you say, I now want to be an engineer, or how, how did that happen? And what did you do about transitioning from design to engineering?

Annie: [00:01:47] Yeah. So it’s a bit of a long winded process. To be honest, I studied multimedia design at university and I worked for several years as a designer in Australia and in England. And after that I decided, okay, I wanted to change a pace. I really wanted to move to Japan because traveling is something that I really enjoy. And so I actually went from design to being an English teacher for several years and then decided, okay, I’m going to move to. To Canada and try to get back into design, but because the landscape had changed so much, it was a real struggle. And I didn’t know anybody in Toronto as well. So I basically was in this position where I was just like freelancing on the side, like trying to get my design hustle going. But I was also lot working a bunch of minimal low low-paid jobs to kind of pay the bills at the same time. So I was kind of in this place where I was like, okay, this is not where I want to be. What can I do? How can I level up, how can I get the skills that I needed? And I looked into something called bootcamp. At the beginning, I looked into a lot of UX boot camps, and then I found a school called hacker youth. They’re called Juno now. But at the time, the only. The only boot camp that they offered was a front end web development boot camp. But I really, really liked the community that they built around it. So, you know, I’ve, I’ve built websites in the past before, and it wasn’t something that I really enjoyed. I really enjoyed the designing part of things, but I was always happy to hand off the coding. You know, part two, the developers, however, I did have to build websites and when I did them, I didn’t enjoy at the time, but this time I thought, okay, let’s try again. Let’s see if something has changed. And so I started attending. Small kind of little free, not seminars workshops around the Toronto area. And I was like, okay, what is this? Flexbox what is this? And everything had changed. And so I started getting really curious about it. And so I remember it was really interesting because I never, never thought that I’d be interested in code. But after doing the workshops, I was like, okay, maybe I can do this. And so I applied for the bootcamp afterwards, got a subdued. And as they say, the rest of the street,

Michaela: [00:04:10] Okay. Okay. And so you said you were mainly interested by the community. How did you, was it an online community or was it an offline community and how did you get in touch with the community? How have you, you know, like, I imagine that you get access to the community after you joined, but it seems like you have, you knew the community exists even before you joined this particular

Annie: [00:04:33] bootcamp. Yeah, that’s a really, really great question. And that was a reason why I joined the community. I always have this idea that it’s less about what you do and more about who you do it with. I really, really liked this idea. And so the way like the hacker U has a really strong junior college has a really strong community because there’s a lot of past alumni who shared about the journey. So I, I started contacting them and say, and asking them. Hey, how was your experience? Would you meet up for like a coffee so I could talk to you about it. And I, and I went to several events and talk to a lot of them and every single one of them said, this was something that I don’t regret. I a hundred percent recommended it. This was pre COVID. So the bootcamp was an in-person boot camp as well. So it was nine weeks of 10 to six. And then on top of that, you have your assignments and classes. So it was just like a full-time in-person bootcamp.

Michaela: [00:05:30] Okay, so it’s nine weeks. So you make a commitment for nine weeks. You leave everything other aside, right. And you just go and do your work there. And I don’t know. Do you have homework then? Or is that, do you do everything in class and then you go home and then that’s it the next day you do it again.

Annie: [00:05:48] Yeah, well, it started easy, like off pretty, you know, easy where it was just like the 10 to six, but there’s so much work. And the way that works is that you’re, you’re constantly building, um, projects. So there was no way that you would have been able to do everything just in the 10 to six. There’s been like, it’s, it’s such a fun little, like, it’s almost like a summer camp experience because we all had access to the school basically. And there’ll be nights when it’s like midnight and there’s like all my classmates around me and we’re all just working hard and we have like pizza coming and it’s just a really fun. And that’s what I mean about community as well as it has a really fun atmosphere where you’re doing something difficult. You’re trying to transition into this new career. But they’re doing their best to, you know, support you along the way and make it fun. And, yeah, so it was, I don’t think I actually went to the grocery store for about eight weeks because, and I’m really lucky to have a partner who could do that, but it was just so intense, like the work that I was doing, the purchase that I was doing and what I was learning, I just really didn’t have time. And a lot of people just didn’t really have time to do other things. And

Michaela: [00:06:58] so do you still have contact with a few of those people that you met

Annie: [00:07:02] there? Yes. Yes I do. Yeah. And there’s still a very strong alumni network as well. There’s like a Slack alumni network. I Stu. Do some mentoring and I go back and help, like, you know, current students and I’ve spoken on some panels with them as well for people trying to get their first jobs. So yeah, I’m still an active part of the community. And that’s something I like about the school is that a lot of us alumni are still very active. Yeah.

Michaela: [00:07:31] That’s really nice. And so this thing had helped you also get your first job or how did you make that transition now from, okay. You’re doing this nine weeks and then what happens then?

Annie: [00:07:41] Yeah, definitely. It helped me to get a good job because the school has a lot of industry contacts. And one of the things that they did was that we had an industry day where they invited a lot of potential employee years to a. An industry day where we all kind of showcased our work. It kind of almost works like a blind date. If you think about it, where we all the students were sitting around tables and we had like a, a minute to give out pitch and to talk about ourselves and to share a project that we’ve really proud of. And then the bell rings and then they kind of let go to the next student. So it’s like speed dating. Yeah, it was completely like speed dating, but for employers versus, you know, and like potential employees. So it was really, it was like very stressful because all of us were trying to like practice our speeches and our pitches and, you know, like try to finalize the work that we wanted to show. But as a result of the industry day, I got invited to, to. Interviews with some companies. And I ended up getting an offer, which I accepted a week later. So I was actually the first person from my cohort to accept the job.

Michaela: [00:08:52] Yeah. Very cool. Very cool. And so how long has that a goal?

Annie: [00:08:57] That was, I graduated in summer of 2019 and I started in August. Yep.

Michaela: [00:09:03] And then you worked at that company as a software engineer. Front-end software engineer.

Annie: [00:09:09] Yes. So I was hired as a front end developer and I was there for a year and a year and a quarter. Was

Michaela: [00:09:17] that experience, was that good? Did you feel like now you deepening your, your knowledge or did you learn a lot?

Annie: [00:09:26] So the, the first job I had as a software developer basically was a, I worked for an agency. And what that gave me was a lot of structure around things that you don’t learn in bootcamp. So I got introduced to like agile methodology and stand up and the process of, you know, tickets and JIRA and a lot of soft skills that not soft skills, but a lot of processes, internal company processes that don’t. That you can’t really learn in a bootcamp, but you have to learn them on the job. I also got exposure to one of the very big things was I got exposure to a lot of big, large code bases, some with legacy code, and I also had to build architect sites from. Like the ground-up. So, and I work with so many different websites. It was a, they are a WordPress, VIP partner. So all our sites were done in WordPress, but I was doing like the architecture and, you know, like patient, most CSS and some Jacory as well. But because I had exposure to so many different types of websites and processes, it was a really big, yeah. It was a really big boost I would say, and definitely helped me to get my next job for sure.

Michaela: [00:10:38] And so is the next job that you done accepted? Is that the one that you’re currently at is that the startup that you’re working

Annie: [00:10:44] for? That’s correct. I’ve been there about four months.

Michaela: [00:10:48] And so how does that happen? Like why did you change and why, why did you go from an agency to a startup? What was, what was the interest for you?

Annie: [00:11:02] so I was. I’d been working at the agency for quite a while. And because I was doing a lot of the same type of work, I wasn’t feeling that I was starting to feel like I wasn’t growing anymore. And I was also quite worried about my JavaScript skills in particular, because I was so comfortable doing all the site architecture in patient mode, CSS. And I would basically get, like, I was basically lead in a lot of those. You know, for those projects that came up, but I wasn’t really practicing my JavaScript or react skills. And those are things that we had learned in bootcamp. So it was, I was, I’m going to say that I’m really, really fortunate because Twitter actually played a big part in. How I got this job or this offer, they, the company is called pesto and they were looking for a first hire someone to basically take over the front end. And they had a list of potential people that they wanted to reach out to and interview and invite them to go to the interview process. And I was one of them. So. I didn’t actually apply for this job, but the CTO reached out to me and said, Hey, I’m really like what you’re doing. Sort of some of your work that you’ve shared, and we have this position coming up. Would you be interested in applying for it or going through the process? So I looked at the stack, it was next JS was reacting, was TypeScript. It was all the kind of modern technologies that I really wanted to learn. And so I thought, okay, let’s give this a go. And I did. And I went through like the interview process. I did a coding challenge, which was a take-home challenge for a week. I’d built an entire app for that. It was very stressful. I hadn’t touched react for so long by that point. So it was a lot of learning. I was still working and then trying to do this on the side. Yeah. It was a very, very stressful week. I remembered that, but it was definitely worth it.

Michaela: [00:12:58] So now you are working in that startup and what are your responsibilities?

Annie: [00:13:05] So because they, when they hired me, they, I knew that my JavaScript side of skills, weren’t amazing. And I told them I was very honest with them at the beginning. I said, I’m not going to be like a JavaScript Ninja from the get go, because I haven’t worked professionally with JavaScript for so long. And David very aware of that. So they knew my abilities from the start. And one of my main responsibilities at this moment is just to. Basically level up as fast as I can to get myself to a point where I can just do it really well and eventually be responsible for the entire front end. The other thing I do as well is I build features. We have like a roadmap where we, you know, Look at all the features that we have coming up and I get, and I work on an, on building. Those features. Occasionally we have front end bugs come in as well, which I work on, but the two main things are the side that I am responsible for right now is building features and just like learning as fast as I can to get myself to a spot where I can be super comfortable.

Michaela: [00:14:10] Yeah, I think that sounds like really good next step for you and the ability that you can grow in that role so much, how old is the startup and you know, how does that work? A startup I imagine, right. Like extremely stressful and a lot of pressure or we have to ship. So how does that work in a startup that there’s so much time for you to learn things and how, you know, Is everything actually running smoothly. And so it just doesn’t need that. There’s not too much presser pressure or how does it work?

Annie: [00:14:43] Yeah, that’s a great question. So this startup actually started in March, 2017 and I got hired and started in October, October last year, October, 2020. So they have been going strong for just over four, almost four years, by that point that they hired me and they were. Basically profitable at that point. So they decided to, you know, start growing and becoming like an actual company. So just to give you a bit of context, there’s actually just three people in the startup. Before I got hired, it was the CTO and the CEO and the product guy. So a designer and engineer and operations. So. As they were growing, they realized they needed more help. And that’s kind of what I got hired for, because we’re profitable at the moment. And we have a, our motto of, we have a SAS product that is a subscription model. We know that the money is coming in all the time. So while there is a bit of pressure to ship features and I definitely feel it, I think a lot of the pressure is more the internal pressure that I feel too. Kind of validate that I belong here by shipping features, but I’ve had a lot of discussions with my, my CTO. And basically he said, one of the things that is important is that I’m able to learn to like, basically start slow to speed up later. So. They understand the importance of learning and growing as a junior developer was someone very early on in their career. And they’re thinking the long-term game it’s, you know, I can like probably like try and just like really hustle and ship a lot of features, but would they be like really good features? Well, I actually learned the things I need to learn so that I can do it a lot better. You know, like later on for the company, I think it’s like for everyone involved is really important that we have like a strong foundation built first so that we are able to then, you know, become a lot better and faster later on, I really

Michaela: [00:16:49] liked this long-term vision and long-term thinking it’s something that I think is quite the rare. Even for large corporation that could definitely, you know, invest into their employees. There’s often, you know, a very shortsighted action that I, that I feel like you have to provide value and you have to provide it now. But there are companies that I, that I hear really provide value also to the employees, like for example, automatic and all from several peoples that work there, they have also, for example, I think a really great place to work because. When employees are in trouble, I always heard like they are there, right? Like they give you paid time off or like some time to breathe and to think and so on. And so I really liked that mindset as well, that, you know, they are getting someone on the team and they’re investing in the person and I think. I don’t know about you, but probably it also makes you very loyal to that, to that

Annie: [00:17:46] company. What you said about investment, because that was basically in some of my discussions with my CTO. They are definitely investing in me. So when I got hired, they knew that I had the skills coming in from as a designer and. You know, they didn’t, they wanted someone who could basically have ownership of the front end and not have to worry about, Oh, can you move this pixel here? Can you move that? The light that’s all taken care of. I’m very, very pedantic about those details and let the UX and UI or things. They don’t have to worry about that at all. So he says it’s a lot easier to teach someone to code than to actually care about the product and how it looks and how it feels. So, yeah, totally resonated with everything that you said there. Yeah.

Michaela: [00:18:29] Yeah. And I think this is a really good perspective as well. Right? So you want action to the right people that are caring. And I think also people that feel cared for, and at least from what you’re telling me here, it feels like you, you feel cared for which I think trans translates back. Right. So it’s, it’s like giving and taking. So one thing that I’m super interested in as well is how do you experience. Developing software in a startup, like, what are the processes there? Is it very flexible? Do you have like mentorship? Do you have like code reviews? What about testing? You know, like what you’re telling me, it’s like two people, right? So it’s the CTO and you, so how do you do that? How much, how much formality is there and, and, and who takes over what.

Annie: [00:19:18] Something that we discussed at the very beginning is that with processes, we don’t have processes for processes sake. So that’s because as a startup, we want to basically move fast and iterate on things and be able to push things up. We basically follow a, although not formally, we follow an agile process where we have stand-ups, we do the sprints and we do retroactive at the end of the week to see what has gone well, what could be improved and then kind of reiterate on that. In terms of the, the product development process. We basically have roadmap meetings, roadmap, plannings, every one or two months, basically when we kind of look at the roadmap that we’re building and seeing what features need to be built. And the way we decide what features need to be built is based on the kind of two ideas. The first idea is a, is it something that has been requested? Is it something that customers have requested or is it something that we have some data around how customers are using our app? Is that something that they’re doing often enough? And then the second part of that is what is the potential impact of this feature? So for example, like maybe customers like request something and they requested a few times, but is that going to have a big impact on the company on like the usability of the, uh, like, will it help us to get more potential clients or, you know, so kind of those two things are two things that we think about when we, when we plan out our roadmap and look at all the features that we have available and we didn’t do like a kind of one. One, usually a one month plan where we work on, we prioritize the features that we’re going to work on, and then we just basically go for it. In terms of mentorship, I have a very close relationship. I would say with my CTO slash manager, we do our one-on-ones. We talk very, very openly about things like imposter syndrome, how we want to shape the, the culture of the company, what kind of company that they want to be. One of the things that really impressed me from the beginning was that they said, okay, and this was during the interview process. They said, we are very keen on building a great company culture. They’re kind of the kind of company that people want to come and stay, but we don’t want to have like high turnover. We want our people to feel valued and we want them to have autonomy over their workflow and the things that they do. And we want them to have an impact, but you can definitely, definitely make an impact in our startup. So the TIFA. Management style that they have here is very, very suitable for me because I tend to get bored easily, but in a startup because I’m doing so many different things and have such a, I guess like impact or influence or ownership over the product is I feel very invested in the job and in the company.

Michaela: [00:22:08] When, when I actually started out of university, I thought like, what kind of company do I want to work for? And I was very impressed by these large corporations, but I think it was more the names than everything else. Right. And now over the time, I think my view shifted quite a bit because at a startup you can maybe make the whole, the whole half of the product, right. Or maybe the whole product. There’s definitely something there, which also right now fascinates me more like having more impact, having more, you know, like. Yeah, contributing more and also maybe different heads. That’s something that I liked a lot. Actually, when I was working at Microsoft, I wasn’t a very specific position. Right. It was in the tool engineering teams. And so there, there was a lot of research, a lot of innovation, and that also had like a lot of hats, a lot of flexibility and a lot of impact, to be honest. But then when I wanted to transition, I looked at other teams and said, Oh, I don’t know. I, this is a little bit too restrictive for me. How is that for you? Do you have like several hats while do you have like probably designer hat, then you have maybe the developer hat, but other, other hats, I don’t know, responsibilities that you take over in the

Annie: [00:23:24] company? I wouldn’t say that I have like responsibilities per se, but I would say that I have the flexibility to kind of shape the role that I’m in and. Look into things that I’m interested in. So for example, one of the things that I did probably in the first couple of months is that I joined because with our clients, with our CEO, so that I could like talk to the client specifically and ask them questions about how they’re using the product, how they like it. And so that gave me a lot of. I guess empathy for our users and how they’re using the product. And actually this product is something that I use myself. So I is like, I am the user at the same time as something that I’m building for myself. So it’s interesting, but I also. Yeah. Like, because it’s such a small company, we do a lot of different things. For example, I don’t have to do this. My core responsibility is to build features and like be in engineering. But one of the things that I also do is that. I, you know, sometimes I’ll reach out to people. I think that we get a benefit from, from using pastel. And so that’s something that I do as well. It’s very, very, very, very flexible. It’s I’ve actually never worked in a company that has been so flexible before, like that, like any hierarchy, like structure is like quite flat. So everyone’s just going responsible for everything we have. Like, we communicate very openly and discuss things and it’s very much a process where it’s very collaborative. We all work together. And we’re very intentional about the things that we do that would move the company or move the product forward. So, and also just going back to what you said about mentorship, and one of the things that. Attracted me, I guess, about large companies was the idea of mentorship. And because like, traditionally we feel like large companies have very formal processes in place for mentoring younger developers. So it was something that I was very, very worried about when I first, when I was talking to the CTO, because there is no formal processes. It’s a bit, it’s a bit chaotic in many ways. So I. Asked him about that and we have code reviews. So I think maybe you’re familiar with the idea that code reviews are in many ways, a form of mentorship anyway, because you know, you’re getting your coffee with you. You’re getting a lot of feedback. He’s very good at the feedback as well. He just, he doesn’t tell me, just do this. He tells me the why. And yeah, it’s like very, very detailed and it’s, it’s really helpful. But the other thing that we do very consistently, at least twice a week, if not more, is that we pair on a very regular basis. And that’s been an immense source of mentorship as well.

Michaela: [00:26:04] Yeah, I think to be honest in a company like that’s that small, right? And you have like the CTO as the main engineering person, you have excess. To the CTO, right? I mean, it means that it’s the person that shaped the whole product that knows the architecture. So which means in another company, there will be several layers that you have maybe to go through, or people are really busy maybe also, and here, because there is an investment from the CTO also in you. Right. It’s in both interests to be like pairing and exchanging ideas and learning. And so, yeah, I can imagine that this is actually a really good spot to be in and have like. Almost like, like a really personal mentorship, you know, th there are mentorship programs in larger organizations, but I don’t think that people are that invested right in their mentees. Then probably your CTO is in you. Right. Because there is like higher stakes to make it work for that person. Right. So. One thing that I wanted to touch base, which is a little bit out of context, but you mentioned it at the beginning. And I think it’s interesting for a lot of people that are looking for jobs maybe that are coming out of would come, you know, coming or transitioning or coming out of college or whatnot. Right. And getting a foot into Tash, you said, well, actually by Twitter was super helpful. So. How, how, how are you using your Twitter or how are you building your following? What’s the value that you get out of Twitter and how can you, you know, how can others maybe also benefit from that and let it help them also a little bit in there in the job search.

Annie: [00:27:46] It’s interesting because I was never really a social media person. I had to open our, my Twitter account because my bootcamp made us open the account. And I remember in the very early days, I had no idea how to use Twitter. I was like, okay, I have to tweet something. What do I talk about? How do I connect with people? It was a very confusing kind of landscape for me because it was just a platform that I wasn’t familiar with. And I hadn’t used it before. When it started to change was when I, when the pandemic started and I’d been in my job for awhile and I was very comfortable with what I was doing, but I really wanted to level up. So I joined a hundred days of code and I started sharing my process on, on Twitter. And that was when I started to meet more people, build a community and. Basically, that was how, like my following grow. I, I guess it was very unexpected. I wasn’t expecting it. And it was very intimidating at the beginning, but in terms of why our boot camp made us open a Twitter account, it was because they knew the value of having a online, personal brand. And your Twitter account or any other, like your LinkedIn and stuff, your website is all part of that overarching idea of your personal brand. And it’s really helpful because a lot of companies do checks on you to see what kind of person you are outside of just the code that you do. And people hire other people for soft skills, not just, you know, like they can like, do like a for-loop and stuff, but it’s actually like what, what you bring to the company and. Twitter as is a way to not only kind of show the projects that you’re working on, which I was doing. I was like doing a lot of projects and just showing them, or freely on Twitter and on cold pen as well. But it’s also a chance for them to see who you are as a person. And I think that is the value of like Twitter or some of the other. Um, social sharing social networks as well. Yeah.

Michaela: [00:29:46] Okay, cool. So any, thank you so much for taking the time talking with me. Maybe I want to use the last few minutes to just catch up with things that you wanted to say to my listener, or, you know, like something that you want to leave. People were, I think especially people that are coming from bootcamps would be interested, people that are transitioning. Right. What is your advice for them? What do you think? What should they, yeah. What, how do you think that they could make themselves successful? I set them up for success.

Annie: [00:30:21] One of the things that I heard over and over again was that your network is so important and I really, it was something I really, really. Um, felt when I started to get into coding because when I came to Toronto and I didn’t have a network, it was extremely difficult for me to get into design. I didn’t know anybody. And once I tapped into a network and a community, everything became so much easier. So there is a lot of value in reaching out to people, because at the end of the day, you do the things that you do, you don’t. Build features and products and cold by yourself. You build it in a team with other people and having mentorship and a mentor can also be just someone like who’s a little bit ahead of you. If you can look on your current journey and give you advice on what you can do and just talk to them and kind of encourage you as well, having that kind of connection with someone who is already in the field or with a larger community, I think has a really large impact on, I would say a developer’s career. Something that I heard from somebody I remember this very clearly was that he said that the most successful developers, uh, people who have a large network to draw from, and also they’re not kind of tied into one specific like technology or something. They’re always kind of learning. They’re always open to hearing about like more things and they have like a large depth or breadth of knowledge and. They’re successful because they can draw from all districts areas. And I think that’s, that was like something that had always stuck with me. So. Yeah, like reaching, reach out to people, get involved in community, but also actually do work. The only reason that I was able to probably attract the attention of my current employee was because I was like really, really putting into putting in the hours of all the projects I was doing. And I think it shows as well, like the kind of work that I was sharing. Like I had spent hours and hours on them and just kind of refining my skills, getting better and improving each time. So. Those are things that come across when you’re sharing. And it’s very easy for people, I guess, like as new devs to become very discouraged. When, you know, you’re looking for your first job and you get a lot of rejections and it’s like, it’s really hard. It’s like so crushing, but you kind of have to understand that rejection is not. It’s not personal. It might be just that the company didn’t, it’s not the right fit at the right time, or there’s a lot of different factors and it’s not like really personal and cut you kind of, kind of help you to get over that hump is just to do work that you want to be hired for, or you want other people to see. And I think being able to show and share your work and show that you’re passionate about what you do and that you’re willing to learn is very, is very important.

Michaela: [00:33:24] And so was that work that you showed and that you did, was that outside of work or were you able to showcase the work that you did for work?

Annie: [00:33:34] It was outside of work and that was because the work that I was doing at work belongs to the company and. I was comfortable with the job that I was doing this. So I wanted to learn other skills beyond the work that I was doing at work. And actually this brings out a really good point because something that, that maybe like you kind of feel, feel this as well, like tech is one of those industries where there’s almost an expectation to work outside your job. And I just want to clarify and say like, that is not expected and you definitely shouldn’t do it because like a doctor doesn’t, you know, practice like operations in like his or her free time. And like, I don’t like the feeling that I have to, you know, work outside of my job, but it was something that I wanted to do personally to kind of level up because I wasn’t getting the kind of skills I needed. At my current job at that time. So that was the reason why I did it.

Michaela: [00:34:35] I also think like building up those profiles, then we just touched on before, right. Is something that’s really hard if you’re employed, because most of the time the code doesn’t belong to you. Right. And it’s not something that you can easily share and say, Oh, look at my guitar. There’s my code that I write for my employer. That’s confidential. Right. So if you want to fill your GitHub with nice stuff, it somehow. It means that you are doing stuff outside of work, but yeah, we have to be ready. The realistic that a lot of people are not, you know, they don’t have the position to do because they have like a full-time job they have to care for. Right. So, yeah, I think I understand. And they understand that this probably has a big impact, but it’s also. I also, as you said, I’m not advocating or at all right. That people should, should need to do it, but it’s, it’s definitely interesting to, to hear that that’s the way how you grow your following, how you grow your skills, right. So there is a trade-off that you have to make and, you know, if you’re in a position to do it, then that’s great. And I think it’s okay. Also not good to forbid people to do something outside. Right. I mean, sometimes it’s what you have to do. That’s how it is.

Annie: [00:35:48] Right. And in lieu of that as well. I also think that’s why having a network is so important because that’s how you can get your next job without having to do all the extra work of learning outside of your full time job. Yeah,

Michaela: [00:36:00] exactly. Yeah. Yeah. Okay. Any, thank you so much for taking the time and talking with me today, it was really a pleasure to have you. I wish you all the best for your job and that you learn a lot and I will. Continue following you on Twitter and see what you’re doing. And I’m really excited for you. Thank you so much for being on my show.

Annie: [00:36:20] Thank you for having

Michaela: [00:36:20] me. Yeah, it was my pleasure. Okay,

Annie: [00:36:23] bye.

Michaela: [00:36:26] I hope you enjoyed another episode after sup engineering unlocked podcast. Don’t forget to subscribe and I’d talk to you again in two weeks. Bye.