Women in Tech

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

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!

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.

Episode 37: Underrepresented, Underpaid & Undervalued – Having to change jobs to advance your career

In this episode, I talk to Jenn Creighton. Jenn is a Senior Staff Engineer at Apollo. Jenn specialized in frontend-end development is currently working on the open-source work for  Apollo GraphQL.
She also is a frequent conference speaker, an authoritative voice in tech, and recently started her own podcast called single-threaded

We talk about:

  • what a senior staff engineer does, and which responsibilities this title entail, 
  • why she needed to frequently change her job in order to advance her career,
  • how gaslighting, bias, and being underrepresented, underpaid, undervalued is part of her decades long experience as a developer
  • and how she makes sure she is helping others to enter tech and have a better experience.
Continue reading

Episode 36: From Bootcamp straight into a full-time dev role

In this episode, I talk to Natalie Davis. Natalie is a recent Bootcamp graduate that managed to get hired quickly after graduating. She is vividly sharing her knowledge on Twitter and started to make real waves in the dev community within just one and a half years in tech.

We talk about:

  • her experience at a developer Bootcamp, 
  • how she managed to quickly get hired after graduating,
  • how she keeps up with all the stuff she has to learn,
  • how she decides to adopt best practices,
  • and how to overcome rejections by staying positive and focusing on growth. 
Continue reading

Episode 35: How Programmers Think and Learn

In this episode, I talk to Felienne Hermans, who is an associate professor at the University of Leiden and researches how developers think and learn.

We talk about:

  • why it is so hard to read and understand code,
  • her book “The programmer’s brain”,
  • how we can learn easier to program,
  • techniques to understand complex code quicker,
  • how a shared vocabulary can help teams, not only during code reviews
  • and her process to write a book developers will love.
Continue reading

Episode 34: Vulnerability disclosure with Katie Moussouris

In this episode, I talk with Katie Moussouris, founder and CEO of Luta Security.  Luta Security specializes in helping businesses and governments work with hackers and security researchers to better defend themselves from digital attacks. Katie is also an expert when it comes to bug bounty programs and how to successfully prepare organizations to implement a vulnerability disclosure program.

We talk about:

  • vulnerability disclosure,
  • the security challenges faced by military and government organizations,
  • her entrepreneurial path,
  • how to establish yourself as a hacker or security expert,
  • and how to build security in your software development process. 
Continue reading

Episode 33: From intern to CEO with agile testing expert Alex Schladebeck

In this episode, I talk to Alex Schladebeck, a testing expert, and a powerful voice in the tech community. Alex is the CEO of Bredex, a dev shop that offers tailor-made IT solutions but also specializes in quality assurance and testing.

A decade ago, Alex graduated in linguistic and came into tech by accident. So, I obviously have to ask her about her career transition, and testing.

What we talk about:

  • transitioning into tech from a non-traditional background
  • what it takes to get from an intern position to becoming the CEO 
  • which role testing plays at Bredex
  • how mob or ensemble programming is used to facilitate learning
  • how to lead remote software teams
Continue reading

Episode 28: How design systems help create an inclusive user experience at Github

In this episode, I talk to Diana Mounter, the Director of Design Infrastructure at GitHub. Diana traveled the world and lived in many different countries – even continents. She started as a print designer and spent some time in government before she got into web and design. Now, she leads the design systems at GitHub.

We talk about:

  • what design systems are and why we need them,
  • how GitHub deals with legacy code and refactoring.
  • how the designer role interplays with other roles at GitHub,
  • how and why designers do code reviews,
  • and how GitHub strives for inclusive designs that make everyone feel like an expert.
Continue reading