This post was originally written for
Trend Micro .Reasonably Accurate 🤖🧠 Transcript
Mark: Hey everybody. And welcome to yet another episode of #LetsTalkCloud. we are coming to you, live across three main platforms here. we are hitting up, LinkedIn Live, we are, on YouTube, as well as, Twitter.
Hashtag is #LetsTalkCloud as you can see, from up at the top of the screen. And we've got the tea- excuse me, we've got the team monitoring, the chat across all three so if you have questions, or comments on the discussion, as we're going along, please feel free to jump in. I can see already we got a ton of people, live on the stream.
We've got folks, from, Canada, from the States, from Mexico. from India, from Chile. tuning in from the EU. folks from all around which is really, really awesome. this has been a really fun series. My name's Mark Nunnikhoven.
I'm the Vice President of Cloud Research here at Trend Micro. and every week on #LetsTalkCloud I get to talk to somebody, exciting and interesting about, stuff that they're doing in the cloud.
What challenges they're facing, about issues they're dealing with. and this week, I have, the privilege, to speak, with Madeline, Van Der Paelt. She's a rising star in the Trend Micro engineering development ranks.
Madeline, welcome to the show.
[00:05:58] Madeline: Hi. Thanks for having me.
[00:05:59] Mark: Do you want to give us a little blurb about yourself?
[00:06:02] Madeline: Sure. I'm a software developer at Trend Micro like Mark said. I work on a team who's working on Trend Micro Cloud One.
And we get to do all sorts of cool stuff with serverless, cloud architectures. It's really interesting stuff. Yeah.
[00:06:17] Mark: Awesome. Very, very cool. So, for our discussion today, and the title of the show what I thought would be really interesting is to frame it around, a new book that came out.
And this book is called, The Unicorn Project. It is part of a series, you can see here on screen now, that started back in 2013, if you can believe it or not, with a book called The Phoenix Project.
And that was, really, what sort of solidified the DevOps movement, the merging of development and operations, followed up quickly, by The DevOps Handbook, Accelerate, and then finally The Unicorn Project.
[00:06:49] And the premise around The Unicorn Project is, it's all about, developer enablement. Really about developer productivity. So who better to speak to, than one of our top developers to find out, the challenges and sort of the real side, the personal experiences.
Because if you're not in development, you can read this book and go, "Okay. This seems pretty logical." obviously you know it's written, like The Phoenix Project, as a novel as opposed to like The DevOps Handbook where it's, you know, more academic, more structure problem.
But this focus is really on developer productivity. So why don't you kick us off, Madeline? Give us an idea, like, what do you think the key to developer productivity is?
[00:07:30] Madeline: Oh. Good question. I would say that the key to productivity as a developer is being encouraged and allowed to experiment and sort of deviate from, you know, the way you've always done things.
And being allowed to, try new methods, new architectures, new technologies. because that's really what enables you to find what's going to work for your product or your project, and enable you to go faster while doing those things.
[00:08:02] Mark: Yeah. Okay. That's fair. So one of the things that Gene... so Gene Kim is the author of this book as he was the primary author on The Phoenix Project. one of the things that Gene is, is fond of quoting lately, because you know being a key in that mo-, movement he always gets asked, you know, "What's the definition of DevOps?"
Which is one of those questions for you to just go like, "Oh! Crap." Like, "Okay." you know, and being the guy I'm sure Gene's sick and tired of it.
But one of the answers he gave in a talk, recently around the, the book that, we're discussing today, was, he liked this definition which is, "Better value. Sooner, safer and happier," was the definition of DevOps and that's from Jon Smart. and I think it's, it's a really interesting one.
You know, because it talks not about like, "Give them better tools. And do this." It's more of a principled goal. what- what's your opinion on that?
[00:08:48] Madeline: Yeah. I think, it's an ide- ideol- ideology, not a prescription by any means. enabling people to feel as though they can, they can try to improve things, [00:09:00] is super important, right? That culture of, of, like a learning culture or, where there's no fear of falling on your face. [laughs].
[00:09:09] Mark: [00:09:09] Yup.
[00:09:09] Madeline: ... that's super important to enabling it. I would totally agree that it's not, you know, a one-size-fits-all solution. you have to figure out what, what works for your people and, and go from there.
And, and asking them what they need, as opposed to just providing them a bunch of tools and saying, "Hey. These things will make you go faster," is super important too.
[00:09:29] Mark: Okay. So l- let's explore that a little bit. Because I think that's interesting 'cause a lot of, like, maybe they- they're not as connected, not as with it, approach would be like, "Here's a set of tools." Like, "Here's our standards.
Here's, how you should be developing. This is what you should be using, because this is what the team is using, right? We've standardized on the following things at our organization." Does that run counter to this idea?
[00:09:53] Madeline: I would say there's a time and a place for standardization.
[00:09:59] Mark: Mm-hmm [affirmative].
[00:10:00] Madeline: So, within a team for example, you don't want five developers working on the same codebase using five different tools. But at the same time, what works for that team might be different from what works for a different team.
So, I would say standardization isn't necessarily counter to it, but you don't start with standardization, in my mind. You would start with exploring your options, you know, experimenting and then figuring out what works best for the situation that you're in.
And then saying, "Okay. When we're in situations like this in the future, here's a set of tools that I know worked for me in the past. Maybe I can leverage them again. Or maybe there's new tools that have come out and I should explore some new things again."
[00:10:41] Mark: Okay-
[00:10:42] Madeline: So I think it's sort of an iterative, iterative thing.
[00:10:44] Mark: Yeah. And I think that seems to strike a balance between, you know, ending up with a 20-year-old IDE that you're trying to make work, and also not going cutting edge non-stop, right?
And actually just never, you know, like I always look at the JavaScript world and go like, "Oh my god." [laughing]. Like, it's Tuesday, let- let's create an entirely new framework and movement, right?
Like it's, it's overkill on that side. but do you find it if... you know, personally, do you find it challenging to strike that balance between sticking with what's working and exploring, newer stuff that might be better?
[00:11:14] Madeline: Yeah. There's always a little bit of a challenge, partly because there's so much unknown and there's so much, change, right? Every month there's a new tool.
[laughing] every day there's a new tool. and whether that tool works for your purposes or you have the time or the need to actually explore it, is something al- altogether, right?
You might, you might think it's really cool and might work for another project in the future but it might not be worth interrupting your current, you know, setup that you have going for your current project. there's definitely, definitely a balance and I'm one of those people who really likes exploring new technologies.
So for me it's sort of something I have to rein myself in on from time to time where, you know-
[00:11:55] Mark: Yeah. You can get lost down that rabbit hole, in a good way. Very, very easily, right? So do you actually account for that?
Like, I know, you know, working on sort of a, a more tradi- well not traditional but a- a- an agile methodology where you're planning up your sprints and your- you're accounting for, for sort of velocity and stuff. Do you account for that kind of like tooling exploration, as part of that flow?
[00:12:17] Madeline: Yeah. Actually, my team... I- I've been reading a lot of books lately, actually, and one of them was called Making Work Visible. and my team actually just switched to using kanban instead of, instead of sprints.
[00:12:29] Mark: Okay.
[00:12:30] Madeline: And, as part of that... The reason we did that was because we found that there was a lot of work that wasn't being brought to our attention that wasn't visible. and that people were doing sort of...
I- it was taking up their working hours and it should've been, it was learning and it was experimentation and things like that. so what we actually do on my team is when we get a new project, we'll actually create separate tasks for exploration and have a goal of, "At the end of this, I want to know, what my options are. What is the recommended approach?"
And then we go on to the task to actually do, like the implementation of that feature, if it's like a really big feature. so we're really trying to sort of make it clear, and make it easy to track that progress and, and also it allows us to sort of track the things that we've tried and, and experimented with and tools that we've looked at.
And then next time we can go back and, and look at those notes again as well.
[00:13:32] Mark: Nice. and is that... So one of the things you said there I think is really, really important. was, you know, work you're already doing, but making it visible and that what's prompted you to, to move over to the kanban approach.
Now obviously, you know, that's not sticky notes on a wall right now. [laughing] what, you know, let's, let's dive into the more technical implementation side for a second.
What are you guys using to actually implement, that kanban approach right now?
[00:13:55] Madeline: So we do it through Jira-
[00:13:56] Mark: Mm-hmm [affirmative].
[00:13:57] Madeline: ... which is what we were using for sprints before that.
[00:13:59] Mark: Yeah.
[00:13:59] Madeline: one, one crazy thing though was when we s- made that initial switch and I was setting up the kanban board for my team, I noticed we had like 90 things in our backlog.
And... Yeah. And for, we're a team of four pe- four developers. So, I went through those with you know, project management, product management.
[00:14:18] Mark: Mm-hmm [affirmative].
[00:14:19] Madeline: you know, every- everybody who needed to be involved. And I said, "Which ones of these are never gonna be done?"
[00:14:25] Mark: Yep. Good question.
[00:14:26] Madeline: "Which ones are provide no value to our customers, no value to our developers, right? Why are they all here? [laughs] Do we still own all of these things, right?"
Because they were areas of the product that had been shifted to other teams over the last year and the cases just hadn't been taken with them. so, in a couple of days we got it from like 90 things down to 40, which was like half, pretty much.
[00:14:50] Mark: Yep.
[00:14:50] Madeline: And then as we kept working on delivering our, our big sort of feature, we, we got it down even further and now it's going back up again as we're n- doing more projects. [laughing] But it's one of those things, it was really important I think to do.
[00:15:04] Mark: Mm-hmm [affirmative].
[00:15:05] Madeline: because it got rid of, like this huge... it made all this technical debt that we had, like, really visible. All of a sudden it was, like, in your face.
Every day you opened up this board and you had 90 things, it was overwhelming. Whereas before we had, you know, our backlog and then our sprints.
[00:15:19] Mark: Mm-hmm [affirmative].
[00:15:19] Madeline: And you pull the stuff and do your sprint and you kind of ignored what was on the backlog.
[00:15:26] Mark: I think I-
[00:15:26] Madeline: I found myself doing that at least.
[00:15:28] Mark: Yeah. And I, I think that that's a key takeaway. Especially for those of you... those people watching who aren't actively developing. you know, a few things that, that kind of triggered in my brain when you're talking about that is that none of the work changed.
[00:15:38] Madeline: No.
[00:15:38] Mark: It just... you finally saw it, right? It's not like there's all of a sudden you're like, "Oh. We're switching methodologies and we've created a backlog of 90 things."
That backlog was sitting there but somehow you guys were blissfully ignorant, [laughing] or willfully ignorant of it, as opposed to it sort of mentally weighing down on you non-stop. Which is the, basically, you know, the bad way of phrasing, making work visible [laughing].
So that you're like, "That's really annoying me. I want to do something about it." And have you found... So how, how recent was this switch over to, to the kanban approach?
[00:16:08] Madeline: I, it was probably the start of March, I think.
[00:16:12] Mark: Okay.
[00:16:13] Madeline: So about two months ago or so.
[00:16:13] Mark: Yeah. So a little bit. So have you found, you know, a little bit into this obviously crazy times and a different structure for the team, period. [laughing] but have you found that this is your ke- you're able to feel that more by seeing it?
[00:16:27] Madeline: Yeah. I've... actually, we ran this sort of experiment with our team.
[00:16:31] Mark: Mm-hmm [affirmative].
[00:16:31] Madeline: So at the end of the first month, I followed up and I said, "Okay. What have you liked and not liked? Should we change how we're doing it a little bit?" so we decided that it was a little bit harder to prioritize work because initially we had so many things on the backlog. it was harder to keep them in order of priority.
So that was one thing that we didn't like. Whereas sprints you can see, "Okay. We've clearly chosen these things to work on for this week or two weeks or however long your sprint is."
[00:16:59] Mark: Mm-hmm [affirmative].
[00:16:59] Madeline: however, we really did like the flexibility of it. Because at the end... We were doing one week sprints because our team, the service that we were developing is very like rapidly changing and growing.
So at the end of one week we were often finding that we'd have, you know, a set of things that we're carrying over to our next sprint. And that was weighing on us. We... You know, you don't feel satisfied. Or at least that's kind of how... we, we didn't feel satisfied because we didn't feel finished.
And we'd have, you know, our sort of sprint wrap-up and on that day, we'd be rushing to maybe get a couple last things in to just make ourselves feel better, [laughing] that we've gotten it done. When in reality, it doesn't really matter if it was delivered on Friday afternoon or Monday morning, right. In the long run.
Especially for things that aren't, you know, supersonic time sensitive.So that sort of psychological aspect, if you will, was kind of like one of the big factors in us moving to kanban. And since then it's been really... I found it really easy to see exactly what's in to progress.
And I can, I can tell if people aren't updating [laughs] their, their, tickets as well.
[00:18:18] Mark: Yup.
[00:18:18] Madeline: And then I'll be like, "Okay. What are you working on? All right. Let's move that." but also, at the end of the week we still have sort of like our demo.
What we used to do is, at the end of our sprints we would have a demo-
[00:18:29] Mark: Mm-hmm [affirmative].
[00:18:29] Madeline: ... and we'd talk about what we worked on, what problems we hit, if we had incidents we'd talked about those. And just sort of, you know, make sure everybody... we shared all that knowledge that we gained through the week.
So we still do that. And we still have like a weekly not wrap-up but a, just a weekly meeting to see what we've been working on. Sort of more like a check in and we demo new features that we built and things like that.
And I think we come to those meetings more excited to show what we've completed-
[00:18:57] Mark: Good.
[00:18:58] Madeline: ... as opposed to like feeling like we need to talk about, "Oh. Well, you know, this is gonna carry over and, and." So, I personally have really liked it and I think that in itself just makes you more productive.
Because you, you're more excited about what you're doing, you're more, you're not worried about not meeting a very random target of Friday at four o'clock, right? sort of arbitrary.
We could have changed our sprints to finish on Monday and you would always have something carrying over.
[00:19:26] Mark: Yeah. Yeah. Yeah. Yeah. Yeah. And I mean, that- and that's part of the challenge. You know, you u- use that term making work visible and I think that's key.
Because even that backlog, you know, was assumed from the rest of the teams of like, "Oh. You're on it." Even though you're probably never, you know, as you figured out you're, on half them, you're not on it. And you're never gonna be on it. you know, and that feeling... I always find it interesting when people have deadlines.
And, you know my, my career favorite pet peeve still has to be, you know, "Get that to me by the end of the day." And it's like, "Well, are you working this evening? No. Then you don't need it by the end of the day then. 'Cause you're not doing anything with it by the end of the day."
But it's that, you know, you need a deadline at some point but make it prou-, you know, make it productive, make it that, you know that feeling that you expressed I think i- is absolutely critical.
[00:20:08] And I think this is probably a great time, for me to actually pull up the graphic for, from The Unicorn Project. Gene has broken developer productivity down into basically five ideals.
So, you know, locality and, simplicity. Focus, flow; enjoy, which you've already mentioned a bunch, improvement of daily work; psychological safety, which a lot of people don't think necessarily would come up, and then customer focus.
And, you know, it just even in the, the first little bit of our discussion here, you've covered on areas where, you know, each of these are under different areas of the ideals. But I thought it might be good to frame some questions under each of these ideals.
Just for the audience to explore these concepts a little bit more. Because I think there's, especially for people who aren't in, development who ar- aren't working with, teams who are building, technologies and services. I think there's a complete misunderstanding o-...
[00:20:54] Mark: [inaudible 00:22:00] services. I think there's a complete misunderstanding of sort of the... the challenges there because it's [00:21:00] very creative work.
It's very mentally, you know, challenging work, which is what draws, I think, a lot of us to it. but if you're gonna spend 90% of your time doing grunt work and plumbing and managing backlogs and all that kind of stuff, like that's not a enjoyable day, let alone gonna put you in a position to create, what you need to create and to move things forward.
Right? so let's, let's start with that, that first ideal.
[00:21:27] That first ideal, you know, is around, locality and simplicity. In the context of the book, that's really about making sure that, you know, developers don't have to go from team to team to team to set things up.
So the... the... the hero... heroine or the book, Maxine, you know, transfers over and she has this, baffling, if I hadn't seen it a million times experience of getting a developer environment up and running.
[00:21:52]she's gotta talk to multiple teams. She's got to get credentials from people. She's pulling together, you know, a multitude of half-written, if that documentation. what has been your experience?
So you've been with Trend for a couple of years now, so it's not like you've been setting up development or environments, but I know, you know, being one of the leads within the organization, you're definitely trusted to help bring new people on board.
So just from your own reference, you know, you don't have to get into, into the nitty gritty or call anybody out, but what do you think that's a real problem for developers is, is to getting up and running and what do you think the impact of that is?
[00:22:25] Madeline: Absolutely. I would say it's a problem. and at any organization, even if you're not IT or developers, there's always a learning curve, but I think in development, getting an environment up and running, it took me three days when I first joined Trend.
[00:22:44] Mark: Okay.
[00:22:44] Madeline: And I didn't know any better, but people were saying, “Oh, this is so much better. This is so much better than it used to be.”
[00:22:51] Mark: [laughs]
[00:22:52] Madeline: Oh, it took me a week, right?
[00:22:54] Mark: Yeah.
[00:22:54] Madeline: And I was there going “Wow, you were this frustrated for a week. Like that stinks". I... I think that getting your environment set up should be one of the simplest things to do, because everybody should have the same environment.
It should be reproducible, it should be working, it should, you should just have all the tools that you've needed in the past. maybe not all the tools you need because there might be new ones, but you know, it, Docker is a fantastic tool for that sort of thing, right?
Having an environment that is reproducible that you can take from computer to computer. But that's not always possible, right, for every right environment. [laughs]
[00:23:33] Mark: Yep.
[00:23:34] Madeline: I would say with some of the newer projects I've been on, so that would have been three years ago, with some of the newer projects that I've been on, we are sort of defining what our environment is because we're using different tools, different ideas. and as we go, we're, we're documenting that so that when we have new people join our team that we can say, okay, here's, here's Wiki.
You just go and follow these steps and hopefully you should be up and running. If you have any questions, pop them in our Slack channel. Right?
And there's always questions and there's always things that you can prove and every time a new person gets set up, they have new things that you've, you've missed, right?
[00:24:13] So we really encourage our new hires or interns to edit those, that documentation, add to it. Anything you find that you didn't know you needed, you know, put it in there so the next person knows. so again, it's one of those things that we keep really iterative, iterative, and like it's not, it's always changing, right?
And your, your environment's always changing because you have new needs. So there's always new tools as well. But I, in an ideal world, you could come in and within, you could start up your computer and you just have to download some environment and you'd be up and running in, you know, minutes, not days or weeks.
That would be, that'd be wonderful. But it takes time to get there. And I know that a lot of people are in different places in that process, but -
[00:25:05] Mark: Very diplomatic of you. Very diplomatic.
[00:25:07] Madeline: Well, I mean even within our own company, different teams are in different places with that.
[00:25:13] Mark: Sure.
[00:25:13] Madeline: And I think that if a developer could come and sit down at their desk on day one, open up an environment and make you know, a small change and push it to production on the first day, that would be so rewarding.
Right. Instead of, you know, being three months down the road and you're finally making your first [inaudible 00:26:56], it to me it's so much, so much more satisfying and gratifying and you're getting excited about your new job, right?
Or your new team or your new project. And yeah, I just, I think that'd be fantastic if one day everybody was just at that point.
[00:25:53] Mark: And I hear you. And it's interesting cause you know, there's a couple things.
So, you know, for those folks who are on more of the business side, I'm going to go out on a limb and assume that, you know, when you started and it took you three days to get up and running, that you were paid for those three days?
[00:26:08] Madeline: Yep.
[00:26:09] Mark: And there was an expectation from a resource side that it's like, "Oh we have Madeline starting on Monday. Like we've got, you know, that team is stronger right out of the gate".
Yet, you know, you were told by people around you like, Oh, you're up in record time in three days. That's so much better. you know, and that's not even to the point where you're learning the code base and the challenges and that's literally just to get into the environment to start that learning.
[00:26:32] And yet it, you know, it's a huge thing around developer productivity. So knowing that, cause I don't think you're going to meet a developer who's going to argue that point that it should be just, you know, run one script and you're up and running.
Why don't like, cause I've yet to meet- I think I've maybe stumbled across a handful of organizations that have that in place.
And normally they're really small and they had someone who was super vigilant from day one of making sure that that Wiki page was actually a script and it always worked no matter what.
[00:27:00] So given that it's so important and you know, that I think your point about feeling good about coming in, doing something right out of the gate, day one, making, you know, even if it's just a small, tiny change, but to be able to come home from work that first day and say, you know, "hey I deployed code today to production, I'm already helping customers"
That's such a huge psychological plus. What do you think, why do you think teams then don't spend the time to build that out? Cause it shouldn't be that hard to build it out and keep it maintained?
[00:27:29] Madeline: yeah. I think because a lot of people didn't do it upfront. Now it's essentially technical debt, right? And with a lot of companies, technical debt isn't even on the radar.
And the ones that it is, they're starting to try and make more time for technical debt and paying that off. but it's sort of, at least within what I've seen, it's just sort of being, being talked about more now, as something that, that companies have and they're starting to acknowledge that they have technical debt.
And so it's one thing to acknowledge it, but it's another to give teams the time to do it. And like, there's lots of companies who are like “Oh yet, a lot of the times they'll prioritize, you know, that new feature that the customer is asking for versus technical debt.
[00:28:30] And even though that technical debt might speed up their developer productivity so that they can actually get features in the future, you know, faster.
And that's one of my kind of pet peeves I have to say. my team actually, we ran a, what we call debt days, I guess it was two weeks ago maybe. so think of your typical like, you know, sort of hackathon.
[00:28:56] So we try and we have hack days, at least in the auto office, we have hack days, every six months I would say. And you're encouraged to just try new technology. it doesn't even have to be related to your, you know, daily work.
A lot of times it is. but like people play with sensors and they do all sorts of things that wouldn't be normal for them. so I actually, this came from Accelerate, I think they called them yak days in Accelerate.
[00:29:20] Mark: Mm-hmm [affirmative]
[00:29:21] Madeline: And I read that and I was like, that would be cool. So, so we tried it and it was just on our team, so the four of us.
And we t's slowing you down, that you have been wanting to fix for the last forever, anything that you come across in your day to day wo
[00:29:49] Mark: Yep.
[00:29:50] Madeline: And I said, let's just focus on that. Pick, pick something that is meaningful to you and we have two days, we'll do a demo at the end of it and see where we get [00:30:00] to.
And it was fantastic. One of our developers, you know, improved, they automated sort of, improved an automated process so that we don't have to do as much manual work.
[00:30:12] Mark: Mm-hmm [affirmative]-
[00:30:12] Madeline: one of our developers took telemetry and metrics and said, I wish these were better and they just went and, you know, made better dashboards and made better widgets and metrics.
And, I went to our backlog and I said, there's some things on here that have been here for seven months and they've really been bothering me and they're super quick to do, but I never have the time to do them. I'm doing those.
[00:30:33] So I closed off like three tickets, that, you know, have just been sitting there and needed a little TLC. And so yeah, it was, it was really important. And I, we sort of kicked that initiative off and said we're going to do this, we're going to see how it goes.
But if it goes well, we're going to tell everybody about this. And so we did, we shared it more broadly within the company and we said, Hey, this worked really well for us, maybe you should give it a try on your team, see what happens.
[00:31:04] So we're trying to spread that, from the ground up and just help people recognize... 'cause one of the things that came out of it is, is we started looking at our day to day work more, sort of more closely and going “Oh okay, this is, this is technical debt now”, if we do this often enough, if we have these dedicated days, often enough, number one, we'll get the technical debt down.
But my goal isn't just to reduce technical debt, it's, it's to help people recognize what is technical debt, what's weighing them down and just do it. Don't, you know, make a ticket, put it on the backlog and just do it or don't even bother.
[00:31:58] Just, just if it's something really simple, just fix it. you know, don't wait six months until you have another half day to do it. I want, I want to encourage people just to do that more as part of their day to day work, which is sort of the, you know, improvement of daily work that, that they talk about in, in the unicorn project and in so many other books.
[00:32:15] But, it's truly, like, doing that and doing it every day will make you so much more productive and so much happier. Like, you know, if there's that one little task that you have to do every, every day and you just, you come in in the morning, you're like…
[00:32:38] Mark: Yeah.
[00:32:39] Madeline: Set yourself an alert. Something's actually going wrong? It'll let you know.
[00:32:42] Mark: Yeah.
[00:32:44] Madeline: Yeah.
[00:32:44] Mark: But I mean, I think that's, that's a really good point. I want to dive into that. I just want to take a second to remind the folks, we've got folks in from, watching from Brazil, from Turkey, from Germany, from Iran.
You want to join the conversation feel free to comment on LinkedIn, on YouTube, on Twitter. the hashtag is let's talk cloud. if you have questions for Madeline, please feel free.
We've got Joy and Ingrid, checking that out to bring it into our attention to include it in the discussion, share your experiences.
[00:33:09] But a couple things you said that I think are absolutely key. So, you know, your basic theme here is try to get a habit of tidy as you go, as opposed to letting it all pile up. And I think everybody being isolated and living in close quarters for the last few weeks can very much take that to heart, that it's much easier to clean as you go than to let it, let it pile up.
But one of the things I wanted to ask you, and this is not in a confrontational way so don't take this the wrong way, but cause I just think, I think it's absolutely fascinating the problem.
But, you know, so this debt that you're cleaning up it a] isn't always visible and b] do you have the development environment and sort of that developer onboarding, is that part of that debt, that you want to be cleaning up regularly?
[00:33:51] Madeline: Oh, that's a good idea. I would, so the first question was, is it always visible? No, absolutely not.
[00:33:57] Mark: Okay.
[00:33:57] Madeline: I would say 60 or more percent of the time it probably isn't. which is why I wanted to help people recognize what technical, what technical debt truly is.
And, they actually had a really good quote from, from the unicorn project and they said technical, I think that's probably the best description I've ever heard of it. It's the thing that you come across while you're doing something else, expecting it and then you remember you have ... like, I think that in itself, being able to recognize that is how you make it visible.
[00:34:48] Because yeah, a lot of it isn't. And then once you recognize it and you can communicate that and make it visible, another piece of that is bringing it up to, you know, the visibility up to your team leader, your manager, whoever it is that needs ... so that you can get the time to work on those things
[00:35:07] Mark: Mm-hmm [affirmative]-
[00:35:08] Madeline: Because if they know that you have all these other priorities and you can explain to them “Hey, you know what? This will actually can start to see the, the debt and they can start to understand, you know what, let's hold off from giving them this next thing and give them a month to tackle some of this.”
And that, that's kind of the layer that's missing a lot of the times too, is a project manager or somebody will look at your, look at your backlog and go “Oh wow, they actually don't have too much happenind work on and...
[00:35:52] Mark: Yeah.
[00:35:52] Madeline: So yeah, I think that's really important. What was your second question, sorry?
[00:35:57] Mark: Is the developer, like, onboarding [00:36:00] developer productivity stuff, is that visible and treated as technical debt? Because for that challenge, it's, you know, you only get a new person on the team or a new person into the organization every so often. It's not a daily occurrence. So it's one of those things that sort of, you know, you said it's a debt is that thing that, you know, the next time you want to do something you have to do that first.
[00:36:20] And then the analogy I had in my head there was, people who don't fill up their vehicles, when they're on the way empty, like onate, but that was, I was like, oh yeah, I know that's always, you know, or like empty the dishwasher or whatever, like, you know, do it before you have to serve a meal.
But developers bringing them on board seems like very much one of those activities that's just rare enough to not be one of those things that's top of mind. But then when you get hit, you get hit hard.
[00:36:57] Madeline: Yeah. And I, I don't think I've ever thought about it that way before. I feel enlightened. It definitely is one of those things that you don't do very often and when you do have to do it, depending on the project and your resources, it can be very time consuming.
[00:37:14] You know, even just explaining to a new hire how your product works or what the project is in itself is something that, you know, takes time and that's something that you sort of have to do yourself, you can't automate that.
But setting up their environment right, shouldn't, shouldn't be time consuming, it should be one of those things that, that we can automate and that we can have a collective, like, resource essentially that we can just deploy or you know, a community sourced thing.
[00:37:50] We do that a lot with sort of like, templates sometimes where we can, you know, one team's explored a new technology, other teams are starting to adopt it.
We'll create, like, some guidelines or a template and say “Hey, here's some suggestions, feel freeing to start thinking about it as technical debt because…”
[00:38:12] Mark: 'Cause even just, well, and even just the normal like, Hey, you know, mac OS updated and now you need to use this flag instead of this one or there's an extra prompt or you know, that kind of stuff.
Just even if nothing else changes, there's just normal churn that needs to be addressed that you wouldn't count, you know, you wouldn't encounter until the next time you tried to onboard somebody.
[00:38:32] Madeline: Yeah, yeah. For sure.
[00:38:35] Mark: …and that brings up something else I wanted to tackle, because we've been kind of dancing around it. you know, and again, for those of you in the audience, you know, Ronnie, thanks for joining Muhammad, Annie, Hernan, all these folks from around the world.
If you guys have questions, please jump in on the chat on LinkedIn, YouTube, Twitter hashtag is let's talk cloud. we like to keep these, interactive, as much as possible.
[00:38:55] But one of the things Madeline's been dancing around and I want to get your opinion on this is, architecture. So, one of the things in the unicorn project that Gene covers I thought quite gracefully, was that, there's a definite tie between how your people are set up and how the, architecture of your product, ends up being.
[00:39:12] And normally that's a bad thing in that you've got like, you know, really centralized gatekeepers. and they match the, the structure of, of your teams. and that, you know, you can kind of look at the architecture and dictate out, what the team is going to be.
A couple of weeks ago we had a Forrest Brazeal on the show. he's an AWS Serverless Hero, does a bunch of stuff around architecture. And he had a great post on CI/CD pipelines and he said, if you look at the pipeline, I can tell you the team structure. you know, and I think that's very, very true.
Now, a lot of the stuff you've described, you know, you work in a small team, you know, that collaborates obviously around with a bunch of other teams. but I also know, having, you know, been at Trend for a long time that, you know, like the Cloud One platform you work on is a variety of services at different states of maturity with different decisions made under different constraints.
[00:40:03] And there's a lot of variety in there and the architecture isn't necessarily what you would do if you sat down today in a green space and said "I'm solving all these problems here I go".
How do you find that, you know, how do you find the linkage between teams and architecture and does that challenge how you can take on work?
[00:40:24] Madeline: Yeah. Definitely dependencies affect the way you do your work. when I first started at Trend, I was on a team where we had dedicated QA people, we had dedicated developers. the ops team was completely separate.
So my job sort of ended where QA started.
[00:40:46] So I would, you know, create a feature and I would test it to my ability and then I would pass it over to somebody who was a QA for a team and they would do the actual testing.
If they found problems, they'd pass it back to me. And around we'd go until it was approved. And then it would go to, you know, you'd make your pull request and then whoever would approve it. Usually it was your manager or your team lead and then that would go into the code base.
[00:41:14] But then we actually might not deploy for another few days or a week or it would depend. And that, sort of, is very different from where my team is today.
[00:41:24] Mark: Mm-hmm [affirmative]-
[00:41:25] Madeline: There are still teams like that, we're deploying daily though now instead of, you know, every week, which definitely helps with all of that.
But when my team was formed, we were sort of pulled out from this little, we were just a little team. We were two, two people in an intern, I think. so it was just a tiny little team.
[00:41:43] Mark: Yeah, it sounds like the the name of a podcast, by the way. Two people and an intern.
[00:41:47] Madeline: Yeah. And we were sort of given a lot of stuff.
[00:41:50] Madeline: We were sort of given a lot of freedom to decide how we wanted to tackle our project and how we wanted [00:42:00] to, you know, interact with other teams or not interact with them and how we want to structure ourselves.
But because we were two people and an intern, we didn't have that dedicated QA person and we sort of took that as a big opportunity to define what we wanted-
[00:42:19] Mark: Okay.
[00:42:20] Madeline: Our team to work and look like. And that's actually when we started going into, sort of, [Servalis 00:44:37] and different cloud native approaches.
And through all of that, you know, we kind of each carved out our own sort of space within the team but we had somebody who was really good at CICD and we had somebody who, you know, started off just on developing, starting a code base, getting our project off the ground and we, within ourselves, collaborated because, you know, we were sitting right next to each other and we could...
We could do all of that and we could white board things, and then we became our own ops people, right?
[00:42:59] Mark: Yep.
[00:42:59] Madeline: Once this was in production we added metrics and things so that we could monitor our own service and we didn't need an operations team. We were that operations team. And then we learned a lot of things along the way. It didn't go, you know, perfectly.
[00:43:14] Mark: Mm-hmm [affirmative].
[00:43:15] Madeline: But, we sort of allowed ourselves to try to wear all the different hats and limit, sort of, our dependencies on other teams and other services.
And I think it was really interesting because we were almost in our own little bubble and it was very... so very different from what we had been doing that, I felt like I was learning. I haven't stopped learning since I came to Trend.
Every single day.
[00:43:46] Mark: Good.
[00:43:46] Madeline: But, I was learning at such a huge speed, all these new tools, like CICD. I could build pipelines all of a sudden when, you know, a month before that I didn't understand what a pipeline was other than this magical thing that built your code and so...
[00:44:02] Mark: There it goes.
[00:44:02] Madeline: Yeah. It was just like, "Oh", and an hour later you have this thing. And we were like, "Man, I hate waiting an hour for our builds."
So we sped that up and we did, you know, different things that we had sort of that, that fear of doing or even that like just, "Oh I hate doing that thing because it means I have to do this other thing."
And we, we took all of that pain and we, we turned it around and we said, "Okay, how can we fix this now that we don't have somebody to go and ask all these question to and we don't have somebody who's going to go fix it for us, what can we do?"
[00:44:33] And we've sort of, we've grown that now. We have four full time people, which is fantastic.
[00:44:38] Mark: Yep.
[00:44:38] Madeline: but, we've sort of taken that ideology with us into all of our new services and, even taken it further and started automating, you know, the setup for our pipelines.
So not even just the pipeline itself. So now when other teams want to use sort of the deployment space that we're in, all they have to do is add one line, make a pull request, and their stuff will automatically start getting created. Like, that's really cool to me.
[00:45:06] Mark: Very cool.
[00:45:06] Madeline: And so, so different from that initial like, make your changes, wait a week, hope that they get deployed on the next deployment, like.
[00:45:14] Mark: Mm-hmm [affirmative].
[00:45:15] Madeline: and I know that, like that side of the things has also come a long way too.
[00:45:18] Mark: Yeah.
[00:45:18] Madeline: but it's... I think we were sort of unique in that we were given the opportunity to form our team around our function.
[00:45:25] Mark: Okay.
[00:45:25] Madeline: Whereas, as a whole, most of the other teams were formed for a specific purpose or before they had a specific purpose, like you mentioned.
[00:45:35] Mark: Yeah.
[00:45:35] Madeline: So, yeah.
[00:45:36] Mark: So that, that ties in... So first of all, I think it didn't always go perfectly-
[00:45:40] Madeline: Yeah.
[00:45:40] Mark: Is a euphemism for some really big disasters. but that's, that's part of the... That's how you learn, right?
[00:45:46] Madeline: Exactly.
[00:45:46] Mark: When things blow up, you learn fast. but this comes back to one of the things that, the Unicorn Project covers around, the first ideal, which is around testing. and it says, you know, ideally, you are able to test what you are building fully and in a non-ideal, which I always think is a super polite way of saying, you know, this is horrible, we need to avoid it.
But in a non-ideal way, you're locked into testing in these big integrated environments. It takes forever to set things up. There's a whole bunch of dependencies. so it sounds like with your team you were given the freedom to sort of create that environment, you know, to get away from that QA structure.
And it's not that QA goes away, it's that everybody's doing QA. You're taking a different approach to it. Is that, is that right?
[00:46:27] Madeline: Yeah. Exactly. So everybody... So, on our team, if you haven't written a unit test for what you just wrote, you're not done yet.
Or, you know, some other sort of automated test. And I would say 90% of our tests are automated. There's not a... Like, there's... The times when we do have to do, you know, some manual exploratory testing.
And I think you'll always have that, but it's not that QA goes away, it's more that they've become these experts that we go and ask advice, and we go and, "How would you approach testing this sort of scenario or situation or project?"
[00:47:04] Mark: Mm-hmm [affirmative].
[00:47:05] Madeline: because I don't know. I'm not a QA expert. I wasn't... You know, I didn't come up through that stream of things. so for me, I've written tests that I think cover, you know, all the edge cases, and I think I've, you know, done a good job of it but then to have somebody that I can go and ask for that extra, you know, level of review and help I think is really important and, and yeah, I don't want to diminish QA in any way.
[00:47:34] Mark: No.
[00:47:34] Madeline: I think they're... Their role has just sort of shifted from doing all of the testing and stuff to enabling all of the testing. And enabling teams to learn more about the [inaudible 00:50:14] as well.
[00:47:48] Mark: So before I, we get bombarded and slapped by the QA people, I think, I think what you're saying is very similar to, for a different reason though, what happens with UX and what happens with security. Is that, in that case, for UX and security you have a limited amount of access to those people, and they can't do everything, right?
Where as, QA we used to hire almost one-to-one to build that up. But what you're talking about is removing the grunt work from QA and up-leveling them to where they really have the interesting stuff or the complicated nuance-
[00:48:18] Madeline: Exactly.
[00:48:19] Mark: Of how the larger stuff goes. Same with the UX people. They can't program every button and every piece of the UI or the, you know, the onboarding experience, or whatever, but they're there as a resource, right?
They're there as, okay, what are you trying to accomplish, let's help you go through that. And it's nice that QA has gone the same way because that always was a crazy system and this was well before your time, in the... We used to structure that, you know, if you look at Microsoft in the 90's, it was basically one-to-one, if not two-to-one, like QA to normal, to dev.
And you're like, how, how does that make any sense to have an army of people who only test the army of other people's work? Like, you... How are you moving forward at the speed given the amount of people?
[00:49:03]so that's good to hear. and that directly aligns with, you know, developer productivity and joy and flow. this... You know, we're doing great here, you know, we've only really like... I didn't, I figured I would structure this all but I think, you know, we're covering in an organic way across these five ideals.
I want to bring them up on screen again just to remind people. because we have touched on, you know, the localities really, that testing thing. Can Madeline and her team test everything as opposed to going out to other areas?
[00:49:29] Automation really speaks to simplicity. you know, the focus and the flow and the joy is really underlying all of this. Same with that improvement of daily work. there are some other areas I want to dive into more, but what I wanted to do was take a quick pause here and go to a segment that we do normally on this show, just for fun.
We call it rapid fire. and what I'll do is I'll just fire off a few, questions and you have to pick one or the other answers with no explanations.
[00:49:55] Madeline: Okay.
[00:49:55] Mark: And, and then we'll go back and, and dive into them a little bit more. because I... It's just fun. And, you know, you're not going to get in trouble. maybe a little bit. not more so than that QA comment, because I guarantee [laughing 00:52:45]. so, programming model. functional or object oriented?
Which one's better?
[00:50:15] Madeline: Functional.
[00:50:16] Mark: Okay. Immutable infrastructure. Is that a real thing or just a pipe dream?
[00:50:22] Madeline: Both. No.
[00:50:26] Mark: I love the amount of questioning in that answer.
[00:50:30] Madeline: Well, I'll go with pipe dream then more than it is real.
[00:50:32] Mark: Okay, okay, we'll come back to that one. YAML, begrudging useful or the bane of everything in space and time?
[00:50:41] Madeline: Useful.
[00:50:42] Mark: Okay, you can tell my opinion on YAML.
[00:50:44] Madeline: Yeah.
[00:50:44] Mark: Just by the way I phrased that. this one I was really curious. Code repos. The mega repo or individual repos for every component?
[00:50:54] Madeline: Individual.
[00:50:55] Mark: Okay. and then micro services. lifesaver or ticking [00:51:00] time bomb?
[00:51:03] Madeline: I kind of want to say both. I'm going to go with lifesaver for now.
[00:51:06] Mark: Okay. Let's circle back into these because these were, I really... One of the fun parts about this is like, I think in my head, like, "Oh, she's going to say this, this, this, and this", and then completely different things come out.
So, you were pretty solid on functional for programming. why? Curious.
[00:51:22] Madeline: I've been able to explore that a little bit more lately. yeah, everything they teach you in school, everything you sort of start off with was object oriented. and, at least that was my experience.
[00:51:34] Mark: Mm-hmm [affirmative].
[00:51:34] Madeline: And, it made a lot of sense.
[00:51:37] Mark: Okay.
[00:51:37] Madeline: because you had this object, you were doing this thing to it, changed it in this way. but functional programming opens up a lot of other doors.
And you see it a lot more in sort of lambda's, and things like that as well. And I think that's what I've been dealing with more lately. and I've seen the, I've seen the bright side of it as well.
[00:51:58] Mark: Sorry.
[00:51:58] Madeline: Whereas, object oriented, you have to pass around things and there's sometimes that, that like, "Oh did I actually pass a... Am I modifying the original one or the...
Did I mess it up, the threading? It just, you know, there's a lot of, kind of room for unknown things to happen or unexpected things to happen.
[00:52:18] Mark: Sure.
[00:52:19] Madeline: That you didn't mean to do. yeah.
[00:52:20] Mark: The complexity adds up quick, right?
[00:52:22] Madeline: Exactly. Yeah.
[00:52:24] Mark: Okay. So, for immutable infrastructure, you wanted to say both instead of real or pipe dream. So given that you're now with your team you're responsible for a lot more, right?
[00:52:33] Madeline: Yeah.
[00:52:33] Mark: Like you're doing a lot of the operations, you're standing up your own stuff. what, what was your thought there? Because I noticed the wheels started turning hard on that one.
[00:52:41] Madeline: I would say that, you know, you want to have infrastructure that, that stands up, that does what you need it to do, that always works, but that isn't the reality.
Because if you make one little change to how you deploy it, or how do you, you know, you hit the wrong button, like you tweak the wrong setting, you can change it.
[00:53:06] Mark: Mm-hmm [affirmative].
[00:53:07] Madeline: the way I like to approach it is actually setting up infrastructure as code, so, it's less intentional... Or, sorry, it's more intentional when you make a change and less, you know, it's harder to actually do something by accident.
And, you know, when you make that change and it's a pull request and somebody else has to say, "Oh yeah, that's a good idea", or "Hang on a second, what are you doing?". it sort of helps you get to that pipe dream.
[00:53:31] Mark: Sure.
[00:53:31] Madeline: I think that we're not there yet, but I think it's not that it's inconceivable. Like, I think you could get there.
[00:53:41] Mark: Fair. Because that's a big shift, right?
[00:53:44] Madeline: Yeah.
[00:53:44] Mark: Like same with functional from object, is that for the last 30 years we've taught people object oriented programming as the primary way. and, you know, it's not always the best way because those abstractions start to break down on the edges. you know, same with that kind of like, okay, we've had infrastructure that's always been live and you need to care and feed for, you know, feed it and keep it going.
Going to immutable is just a big like, okay, now we're doing this a completely different way. I mean, that ties to that last one where you, where you kind of had that hiccup on micro services. you know, whether it was a life saver or ticking time bomb, it seemed like you might have had a tiny bit of an opinion on that one.
[00:54:19] Madeline: Yeah. so I started off with this project, or, product that's sort of built around this monolith of code and you've got all these intertwined things and it's...
Nobody, I don't know anybody who understands the whole system, which scares me.
[00:54:37] Mark: Yep.
[00:54:38] Madeline: Right? Because we each understand our, our components and our pieces of it, but we don't understand... When something goes wrong, sometimes you have no idea if it was your thing or somebody else's or, you know, something way over there that you didn't even know was related. and I think breaking things into micro services, it's very easy to validate exactly what your service is doing.
It's very easy to wrap your head around something that's, you know, 500 lines of code, versus 5 billion lines of code, right? as well, you can use contract testing and different things so that other services know if what they're about to do is going to break your service and vice versa and that enables so much more.
And it... Just, your, that understanding is so much clearer and I just, I think that helps so much.
[00:55:28] But at the same time, like who knows 10 years from now if this is all going to, you know, we'll find a new thing and we'll be like, "Ugh, micro services". Like, I think... I think they're the new thing and everybody's really excited about them.
[00:55:44] Mark: Mm-hmm [affirmative].
[00:55:44] Madeline: And I think they make a lot of sense in the moment, and compared to that monolith. But I think there's also sort of the desire and the like, people see them as this really cool, really, like awesome thing and they, they almost make too many micro services.
[00:56:03] Mark: Yeah.
[00:56:03] Madeline: If you have that ticking time bomb where you're like... It's, so there's sort of like a balance that you need to strike, and-
[00:56:10] Mark: Yeah. Yeah. I think where you're getting at there is, you know, finding that decomposition line-
[00:56:16] Madeline: Yeah.
[00:56:16] Mark: Is really important because, you know, and I've seen it, and same with containers, where people go, "Oh my god, this is going to solve all of our problems." You know, like, what? Nothing ever solves all your problems.
But they very quickly go from, or not very quickly, but over the course of six to nine months, they go from having a monolith problem to a, you know, that they don't understand, to 300 micro services that they don't understand the interactions between.
And it's like, you took the same problem and just distributed it, right? Like there was no...
[00:56:45] Madeline: Yeah.
[00:56:45] Mark: You didn't actually get, get it. The idea was to break the monolith into functional pieces that make sense for your team and your logical model of what you're building, not just you know, you get a micro service.
[00:56:58] Madeline: Yeah.
[00:56:58] Mark: You don't want to open up the micro services where everyone gets a micro service and you know, you're like, "Oh, you've got 10 lines of code? That's a micro service now." You're like, what? Like...
[00:57:07] Madeline: Yeah.
[00:57:07] Mark: So I get it. I think that that's totally, totally logical. so let me, you know, we've gone all over the map on this in a really good way. I think this has been a really dynamic conversation.
We didn't need to kind of structure going pillar by pillar, but there was a couple overall questions as we're wrapping up here that I wanted to ask or get your opinion on, because I think, you know, you've got a really unique perspective.
You've been in, you know, you've seen a lot of transformation in a short amount of time, which is not everybody's experience. And I think, you know, that perspective is really valuable for, for the audience, and obviously for yourself and your teammates. but having read the Unicorn book, or at least the crib notes, you know, you never know, if there's lock on the thing.
But I'll assume you've read the book.
[00:57:46] Madeline: I did.
[00:57:46] Mark: the the Unicorn Project, very much like the Phoenix Project, is a very different kind of tech book. what was your thought of the, just the presentation, you know, through like that story, that novel form?
Did it work for you? Did it not work for you? What did you think?
[00:58:00] Madeline: So, my first introduction to tech books was The DevOps Handbook.
[00:58:05] Mark: Okay.
[00:58:06] Madeline: Which, objectively has some very good ideas.
[00:58:10] Mark: Mm-hmm [affirmative].
[00:58:10] Madeline: However, I thought it could have been, you know, like a third of the size that it was. personally, I just, I wasn't into the like, "Do this and you shall receive these benefits."
Like, it was so prescriptive, I found.
[00:58:22] Mark: Mm-hmm [affirmative].
[00:58:23] Madeline: you know, I found that the case studies and that stuff really interesting. But I just, to me, it was, it was too much. Whereas, the Unicorn Project, I actually wanted to read it. It was one of those books I started and I was like, "Oh, I'm into this. There's a story."
I think I didn't know that sort of tech book existed. I thought they were all this, sort of, prescriptive, you know, natured book. But, there's, there's a lot of them that are more, you know, story, story-esque. Turn the Ship Around is another good example.
And I, personally, relate to that so much more because I don't want somebody to tell me, "Do these things and they will work for you too." Because they might not. I want somebody to say, "Hey, we have this situation and this is what we did."
[00:59:13] I actually found myself frustrated reading the Unicorn Project because I was frustrated for Maxine. I could see where they were taking these things and I was like, "Oh that would suck."
Or like, you know, you're... I got, I got really into her character and I could feel her pain as opposed to the dev ops handbook, where it was more, you know, do these things,
[00:59:36] Mark: Yeah.
[00:59:36] Madeline: Yeah. I really liked it.
[00:59:39] Mark: Yeah, that's really interesting. Because it's... The dev ops handbook is more of a reference book.
[00:59:43] Madeline: Yeah.
[00:59:43] Mark: Without an easy way to access it. Now, there's a ton of great stuff in there, but it's written like a book that you're going to read start to finish, even though it's designed as a book that you should just pop in and out of.
[00:59:53] Madeline: Yeah.
[00:59:53] Mark: Which is, I think, the frustration, because it kind of sits in the middle. It's a book that's really talking about cultural change, but it's [01:00:00] written like a book on, you know, on Scala or Clojure.
[01:00:03] Madeline: Yeah.
[01:00:03] Mark: Or something like that where you're like, "Okay, cool, like I can, this is how you create a variable, and this is..." Like it walks you through the process, which is the traditional tech book way. but yeah, I agree, the first time, like when I read the Phoenix Project when it came out and then the Unicorn Project, you know, when it was released, same thing.
Like, you empathize with the character, you understand the cultural impacts, and yeah, unfortunately there are not many tech books that are written that way. and I think that's a problem because it does exclude a lot of people who prefer to get that communicated that way.
[01:00:32] Madeline: Yeah. And I think, you know, both kind of types of books, and types of, you know, literature, have, have different audiences and different people that they speak to more.
But I think a lot of people, if you can put yourself in that character's shoes and you can feel what they're feeling and you can understand what they're going through, it sort of sticks with you more than reading something that reminds you of a text book.
[01:00:57] Like, I was never one for reading textbooks. They just... I fell asleep. whereas like, the Unicorn Project, I actively was like, "Oh, just one more chapter." Like, I actually was like, you know, invested in it.
[01:01:11] Mark: Yeah.
[01:01:11] Madeline: And I think you, that's much more memorable. And when you're trying to instill these values in people and help them understand the importance of doing, you know, daily improvement and different things like that.
Like, being able to, to feel it as you go through can have a huge impact on people.
[01:01:31] Mark: Yeah. I, I think so. And Laura, thank you for that positive comment on LinkedIn. I think I'm waiting in dread for like the security version, which will be like, the grumpy bastard project or something, where it's just like non-stop screaming through the whole book and then somebody at the end just crying for like seven chapters.
But I agree, it's, it's, you know, when you can empathize, and I think that was the... I remember when I read the Phoenix Project, walking through, just going like, "Duh." Like, "Of course. Of course. Of course."
Like, "Why isn't it that way? Oh my god, what are you guys doing?" And I, I enjoyed it, but I was so frustrated.
[01:02:07] Madeline: Yeah.
[01:02:07] Mark: For the main character. And I felt that for Maxine as well, in the Unicorn Project, more, with a like, "Oh god, I know what... I know what's coming next." Like here, and, "Oh, and here it is. The, you know, person playing political games in the background for no reason other than her own ego." And you're like...
[01:02:23] Madeline: Yeah. I literally wrote notes in there that were saying like, "Why does she think this is helpful?" Like, like I had one where I was just like, "No." Like, I just had... But then I also had my like, because that's sort of how I read these books is I, I put little sticky notes in them as I go. But, I had so many, when I went to review them, I had so many that were just like, "Why?"
[01:02:45] Madeline: Funny, when I went to review them, I had so many that were just like, [inaudible 01:06:03] [laughs] no, is it-
[01:02:49] Mark: That, and that, that's a good, that's a sign of a good book, right? And I don't think, you know, we would be, it's rare that you're talking about a tech book or a tech culture book in the way you would be talking about, you know, the latest bestselling novel.
[01:03:00] Madeline: Mm-hmm [affirmative].
[01:03:00] Mark: And, and I think that, that's a testament to Jean and, and the crew who put these together. so let me ask you a different question, a little more personal on this side.
So you're at the start of what is bound to be a very long and productive and hopefully fun career. but even in that time, so, you know, let's reference back to school, where you were, you were, first of all, what did you take for, for undergrad?
[01:03:22] Madeline: computer engineering.
[01:03:24] Mark: Okay. So right in, right in the wheelhouse here.
[01:03:26] Madeline: Mm-hmm [affirmative].
[01:03:26] Mark: ... what you were taught there versus what you saw when you first came into the workplace versus what you have enabled and helped create for change. What has been your experience, you know, seeing that difference in developer productivity?
[01:03:41] Madeline: Yeah. Okay. In school, it's a very different culture and a very different, you know, vibe. you're, you're under really tight deadlines which have zero give because the profs don't care whether you get it in or not. you either get the marks or you don't.
And you're also under that pressure to, you know, get it right the first time. And in the real world, like that never happens. You, you, very rarely do you get it right the first time. You have to, you know, iterate and improve and add to it over time.
[01:04:14] But you know, you're, you're given exams where you have to code on paper. And you're like, "How was anybody successful at this?" and then you go and you're looking for a job and you have interviews where they make you, you know, code on a whiteboard.
And I'm just, I don't know how many times they looked at the person and I was just like, like one asked me to code a cache. Like design and code a cache on a whiteboard. And I was like, "You go ahead and do it. Like, [laughs] I don't, I don't know how to do that." And-
[01:04:42] Mark: Yeah.
[01:04:42] Madeline: ...it's one of those moments where you're, and, and as the interviewee, you're standing there going like, "Wait, what? Like, how does anybody prepare for that question?"
[01:04:53] Mark: Mm-hmm [affirmative].
[01:04:54] Madeline: Like, I know what a cache is, I can tell you how they work and I could design, you know, tell you what to optimize for and I can help you do that.
But to actually code one, like any regular developer would probably have to, you know, ask different people questions and look things up and you know-
[01:05:10] Mark: Mm-hmm [affirmative].
[01:05:11] Madeline: ... remember all these references in the real world that you don't in these sort of school and interview scenarios. And I think that has to be my biggest pet peeve about interviews, like technical interviews is-
[01:05:22] Mark: Yeah.
[01:05:23] Madeline: ... coding on a, wait, that's not the scenario. Put me, put me at a desk, give me a computer, ask me to refer you something like gladly [laughs]. and actually I did have that experience as well and I have to tell you, it was like amazing, so much better. And it made me so much-
[01:05:38] Mark: Mm-hmm [affirmative].
[01:05:38] Madeline: ... more encouraged to, to, you know, choose that company if I was given the choice. And-
[01:05:44] Mark: Yeah, yeah.
[01:05:45] Madeline: ... so that, that experience is very different. And then culturally like when you start working, I think, I think different workplaces have obviously very different cultures.
But at Trend it was very much they really value sort of your work life balance. They don't want you taking homework at the end of the day. They don't want you, you know, working 18 hours a day.
[01:06:09] Mark: Mm-hmm [affirmative].
[01:06:09] Madeline: ... so I personally was like, "I suddenly have all this extra time on my hands." Because you know, your deadline is still your deadline, but as long as you can manage that within your regular schedule, which you know, you learn to do, it's very different from school. So-
[01:06:28] Mark: Okay.
[01:06:29] Madeline: ... and then, yeah, I think it's, I, at least I, I found Trend that way. I know a lot of companies have, you know, different startups, have different vibes, and other-
[01:06:39] Mark: For sure.
[01:06:39] Madeline: ... companies in general. But I think it's really important that you, you know, have that me time where you're not working and you know you have time to spend with your families and you have time to do the things that recharge you. So like-
[01:06:55] Mark: Mm-hmm [affirmative].
[01:06:55] Madeline: ... go back into your work on Monday and, and be ready to go again. yeah, and I would also say the one other thing I've noticed, just being sort of a woman in tech [laughs] is very different from being a man in tech.
And so in my classes in university I was, there were, it was 10% female.
[01:07:16] Mark: Okay.
[01:07:16] Madeline: So the engineering faculty liked to say that they had, you know, 18% I think when I started. And that was one of the highest in Ontario, which is sad, but true [laughs].
[01:07:27] Mark: Yeah, yeah.
[01:07:28] Madeline: And, they're up to like 30% now, which is great. But when you actually break it down by discipline and engineering, it's-
[01:07:36] Mark: Mm-hmm [affirmative].
[01:07:37] Madeline: ... very different across the board. There's a lot of women in chemical, mechanical engineering, civil engineering.
[01:07:41] Mark: Yeah.
[01:07:41] Madeline: There's still not very many that are going into computer and electrical engineering. So-
[01:07:46] Mark: Mm-hmm [affirmative].
[01:07:46] Madeline: ... I was, you know, one of like 10 gir- I could name all the girls [laughs] because there were that few. And,
[01:07:53] Mark: Yeah.
[01:07:54] Madeline: ... so, you sort of have a different situation. And it's more, you just have to learn sort of how to, how to work with that, right?
And, and work in different groups and settings and things like that. But then when you come into the workplace, your employer might have 50-50 or they might have that same 10% and you sort of have to adapt and adjust a little bit.
[01:08:20] Mark: Mm-hmm [affirmative].
[01:08:20] Madeline: and different companies have different cultures obviously as well. So-
[01:08:25] Mark: Yeah.
[01:08:26] Madeline: ... being a woman in a one company could, you know, be a very, very different experience than, than not another. And I've been very fortunate that it's not, not a big deal. At least it hasn't been like a big prevalent thing at Trend. Even though-
[01:08:42] Mark: Mm-hmm [affirmative].
[01:08:42] Madeline: ... we do have, I wanna say probably around that 15%, 20% mark.
[01:08:45] Mark: Yeah.
[01:08:45] Madeline: And then-
[01:08:45] Mark: And for engineering it's, yeah, it's somewhere around there. It's around there.
[01:08:51] Madeline: Yeah.
[01:08:51] Mark: It's closer to 15 and the 20.
[01:08:53] Madeline: Yeah. So it's still like that same sort of ratio, but you can have [01:09:00] that ratio and still make sure that people don't feel any different.
[01:09:03] Mark: Mm-hmm [affirmative].
[01:09:04] Madeline: ... so I haven't, I've been very fortunate. I, have come across people where, you know, like in an interview I was told, "Oh, you're, you're not our typical candidate."
And I went, "Oh." And they went, "Well, you know, typical candidates is usually a boy who has been coding since he was in grade nine and normal." And I was like sitting there going, "Is this a trick question? [laughs]." I could, I don't know.
[01:09:25] Mark: Yeah.
[01:09:25] Madeline: No, I don't know how to respond to this [laughs]. And it was, you know, the man at a company who very experienced person and, and you would think that like that you would hope that that doesn't really play into their decision anymore.
But it does. And in some places. And-
[01:09:41] Mark: Mm-hmm [affirmative].
[01:09:42] Madeline: ... so it's, yeah, culture can be, it's, it's a weird thing. It can be totally different everywhere you go.
[01:09:48] Mark: Yeah.
[01:09:49] Madeline: And I think, I like to think that you can always find the place that you fit and if you feel like it isn't the right fit, maybe you can help change that culture or maybe, maybe you can't.
Maybe you come up with too much pushback and then you have to find the place where you do fit. And-
[01:10:05] Mark: Mm-hmm [affirmative].
[01:10:05] Madeline: ... yeah. So.
[01:10:06] Mark: So would you consider that getting that question, like, or that comment, like, "Oh, you're not our typical candidate." Was that a warning flag for you or?
[01:10:14] Madeline: Oh, yeah, absolutely.
[01:10:16] Mark: Okay.
[01:10:16] Madeline: I, I, in the moment I was sitting there and I was like, are you like, are you testing me? Are you trying to like see how I'm gonna react to this?
Or do you abs- actually just believe that, that I'm a lesser candidate because I'm not your typical candidate, right?" And-
[01:10:34] Mark: Mm.
[01:10:34] Madeline: ... so immediately I was like, yeah, I've been checked out of this interview. I, I don't really, I would have ended it there if I could have, right?
[01:10:41] Mark: Yeah.
[01:10:41] Madeline: 'Cause I was just like, "This, you know what? This is a huge red flag for me and I don't really want it." And that might've been one person at that company, right? The rest of the company might have been totally different. But when you're-
[01:10:51] Mark: But-
[01:10:51] Madeline: ... being interviewed, you're also interviewing them to see if it's a good fit for you. And-
[01:10:56] Mark: Mm-hmm [affirmative].
[01:10:57] Madeline: ... I, that moment I was like, "Mm, I don't think so. I don't think this is gonna work for me [laughs]." And I think having-
[01:11:03] Mark: Yeah.
[01:11:03] Madeline: ... that, that self awareness to, to recognize that and, and to say, "You know what? I would rather not have a-
[01:11:12] Mark: Mm.
[01:11:12] Madeline: ... computer engineering job than, than work where they make you feel as though you're lesser because of any, it could be anything, could be because you're women or race or sex or gender or any of these things." But it just, it was such a-
[01:11:27] Mark: Mm-hmm [affirmative].
[01:11:28] Madeline: ... it came from left field too. Like we were in the middle of some other conversation and then I just was like, oh, you know, and it was this offhanded comment. And I was like, mm, mm, [laughs]. It just get up me boiled up [laughs].
[01:11:39] Mark: Yeah, I, I, I can't sympathize obviously. I, I am, as you can tell, I have the majority problem. the, but you know, it's interesting 'cause, so, you know, I have a young daughter, my partner, she's in, genetics research and she's faced similar, throughout her entire career, being in, you know, a very, intensely male field.
And I know at Trend, you know, our CEO and a lot of our senior leadership, are female, but in the engineering ranks we dropped down to that sort of typical, we're a little above average on our ratio.
[01:12:09] And we, you know, we have efforts like Close the Gap where we're sponsoring, women in engineering, women in computer science programs and things like that.
But I think, you know, your comment of like, it's, you know, our typical candidate starts at like nine and dah, dah, dah. I think the problem is, is, you know, it's prevalent, but it seems like everything we can do to encourage at an earlier age that equality generates-
[01:12:31] Madeline: Absolutely.
[01:12:31] Mark: ... other results.
[01:12:32] Madeline: Yeah. I'm actually, that's one of my big passions. I'm like really involved in, in that sort of work. so in university I was part of Robogals and the Women in Science and Engineering and different, different clubs, I guess they were, like-
[01:12:47] Mark: Okay.
[01:12:47] Madeline: ... that. And we actually did workshops for, for young girls. And I went and played with like of robots with them and help them, you know, learn and then just have fun and just expose them to these sort of things that they might not normally get exposed to.
And even now I'm actually, a Brownie leader with the Girl Guides and-
[01:13:05] Mark: Nice.
[01:13:05] Madeline: ... yeah, and I actually, so I have my own unit, but I also go across the city, across Ottawa to other units and I put on engineering workshops for them. So we do things like-
[01:13:17] Mark: Awesome.
[01:13:17] Madeline: ... making slime and building structures and, Rube Goldberg's and you know, all these cool different things that they might not normally get exposed to because-
[01:13:25] Mark: Mm-hmm [affirmative].
[01:13:26] Madeline: ... it is so crucial that they just, just see what's out there. And if one, if one girl from these activities goes, "Hey, you know what? That was really cool. I wanna do it again."
[01:13:36] Mark: Mm-hmm [affirmative].
[01:13:37] Madeline: That's all I can hope for. Like I just, I just want them to know that they have that choice and that opportunity and be exposed to it and get to try it.
And some of them might hate it, right? It's not for everybody. And I think the difference though is that like historically sort of science and engineering and those sorts of toys and things that like would help you develop that curiosity and those skills are really-
[01:14:04] Mark: Mm-hmm [affirmative].
[01:14:04] Madeline: ... were marketed to, to the young boys. And-
[01:14:07] Mark: Mm-hmm [affirmative].
[01:14:07] Madeline: ... you know, science camp, if you were a girl going to science camp again, you were like one of a couple [laughs], right?
[01:14:13] Mark: Yeah.
[01:14:14] Yeah.
[01:14:15] Madeline: ... but like helping people to make that more normal is, is so important because then they grow up going, "Oh yeah, I've always done science. I've always liked science." And you know, I didn't have that. I, I coded for the first time in first year university and so-
[01:14:32] Mark: Really?
[01:14:32] Madeline: Yeah, yeah. And that was robots because we had the little over, like, like a robots. And-
[01:14:37] Mark: Yeah.
[01:14:38] Madeline: ... I was like, "This is really cool [laughs]."
[01:14:40] Mark: Mm-hmm [affirmative].
[01:14:40] Madeline: And that one course with all it took and I was like, "Yeah, you know what? I'm gonna give this a shot." So it's like, yeah, it's, it's really, really important and it's something I'm really passionate about.
And I, we were gonna even do, some events at Trend. but they kind of, you know, got postponed due to COVID and everything else.
[01:14:57] Mark: Yeah.
[01:14:57] Madeline: But-
[01:14:58] Mark: Yes.
[01:14:58] Madeline: ... you know, I'm still hoping that we can do [01:15:00] that in the future once things kind of shift-
[01:15:03] Mark: Absolutely.
[01:15:03] Madeline: ... back to a sort of more normal, yeah.
[01:15:06] Mark: We'll, we will make sure that happens.
[01:15:08] Madeline: Yeah. I'm excited [laughs].
[01:15:09] Mark: the, you know and I'm, I'm encouraged by seeing, so you know, my daughter through the years in grade school, they start teaching them scratch. and I was encouraged and that they didn't sit down and go kick her and learn how to program.
They gave them, a, they had to find a social problem and then code a game that addressed or that helped educate people about that problem.
[01:15:29] So like homelessness or food shortages or, so they were really doing like a social studies project. And they just happen to deliver it instead of in a paper, they were delivering it in a game, which, you know, they were like, oh, this is, they didn't even think that they were learning about functions and variables and all this kind of stuff.
They were, you know, at the end of it, they had a big demo day where all the parents came through and we had to play their games and they explained all this stuff. And I, you know, I stepped back and went like, "This is how it should be." It's-
[01:15:56] Madeline: Yeah.
[01:15:56] Mark: ... just another tool. It's exciting. It's great. It leads to an awesome career path. but there's no, you know, I'm always reminded of the, my age will show of the-
[01:16:05] Madeline: [laughs].
[01:16:06] Mark: ... Lego, Lego ads in the, in the '70s and the '80s where it was just about, you know, they had, it didn't matter, it was just about bricks and building stuff. And then at a-
[01:16:13] Madeline: Mm-hmm [affirmative].
[01:16:14] Mark: ... certain point Lego got semi-gender, which was ridiculous. in that, you know, they were targeted towards boys versus girls versus this is just something that you can express your creativity with. and it's nice to see that coming back.
So you mentioned, you know, you're doing work with, with the Brownies, which is amazing. I used to be a Beaver leader myself. I know how-
[01:16:31] Madeline: [laughs].
[01:16:31] Mark: ... rewarding that work can be. you know, and hopefully you're working towards a badge for them, getting the engineering badges, the-
[01:16:36] Madeline: Yeah.
[01:16:36] Mark: ... computer-
[01:16:37] Madeline: Yeah.
[01:16:37] Mark: ... badges. are there any other, groups 'cause one of the things we do with the show is we put all the, you know, for the audience at home, all the stuff that we've talked about.
So all the books, all that kind of thing we put up in the show notes and the links so that people can easily reference, I'll put up the stuff for Trend's Close the Gap, Girls in Tech, women, you know, all the organizations that were associated. but is there anything else that you'd like to, to, to put out a pitch for or just get, raise awareness-
[01:16:59] Madeline: [laughs].
[01:16:59] Mark: ... for more Brownie on?
[01:17:01] Madeline: I mean there's, there's a whole ton of really awesome resources and they would depend, you know, we have people from all over the world. So-
[01:17:07] Mark: Mm.
[01:17:08] Madeline: ... I would really encourage people if they're looking to get involved in this sort of stuff or for their daughters or nieces or whoever, even for their sons, like for everybody, reach out to your local universities.
Every, most universities have some sort of, engineering summer camps or engineering day camps. the University of Ottawa and Carleton do something like that. they actually have a day dedicated for Girl Guides. So-
[01:17:37] Mark: Mm-hmm [affirmative].
[01:17:37] Madeline: ... they, we brought her around, reason, it was lots of fun and we got to, I don't know if it was scratched, but they coded with something and they did,
[01:17:43] Mark: Mm-hmm [affirmative].
[01:17:44] Madeline: ... different experiments and learned about structures and you know, different things like that. there's a lot of really good resources online if you just wanna try something, just honestly just search it up 'cause everything's out there.
And I would say, there's Robogals, they do a really cool workshops-
[01:18:03] Mark: Mm-hmm [affirmative].
[01:18:03] Madeline: ... and, and normally those chapters align with universities as well. and they're-
[01:18:08] Mark: Yeah.
[01:18:08] Madeline: ... global. there's the Code Mobile in Onta- in Canada, I think it goes across-
[01:18:15] Mark: Uh-huh [affirmative].
[01:18:15] Madeline: ... Canada. I might be mistaken, might be Ontario. and they'll actually come to your school or your youth group and they'll put on like a whole workshop for them for the night. there's, yeah, a whole bunch of different organizations, but I would say the easiest place to find information is usually, you know, your rec centers, your universities, colleges,
[01:18:37] Mark: Mm-hmm [affirmative].
[01:18:37] Madeline: ... anything that's sort of local to you.
[01:18:39] Mark: Yeah.
[01:18:40] Madeline: Yeah.
[01:18:41] Mark: Perfect. And no better time than, you know, especially for the kids now, when we're all stuck and isolated looking for things to do.
[01:18:47] Madeline: Absolutely.
[01:18:47] Mark: also, you know, it's not just for kids. At any age, you can start programming, you can start to get into this stuff. because I think there is a massive amount of free resources out there.
[01:18:56] Madeline: Yeah.
[01:18:56] Mark: ... lots of great expertise and a great community, to dive in. So we had, Tanya Janca on two weeks ago. she's a security expert, in AppSec.
She's a teacher, a coach, you know, used to travel around the world. Now, she's doing a lot of it virtually because of the pandemic. but she does, on Twitter, Cyber Mentoring Monday where-
[01:19:13] Madeline: [inaudible 01:23:22].
[01:19:13] Mark: ... just, we'll help a lot of match people with mentors, to help them break into the community specific to cybersecurity. But there's similar for development, right? So-
[01:19:22] Madeline: Mm-hmm [affirmative].
[01:19:22] Mark: ... tons of resources out there. with that, Madeline, I wanna thank you very, very much for this. this is a fantastic discussion, great perspective. great references, very much appreciate it. Thank you.
[01:19:32] Madeline: Well, thank you so much. This was a lot of fun [laughs].
[01:19:34] Mark: Perfect. And thank you everyone form, tuning in. you can hit us up in the comments, #LetsTalkCloud. we will be back soon enough, check https://trendtalks.fyi.
For updates, very soon, our new show, #LetsTalkSecurity is gonna be kicking off, starring Rick Ferguson. and I say starring because if you've seen any of Rick's work, you know exactly what I mean. so please stay tuned for that. thank you very, very much.
We'll catch you on the flip side.
