Getting ready to build a billion-dollar business

May 4, 2021 michaela 00:52:46

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

We talk about:

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

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

Links:

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

Transcript: Getting ready for a billion-dollar business

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

with spectrum you can look at it. It’s, it’s one big Monterey pro basically that contains all of our servers, all of our clients, everything we ever built. It’s all completely open source. It’s terrible code, please. Don’t look at it too, too closely. I love product what we did cause we did a lot of shipping and not a lot of cleaning up, but it works and it’s open social people to look at. It’s a, it’s quite funny because I think spectrum is quite a messy copays personally. Like it’s not, it’s not the nicest code I’ve ever written. I didn’t have as much experience then as I do now. And, and also we were just trying to ship as much as possible. I’m trying to figure out, trying to find product market fit and then eventually the business market fit And it’s funny because sometimes I see tweets of people saying, Oh, if you want to see a really well architect, the copays, go look at spectrum. And every single time I see that I like please, please. Don’t like, that’s not, it’s not that well, I can think of, it’s kind of a pain to work with. I don’t know. Yeah,
Michaela: [00:12:37] I know you cannot respond to every tweet like that. Like
Max: [00:12:41] exactly. Yeah. I can’t really be like, ah, hello. Yeah, please. Don’t look at my work. It’s really bad. That’s not a good idea. I can’t really do that. But it is, it was very interesting. I do think spectrum helped a lot of people think about how they build apps, right. And it has a lot of people to learn and it was quite fascinating to open source it and see how many people actually cared. Because there is so few food products out there that are open source, right? Usually when something’s open source is either a toy product, the toy project that somebody builds, or it’s a library that’s very encapsulated, very small, but very few people open source, entire apps, right. Century being one of the many, many exceptions and one of the most famous ones or ghost, for example, but there’s only like a handful of those. And so adding to that list was quite interesting how much people responded to that and how much they liked it.
Michaela: [00:13:27] Yeah, because I mean, I think so I’m a, for example, I’m learning Peyton things two years now. And I’m also a little bit struggling with, how should I actually go about learning Peyton. Right. And that, that has to do that while I’m not employed as a heightened developer right now. Right. Which also limits, you know, the. The amount that I can actually spend on it or that I spend on it. It also means that I don’t have like a network of people around me that I can learn from, right. Like code reviews that you have. If I would be a Putin developer right now, I would have like my colleagues also writing Python code and I can learn from them. Right. And so open source is definitely something that I’m also sometimes doing. Right. I go and look at Ida patent application to just understand, you know, how ID architecting something, because these are the questions that I still have. Right. I don’t have the question on which type to use or how to do it area or how to do a list, sorta whatnot. Right. So I know those things already from my other programming adventures that I did, but I’m more interested in, Oh, I’m coming from the job are object oriented C-sharp world. Right. So how do you do that in Piketon and, and how would you, you know, structured applications and open source is something that sometimes helps me, but it’s very hard to find like either like a good application again, because sometimes you find application and I’m looking at it. And even though I don’t feel like I’m the expert for piping, I can say, Oh, I shouldn’t call it. What’s going on here. Right. And then it’s big enough that it’s interesting to look at and has, you know, good quality and you can learn something from it. I think it’s very, very valuable. I can totally see how people are. Yeah. Interested in, in doing that and learning more about it. So, but now you, you build spectrum and then it was actually acquired by GitHub. Right. And so you’d done because it was acquired, you worked at guitar building, you know, GitHub or spectrum into get-ups right. And get into YouTube. How did their view changed on software engineering practices on good code? Did you experience something like that that suddenly you were in a team and they are all, you know, like working together and you can learn you know, you can improve your skillset, sat there with, with the input of your peers or how, how was that for you?
Max: [00:15:36] Because we very quickly realized that spectrum just wasn’t built well enough to run a Kitsap scale. It was very fascinating to learn how Kitsap scaled itself, because obviously when they started building gets up 10 years ago or however long that was, they also didn’t build it to handle the amount of traffic that it has now, because GitHub is massive. It’s one of the, I think, 10 biggest websites on the planet, maybe 15 biggest websites on the planet. It’s, it’s massive. It, it gets absurdly much traffic. And so it was very fascinating to be at Kitsap and to see How careful they are about the code they write and how many conventions and constraints they built into their systems, particularly for the developers. So that any code that that is that is written is good enough to run at that scale because most people have never worked at that scale before, unless you’ve worked at Kitsap before, or one of the other 15 companies, that’s this big, you have no idea how to work with that scale. Right? And so a lot of the work that many teams that get to did was building tools for other developers that gets hub to guide them towards success and to avoid expensive database queries, to detect them, to warn people when they were writing them, stuff like that, where they built a lot of internal tooling to make sure that they could run at scale and that they could continue scaling into the future. And I actually think a lot of what I, what I learned there was how important constraints are with programming. You have all the options, you have all the possibilities, you can do whatever you want, but a lot of what it means to be a senior or an experienced developer is knowing which 90% of those options are actually trash. And you probably shouldn’t do them because you’re going to run into problems. Right? A lot of the choices that experience developers make are based on experience and I’m talking to other experience developers and they avoid future problems, right. By, by making good decisions. Now you avoid a lot of future problems and sort of. Avoid running into troubles down the line. And that’s something I’d never done before with spectrum. And so with spectrum, we actually had a lot of scaling problems when there’s this sort of rule of thumb that started people say where every single time you get a new order of magnitude of users, you run into new scaling problems. And for us, it happened like that, like clockwork. When we ran from zero to a thousand users at the, when we onboarded our first community, we immediately hit scaling issues. We immediately had to move away from Firebase, build our own backend because Firebase was couldn’t sustain the load anymore. Then when we went from 1000 to 10,000 people, we hit the next set of scaling problems. As soon as basically as soon as the 10,000 persons joined almost to the day we started having server issues. And so we had to resolve those, then everything went fine. We’re going, we doubled, we tripled, we quadrupled. We went from 10,000 to 9,000 people. No problem. And then as soon as we hit the a hundred thousand monthly active users, the next set up problems, they didn’t get in with them releasing our server. Our servers were crashing constantly. And it was very fascinating how these, this sort of order of magnitude step change of traffic really impacted our stability. And so get ups really focused on making sure no one that gets up some writes code that doesn’t run it, their order of line of traffic, that no one, there can even commit something to the code base, no matter how inexperienced they are or how much they fork rails, for example, that could break their systems. And then when something breaks, they have a lot of infrastructure, of course, around that, to monitor, to fix those issues, to roll back deploys so that when problems do arise, they don’t impact many users. And it was fascinating to see that and to see how many constraints. They put on people, but they were very productive constraints as a developer. They made me free to build the stuff that I wanted to build without having to worry about scaling, because I knew if I did something that was bad, there would be an Arizona. Right. See, I would throw an error. There would be a winter error. There will be a test error, right. Like somewhere, somebody somewhere would catch my stupidity and tell me to do it differently. And so that was actually really fascinating. And they learned a lot about scaling engineering and then organizations there.
Michaela: [00:19:31] Yeah. And so it seems that this is also very specific. So some of the engineering practices, some of the tools, some of the processes are really made for the scale there. But now if you’re going back and I know you’re now building a new startup, so what do you take away from that? What do you say? Well, you know, this is overkill not needed for me right now in my next startup. Right. And what are some of the, the, the practices the knowledge that you acquired your thing? Well, I’m going to build that in from the start and get go, because I don’t want to run into issues. Long-term with maintainability, readability of the code base, many things.
Max: [00:20:08] We, we made many, many mistakes, or I should say I made many of those mistakes as the main technical person, that spectrum, I made many tech choices, mistakes. And one of the main things I really learned is that. Using technology that’s widely used is a very good idea. There’s a reason people use Maya’s quail or now Postgres, right? It’s because those two databases, they run and they keep running no matter what scaling crap, right? Like it’s a famously uses my SQL and is the 15th biggest website on the planet. And I think they’re now starting to hit the limits of that. And they’re starting to have to really work around a lot of these problems. But they managed to become the 15th biggest website on the planet with my SQL. So why would you use anything else? And I’ll be like, there’s no reason to choose anything that is less battle-tested because, you know, if, because if you end up being the 15th biggest website on the planet, you can fix my SQL. If you don’t end up being the 15th biggest website on the planet, it doesn’t matter. Right. It it’ll still work. And at spectrum we chose a database that was a lot less populated. What’s called rethink to be the company behind a shutdown because they weren’t financially successful. And the database system just wasn’t as well built as my, as going reading be. And we ran into a lot of scaling troubles because of our database choice or because of the database choice I made. And so I learned to rely on battle, test that technology, even if it’s under equals boring, even if it’s something that a lot of people use, that’s a good thing, because that means it’ll scale with you. And if you have a problem, you can Google it right with rethink to be almost nobody used it. And so when we ran into problems with our careers, when we ran into problems with the database engine, we Googled them and we found nothing. There were, there was no information, which is very different if you’re using MySQL or Postgres, if you Google any problem, I guarantee you you’ll find 10 pages of Google results with people explaining different solutions to the problem, how they approached it, how they fixed it, how it held up over time, right. And that that sort of Corpus of knowledge and that Corpus of experience is incredibly valuable when evaluating technology choices. That’s really one of the main things I learned, which is obvious in hindsight and is, it’s a common thing to say. Don’t use boring technology, use things that are proven to scale. But it’s really hard to keep that in mind when you’re using technology, because you will, you’ll see something that’s fancy and new and you’re going to want to use it. And it’s, it’s cool and everybody’s using it. And you feel like everybody in Twitter is talking about it, but if nobody’s used it at scale before, you’ve no idea if it works out right. And you can only, I think there’s often these tools have upsides, but the trade off of the missing community, the missing usage, the missing scalability, isn’t worth, there’s some tools where that isn’t the case. So I would still evaluate that sort of as a trader. Right. Does this tool make me so much more productive that I can handle production problems? Is it, is it production critical at all? So there’s like, there’s, you have to think about that, but always err, on the side of choosing boring technology, that’s proven to scale.
Michaela: [00:22:52] Yeah, I think that’s a, that’s such a good advice. And I also ran into dad when I was I was choosing which, you know, static site generator to use. And like, they’re, they’re the ones that, you know, right. Like Gatsby or Jacquelyn, I think like this. And then there are a lot of others, like tiny ones. And I was like, Oh, this is one that nobody knows over there seems really promising and interesting and you know, like shine in you. And I think it was also curiosity. Right? I think that a lot of engineers are very curious. I am curious. So I went with that one. But what I forgot to calculate is how much time I’m actually spending, building my website with that acquiring knowledge, then knowing how to use that thing, but also at the same time, learning that there is not enough support information around to, to get me out of errors that I run into, or maybe it’s even, you know, like the thing itself it’s broken. Right. And it also reminds me of, I actually tweeted, I think recently about this where some tools make me cry. And it was like when we, when I was at Microsoft and I had to use some internal tooling, that was really new and we just build it until we were doc fooding it. And we were forced sort of like to use that new thing, which is it’s a good thing. Right. But on the other hand, I couldn’t just go and search for the problems that I run into because it wasn’t even existing outside. And so internally people were building it, they weren’t really like, you know, supporting others or writing blog posts. So it was really a bad experience and something that made me think a lot about so important that if you’re stuck, that you can find information that gets you out of this, that gets you unstuck, it gets you out of this, you know, stuck situation and maturity of software projects and community and livelihood. Right. It’s definitely something that’s, that’s important here.
Max: [00:24:43] Absolutely. I think this is. Even more critical in areas where you don’t have a lot of experience that the less, you know, about a problem, the more you shouldn’t rely on boring existing solutions. I know nothing about databases, so I should probably use my SQL and Postgres because I know that those are gonna work. And any problem I have, I can find a solution for, I know a lot about react. And so I can, I know I can, for example, use Preact instead of react, because I understand very deeply how react and Preact work and I can debug my own problems. Right. And so a lot of this also has to do, like you said, with familiarity, right? If I’m familiar with, with a certain problem space, if I’m familiar with the tools within the problem space, I have a lot more leeway to use cutting-edge solutions. If I’m in a problem space where I have a NOAA experience where I don’t know how anything works, if that doesn’t make sense to be on the cutting edge, because I’m not gonna be able to resolve my own problems. And so I think, like I said, that that really ties into it, that sort of familiarity that understanding of the ecosystem is really critical. If you’re using something on the cutting edge.
Michaela: [00:25:39] Yeah. Yeah, definitely. And so maybe, I mean, what me too is very often startup founders, especially ones that are new and maybe they don’t even have a tech background. Right. They’re like what tech stack should I use? Grade one? What what languages and so on, should I build up? And most of the time the answer is, well, the ones that you’re mostly familiar with, right? So if you are a Python developer, probably just stick with Python. If you’re a Perl developer, maybe it makes sense, you know, to update your texts. Most of the time you’re like, Peyton is just fine or Ruby is just fine. Right? You don’t have to have, like, you don’t have to learn JavaScript and react if that’s not where you’re coming from. But so now for your new startup, I want to talk a little bit about the app. So you’re going to do something new. How are you going to, you know, how are you going to come up with the idea? And maybe with ties in a little bit here, it’s like bedrock. So recently you released a new product called bedrock and that’s like everything you need to know or everything you need to have to build SAS apps. Right. So it would be authentication. It would be emailing a little bit community subscription payments and all of that. Right? So sort of the pilot plate code of SAS applications that people can use. And when I saw it, I mean, it, it got really viral on Twitter. So people were really like, very happy to get that. And and I think it’s one of those problems that you see people running into. And so how was that for you? I mean, it looked like super popular. Was it also from the sales perspective, was it as successful as you hoped and, and will the next product that you’re working on being that space or will you go somewhere completely Allison? How are you going to, to tackle the next problem? How did you come up with this idea?
Max: [00:27:27] Sure. So I’ll start from the beginning. I I’ve spent the past, basically all of my career building JavaScript tooling. I’m sort of, I would say mainly well known for making a bunch of open-source projects, like react polo plate and style components that are cutting edge, new ways of doing things right. And I have a very deep understanding of react and JavaScript tooling and to have a good overview of the ecosystem. And I know how things work at a very deep level. And particularly at Gatsby now over the past year, I really dove deep into that because Gatsby basically is just a bunch of open source 20 combined in a very nice way. And what I realized was that I kept building SAS products on the sides, but I kept doing the same setup every single time. And every single time, it kind of sucked. Like I have enough experience to know, like I said, to avoid 90% of the bad choices, but in the JavaScript ecosystem, it can sometimes feel like 99% of the choices are bad. And you have to just make that 1% of choices to make all of the tools that you use work really well together. And making all those choices right, is really, really, really difficult and takes a very long time. When I set up my last, my last sort of SAS product feedback Fisher, I probably spent at least a week just setting up the boilerplate code, right. Just setting up TypeScript, prettier easily in payments, authentication database, a GraphQL API, graphical client, all of those stuff, all of that stuff. So that it works well together and sort of is easily usable. And doesn’t just break down after a while. It’s actually really difficult. And even after a week, I wasn’t happy with where I was at, but we just kind of have to build our product at that point. Right. Like you can only spend so much time setting up. And so after that, I actually took what I had after a week. And I said, okay, I’m going to sit down and I’m going to make this as nice as possible. And I spent at least three weeks of evenings and weekends just building Building a boilerplate really like I just plugged together glucose, right? Like it’s basically a bunch of configuration and glucose so that everything just works really well together. And now it’s at a point where, for example, if you change, if you add a required field in the database, your seat data for your end-to-end test is going to throw an error that, that the required field doesn’t exist. And the entire thing from tobacco just works really well together from testing over client, over backend, over everything you need just works really, really well together. And I had that, I had that boiler plate and I was like, well, this is kind of nice. Like, this actually feels really fantastic to work with just yesterday. I set up a new version of change feed one of my SAS apps. Cause we were we, we kind of need to rebuild it because it takes stack. Isn’t very nice that we chose there and slowing us down a lot. And so I basically rebuild all of the core functionality in an hour. Right. I took bedrock. I added a bunch of stuff to the API. I added some fields to the client and it’s ugly as hell. Like the client, doesn’t it it’s completely front-end list. So the client looks likely to sell, but everything works. And that only took me an hour. And of course there’s a lot of stuff to make it production ready into, add to make the build the client of course, make everything nice at onboarding, whatever, but it works right. And it has everything I sort of need. And so long story short, that’s why I thought about selling it. Right. And I was like, well, if I think this is nice and it’s, if it took me, somebody who really understands this problem very deeply into really understands that ecosystem deeply. If it takes me four weeks to set up something that’s good, that that’s really good. And that, that that sort of saves people time and is better than what they could do themselves. Then maybe it’s we are selling that, that sort of knowledge and that experience to people as a boilerplate and people were kind of excited about it. Then I think by now I have about a hundred pre-orders somewhere in that order of magnitude, 105, I think, which is really exciting to see. It’s kind of funny. I, I honestly didn’t expect to get a hundred pre-orders because there, there isn’t even a demo on the landing page. It’s just a landing page to explain what I want to do. It doesn’t even show anything yet. And yet people, a hundred people pre-order, which tells me two things. One, the community really trusts me, which is fricking scary. Like that is very scary to, for me because now I have to deliver and I have to deliver something. That’s actually as good as I promised, which I think I can do, but it’s a lot of pressure. And then secondly, there’s a, there’s a need for this, right. People struggle with setting up JavaScript project very well. And they’re willing to pay for a solution to that problem. And so that’s exciting to see, I don’t think I’m going to make this, my next startup per se, but it’s a really nice product to work on. And it’s just something that I personally really care about and I really enjoy doing. And so it was just like a fun, fun project, if that makes sense. Yeah. When I
Michaela: [00:31:46] started tweet was like, wow, that’s such a great idea because I was exactly imagining something like this that you run into the problem over and over again, you have this expertise, you have the wig Dan sort of, right. So you’re there, there’s obviously more work that you probably could in now to make this even better than what we would do for yourself. But in general, there’s like this foundation. And I mean, especially if people want to start a SARS app or, you know, do their own startup, I hope that they’re smart enough to realize that, you know, I think right now you’re selling it for 150 or 149 bucks. And later it’s like 200. I mean that this is like a bargain, right? Because I mean, if I’m spending a month, I could do. And as you said, they probably spend two months. They could really think about their, their solution. They could talk to customers, they could, you know, find out which problems to solve instead of doing that work for you. So I think it’s really a fantastic idea to, to go that route and do that. And it’s also great to see that people are backing you up. I think, I mean, obviously it’s frightening, right? If you have like, you have a platform, you have like a community around, but it also see you also, I think it’s also really beautiful to see that. They are people who care about what you’re doing and who trust, you know, you and I experienced you as a very authentic, very honest person. Right. So it’s not like, Oh, I’m doing everything that I do is really cool, but like, Oh, I’m making mistakes, but I’m learning from it and I’m sharing it here. Right. And so I think this is definitely something that people can, they realize, and, and this is why they are there right beside you. Right. And so but now we’re coming, you said, this is probably not what you’re going to do for your, for your new startup. So how, how is that? No, dis tricky, first part, like we have this idea, you want to do something and now you have to start in one direction. Right. And so how are you going to tackle that problem? And, and yeah. How do you think that you can set yourself up for success in the right direction? I think,
Max: [00:33:48] Multiple, multiple things. One is being very clear about what I want to accomplish. I want to build a billion dollar startup in my life. That is sort of the thing I want to try next. I’m not right now. I don’t want to build a, a indie hacker business. Right. I don’t want to build something on my own and I I’m perfectly happy to do that. Right. But right now at the life stage, I’m at, I don’t have kids. I’m relatively young, still. I don’t have a lot of commitments. I have the opportunity to try and really build something that changes the world. And so I want to try doing that. And that immediately already tells you a lot about the problems I can tackle, right? There’s problems I can tackle with that, that are big enough. Like the, basically the promise has to be big enough to eventually be worth a billion dollars. Right. They have to be really big problems. If you’re solving something that’s a small problem. It’s never going to be a billion dollar startup. It might be a nice indie hacker product business, but it’s never going to be a billion dollar startup. And so I know that that already deletes 80% of the ideas I have probably if not even 90%. And then the other, the other fundamental assumption, or, or axial I have is that I want to build something that I use, that I need myself. And that doesn’t necessarily mean a problem that I have myself right now, but something that we’re, if it exists, I’m an, I’m a user. Right. And I can think about what I needed and talk to my customers and figure out what they need and sort of reconcile that with my own needs, for the product. I don’t, I’m not very good at building stuff for other people. I would say, like, I, I’m fine at doing that, but I’m much better and much more motivated if it’s something that I want to use myself and that I want to make better for myself, where I see, ah, This part of the app kind of sucks, right? Like I want to fix this NAF part because it’s really confusing. Right. And no one needs to tell me that. I just feel it because I use the thing every single day. And so again, that restricts the problems based on a lot, right? There’s only so many things I know so many problems I care about. And so immediately that restricts the problems I can tackle a lot. And where exactly that Venn diagram of big problems that I have sort of overlaps. And then ideally that the other part of this is that I want to solve something that businesses are willing to pay for it because we spectrum, we had, we built a product that many people found valuable in that many communities found valuable, but we never managed to get anyone to pay for it. We never made any money. And so that’s why eventually we just had to sell because we ran out of money and our server costs were exploding, but we didn’t, we that doesn’t correlate to an increase in income. And so now I want to build something that businesses are actually willing to pay for it that solves a problem for them that they’re willing to pay for. And so again, that restricts the progress based on even more. Right. And so the more of these sort of axioms, I add the more of these properties I want to have in my idea, or in the problem that I want to solve really that the smaller, the space of possible problems kits. And I have no idea what I’m going to build. I have a couple ideas that that I want to maybe explore. We’ll see. But right now I think. The main thing I’m doing is talking to people. Right. And I’m doing a lot of customer research. I’m talking to people I’m talking many to developers because I kind of want to build something for developers, not for again, I want to solve my problem. Right. And so talking to a lot of developers about what they struggled with day to day, what their work life looks like and thinking about how one could make that easier. And we’ll see where that leads. I have no idea. It’s very scary. It’s sort of a pretty scary time in my life right now because I have no idea what I’m going to do. But it’s fun. I’m looking forward to it. I’m looking forward to the challenge and I’m really excited to be back in sort of back in the trenches of trying to figure out how to leave my stamp on the world, if that makes any sense. Yeah. Yeah.
Michaela: [00:37:19] It definitely makes sense. And I mean, I think we are in very different situations, as you said, right? You’re looking at your own situation, do you think? Well, right now I’m really free and I want to tackle this 1 billion thing. And for me it was more like, well, I’m completely not free. Sorry, I’m competing. I have my two kids and I want to spend a lot of time with them. But on the other hand, I want to go. And for me the thing, he was more, how can I use the time that I have right now to set myself up for success in two, three years, right? When my kids are a little bit more grown up. And I think that I’m getting closer and closer to that clip where I feel like, well, maybe, you know, my time to build something really cool will start soon. And And so, yeah, I think this, this all, I, it really resonates with me, like thinking about, you know, what can I actually tackle? What do I want to do? Right. What is really my, my ambition to, to do here and then trying to figure out. But I still think that even if you take this Venn diagram, it’s a huge problem space still, right? So there are so many things that you could tackle. And so if you do something like, do you try to get now this idea by talking to people, or are you going to build a little bit and testing the waters? So, so what will be the next steps to really understand if there is there’s a market for it? Or, or do you say, well, I’m completely committed. This is the idea I’m completely committed. I’m going to build it. I give it a year. Or is it like tiny bats that you do? Like, Oh this week I’m trying out, you know, I’m sending a tweet and see if people respond or I’m building like this little email list about something. How do you, how do you see that? I do all of
Max: [00:38:57] those things. It sort of depends on how serious I am about an idea and how much I believe in it, myself. Right. There’s thanks to my audience. There’s a lot of things I can validate just by tweeting. Like you said, particularly if I’m building something for developers, I can tweet, does anyone else else have this problem? And then I will feel the resonance or not. Right. Maybe nobody will respond or maybe a thousand people respond. Right. And sort of in that spectrum, I can tell how much that problem resonates with people. And then I can think about how would I approach solving that? There’s a, there’s a little validation that happens that way. And then the other thing is that I. Just ping friends and colleagues that I’ve worked with before or people that I know are using certain technologies. And I talk to them about how they’re using them and what they’re struggling with. And usually I go into those calls with some sort of hypothesis, right. I think maybe there’s this problem that maybe I could solve this way. Let’s see if they have the problem. And if you ask people straight up, do you have this problem? Would you pay for a solution if they’re friends of yours? They’re probably just going to say yes. Right. Because they’re friends of yours. They’re like, they’re probably not going to pay for it, but they’re still going to say yes. And so I actually go into those conversations and don’t even talk about my idea of what I want to do. I asked them what their problems are and then I look and listen and see if they even think about that problem at all. Right. And if they sort of stumble upon it themselves, and if they, if they’re annoyed by it, if it’s grinds their dead, their gears, right. Like the sand in the gears that grinds and it’s been really fascinating. It’s helped me invalidate a lot of ideas and, and tell me that people probably wouldn’t really care about them. Which has been really fascinating to do. I learned that from a great book called the mom test. I highly, yeah, I know that one.
Michaela: [00:40:22] Yeah. When you said that, I was thinking I should have mentioned it, but
Max: [00:40:29] it’s really well, it it’s helped me invalidate a lot of ideas. I have very, very quickly by just talking to someone for five minutes and being like, Hey, you know, what are your problems? What are you struggling with right now? What do you care about? And that very simple approach would be to the tests. We do daycare about your. Problem. And then could your solution solve that problem or not? And it also helps us cover other problems, right? Like I’ve discovered other problems that people have. And now I’ve talked to, I don’t know, 10 to 20 people and I’m starting to see patterns. Right. I’m starting to see, Oh yeah. A lot of people care about this one problem. I wonder if we could maybe solve something there, maybe there’s a solution for that. Right. And so that, that process is very, it’s very fun right now.
Michaela: [00:41:02] Yeah. That’s so smart. It’s so smart because it’s not like just, Oh, I’m going to build this and then you build it. Right. And you’re spending so much time doing it. Then I think it felt, feels maybe a little bit slow. And because you’re not really building something, which I think everybody wants to fill it, rightly we want to do, and we want to make progress. And if you just, just talk to people, it doesn’t feel like progress. It feels like, Oh, I’m still, you know, even before my idea phase, but this can pay off. So I mean, tremendously, if you’re studying and you’re going the wrong direction, I actually tweeted recently about that the tiny steps actually bring you the big success and, and, and do you have to be in the right direction? And this is also what I, I try to be very patient with myself thinking, well, you know, my steps are tiny right now, but as long as they are going in the right direction that I want to go and, you know, have a go completely straight. Right. So you, you learn and you bounce back and you think well, but if you’re open enough to see, well, this is the wrong direction. Now I have to go the other way around. And you know, even six sucking your way to success. I think this is so important and I see that. Yeah. I think you will be very successful. I can can see that. And so I’m definitely going to invite you again. Yeah. In, in a couple of years, right? I know we talk about like how it went
Max: [00:42:19] there. Yeah. We should
Michaela: [00:42:22] do that. Like we do that like in a year, maybe we do it, like go on a journey. Right. So in a year we talk again and then in a year we talk again and look how it goes.
Max: [00:42:34] Exactly. Yeah. I do think one of the things you, you said is really important is, is realizing when you’re doing something that’s wrong when you’re building a company or when you’re building a product, you’re so enamored with that product that you forget to think about. Am I even building the right thing in general? Right? You’re so in the deep, in the specifics you’re showing, Oh, which button do we put? Where, what feature do we build next? What features should we not build? What is more important? What do our users care about? Then you stop to think about the higher level. Does it, is this even a problem we’re solving, right. Is this even something that people care about at all? Or should I do something else entirely? Right. And I see a lot of startup founders particularly end up with problems or solutions to problems that no one cares about. And they never stopped to sort of reflect on, am I even working on the right. Thing right now, like, am I even doing something that anyone’s going to care about? And there’s, there’s sort of different there’s different problems to solve, right? Some are more immediate, some are problems that are problems right now. And people try to solve them right now. And then you very quickly learn whether it’s something that people very much care about or don’t care about whether you have product market fit or you don’t, if you sort of want to talk in the startup lingo. But then there’s sometimes there’s founders that are working on stuff that is way in the future, right. They have an idea of how the world should look like in 10 years and they want to help people get there. And that is really, really hard because at that point right now, no, one’s going to care, but maybe in 10 years, people care and you have to have a lot of conviction to sort of stay on your path, stick true to your values and goal the 10 years to see if that’s actually the future. That’s something I’m way too scared to do, right? Like I, I don’t have time to wait 10 years. I only have very limited time on this earth. And I know a lot of funders that are doing that and I respect the hell out of it. Right. But I’m, I’m way too scared of that. I would much rather solve an immediate problem right now where I know that people care about it rather than trying to do something so big. And so future that it would take decades to realize. Does that make sense?
Michaela: [00:44:38] Yeah, I think it’s, it’s painful. I mean, it’s painful to look at what you have invested in what you have spent your time on and to say. Honestly, I have to do something else here. Right. It’s it’s like I was standing, so I was, I was studying in London and then there was this really cool discotheque where you can go in the night. Right. I think it was called February or something like that. I forgot. And so we got a ticket there and we went there probably at, I don’t know, maybe it was like one in the morning or something or 12. And there was a line around like one of these huge buildings and we really wanted to go in, first of all, the ticket was expensive. Right. And say, if we wanted to see it and experience it. And so we stand in line and we stand in line for an hour and I say, you know, we didn’t even come, you know, like sit around. So what are we going to do? But then, because you’re already standing in our, like, it feels like, Oh, any minute, anyway, we stood actually three and a half hours and it wasn’t a morning when we could enter it. Right. And so it, and it was really this problem off, you know, like you’re standing already in line, so are you going away now? Or, and you leave all this waiting time for nothing. I was really horrible. And I think that this happens also to, to pounders. I mean, it, it also happens to me that you feel like, and, and it’s, it’s a blurry line. Like it’s, Oh, is there not traction because I’m doing it wrong? You know, is there not traction because I don’t have an audience yet? Or, you know, nobody goes to, I mean, there’s also build it and they will come if it’s not true. Right. So. It’s a little bit different, I think for especially people that don’t have like a platform and an audience yet to say, well, I’m tweeting about this amazing thing. And it could be that I am getting zero likes. So one like, and it doesn’t green really mean that, that what you’re building is not interesting. And so, you know, it’s not always easy to really understand is that the wrong direction or is it not? And then to be as honest to you and take this pain to say, well, I think it’s the wrong direction. Let’s do something else. Let’s start over. Yeah. So, so what I try to do is I try to have my, my activities always have one purpose that I know it will definitely work out. Right? So I’m doing this stuff and maybe the whole idea of turns out, but at least I know that whatever happens, there are three steps that are going into the right direction, right. Is it building an audience or, you know, building a community or learning something about the tech that I know I will use. Right. So I have, I have a couple of different goals around something where I say, well, maybe it doesn’t completely work out, but I can for sure say that those three checkpoints that are on my way to success, those three are going to work out. Right. I don’t know if that’s something, how you think about things, but this is, this is really my salt pattern pattern for everything I do. And very often it’s just learning right? Learning about. You know how to blog or how to do a podcast or, you know, something like this, which brings me to the right, you know, brings me closer to where I actually want to want to go. And then I know I have it. I have control over that.
Max: [00:47:49] Absolutely. That’s one of the big reasons I joined spectrum was because I said, there’s no downside, right? I get to work with two fantastic designers that I know online that are very famous for their great work. I get to watch them close and learn about design myself. I get to be a technical co-founder, even though I had no idea how to do that, I could learn how to do that through spectrum. And then you worst case scenario, if it doesn’t work out at all in one and a half, two years, I’ve made two new friends, at least if not many more and learned a ton about how to build a startup and what that even means. Right. And so really even if the product itself had gone in a completely mood, I knew there was no, like, I wouldn’t have any regrets about it, but I knew it could only work out and any success at the proton on top of that was just a bonus. Right. There’s the fact that we got acquired, but gets up is just a bonus, right? Like that’s sort of like that happened and it’s fantastic. And it was a great experience, but it’s not something that was required for it to be a success in my mind. Right. It was always already a success just by the fact of me doing it. And I, I think very much in the same way that you do where I sort of consider the, the whole, the, the implication of everything that I do on a sort of broader scale, right. It’s not just, I’m building a startup, is it going to be a success or not? And that sort of binary, the outcome is good or bad, but it’s. How much do I learn? Who do I get to know? What do I, what do I do? Do I enjoy my life? Do I have fun? Right? Like all these things can tie into it and can make something a success. Even if maybe directly it isn’t the success. If that makes any sense.
Michaela: [00:49:14] Yeah. That’s exactly how I approach things in life. So I think I’m fairly new. I’m happy that I got some confirmation bias here.
Max: [00:49:26] yeah, maybe. Yeah. I have no idea.
Michaela: [00:49:30] Yeah. We can see, maybe people can reply to this episode on Twitter and tell us if they are the same pattern.
Max: [00:49:37] I really curious if anybody else thinks that thinks that way. Yeah, absolutely. Please let us know. I’m I’m I’m super curious. I only start
Michaela: [00:49:43] things where I know it can, can only be a success and it can be a bigger success. Right. But it’s sort of the things that I’m doing are already success, right? Independent of how it turns out. I mean, yeah. So, well, I took already much more time than we actually that I actually set out to talk with you. So I already stolen a little bit of your day-to-day, so I I’m going to end it here, but we did promise that in a year I’m going to schedule again and then in a year we are going to talk again because I really enjoy it. I could talk on and on. And so I’m really curious where your journey goes and how, you know, how you think about the things that we talked about today in a year from now and 10 years from now. So thank you so much, max, for being on my show today, talking with me about all. All these really interesting topics and getting, picking your brain and getting a little bit an idea of how you approach things. I think this was so valuable, at least for me, I hope for my listeners as well.
Max: [00:50:39] Thank you for having me. I hope it was interesting were valuable or at least the pertaining, I hope it was at least entertaining. And I can’t wait to be back in a year and see, I, I honestly can’t wait to listen to myself. Talk about what I’ve just done for the past year. Cause I’m really curious to see where I live.
Michaela: [00:50:55] Cool. Yeah. Okay. So I will link everything in the show notes like bedrock and your Twitter profile. Is there something else that you think my listeners should know or, you know, they should check out that that’s important to you?
Max: [00:51:09] No, I think that’s it. If by then I’ll have a, start-up maybe link that to but I don’t know what that is yet. So cuddly can either yet.
Michaela: [00:51:18] Thank you so much for taking the time and enjoy your Sunday and talk to you in a year on this podcast again, hopefully. Yeah.

Episode 39: From designer to web developer

April 13, 2021 michaela 00:36:51

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!

Links:

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 38: Legacy code and what to do with it – With Michael Feathers

March 30, 2021 michaela 00:49:44

In this episode, I talk to Michael Feathers. Michael is the author of the super-popular book “working effectively with legacy code”. He is also the founder and director of R7K Research and Conveyance, a company that helps engineering teams with their software and organization design. Recently, Michael also joined Globant as Chief Architect.

We talk about:

legacy code and how to deal with it
how systems almost feel like living organisms
how we are on a journey with our code, and why it’s so important to care for it,
how legacy code is the result of an organization where engineers turn faster (leave the company/team) than the code churns.

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

Links:

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

Transcript: Legacy code is a living organism – With Michael Feathers

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 Michael Feathers.

Michael is the author of the super popular book “working effectively with legacy code”. He’s also the founder and director of
7K Research & conveyance, a company that helps engineering teams with the software on organization design.

Recently, Michael joined Global as a chief architect. Since I have been at university reading his amazing book, I always wanted to pick his brain. So I’m super excited to have Michael here with me today. Michael, welcome to the show.

Michael Feathers: So glad to be here.

Michaela: Yeah, it’s my pleasure. I’m really, really excited. Michael, you have been probably working more than 20 years with engineers, with software companies from all over the world. This is so, so fascinating to me. I’m super curious about how different organizations develop software. I’m always asking the questions. What makes teams and organization more effective than others? What’s up engineering practices. Do we have, I’m a big fan of code reviews. And so I want to know from your experience, are there best practices? Can you make out best practices that really lead to success for engineering teams where you say, well, if they follow that, right, they will be very successful versus factors that you think they are definitely bad and lead to a lot of troubles.

Michael Feathers:[00:01:23] The question. And it’s interesting too, because like the practice space is very interesting, but I think a lot of it really comes down to organizational culture, you know? And it’s, you know, if you have a good culture, then basically like the practices will develop almost invariably, right. Or you’ll at least be open to going in and exploring different practices and things along those lines. I think, you know, for the thing that I have gotten called into organizations for quite often, you know, legacy code, the thing I kind of noticed over and over again is that. What is missing sometimes is really a very Frank conversation about the quality of the stuff that people are working on. Right. And in the worst cases, it’s kind of like a. It’s like everybody is told, you know, you must write code and you must design this thing and create it, but nobody’s really paying attention to it. And sort of like, you know, thinking about it as being significant, you know, quite often there’s like a task focus rather than focusing on the quality of the thing that you’re producing, that kind of thing. So I, you know, I wouldn’t really know how to go and actually sort of say, what are the best practices? I think that so many of the things that we basically do. In the industry now regarding testing and pairing and mobbing and you know, the way that we allocate work and stuff like that, a lot of those things really kind of help. So.

Michaela:: [00:02:38] Yeah. So one thing that I thought about is engineering values versus practices, right? So I think that engineering values and developing dos is a team. And not a lot of people are talking about it. Unfortunately I think much more people should talk about values. The engineering values that we have. And not the practices because practices can change and they should change. Right. They should change over time. And with technology changes and with our, how our society changes, the practices should change and somebody comes out and has a new idea. Right. And th they try something, they fail maybe 10 times, and then suddenly they found a new thing. . But the values, I think, for example, what about our. Code health. Right? I wanted the quality of the code that we are expecting how we are developing software, how we are talking about the things I think those values are really important. Is that something that you have more and more teams do or, you know, successful teams do.

Michael Feathers:[00:03:28] Yeah, definitely. I think it’s yeah, it’s a lot of, it really comes down to taking the work seriously. I think, you know, in a way, and in terms of values, it’s, it’s, it’s funny with this too, because you know, there are many different, like, you know May different ways. We can look at, you know, values across organizations and different frames we can use. But I think that actually going and seeing the systems themselves as valuable is like a rather important thing to do as well. Right. And that’s a little piece that tends to be missing at times. One things that’s kind of been striking to me across. You know, my career is basically noticing that in the very beginning back in the 1990s, it seemed like there was this thing of kind of like, well, we’re all kind of like disposable and as engineers, you’re just basically there just to do the work and then basically go home or go bowling or whatever it is you want to do in the evenings. Right. So going and recognizing that we can become more whole people at work and basically valuing our own development and valuing our communication, our relations with our coworkers. And I think that’s a great thing, but then there’s also this other thing too, of like valuing the thing that we do and looking at the things that we create as being significant and having their own intrinsic qualities that we can kind of like, you know pay attention to and kind of foster over time. So yeah, I think one of the things I’ve been coming back to over and over again within my career is just this notion of thinking about the systems that we create as if they were like alive in a way. Right. And we get to care about them. Right. And it’s kind of like this way of going, like applying like this anthropomorphic frame to the things that we’re working with. And some people might say, well, that isn’t like a it isn’t like a good thing or it isn’t a realistic thing, but I find it very useful to come and sort of think of them. Think of the systems we work of is basically things that we can foster and care for. You know, I think that helps us become better engineers.

Michaela:: [00:05:17] When I was preparing for this interview, I read through the things that you write on your website on the RS seven K website. And this is something that I read. I was really fascinated by it. Like. That the code is in living organism. Right. Sort of, and, and I thought, well, this, this is true. Right. It evolves, it changes. People come in and the levels are their think of Prince there. Right? So coded I right. Looks probably quite different than code that you write. And even if you have engineering values around that, and even if you have coding standards, you probably can tell, you know, sometimes the boundaries of this is where one engineering team or engineer work. Then this is where another engineering team works. And you also talked about your, how actually Cultures and the organizational structure shape our code, which is one of those laws that we have been seeing and studying for for many years. Right. Where we see that actually. Yeah, exactly. Right. But you see that you have the organization and the boundaries and how you structure and the design, your organization will reflect in the architecture of the system, which also shows that somehow it’s, it’s living with the organization and growing and, you know, Aging and getting to a legacy when the, also the structures of the organization change. And it probably it’s even harder to change the code per se, when you’re changing the organization. Right. So people change organizations all the time. They’re reorgs in large organization. They’re reorgs all the time, but we’re not reordering the code in the same capacity. . So what is your thought on that, especially about technical debt, for example, Then he called that, that cumulates over time. How should we deal with that? And how should we integrate that in our day to day work life?

Michael Feathers:[00:07:01] The, the main thing I keep coming back to us, like the frame. For this, you know, it’s kind of funny. We can talk about this being like a metaphor that basically code is like biology, but I think just about anything that kind of grows incrementally, where it’s easier to add new things than to change existing things tends to go and sort of have like these hallmarks of organic growth in a way. Right? Like I used to say to people, like, if you, if there’s like a young tree and you kind of like kick it and it kind of like falls over a little bit, it’s kind of like, it’s not going to upright itself. It’s going to basically continue to grow. You know, upward, but from the direction you kicked it out. Right. And in much the same way that kind of thing happens with our code is that the things that we do tend to basically leave their Mark upon the structure of the code. Sometimes in complexity theory, this is called path dependence. It’s kind of like that basically. You’re dealing with something that has a memory and basically what’s possible with it depends upon what happened previously. Right. So I think that the main thing is to kind of like, just sort of like recognize this, recognize that that this is part of the character of, of code itself and that we don’t really ever get to go and sort of like say I’m going to build a brand new system. Like the complete rewrite, that’s going to go and be shiny and, and perfect. You know, that’s going to go and serve. I solve all of our problems that, you know, the, the code that we create, basically we’re on a journey with it and it’s going to basically take time for it to go and react to the new situations in this environment. And those new situations are how our organization is structured. What new features we need within the system. And it’s just going to be like this slow process of change. I think the interesting thing with this in terms of practicality is that. It does mean that sometimes it’s easier to go and create new systems than to go and sort of modify existing ones. And we should be a bit more proactive about doing that. Sometimes we’re basically like you know, if we have particular products and an organization think about creating new products sometimes rather than trying to burden existing products with new features that may not quite fit for instance. So, you know, that’s. It’s a rather abstract answer. I’m sorry, but it’s kind of like, you know, I think that basically this frame that we have of looking at software in this way can help us make some of these decisions a bit better, but they don’t like sort of solve all the problems necessarily in there.

Michaela:: [00:09:21] I heard you say a couple of things, especially before where you said, well, we have to take the quality of the system more seriously. We, you know, we have to be more careful. In my experience. I see, I see several camps, right? So there are the, really the, the engineers that, you know, they love high quality code. They, they learned a lot about how to create high quality code and they really do and nurture the systems quite a bit. Then you have like some tension between business goals here because as long as it works right, and it fits the business goal, there’s like this tension and this, this pull towards, well it’s good enough. Let it. Be please don’t make it nicer or more elegant and more inspiring. Just let it work. And then you have also very pragmatic developers that are maybe, you know, they’re not, they’re not into elegant code so much. I haven’t seen many of those, but they are. And I think a lot of more people become, especially like people that are creating software because they want to create something, right. They want to do products. So we have like a new wave of engineers. I think, especially when I studied a lot of people studied really for software engineering, but they were not entrepreneurs. Are, are only a couple of them were right. And now I see there’s like a huge mass of people that are also. Engineers, because they want to be entrepreneurs. They want to create products. And I think they’re coming a little bit with a different mindset into the whole you know, why are we using code and using code and code is just a means to an end, whereby I don’t know when, when I was in university, it was not a means to an end. It was the end, right? Like, this is why we are here. This is, it was not, it was a product focused. I had not. Lecture about product. I had only lectures about code and what is good code and what are good, you know development practices. And I also studied computer science. So a lot of computer and computer systems and system architecture and so on. But no product, right there was not all, how do we position that product or what makes a good product, not even product management, which probably should be there with it anyway. So I’m saying. I think there are more people now with a more pragmatic view on software than maybe 10 years ago. That’s at least my experience. So how do we balance that? And is that a good thing? You know, is it a bad thing? Can we even say, you know, it’s good or bad? Is it binary?

Michael Feathers:[00:11:46] Yeah, we can, we can basically have like a very instrumental view of code and systems and say they’re there. To serve us. Right. And that’s a frame, which like you say, can basically help you out if you’re an entrepreneur. And you’re just trying to get something to market very quickly. But you know, it’s a story which is, you know, just, you know, an age old story that essentially it’s like people get to market and then they discover they can’t change anything because they’ve created such a brutal system that it’s impossible to work with. So you’re always going to have like a mix of people they’re pragmatic and people that are idealistic, I guess, the. The important thing culturally is getting them to be able to talk to each other and see each other’s point of view and recognize that sometimes you have to be in it for the long haul and you have to be able to make trade-offs that sometimes it’s good to be opportunistic and do something very quick and dirty and disposable. And other times you want to go in like really invest in a particular thing, because it’s important to you. One thing that is weird about this is that I think. If we look at code as being just this mechanical thing or this thing, which is like over there someplace, or the thing that we mess with, you know, when in between our business conversations, which are really more important, you know, then we we aren’t paying attention to it enough. To basically understand when it can get in our way sometimes. There’s a guy I know Colin Brecht who basically started doing this thing called quality views. So it’s an idea that I had years ago and he was doing this within his organization and it’s a really, really cool tool for going in, dealing with technical debt. And I really want, that’s a great thing to go and talk about. It seems like with technical debt, we always go and we ask like the business side for like, Time to go and like go back and fix things. Right. And it’s kind of like, that’s always like a tough sell and it’s also kind of like people say, what am I going to get for that? Right. But the technique around this is to go and say, let’s take a look at our systems. And kind of like make a little pictorial representation of that. Maybe like if you have a big system, maybe it’s like five boxes of things, right. And then when we’re discussing the features, we want to add to the system, we can go and say, okay, well this particular feature touches these three boxes and this other one touches these two boxes. And what you do is you put colors on these boxes to indicate their level of health. Okay. And what happens is that color gradation is going to change over time. Right. And you just basically don’t use that as a basis for conversation with the people who aren’t looking at the code all day. Right. And the neat thing about this is that without talking about technical debt at all, it starts to become like this feeling within the system, within the organization that, you know, the code is a real thing and it has a particular qualities. And those things can either help us or get in the way, depending on how healthy it happens to be. Right. So it’s not uncommon to go and do this and have somebody go and say, gee, you know, this one area of the system is very red and it seems like every time we ask for features to touch this area, you know, it’s going to take a long time. Can we do anything about that? And then you actually have the business going and asking for system’s health. . Whereas before it would be completely invisible to them. . So I think that stuff like this is kind of like the path forward in a way is to basically sort of make. The systems are real to people within an organization. And, you know, sometimes the choice is going to be to do something very pragmatic that might actually go and sort of hurt things for a period of time temporarily. And you might just need to do that for the business, but you’ll at least understand what the consequences are of longer term.

Michaela:: [00:15:07] Yeah. I liked that. I liked that idea a lot, because if you think about a business and it has a building and it is in the building, like, and the building just rots right. Buildings wrong. Right. So they. They get older. The forsake is not nice anymore. The entrance is maybe not nice the floor, right. Ceiling and so on, but people it’s very visible to people and you think like, well, it’s good enough still it’s good enough. But there comes a point where you think, well, we cannot have this entrance. It’s still functioning. Right. It opens the door, but it makes them noise. Right. And it looks horrible. So you don’t want to Valcom your, your people there and, you know, At one point, there is no, you know, no way back to repair it, right? So then you have a big disaster, but this is very visible. So I liked this idea that you actually, you show it, you help people imagine what actually the system looks like, right? So there’s some visibility and transparency in it, which I think is very often missing. And I think that this, this missing visibility and transparency is also something that makes our, our lives so hard as engineers. Right? We are in front of the computer.

Michael Feathers:[00:16:10] It’s completely invisible to people. Right. All they see is people looking at monitors and it’s like, who, you know, they look at us looking at monitors and they’re like, Oh, what are these people looking at? Right. So it’s rough.

Michaela:: [00:16:20] And, and you also, you don’t see, the work and the quality of the work. Right. Do you see a button and one engineer can create a button and another engineer can create a button, but you don’t see what’s behind it. You know, like how is the backend integrated? Is that button actually really usable for another button? The CSS come, you know, from a class or is it just. Do you know, hand drawn into in, in lane style or something, right.

Michael Feathers:[00:16:41] I think it’s almost it’s beyond metaphor in a way, is that I think it really is true that software’s physical in a way, you know, it really is. Now, when you think about object orientation, it’s like objects are meant to represent things or to basically be things that, you know, have cohesion and coupling and can communicate with other things. You know, all of these things live in this virtual space, but it’s like they still. Obey some laws of physics in a way it’s kind of like modularity is like when something grows too big to basically fit in our heads, we basically want to keep it smaller. Right? So you can see that as being just like objects in the world. Some things are just ungraspable because they’re so huge and software can be like that too. So we want to go and keep it smaller like that. So I think, you know, we can use the real world as like a decent, you know, framing device for going and understanding these things and helping us make better decisions.

Michaela:: [00:17:32] Yeah. So I’m interviewing and talking to a lot of people right now, engineers, and I’m talking a lot about, you know, their values and also the code based health and what makes them happy, what makes them productive. And one thing that I hear over and over, and again, is that. You know, you have your engineering heart, right. So good code, good quality makes you happy. That’s definitely something that I see for, for many, many people, not everybody, but a lot of engineers, but then you have all these system constraints and now the system is an organization, right? So you also have, you have to fulfill. Your duties, you have to do what you’re supposed to do, and knowing that you’re doing what you’re supposed to do, it makes you also happy. It makes you more excited. Right? So if you know that you’re actually working on something that you’re not supposed to work on, it makes you unhappy. And, and it’s also risky to take on the task, right? So there’s this, there’s this productivity then there’s this code health and they’re all some how intertwined. Right? So people want to work on, for example, technical death is something that people, a lot of engineers would say. Well, it’s a challenging problem. I like to tinker with Dakota, like to make it nicer. I like to make it more, you know, reusable, more maintainable and so on. But on the other hand, there is business constraints and business needs. And my manager, you know regards me, or also evaluates me based on the features that I’m delivering. So I actually cannot take on. Technical debt. And very often I hear also people talk about the commitment is too big, right? So it’s not only that it’s a single engineer that cannot take on the technical debt. Even the team mission is not aligned with, you know, getting rid of technical SRE. They will work a little bit on technical debt a little bit here, but then the. They’re getting more, accumulating, more technical that overall. So they are actually not, you know, they don’t feel that they can really do a big thing. And I think you probably people will call you when there is like, when you have a problem. Right. So it’s too far. So how are you going to change the mindset? How you’re going to work with the people?

Michael Feathers:[00:19:32] People usually call me once they recognize that they actually have a problem, you know?

Michaela:: [00:19:36] Yeah, it’s very late, right?

Michael Feathers:[00:19:37] And I think that’s the bigger thing too, is just as developers, when we’re working in an organization, it’s a bit of work to go and actually go and convince people that actually some investments in going reducing technical debt gives you a payoff. Right. I think the most important thing to go and recognize this, that like there’s almost like this 80 20 rule that basically goes and happens with code change. And I, you know, I haven’t really seen research around this, but it seems to ring true. Maybe you have, I know you have a. We have a research background, but it seems like there are hot spots in code systems where basically there a lot of change tends to gravitate towards them. They can shift over time. Right. So the thing is, it’s kind of like as a developer, if you’re going and looking at something that’s pretty messy and then you look back and you basically see that that area had like, Thousands of commits made against it. One thing is you can pretty much count on us, any little thing that you do to go and make things better. There is probably going to go and give you a bit of a payoff, you know, going forward because of the fact that it’s a hot area of the system that goes and gets a lot of change, right. And I’m getting, you know, in the organization, just, you know, we should never look at technical debt as being like this thing, which is a uniform across an entire code base. I mean, it is in a way, but it’s like in terms of the value of technical debt, It’s wildly different in different areas of the code. Some areas are more mission critical in your code base than others are. And if you can at least have different say, rules of engagement for the system and go and say, you know, we know we don’t have very much time, but you know what, whenever we touch this particular part of the system, we’re going to be really careful about this. And we removed. Technical debt because we know that it’s critical for our business and we’ve changed it a lot. Just getting simple agreements about that, going forward, give you almost like a bit of a foot in the door in your organization to go and have this conversations about how quality impacts things. So yeah, it’s never like this thing of like, Hey, let’s go install technical debt. It’s more like let’s find out where it really pays off and then go and use that as a way of going in sort of like surfacing the conversation and doing something about it. Cause that’s gonna be a smaller investment.

Michaela:: [00:21:36] Yeah, hotspots is definitely something that we saw in many different empirical studies as well. Right. So that problems accumulate in different areas more than others. And there’s clusters that around that and so on. So it is definitely. Rings true for me from, from this perspective as well. And I like what you said, well, technical debt, you don’t have to work on every technical debt unit code base. Right? Some of that, it doesn’t even interest you because you’re not touching it. The system runs, there’s not, I think a lot of much it backs you has to do with how often you’re changing the parts, that there is a lot of technical debt, right. So if you’re not changing the parts who cares, right. Probably I don’t

Michael Feathers:[00:22:17] And, and really, I think, I think that’s one of the things I like in my book. I talked about this a bit in terms of writing tests, like going and breaking dependencies and writing tests for particular areas of the system is that because there’s this kind of like power lodge, predo distribution of code change that if you take the time to break dependencies around a huge class and write tests for it, chances are, you know, you’re going to come back to that relatively soon and basically go ahead and discover that that work has already that hard work has been done. And you’re going to be able to take the benefit of that work. Right. So it’s kind of like, it’s, it’s weird because like that power Lalish growth goes and leads to some chaos and systems, but it would also helps us in terms of going and sort of focusing our, when we focus our energy, we get payback for it also. So it’s like a place where we get a virtuous cycle that goes into Alliance with the psychotic cost of the problem, you know, so we can sort of. Leverage it to go and solve the problem as well. Like, I’m not sure I can put words better yet, but.

Michaela:: [00:23:15] No, it sounds, it sounds good. Yeah. . So you were talking about testing and in your book, and this was also a good question and it was actually asked on Twitter, right? And your book, there was this really strong connection with legacy code and the. Lack of tests, for example, because if you don’t have tests, tests, somehow are also a means to an end. Right? Did they give you confidence that when you are making changes, the system is still very similar to what work, what it was before, right? So you’re not introducing anything. Box, hopefully. Right. And so the better, the better the test, the better your confidence. And so you’re, you’re actually able to do changes without any tests you don’t know, like, are you messing up completely here or, you know, are you introducing a lot of side-effects and so on? Is that still in definition that holds true for you today? Or would you say that over time, the definition of, you know, what legacy code is changed for you?

Michael Feathers:[00:24:09] Well, I think any definition like this. And instrumental. I was actually the time I came up with us working with a team and I sort of just got angry and I said, you know, people, weren’t writing tests. I’m kind of like, you know, it’s kind of like, you know, this is legacy code because it’s code without tests. And I started ranting a little bit right in front of mine, says, you know, you should write that down. I’m like, okay. So I did. But the, the reason why I really was trying to press that point is because it was like really obvious to me through my experience at that time that. There’s a real strong, qualitative difference between code that has test coverage and code that doesn’t in the sense that if you don’t have test coverage, quite often, you’re scared of making changes and you can be much more conservative about how you, you know, do things you may not refactor as much. And you know, just, you, you have like a, a greater sense of ease working in code that has decent cusp test coverage. And I thought that qualitative difference is just so high. That’s worth going in highlighting that and basically going and tying that into a definition of legacy code. But then, you know, there’s the thing of kind of like there’s many different definitions of what legacy code is, and, and they’re all useful to some degree and that’s fine, but you know, I think for people that need to hear it, that’s the one I still use just because it’s, you know it helps people go and it’s, it’s a definition which kind of points to the solution, which I think is useful for us. If we’re trying to go and galvanize attention towards better practice.

Michaela:: [00:25:32] So on your head you also wrote. What we call legacy code is exactly what you would expect when developers turn over his I fast error, dent code turnover. Right. So for me to seems very much it, legacy code has to do with the loss of the knowledge about the code base. Right? So if you’re, and this sometimes has to do with the technology as well. Right? So if you think about systems, you know, written in some languages, Well, we just have really only a few people that are still familiar with this code it’s legacy code, right. Or if you’re having a code base and people leave, even it’s written in reacted, she’s now, you know, modern and that everybody knows it. People don’t have knowledge about the code base. So it’s legacy code. Is that something that you think also rings true for you?

Michael Feathers:[00:26:18] You know, I kind of like somebody offered that as like a an alternative definition is that, you know, legacy code is the product of, you know, it’s when your team turns over faster than your code turns over. Right. That kind of thing. And I think it’s important to go and basically see that system dynamic because it really affects. A lot of the decisions we make about process and team structure and all these things going forward within our organizations. I remember, I try to remember which tool this was. So I won’t mention the name because I’ll probably get it wrong, but there was like a tool that’s widespreadly used within the industry of database technology. And my understanding is it’s actually done only by two or three people. And they’ve been working on it for decades and it’s kind of like their life work is basically going to supporting this particular piece of software. Right. And to me, that’s almost like the ultimate fantasy in a way. It’s like, Oh, you know, have this house that you live in, that you basically sort of like remodel, continuously accepted this code. And then basically, you know, it so intimately that you’re. In this space where basically it’s never really legacy to you because you’re constantly able to go and improve it and add to it and stuff along those lines. Right. And it should never be something which is too big, where it’s too big, then, you know, It’s so big that a couple people can’t work on it together, you know, that you need an entire team. But it’s interesting without to go notice that that’s almost like an idealistic situation of having something that’s durational, the people are going to be with it. Long-term, it’s relatively small and you can basically do a lot of really great practice with it. But the thing is, it’s kind of like in. The typical development that happens to these days that never really quite happens. The software tends to grow up, grow bigger than us bigger than what will fit in like two people’s heads, for instance. Right. And beyond that people will basically leave and go to other jobs and other people will come in and stuff like that. And it’s these things that happen, which go in, tend to go in. Cause you know, the, these issues that we tend to have, and then we have to go and introduce practices like, you know, extensive testing. You want to make sure that we can. Detect when something goes wrong in this thing that we don’t quite understand when we make changes to it. Right? All these things are almost like props that we use to go and basically deal with this fundamental mismatch between the lifetime of the team, the lifetime of the code. And I think it’s kind of a fascinating thing to go and recognize that those tensions are inherent in what we do. And it’s not that we’re bad programmers. We’re just dealing with a pretty hard problem that we have this, this lack of alignment between team and, you know, piece of code that we’re working on.

Michaela:: [00:28:44] Yeah, exactly. And I think it has also to do with, I mean, there are so many factors that influence that. So for example, in our industry, people that are, you know, five year in one company, this is like, Five years. How could you say that long? Right. Like people are turning over really quickly also for various reasons. Very often also because they want to level up. And because there is, or yeah, because there is a lot of opportunity out there, right. So people can choose, pick and choose, be quite choosy. But on the other hand, as you said, well, people are leaving and they’re with them. A lot of knowledge is leaving, which I think sometimes organizations still don’t recognize the value of the, just the knowledge that people have in their head that they accumulate. Right. Because, and we see that and you know, that I’m a big fan of code reviews, for example. And I did a lot of research on cultural reason. What we see for example is that. The person who has seen fight at least once this is the big zero to one, right. Has seen the file, the, the code that you’re asking them to review, at least once, then it will give much better feedback than before. Right? So if you look for example, usefulness of feedback, and so how many of the code review comments are useful? We see that if they haven’t seen the file before the code, before the code base, before this part of the code base, before they give around three. Out of 10 useful code comments, right? So only 30% of their comments is really useful to the author. But if they have seen it, at least once it, grows from 30 to 70%. Right. So this is a big jump, but then you only see incrementally, like until five times, then it doesn’t matter anymore. Right. So if a person has seen the code five times, then it’s plateauing the usefulness of the comments that they are giving. Right. So, but culturally is in general. I think it’s a really, it’s a good practice if it’s done right. To help that more people are familiar with the code. So for example, if you have at least two people or three people that have seen the code base, or know a little bit of what’s going on there, they don’t have to be in a, like the author of it. But I think they are quite intimate, familiar with the code base because of the cultural reason we see that. Knowledge really increases that we can measure, even at the knowledge of the code base increases for teams that are doing code reviews versus with teams that are not doing code reviews. How is your experience with that? Is that something that you recommend that you recognize as important and so on?

Michael Feathers:[00:31:08] Yeah, no, I think it is. And it’s, it’s funny with this too, because I kind of come, you know, at least I’m gonna become a consultant. I really got embedded, like in the extreme programming and agile communities. And so we had like pair programming in the very beginning and we would basically use that as like a. A way of going and trying to go and arrive at like continuous code review. And then more recently you have mob programming and ensemble programming as well. And it’s kind of weird about this because it feels wrong in a way to go and have five people working on the same piece of code at once, right. In a group. But I can’t. You know, the more I reasoned about it from first principles, I think it’s actually a pretty decent thing to do, right? If knowledge loss is one of the main things we we deal with over time within an organization and basically making sure that everybody’s involved in the decisions and those, the code intimately, it’s probably a decent investment for an organization to make. It’s a hard sell. I’m sure you know, many organizations, but it’s, it’s also something which is kind of fascinating. I think one things that’s kind of funny with this. I know that like, this is like, Knowing this pod, you’re kind of like asking me a bunch of questions, but with your background in code review, the thing that I kind of noticed, and I’m wondering if there’s any research around this is that sometimes there’s this issue of like, whether people will really be forthright about their criticism of a piece of code. And if they’re not, do we basically just sort of like let quality deteriorate because nobody really wants to step up and say, there might be an issue here, you know, is that a thing which happens in code review that you’re.

Michaela:: [00:32:34] This is definitely something that happens and it happens for various reason, right? It could happen for example, because people know that even if they are criticizing it. The team and the organization, how it’s structured and how, you know, incentives work and all of that. Right. So there’s a lot of that behind the theme thing. It’s too late. Right? So most of the time the criticism that’s not sad is because it’s too late. So even if I would say it right now, we are not going to, you know, change it. We are too far in it. Right. So this is, this is one, one part where this happens quite a bit and it’s really sad. And you know, this is also a planning issue, right? It’s the ticket to big when are we involving people to give feedback? And so, you know, people have worked like a month. On something. And then you’re, it goes higher up and people say, well, this is from an actual perspective. It’s horrible, but it cannot even say it anymore. Right. They cannot change you’re too far in. And then obviously there are also hierarchy issues, right? So is a, is somebody allowed to say something? Is it even hurt when you’re saying something? . People learn if the, Code review feedback is not perceived or not received and not changed people that also learned that this doesn’t, you know, it doesn’t make sense. So this is definitely something that happens. There’s also something called, you know the priming bias. So if you see that other people already looked through the code you’re also primed for their answers. So the best thing would be that people are looking through the code without looking how others responded and say, well, it looks good to me, or, you know,

Michael Feathers:[00:34:05] Yeah. And we’re talking to somebody, an organization, a very big software development organization, and they were saying, we know we hire great engineers. But the one thing that we kind of noticed is that essentially we can see through the metrics that the code quality is deteriorating, but nobody on the team knows because they’re just so used to looking at the same code all the time. They just kind of understand what’s going on with things. So the newcomer. Would be completely, you know, I’m surprised by so one things I kind of wonder about all the time. It’s like, can we basically get new people on the team, people visiting that we’ll be able to basically say, well, you know, you’re saying this is great, but I don’t understand it. And then sometimes I might be like a, like a jolt to go and say, it’s like, wow. You know, it’s like, are we building a silo of understanding here that basically is disconnected from understanding of the world. Might be a possibility with that too, you know, to go and sort of like try to mix things up a bit to the point where the teams don’t become stale in their understanding.

Michaela:: [00:34:57] Then, for example, culture feedback, right? So I’m working also a lot of very often with people or teams on how to give feedback so that others even can, you know, receive it. And very often there is like, Oh, but in our team, we understand when we are talking very harshly with each other or whatnot, right. But this is also a sort of blindness, which I think is very similar to the blindness for your code that you say, well, if you have to be very intimate with your team and know that this is actually not a harsh comment, but it’s a joke for you. Then first of all, it’s not coming to others. It’s not something that you want to leave on because in two years, your team is not a team anymore than it is today. Right? So if somebody looks at this code comment they will not understand. Right. And it’s also, as you said, it’s something that you’re building up where. It’s not conforming to what we were expecting outside. Right. So it’s really something that’s very, it’s a very narrow, very blind view on your system. Right.

Michael Feathers:[00:35:49] Yeah. Yeah, no, it’s, yeah. There’s a lot of really interesting dynamics around all this stuff. I find it really fascinating. It’s funny. Conway’s law, you know, we’re Conway’s laws, you know, saying that the code structure is gonna end up going in, mirroring the structure of the teams to kind of like, you know, look at that at a very deep level and go and say the same thing is true with quality. If the coast starts to be kind of messed up at probably in the case, there’s communication problems within the team, in terms of nobody’s able to go with, stand up and say, there’s something wrong here. Maybe, you know, I mean, it seems like that kind of effect can occur as well.

Michaela:: [00:36:25] Lot of different issues behind why quality deteriorates. Right. So what I also often see you and I mean, It really breaks my heart is that if people want to, but they’re just really, they can’t or they feel that they can’t. Right. And this is very often from an organizational perspective. So one question that I had for you is when you were coming in, I think there’s a lot of buy-in from a path, right? So there’s a lot of top down. Understanding suddenly, Oh, this is important. Whereby teams are dealing with this bottom up, you know approach really have to see, well, I see this is a problem. We feel this is a problem. We don’t have enough time to do it. You know, there’s a lot of deadlines and so on and they would have to communicate up to which I often feel. This is really, really hard. And if you don’t have commitment, this is also what developers say, right. If I don’t have to commitment, I just can’t fix it. It doesn’t matter if I find it important or not.

Michael Feathers:[00:37:19] The advice that might be kind of seen as like problematic in a way. Right. But the thing is, I think sometimes with a good team, If you can find other people on the team that care about co quality issues, the way that you do just form a little bit conspiracy with them. It’s kind of like, you’re not going to ask for permission. You’re just going to make things better silently and just not really talk about it with the rest of the team until they start to notice just like through osmosis, that this is a better way of doing things, right. One of the worst things you can do as a developer is try to lecture your other developers on the team. Right? Nobody likes that. Right. And you know, if you have. Some respect already that you’re able to go in sort of like say, you know, you should really do things this way and it works. You know, communication wise. That’s great. But if you don’t have that, you know, it just doesn’t go all that far. But I think, you know, the, the main thing is the programming can be very fun and cleaning things up can be very fun also. Right. And if, you know, you can develop that kind of culture internally within the team. That’s great. And worked with a team a long time ago that really had this interesting thing. They did great work, but part of it was also a feeling that every other team in the organization was a bunch of idiots. In a way. So it’s kind of like this thing of going and saying, like us versus them and it formed like this cohesive group with them. The thing is they were all smart enough to go and recognize that, you know, that was like not the truth. It was just like this little story they told themselves to basically sort of like say. Yeah. Yeah, we’re doing this great thing. And it’s like, who cares if nobody else really uses it? You know, that way that we intended, it’s like, it’s still okay. I think we can basically play those emotional games a little bit to sort of like not hurt anybody, but also kind of bolster ourselves up as we try to do things. It’s funny, cause I’ve mentioned this a couple of times in interviews and stuff that I really feel that I missed an opportunity with the legacy code book to basically give it a positive frame because even though it can be kind of treacherous to go and deal with legacy code, it can also be like, And adventure, if you basically sort of frame it that way, you know, it can kind of let go and say, look, you know, you’re kind of like going through this crazy jungle and you’re learning things and you’re picking things up and making things better as you go. And that can be a decent way of going and motivating yourself and people around you to go and do some cool things.

Michaela:: [00:39:26] I think that a lot of engineers actually like cleaning up, right. It’s like, If you have like a kitchen sink and it’s, it’s dirty and then you swipe over it and it’s nice. Right? And so I think a lot people also recognize that and it’s, it’s a hard problem, right? It’s on one hand they had problem. There’s a lot of architecture thinking about it. So sometimes maybe people don’t even have the possibility to be involved in such. Higher decisions or impactful decisions. And suddenly with refactoring, all those decisions are actually at your fingertips that you can actually change something and make it better. And, and, you know, it’s in the small, but it can have a lot of ripple effects and all of that. Right. So to think about that, I think can be very challenging and.

Michael Feathers:[00:40:07] Too, when people are talking about what good design is, it’s kind of like, you know, if you give anybody a blank piece of paper and tell them to design something, they can usually do something really cool. But the real skill in design is working with stuff that’s already there, right? Because the number of constraints that you have basically go into sort of like help you exercise your design skill in a way, because you have to go and sort of like work around them and work with them. At least to deeper design insight, working with things where you have, where your environment is a bit more constrained than than you might hope it to be.

Michaela:: [00:40:36] Yeah. So there were a couple of questions on Twitter as well that I want to be even a little bit. So I was thinking about best practices again. So people were thinking about how can we, you know, show best practices. I asked you that at the beginning as well about best practices. And we talked a little bit about transparency and in my recent discussions, I’m discussing a lot with engineers right now. We also talked about transparency and how cool it would actually be. Okay. In an organization or outside of an organization to see, you know, what are people doing and then also seeing the impact, right? So you can pick and choose. And there is also, this is also something that we are lacking a little bit different transparency of best practices. Well, even if practices, right, it doesn’t have to be the best practice, but the practice. How, how is that team doing? How is this team to doing and similar to what you said too, when I’m working with larger organization, we also see that all there’s this division and that division and the third division. And then they think that this division is actually doing the best. Right. And so they’re really proud of their Practices and the other are doing like really bad work. And suddenly you see that people are working and there are constraints. Right? So because one is like the driver division. Yeah. Which is a very different kind of a beach. And if you’re working on the website side of things right. Where you can update things much easier, but it would be really cool to see a little bit. How are people working and H how could you do that in an organization? Is there something that you learned. Where organizations surface that and show what are good practices that other teams should adopt.

Michael Feathers:[00:42:07] Yeah. Typically with organizations that worked with them, I had them kind of like moving too. Like this show and tell mode where like, you know, once every couple of weeks or something like that, people from different groups will present what they’ve done and kind of like just make that available for people to go and see, you know, where the other possibilities are, you know? And it’s, it really does. You know, a lot of it does come down to what you were saying earlier is that some practices might be better in certain types of development than others. But the thing is, you know, you get to raise the consciousness of those things and it’s. Creating forums for those particular things. And the cool thing with that, as you get developers real used to going and doing a little bit more, like say public speaking, even though it’s internally within the company to go and describe, you know, the various things that they happen to be working on and doing. Right. Yeah. I don’t know. I don’t know that there’s anything that’s really like, you know, it’s just doing that. Sorry.

Michaela:: [00:42:54] Yeah, communication, right? Brown bags, for example, that you

Michael Feathers:[00:42:57] Yeah, I think, you know, nothing. I would go and add to that too. Is that even though transparency like that as a good, I think it’s one of those things where it has to be discretionary rather than we’re completely transparent all the time. Right. Within an organization. I think one things that’s kind of cool is that when you have. Different groups of people within an organization working on different things, they can incubate something and basically not worry about somebody going in saying, well, maybe that’s not a good idea. It’s like, no, we’re going to try this for a while. And we’re going to go and see what works with that. Then basically go and give you results. Once we feel more comfortable with that. And then you get like the enhanced. You get enhanced psychological safety within that cloister in a way because you don’t, you know, everybody’s kind of got the buy-in and the relationship with each other. And that’s just a natural part of being human, right. To be able to come and sort of like, you know, grow things in a safe environment and then present them out into the world a little bit. But you know, a lot of this really comes down to leadership really within your organization. Can you basically go and sort of like, make it. You know okay. For things to be, not to be okay. Not be okay sometimes. Right. And just sort of like, make people feel safe to go and communicate back and forth, then, you know, do the things they need to do. So, yeah. Culture again, you know, I think I said.

Michaela:: [00:44:07] That’s true. Yeah. I, this really resonates a lot with me. So maybe the last question that I want to ask you, and it’s a little bit connected to the Twitter. Things is about testing. So I made a study, actually. I think it’s. I dunno how many years ago? A couple of years, eight years, 10 years, 10 years time flies. And I was looking at unit tests versus integration tests and system tests. And at that time, people were all over unit tests, like unit tests, you know, is, is the bullet that brings you joy and happiness. And I, I feel that this shifted a lot over the last year. So right now people are more into integration, testing, more into systems testing. What’s your thought about that? And especially in connection with legacy code, are we still because legacy costs, I think a lot of things were still unit tests, right? So we are connecting, having unit tests and having tests in general around the system to make changes. Has that shifted as well? What do you think about system tests?

Michael Feathers:[00:45:00] Yeah, I think, I think it’s shifted a lot with service orientation, right? When we’re doing like microservices and stuff along those lines, the there’s like a, you know, We talked about like code being alive, right? There’s this great talk from Alan Kay at oops, look basically in the 1990s where he basically goes and draws a parallel between code and biology. And he talks about, you know, his original conception of object orientation being kind of like cells communicating with each other through messages, by chemical messages. And it’s kind of funny because when you send messages from one cell to another via chemicals, it’s asynchronous and it made me kind of realize it’s kind of like, you know, Well, we wanted Ohio to be Israeli. What services are in a way it’s like you can send a synchronous messages notifications across these services and they can be really very well decoupled from each other. Right. So basically going and testing things at a service level is a very decent thing to be able to do. The unit testing thing was really very proud, met pragmatic. When it comes down to, if you’re making a change to a particular piece of code, you want to be able to go and get close to it. And if you can basically go and write tests, like at the class level around it, then you’re in a situation where you can go and get immediate feedback about what you’re happened to be doing. And so it’s like this way of going and sort of like building. You know, building like this assurance as you basically go and make changes that you really are doing the right thing. So unit, it seems like units in object orientation tend to align around classes or aggregates of classes. And so I tend to see those as being a unit in a way and that wrong. And it’s really all about going and making it possible to go and get that feedback and, and build, you know A knowledge-based through tests that basically can go and find out very quickly by running whether things are working or not. One of the things I’ve been kind of throwing around is as a frame recently as that essentially test determined where your unit in a way that if you can basically go and get an area of code. And it’s easy to go and basically test it. Then that’s a decent, decent definition of unit as you can ever get. And for you, a unit might be a service where it might be a class, but it’s the point at which the testing comes to difficult that you basically know that you’ve got a modularity boundary, that isn’t all that great. And it’s just, you know, like a way of going and looking at things in that realm. So yeah, I don’t, I don’t really, I think as long as people go and understand that tests and modularity kind of. Work together in a very interesting way. It doesn’t matter to me whether you call it unit tests or systems tests the test will give you feedback about your modularity and that’s a cool thing to know.

Michaela:: [00:47:26] Yeah. Yeah. Like the, like the frame so well, Michael I think we are at the end of this show, I’m really happy that I could pick your brains for so long. Is there something that you wanted to let my listeners know before we are ending? And I will definitely link a couple of things down there in the show notes, but is there something that you, you know, that you’ll want to end the show with?

Michael Feathers: [00:47:48] Yeah, I guess just basically going in saying that we’re all part of one, we are part of the system as humans working in software development, and we need to basically take the systems that we work on seriously. And, you know, I think that seriousness for us means kind of like looking at them as entities that have their own qualities and we can make them better. You know, the thing about this, that. I think it’s kind of fascinating is that if we are going from job to job and place to place, and these systems remain behind, you know, it’s good for us to go and actually exercise enough care that we leave the place, leave the system better for the next people, because you know, that’s just what empathy is all about.

Michaela:: [00:48:26] So you show your empathy through your code, right? In the quality that you leave for the people that have to deal with it.

Michael Feathers:[00:48:34] like a couple of years ago. It’s like code is the way you treat your coworkers. Right. And it’s kind of like, it’s true. You’re not really us. So

Michaela:: [00:48:41] Yeah. Yeah. I like that end note. Thank you so much. Um, was a very inspiring talk. Thank you so much for taking the time.

Michael Feathers:[00:48:48] Excellent. Thanks.

Michaela:: [00:48:49] Okay. Bye.https://grain.co/highlight/lUGaWr1iPs39D4HeOqszHXnglk9i9tIRzcy6wk52

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

March 16, 2021 michaela 00:51:40

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.

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

February 16, 2021 michaela 00:46:02

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.

Episode 35: How Programmers Think and Learn

February 2, 2021 michaela 00:50:01

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.

Episode 34: Vulnerability disclosure with Katie Moussouris

January 19, 2021 michaela 00:35:32

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.

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

December 22, 2020 michaela 0:50:08

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

Episode 32: Serverless is your competitive advantage

December 8, 2020 michaela 00:53:32

In this episode, I talk to Nader Dabit. Nader is a web and mobile developer, who specializes in building cross-platform and cloud-enabled applications. Right now, he works at Amazon Web Services, where he develops features in the client team and improves developer experience. Before, he founded his own training company, specializing in React Native, and trained engineers from organizations such as Microsoft, Amazon, the US Army, and many more.

We talk about:

how he managed to build a following on almost every popular social platform,
how he got started with his own training company focusing on React Native
what serverless means, and why you should care about it,
how to build an MVP using a serverless-first mindset,
and how frontend developers can leverage serverless technologies to become a full-stack developer.

Episode 31: Combatting tech debt in war rooms

November 24, 2020 michaela 00:53:32

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

We talk about:

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

Author

michaela

About the Author

Getting ready to build a billion-dollar business

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

Transcript: Getting ready for a billion-dollar business

Episode 39: From designer to web developer

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

Transcript: From designer to web developer

Episode 38: Legacy code and what to do with it – With Michael Feathers

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

Transcript: Legacy code is a living organism – With Michael Feathers

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

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

Episode 35: How Programmers Think and Learn

Episode 34: Vulnerability disclosure with Katie Moussouris

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

Episode 32: Serverless is your competitive advantage

Episode 31: Combatting tech debt in war rooms

Search

Archives

Pages