Entrepreneurship, Career Growth and Testing: Top 5 Episodes of 2022

Read the whole episode (Transcript)

[Improve this transcript on Github.]

[00:00:00] Michaela: Hello and welcome to the Software Engineering Unlocked Podcast. I'm your host, Dr. Michaela, and today I have a New Year's special for you. For this episode, I wanted to share the five best interviews of 2022. It was really a hard choice because I had so many awesome guests. The criteria for selection was the number of downloads, which is a little bit unfair to the folks that were released in Q4. But on the other hand, it gives us all the opportunity to listen to some of the episodes you might already have forgotten, or maybe you have missed them. So let me resurface some of them, remind you of them, and give you a little sampling, a little segment into the episode that hopefully sparks your interest and you go back and listen to the whole.

But now without further ado, let's start with Alvago Trigo, who once was a web developer but could quit his day job to work on open source software fullpage.js. He started fullpage.js as a site hustle, inspired by a task that he got from his boss. His boss asked him to build a website that looked like a PowerPoint present.

After some research, he realized this does actually not exist, and started to build it in his free time. First, it was just an open source project. He didn't get any money for it, but then things changed.

[00:01:21] Alvaro: Well, at first, yeah, I, I couldn't even imagine that. I was like, somebody would be able to, to live out from, from these kind of things.

Um, so I guess this kind of naturally to me, I, I was working on it for free for three years, uh, under the M mi T license and you know, at some point you, you start getting a bit, uh, you have to take decisions like. Should I keep on improving this or should I just go for a barbecue with my friends, right?

Mm-hmm. , or, uh, should I spend extra hours doing this after work or should I just chill with my housemates or my friends, or whatever? So, you know, at the beginning it's very exciting. You, you get people using it, uh, and, and that excites, excites, um, you a lot and then, um, you know, provides you some, um, help to keep on improving it.

But at some point, you, you start. having to work on it, uh, when you don't actually feel like working on it. Right. Because people keeps on requesting, uh, new features or they have bags, very specific bags that almost look like you are doing free consultants services for them, right? Yeah. Um, and that's when I thought, well, you know, maybe I can try to get something out of it.

Mm-hmm. , um, I got motivated by another developer. It's called, um, well, I dunno how to pronounce it either. I think it's des. , uh, he created Ity, Manary and another popular JavaScript, uh, components. And he was, um, providing licenses for them, paid licenses. So I, I, I went into those. I read a bit how he was doing, and then I thought that I could do it as well.

And that's when I started charging for, not for the product itself, but for. Paid extensions to the plugin. Okay. So they were, uh, non-op source, uh, life, uh, extensions that I was selling on top of the open source project. Ah, that's that's

[00:03:05] Michaela: a good idea. Yeah.

[00:03:07] Alvaro: So that's how it started. And then I saw people start, uh, buying them.

Mm-hmm. and that's what motivated me to keep on going. And then I noticed that I was, uh, more, I was. Feeling better about it all. Like if somebody re uh, um, reported the bag or wanted a new feature or whatever, then I wouldn't be so bothered about it because now I knew I was getting something in return. So I think, uh, this way it works a bit better.

Like when you can take the time to do something and you get compensated for that, then uh, you don't feel as bad, uh, because you. You know, you are, you are not just, um, wasting your free time. You're actually, uh, doing something in your well work time, I guess. And that's a win-win for both sides, for the developer arm, uh, for the users who get, uh, better support, better features, uh, you know, better response times.

So I started selling the licenses, um, sorry, the, um, extensions. And then after six months of doing that, uh, I was able to quit my job. Okay, cool. And then after a year or so is when I decided to also change the whole project, uh, to another license and try, uh, charging for the, for the license itself. For commercial use?

Yeah, for non-open source. .

[00:04:27] Michaela: Yeah. I think that it's really, really important that you know, projects, um, you know that they are sustainable, especially if you have some success with it, right? Mm-hmm. , because there is more and more time that you are spending on it, and I think that, you know, nobody, like if, if it's a hobby and you're spending one or two hours per week or something, um, this, this idea doesn't come up right.

But if mm-hmm. , it gets, as you said, if you have more users, you're getting. Requests, you're mm-hmm. getting more ideas maybe for features. Mm-hmm. . So you're spending more and more time and obviously, I mean, we all have to live somehow, right? Yeah. Um, obviously you have to think a little bit about how can I actually, you know, make that maybe my, my job.

And I think especially if you like something, , um, that would be like a win-win, right? Mm-hmm. . So, uh, yeah, I, I can totally understand that. Um, another question that I had for you when you were, when you were turning the route, I saw you had really big names. You have big names on your website. Mm. For companies that are using full page gs, right?

There was like, uh, Google, eBay, CocaCola, Sony, and so on. Right? , did they all purchase a commercial license? Um, and, you know, did you reach out to them when you changed your, your licensing model and your, you know, your monetization idea around that? Did you reach out to them and say, you know, actually buy now license for

[00:05:48] Alvaro: that or, so some of them are using my license.

That's how I managed to, to discover, uh, the website. Cause when you use the license, , uh, well, when you buy an extension, you have to register it for a specific domain. Mm-hmm. extensions, uh, have a different price depending on how many domains you wanted, uh, you want to use extension for. Uh, so those, that's how I discover some of them.

Mm-hmm. others, I think I just discovered them by chance and they might not be using a license. Uh, so it depends. Um, uh, but now I, I didn't reach, well, I mean, uh, when, when somebody buys an extens, Or, or our license for the product Now, uh, I, I get their email and of course I, I get, uh, you know, I get to notify them about updates or changes.

So yeah, when I released a new version, I notified all of, uh, my previous customers and I told 'em about that. But if they were not previous customers, they didn't get a notification. Mm-hmm. . So, um, yeah, if, if, uh, if they were using the previous version, they can keep on using that forever and nothing's gonna change in their.

[00:06:52] Michaela: Okay. And so what, what's preventing people from using the new version and not buying for a license?

[00:07:03] Alvaro: Um, well, I guess some people, well, some people might not know that there's a, a more recent version. Um, and others, I guess they, they're happy with their website and they don't want to touch it at. So they don't want, even want to bother to update to the latest person.

Okay. Uh, others they might not want to pay. It's not very expensive though. It's, it's quite cheap. But, uh, you know that that's all kind of, uh, users, not only companies, but also freelancers or people who just make websites for fun or mm-hmm. , uh, you know, um, so that might be one reason. Cause um, there's no other good reason to not update cause it's totally compatible.

You don't have to almost change anything in your code. I think it's just one line. If. . Uh, so, yeah.

[00:07:46] Michaela: But, but my question was more, um, are there people that are updating and not paying if they use it commercially? Or is that not possible? Do you have some prevention mechanisms around that? What I mean is that, can I, you know, can I,

[00:08:01] Dagna: you know, cheat.

[00:08:02] Michaela: Yeah. Cheat, yeah. Cheat your system, .

[00:08:05] Alvaro: Yeah. You totally can. And, uh, And there's not much that we can do about that. Uh, I mean, yeah, for example, I discover, um, there was a McDonald's website in Russia. Making use of the, of the, of the new version of the plugging with the new license. And they were not paying for it.

And there was a warning, if you open the JavaScript console, you were able to see a red warning and say, Hey, this, this, uh, software is not licensed. , this could be the license here. , you know, um, there's, there's not much that I can do about that. Yeah. Uh, sometimes you can try to send, uh, I think they're called the M C A notices to Google mm-hmm.

or to some marketplaces to take down some of the stuff. But, you know, yeah. I cannot be bothered for, it's a lot

[00:08:46] Michaela: of hassle. Right. It's a lot of hassle. Yeah, exactly. Yeah. Yeah. So you are more focused on. Directing your energy to creating more value for your users. Mm-hmm. , and, you know, doing what you like and not so much bothered with, with the steps.

And, uh, yeah. I mean, I, the trickeries and things

[00:09:03] Alvaro: like this, I, I bother a little bit, uh, but I try not to bother too much.

[00:09:08] Michaela: The second pick is also about entrepreneurship. Daniel tells us all why he left his cashy job at Amazon, where he made over half a million. Dollars per year to start his own business. He also explains his philosophy of small bets, which means that he recommends to start building a lot of small different businesses instead of going all in on one big idea.

Why is that? Well, he thinks that one big idea will take years to make it successful, but also even worse, it could take years to realize it's not gonna work. So he has a selection criteria that helps him to pick the right. Opportunities and startup ideas for

[00:09:51] Daniel: himself. I decided to do a bunch of things at the same time.

Small things, of course, I was realistic. I couldn't, you know, I had limited finite time, like everyone, and that sort of changed my attitude to things. Instead of sort of focusing on one thing, I started looking around me and I started asking myself, what can I do? Low-hanging fruit. That's what can I do?

That is a small thing. Doesn't necessarily need to have large upsides, account revenue, or necessarily be sustainable for a long. I was mostly looking at small wins, like what? What can I do? Something that can be ma, can make me some money into the month's time, which are reasonably high odds. It's still unpredictable.

You never really know whether something is going to work or not. Even today, like when I launched new things, I have no clue sometimes whether things are going to work or not, but it changed my perspective because before. Looking at things, does this have upside? Is this going to scale? Is this sustainable?

And I think the s of that comes with that. Those things that do have those properties tend to have low odds of succeeding. Right? They just to be hard, you know, unpredictable, sort of affected by random things. Good. Timing and other things that are very opaque. And this had worked out really well for me.

So now sort of the, to get back to your question, sort of the reason why now it looks like I have a very diverse portfolio of products is, is because I, I, I've been, the products are a, a manifestation of inspiration that I had over the last two and a half years or so, and I ask myself, is this something that's gonna be a small batch?

Is this something that I can give it a shot? And maybe if it works, I keep it. If it doesn't or if it becomes, you know, too, too, too, too hard to do or something that I'm disliking, I can just drop it. So I tend, it's been sort of a stream of experiment. Some things work, some things worked more than others, some things beyond my expectations.

Some things work, worked a little bit, but didn't meet my expectations. So as you can imagine, in a portfolio, It's like investments. I, I mean, I, I don't think the idea is that's radical. We tend to do the same thing with how, with how, how we invest our money, for example. That's, we almost consider it foolish.

to deploy our real life savings, like in a single stock or a single asset. Right. We tend to want to diversify to tame uncertainty. Mm-hmm. , and I think more or less it's the same approach to my own ideas and my own small ventures, essentially. Yeah. So I know it's a general answer. Hope, uh, happy to dive deep, uh, or deeper into all the individual things.

What sort of, that's the general idea that I think. .

[00:12:23] Michaela: I think when I look at your projects and your products, I think what's also distinctive here is that they have a start in the end. So a lot of people have a lot of ideas, but they're continues, right? So they are, I'm starting with it and I can actually not stop them, but it's more something that I'm doing and I, I keep on getting busier and busier because I'm, I'm adding things to my portfolio, right?

Let's. Um, a SaaS business user base is probably the exception here, right? It's not something that you start and then it already ended. It has some maintenance cyclists, we all know with software, right? , and if it gets more successful, you will have more, have to be more involved, but like a cutting board.

Has a start in the end, right? You, you have the idea, you design it and then it's finished. Um, and then maybe you have to sell it. Yeah. Okay. But there's not really a lot of involvement in it. The same for the video course. You recorded it and now we are selling it. Um, the same for the book, right? You started, you finished it.

So do you think that this is, do you, you deliberately think about that when you're looking at your small bet? I mean, there. As, as we have definitive time, we probably have infinitive ideas, on what we can do and, and I think long enough people struggle with that. I'm struggling with that. What should we, you know, what should we take on?

And there's always a pros and cons list, or however people make the judgment. Is this affinitive. Thing of I'm starting this and you know, in three weeks or in three months I have it finished and then I'm done with it and, and and so on. Is that something that, uh, crosses your mind, that you're thinking about it

[00:14:00] Daniel: explicitly?

Yeah. Yeah, yeah. Uh, definitely. It's sort of, I, I think I've developed a selection criteria. I like to call. It's, I sort of, it's, uh, I, I think, I think back when I started, I almost fell into the trap of learning can do the first opportunity that I felt that I could do, and I would just jump into it. So I think, cause it seems like, okay, I can do.

Let's do it. Nowadays, I've become much more ous, I would say that's with my selection criteria, and I've, I'm feeling completely okay at peace, ignoring things that I feel like I can do. I can give a shot, but if it, if they don't satisfy my strict selection criteria, I just leave them, you know, for someone else or what, whatever.

Mm-hmm. , like, they're just not mine. And what you mentioned is, is an important part of it that is like I ask. Is, is this something that I like to call it? Is, is this something where time is going to be my friend, not my enemy? I think what you're, what you're doing is you, you need to have the payoff happen before a certain period of time.

Otherwise you're going to run out of money or out of time, out of frustration or get demotivated. And I dislike that situation. I dislike that property, right? So I try to avoid those as much as possible. I think with user base, I also made a mistake of what the kind of SAS. It's the kind of size that requires unfortunately, you know, 24 7 support.

I have a page duty app, right? Sort of. Sometimes I get paged in the 2:00 AM in the morning. Like nowadays, I would almost certainly avoid something, uh, like that, right? I would go for something, uh, simpler, almost certainly. Other parts of my selection criteria are also, is this something that I can build and bring to market by myself?

Not because I think I ha know everything or I can do everything, but I think it's a good test to keep things simple, right? It's sort of a proxy for, is this simple enough that I can bring it to market by myself? . Like, if I change my mind, I, or I decide this is not worth pursuing anymore. I don't have to make sure that everyone is on board or I, I'm not sort of hurting anyone else.

Concerns, go away if I keep things simple that I can sort of, uh, do, do, do on my own. Okay. That's what user base that I've invested so much that then I started falling into the trap of some costs. You know, now I should invest even. And I ended up spending, you know, a ton of time, money, and more than what my risk appetite really was.

Right. So definitely a lesson learned and, and what you mentioned, right? I ideally liked projects and ideas that sort of ideally have a start and an end where time is my friend . So what are

[00:16:26] Michaela: some of the, the products that you started or that the ideas that you started that haven. That haven't succeeded yet, or maybe that you haven't even shared with the, you know, are there some that you haven't shared even with, with, you know, with the people

[00:16:39] Daniel: public?

Yeah, absolutely. So there's the various defense of failure, degrees of failures as well. Certainly. I think I mentioned user basical probably the biggest failure that I had. And this one, I did it before. I was thinking about sort of the strategy, right? So I think it's a failure that led me to see things differently, but I almost feel em embarrassed to, to say this, but I've spent almost $150,000 of my own saving.

Building user base. It's crazy talking about it. And this is only making about $5,000 in annual will revenue, not monthly, right? So, mm-hmm. almost certainly I will never recoup my money. Maybe I might, so I sell it in the future, but even there, I'm not expecting, uh, sort of large amounts. And I don't know if even that is an option.

But as I mentioned before, I think my mistake was in the. underestimating uncertainty. I invested too much. I went all in. The more I went all in, the more I felt like I need to invest. And this was sort of this cycle of, of bad decisions. Mm-hmm. , putting that aside, however, like there were a few other small things that I would ne not necessarily, there weren't big failures, but there were things that didn't say the work as I expected.

In fact, the very first digital product that I slide not many people know about. Was I'd decided to sell a spreadsheet. This is a bit of a technical project. I, I started to sell a spreadsheet about benchmarking different e c two servers, their network speed. Mm-hmm. . So, so back then, back in 2019, aw.

Residency advertised accurately what network speed you were getting and what network better you are getting when you are. Buying or using a particular instance type. I thought, I'm going to design a benchmark test and measure exactly what type of performance you're going to get. I was building in public and talking about it.

People were interested and that basically, long story short, I spent a week without the tool open, sourced the tool, benchmarked everything, spent about $500. Uh, I did prepare a very sophisticated spreadsheet with pivot tables, very fancy spreadsheet. Mm-hmm. , I was, mm-hmm. , just very proud of it. I posted it on Twitter, posted on Hacker newsletter and a few other places.

There was lots of interest into this and a tension. It actually sur surprised me. I think the, uh, sort of lending page got about 30,000 views, which was, even nowadays, that's compared to my other products. It was a lot, but this sold nothing like, I mean, nobody paid, and I was, I was judging $10, like not. Not like a crazy amount of money.

A amount. Yeah. Nobody bought it. Right. And in fact, a few days later I released it for free. I, I, and I think a lesson that I learned that is back then I remember thinking, you know, wait a minute, this is back then, it was 2019. I, I said 2019. You know, information wants to be free. Nobody wants to be, Pay for information, especially developers.

But I think actually I'm happy that I didn't sort of take that lesson too seriously because it was, I jumped to the wrong conclusion in my, now in hindsight, mm-hmm. , it's not really to do. In fact, I made a lot of money now selling information, different kinds of information. Right. And sometimes even to developers, that belief or that conclusion that developers don't pay for things.

In fact, I think a lesson that I learned with sort of these experiments is that sometimes we tend to jump to conclusions that are not warranted, right? That that's why did this fail? Why did, why were people not willing to pay for it? Maybe I can take some educated guesses, but nowadays I try to be careful not to lead too much from these things because I know that things are affected by then.

Um, Things by good timing and other unpredictable things that sometimes whether something succeeds or not is just things that we can't even see. Like it's just opaque things. Yeah. So that was another example. You know, we mentioned the cutting boards that the cutting board started as purely as a, as an experiment.

I, I started with working just this time last year as a hobby. At some point I was wondering could I try to sell some of the things that I'm making and. Eventually I bumped into the idea of wooden cutting boards. I, I launched the, sort of the offering, uh, I think in October of last year. So maybe I, four months ago I saw the word $5,000.

Not a big thing. Sort of. Probably if I, if I consider all the tools and everything, I might have just broken even. So it's sort of, it's the failure in terms of expectation. Nevertheless, I still think that I gained something from the. because I did ship, you know, about a dozen around the world and learned a lot.

But I think what's more important is that now nowadays I feel much more, I feel less daunted by a physical, uh, product offering. So, you know, the, the, you mentioned, for example, I have the profit and loss membership. That's another thing that was purely an experiment. So if I was, uh, to, so a bit of, a bit of a background story, I, I, I also have sort of this quarter time freelancing arrangement with Go.

Are you familiar with ga? So this platform like for, for, for, for digital product. and back then when I, when I joined the team, we were launching a feature memberships, like the ability to, to to do the caring sort of payments and I wanted an excuse to try to use the feature essentially. Mm-hmm. . This was literally how it started and I was wondering what could I sell for the caring fee.

And I had already been very, very open with my finances for a long time on Twitter and in other places with my business finance, at least, like with how things are doing. And I thought, what if I tried to sell an even more detailed financial view, like we're talk broken down by product, broken down with all the expenses and where the costs, basically the full profit and loss.

Per product. Mm-hmm. and I, I started it and when I started it I was hoping that I could build like a community around, around these ideas of making money online and figuring out small bets and building a portfolio. I created a circle group. I was posting updates, so not only I was posting my, my financial results, but some commentary as well.

Mm-hmm. , long story short, even though this financially, you know, did did okay. Right. Did about $40,000 in total in about a year or so. I'm quite happy compared to the input I've put, but sort of the, the. The, my goal of building a community didn't until happen like it. Mm-hmm. Sort of originally there was some momentum.

I was getting lots of questions, but it never really changed from, uh, my talking about my own topic. And eventually things sort of, sort of stopped, you know, the energy disappeared and barely any activity continued to happen, nevertheless, almost by Surs Recently, my most recent project actually is a cohort based course.

where we are meeting 25 members at the time. I launched this about, uh, three months ago or so. Mm-hmm. , where we we're having sort of this synchronous. Basically core that we meet together, a small group, and we talk about these ideas in much more detail that we're discussing here. Sort of finding inspiration, finding opportunities, juggling multiple things at the same time.

And funny and enough, even though it wasn't my intention, I set up a discord server just for housekeeping purposes to share the zoom links and the slides and whatever. And the community that I was hoping to build back then sort of happens there now purely by accidents. I, this wasn't something I was.

Trying to do, which is fascinating and it sort of became, the community almost became the main selling point of discourse. Mm-hmm. , almost like people are, word of mouth spreading. You know, there's about a hundred people now like, and people are encouraging others, you know, come here, we're talking and getting good feedback and brainstorming ideas and things like that, which is, again, it is quite fascinating to me most of the things that have been successful and even the failed things, but in particular the successful things.

There are things that I have wouldn't have even imagined I'll be doing. Just a year ago or so. That was sort of very, very interesting. Sort of the, I had the idea before I used to believe you. Business success is going to be a, a self-directed top down. You come up with the idea and you execute it. Mm-hmm.

and now it's almost, I told myself I send them things , see what works. I, so I wait the last night and it's very, very unpredictable.

[00:24:17] Michaela: Yeah. So the third pick in this year wrap up is the episode with Daniel Piek, who's a, is a career coach for software developers. In this episode, she explains how you can fast track your engineering career and what mindset.

Has to do with your professional.

[00:24:35] Dagna: But what I really am passionate about and what I really love to focus on is that mindset piece, right? Like what kind of blind spots do you have? Uh, what kind of limiting beliefs do you have? , I actually like to say that, um, that I moved from programming computers to reprogramming human minds, and it really beautifully describes what it is that I do because once you change your mindset, I'll put it this way, how you.

is how you act. Mm-hmm. and how you act is the results that you're getting then from, you know, the reality, the real world, and a lot of my clients achieve spectacular results once we figure out those limiting beliefs and get past them.

[00:25:18] Michaela: Yeah. Can you tell me some limiting beliefs? I'm, I also, um, regularly reflect on mine and, um, right now, You know, um, I'm also in a, in, in this state where I think because of the pregnancy and the very new birth, I think this is such an inward facing, um, period in my life again, right?

Where I'm thinking like, okay, what, what, what are the beliefs that I have and that are holding me back and so on. So, Um, yeah, I would, I would be really curious, can you give some examples of, um, beliefs that software engineering engineers have maybe that you have seen patterns?

[00:25:55] Dagna: Absolutely. Yeah. They told them back.

two that are super common and super popular. Number one is believing that your work speaks for itself. Mm-hmm. , which it doesn't, it does not like, okay. If someone else works on the same code base with you and they can look at your code, they could see the value that you bring to the table. If they put in the work and effort to actually go into the code, look up what it is that you committed and, um, you know, have some thoughts on that.

But, . In order to be successful in an engineer's role, what you really have to do is market yourself. You have to talk about, uh, your achievements and accomplishments and not expect for everybody in the company just know what it is that you're doing, because people just don't know they have their own work that they're prioritizing, and it's very critical to, to figure out if you have that limiting belief.

Uh, work speaks for itself because again, it doesn't, and that will, that keeps a lot of talented engineers stuck in their career. That's number one. The second one, which always cracks me up, but I used to think that way too. There was a moment in, I have to be honest with you, there was a moment I thought the same way in the second limiting belief is essentially, um, that you are surrounded as an engineer with idiots that just don't wanna listen to your amazing ideas,

And here's the. Whenever as an engineer, you have an incredible idea and you want to pitch it. You want to get people on board. It's super important for you to communicate about it in a certain way. You have to be able to negotiate, you have to be able to like really describe it, but describe it in terms of the priorities of your, of your stakeholders.

Right? So if I'm going to, and I, I'm guilty of that as well. Like there was this two projects, uh, that I worked on in, in my most recent. Engineering job. And, um, I was responsible for taking care of a mobile app and, uh, it was a pain in the butt that the build of the app was taking, uh, a few minutes, you know, and I just felt it was so inefficient.

So I went ahead and I refactored how this particular app was built and I reduced the bill time from few minutes to like 30 seconds. And I was so proud of myself, you know, I was so like, yes, this is amazing. In reality, what happened is, Uh, what I did that work that I did acted my life and one other engineer, nobody else cared.

It didn't matter. Then I had a second, uh, task or project that I worked on in the same company, which was, um, creating a deliverable for a client. Super boring, a lot of copy and pasting a lot of like followings. Steps. Um, I did not enjoy doing that at all, but guess what? Whenever it was deployed and the client could, uh, spread the mobile app to their, to their own client base, I got praise from the sales representative, from our ba from the project manager.

My, my tech lead was like, wow, dag. Now that was super fast turnaround, you know, everybody across the organization was like, yay. Success and I'm thinking to myself, wow. I would have never in a hundred million years figured this out on my own. If, if you ask me as an engineer to like, put a value on this project versus that project, I, I would've thought that the refactoring was better.

So here's, here's long story, but , essentially what I'm trying to say is it's very important to understand how. You are doing trickles, like how what you are doing fits into the, the business as a whole, the business that you're working for and how to communicate about it. That's, that's, yeah, that's the really the key of what I was trying to say here.

[00:29:41] Michaela: Yeah. I think that's really, really important. But I also found myself working at companies where, You are assigned things, right? So you're not really asked for your opinion, , if this is now really helpful or not, or, or something like this. And, and then maybe reassigned as well, right? Which I think there are, there are several impacts to them.

First, first of all, how, what would be your advice for people that are assigned projects where they also know maybe. Doesn't look like this has a big impact on the com company, right? So it's also limiting my ability to advance my career here. Um, what, what should you do? Um, how do you communicate about that?

What's your advice?

[00:30:28] Dagna: Yeah, we're kind of going back to, um, you know, to that communication P piece, right? Mm-hmm. . So first of all, one thing that I wanna, uh, share, the assumption I'm coming here up with is that whoever assigns you that work is not a mind reader. So they would not necessarily have your priorities, your career priorities in mind.

Mm-hmm. . So it's important to, um, To whenever you are asking for work to kind of like be proactive and say, Hey, I am really working towards, uh, becoming, let's say, uh, staff engineer becoming a team lead, becoming an engineering manager. Can you help me out and assign the kind of work to me that will help me achieve that goal?

Right? Asking for that help and support, uh, because. Most of us are, um, nice and friendly people and we want to help, but we don't always know what's the best way to provide that help. So being kind of like your own advocate, um, and talking about what it is that you want to do is, is really critical here. A second thing is, you know, whenever you're in those one-on-ones with your manager is to really.

Ask for, for feedback, how are you doing, how you could be doing better, um, in creating that safe space for feedback? You know, something that is my strength actually, uh, and, and really helped me with accelerating in my career early on, was that relentlessness in asking for feedback like, um, , I had this team lead that worked with me that helped me become a senior engineer because he kind of vouched for me in the meetings, uh, that I wasn't part of.

And he really said like, Hey, she's ready. She can handle it. She can be a senior engineer. Um, I think she's ready. And that's what got me the promotion. But when him and I worked together, I was telling him, look, um, I really wanna know. Don't worry, you're not gonna hurt, hurt my feelings. Uh, I wanna advance, I wanna be hitting the ground running, and I want to really work on the things that are holding me back.

And, you know, one of the critical pieces of feedback that he initially didn't wanna give me because it felt like maybe he would hurt my feelings or, or maybe was too much, I don't know. But, um, after I was pushing and pushing for that feedback, he essentially to told me, dag, now fast is great, but reliable is.

And that advice changed how I was thinking about writing code because I was really, uh, prioritizing being fast, delivering as soon as possible, right? But sometimes my fast, uh, solutions were not fully thought out. And a senior engineer really has to have that understanding of how the engineering decisions impact business, the team, and what it is that, that they're trying to accomplish.

Um,

[00:33:24] Michaela: as a. . Mm-hmm. . Yeah. Um, I'm, I'm thinking back off a time, right, where I think it, it's, it's totally true that we have to go and advocate for ourselves, but I also wonder how many people are a little bit stuck in that, well, this is what the business needs, right? I understand that you want to advance your career, you want to become, you know, a senior engineer or tech lead or whatnot.

Um, and, and, and you know, saying that the project doesn't seem to ha have such big impact. Right? And big impact I think has to do with the stakeholder. Who is it visible to, right? Who is going to see and hear your name and, and so on. So I think there's a little bit a political background towards that as well.

Um, have you worked with people that are just, uh, really stuck in a situation where, There is nobody that really advocates for them too much, or they are assigned a project that's, uh, you know, low visibility and, and they're stuck there. Would you say the best is to move, um, move companies or, uh,

[00:34:33] Dagna: The short and sweet answer is yes,

And you know, in the very first meeting that I have with my clients, whenever we start our coaching sessions in the program, what we do is we figure it, we figure out what are their specific, um, life and career goals, and what are their values and how their current workplace supports those values. And then we measure.

uh, in a specific way. And after that exa, after that, uh, specific, um, exercise, we're able to confidently say whether it's worth staying in that place or if it's time to move on.

[00:35:14] Michaela: The fourth pick is one of the most listened episode of 2022. It is the episode with Mauricio an where he explains how to write tests that fine box.

In this episode, he explains what domain-driven testing is and also how we can use coverage reports to fine box. So when you say systematic and you know that we have to learn it, I'm thinking back at university and the first thing that pops into my mind is fuzzy testing and you know, and maybe verification and all of that, which you know, is scary and a lot of developers don't do it.

And maybe it's not. It's that practical, it's not that scalable. Are we talking about those kind of things or are we more thinking about edge cases, for example, and, and you know, what, what is exactly the systematic way to write test cases? Is it, is it hard?

[00:36:07] Mauricio: It is not, and I think it's closer to the thinking of edge cases, as you mentioned.

So really close to the way developers write tests, nowaday. So it's not a big jump from what you're doing now, uh, to what I'm trying to propose in the book. And so think of, you know, you have this method to test. This method receives two or three parameters. My book basically says, you know, look to the first parameter.

What is it? Is it an Integra? Is it a string? If it's an Integra, maybe you have these cases to think about. Then go to the second perimeter, go to the third perimeter, then try to see how those three parameters interact together. So it's again, super similar to the unit test. You're right. But now in a more systematic way.

[00:36:45] Michaela: So is it a little bit like a checklist for me? That sounds like a, a checklist or, you know, even it's code reviews. You know, we know that the most effective code reviewers are actually the ones that have a checklist, right? Even if they are experienced developers, because it helps your brain to go systematically through the code and think about, oh, did I think about this, about that?

And normally people don't even read the, the code review checklist anymore. They just look at it and, you know, oh, I forgot actually about. That part over here. Can I, can I think about it that way? Yeah,

[00:37:16] Mauricio: definitely. And to be honest, at some moment when I was writing the book, I considered a lot creating a checklist where people could, you know, just try to follow, and these ideas are not fully mine, right?

So I learned it a lot from what is in there. And so the domain testing techniques that are there may be super popular in academia, a bit less popular in industry. They are doing these checklists without calling them checklists, right?

[00:37:41] Michaela: in the book you described quite a few different types of testing, right?

Domain testing, which, um, I would really briefly describe as breaking, uh, down the requirements, right? So what the program should do and looking at that. Then you talk about structural testing, which is looking at the code coverage. Then you talk about example based testing, property based testing, and you talk about.

Can you explain each one of those a little bit more in detail? And, um, maybe the first one is, what is the most important one? Is there, do we have to know all kind of this kind of different testing types or, um, is it enough if I, you know, do domain testing? Are they exclusive? Or how does the, you know, how do you integrate with each other?

[00:38:25] Mauricio: Yeah, good question. I think, you know, if you're a busy person and you cannot read all the chapters, if you read the domain testing one and then the structural testing one, you can grasp the main ideas there. And my, my suggestion is usually you implemented some feature. Right. I'm, I'm not really focusing on test-driven development here.

So just imagine you wrote your feature, maybe you did test-driven development, maybe not. And now it's time that you know, for systematic testing, you wanna explore all the possible ledge cases to look for bugs. My first suggestion is for you to do domain testing, meaning you look at the requirements. You know what the program needs to do, and this is the requirements.

It doesn't have to be UML or a user story, whatever you like, and then you systematically apply domain testing techniques there to come up with test cases. So, you know, those are the inputs of my program. These are the outputs of my program. Let's explore them. After you do this, you create lots of test cases.

Are you done? Almost the next step is, let's now look at the source code and try to get some hints from the source code, because you know, sometimes there are small differences between what you envision the program to do and how you implement it, right? Maybe, I don't know. You're doing some crazy optimization there that requires some extra testing.

whatever. And then you look at the source code, maybe you use some code coverage tool to help you on, on doing this, and you then augment the test suites you created with the main testing. And this is kind of the main loop that I see when it comes to create, uh, test cases. Then of course, after that, my book dives into different techniques you can do to, to make her test better, like property based testing, design, the contracts, so on and so forth.

But the two techniques are the ones that I consider core. for someone that wants to create good tests.

[00:40:11] Michaela: So the main testing I have to see a little bit as it's not, it's not black box box testing because I, I know the code, but it's a little bit more about the use cases, right? So maybe I'm looking at the Jira ticket or you know, some, some story in, in on GitHub or something.

I'm reading down what this, you know, what this code change actually should do and then I'm developing my test for that, and then I should compliment that. with structural testing where actually go at the code and see, you know, how, how is that actually implemented? And do I, because code coverage for me would be, not only about how is that implemented, but also, um, like line coverage.

Do I, you know, do I hit every line even, you know, the exception And you know, if there are, like if there's a switch statement, do I go through each of the cases and so on, right? Is that, and then I go back to domain testing again. What should this actually do? And, and loop through

[00:41:06] Mauricio: that. That's a super good point, and I think this is one of the things my book does differently from the others, and I'm super curious to see how the community will react.

So when we talk about domain testing, we usually have this black box perspective where we don't care so much about the implementation. What I'm trying to say in my book is that maybe you can use those same techniques, but now looking at small units that you kind of know how they work. You know, you don't have to test the whole program using domain testing.

We're not also applying. The same things for a small methods. Were a class, and of course you can then start and going up in the test level. So maybe you test the unit using these and then you're satisfied. Then you go a little bit bigger and you test the whole component using domain testing. Why not? So I discuss the different test levels as well in the book, but so I, I wanna.

First thing, convince people that the main testing can be done at any levels. Those techniques apply there as well. That is the first thing. And then the second thing is about code coverage, because there we are then usually focused on unit testing. And I also wanna say that maybe it can help you in other levels as well.

And, but I think the main difference from, from what I'm seeing there, is that code coverage for me is not there for us to see a number and, you know, did we reach our magical number code coverage for, for the CI to pass? No, it's more like, a tool to augment the tests you created using domain testing. So you don't care about the number anymore.

You care about looking at a line that is not covered and reflecting about it. Okay? If in the end you achieve a hundred percent, I don't care. I just care that you reflected about things you didn't test. Okay.

[00:42:40] Michaela: You know what I mean? And so, yeah, I know what you mean. But, so one of the biggest, um, Criticisms for code coverage is that we are, we are counting, or most of the programs actually look at, has this code been executed or not?

But we are not looking for, you know, Assertions, for example, or like pre-conditions, post-condition. So for me, they always go hand in hand somehow, right? So when I think about testing, and especially if I hear code coverage and coverage reports and this number, right? Uh, the question is always, okay, well, did I hit every line, but did I even check, you know, what's happening here?

Or did I just execute the program? Right? Because, well, if, if, you know, a smoke test, could also execute a lot of the, the code base. Actually just, you know, make sure that the code runs somehow without verifying that, you know, the inputs and outputs are matching and so on. What's your take on that and what is your advice?

Is it something that you, you know, that you talk about in your book and that developers should be

[00:43:42] Mauricio: worried about? No, I think that's, that's common sense in industry. A lot of developers really hate code coverage, and in fact, I have an entire section on the book called something like, why Do Developers Hate.

something like that. And, and, and to me, I, I think if you're looking at code coverage as a number only, and then you decide whether you should go up or down, that's, that's not useful, right? Because the number hides a lot of information. So for me, the first way you should use code coverage is to, again, augment the test cases you created before.

So your test should always come from requirements because you should test what the program should do, of course, and then code coverage as a way to augment your test. and if you're using this tool to see if you missed a test case, then code coverage becomes always relevant. , right? Because you're not only looking at did, did I cover this or not?

But it's more like I didn't cover this line. Why is that? Why did I miss this test when I was looking at the requirements? Right? So it's more of a reflection exercise in my opinion. This doesn't mean though, that the number is completely useless. I like the code coverage number to give you. Overall impression of how tested your system is because achieving 100% coverage doesn't mean much because you still can have bad tests, but having like 10% code coverage means something.

It means you're not really testing anything there. So if you're there to prioritize where to start, you're testing the process right now. Say you're in a legacy without tests. The code coverage can be a, a nice guidance for you. So that is the tip. Don't use code coverage as a number that you blindly try to to achieve.

That's not gonna work for you. The final

[00:45:19] Michaela: episode that made it into the 2022 top five picks is the episode where Nicola Doula shared why the engineering manager manager position he worked for at GitLab, who wasn't really meant for him. He thought that he would enjoy being an engineering manager. He found himself drained by all the meeting requests, and he missed coding after this.

Quite a few people reached out to me and shared that the either went through the same or that they're also looking for a way to go back to software engineering. Let's listen.

[00:45:52] Nicolas: In the beginning there was so many things I had to learn, so I was completely focusing on that and after some time, like eight or nine months, like there's definitely enough things I could have learned, but I then was able to more focus on like how am I as a manager, like what do I like about this job?

I was able to. Step back once again and, and evaluate. And the first weeks were like super exciting and overwhelming. And as I said, like it's a different trap. You jump between projects. You, you need to learn to delegate, be better communication. And what I noticed though, I'm like one of this is one of the things, so.

I'm more of an introvert and I like, like, you can, I can sit on the screen for 10 hours and the back one, uh, buck and fix it and I'm happy . Mm-hmm. . But as an also as an engineer, GitLab, we maybe have like one to two hours of meetings per week, which is amazing. It allows you like to have enough async time and like deeply focused.

But as a manager, you mostly spent your time in meetings. So I had one of ones, I had eight direct direct reports. So I was in meetings for 10 to 14 hours. And this sounds maybe in like not many hours for other managers, but for me it was a lot as an introvert. Mm-hmm. . So this drained me. I was, sometimes it was Wednesday and I was already drained for this whole week cause of, of these meetings.

And so that, that was definitely the one factor for me. . And another one is this emotional burden actually, like, I wouldn't say burden is maybe the wrong word here, but it costs more emotional. Time for myself. Small things happen, like a direct report tells you something and you somehow have the, this emotional part that you want to deal with, or you also have maybe interviewing someone and reject the candidate, like reject the candidate.

Mm-hmm. , and this was hard for me and so it costs, it costs me emotional energy all the day long and I. I'm just not the right person for this. It seems. And one of the things I, I talked to another back then interim manager. She, she's amazing. And so we talked with each other and she was telling me like, yeah, one of ones are the best things of my day.

And I get so energized by that . And I was there after my third day of one of ones and said like, I, I can't anymore. I can't do this robing me so much energy, although I like talking with people and like all of them. , it's just harder for me. So I saw, okay, maybe I'm not the right person for this job. They are definitely the right person, but I'm not, because I don't get energized by it, it costs me more energy than I get from it.

Yeah, I

[00:48:32] Michaela: think it's really important to, to feel your own energy level, right? Not being, yeah. You know, so in taken away by what I'm supposed to do, or you know, people are supposed to be, , you know, a manager role and you know, it's a next step up in your career and Yeah. And then you're overlooking that you're actually not feeling really good about it.

Right? Yeah. I think this is really, this a, it's probably a. A problem that a lot of people have, or a mistake that a lot of people do, right. That they feel like, oh, this is so important and, you know, I have this nice title and, you know, shiny and maybe, I don't know, maybe more, more salary if you are a

[00:49:11] Nicolas: manager, right?

Yeah, exactly. And I, after stepping back, I, I really noticed, I, I don't care too much about the title anymore. I mean, I also would say that at Kittle, The title is not so super important. Um, we, you can influence and change things even though like you maybe an a junior or intermediate engineer, it doesn't really matter, like as long, like what the content matters a lot.

And so that, that was no advantage there in, in that sense. Mm-hmm. and I then step back on those thinking, do I want to become a staff engineer? You know? And my answer was in, in initially. If I get to it, maybe, but it's not what I need to have. I don't need staff title now. I, I'm just happy to work on something that I care about and that's it.

that, that's my goal actually. It's not the title itself, so I learned this as well after, after step stepping back. Yeah.

[00:50:08] Michaela: Yeah. I think it's, it's. . It's very natural. When I was at university, I also always dreamt of this, you know, career and going up the corporate ladder and all these titles. Mm-hmm. and, you know, it, it's some, it seemed as something that we should strive for.

Like also the, the marks that we get in school. Right. You want the one mm-hmm. or. You know, an A in, in another country and so on. Right. Another B and so on. Mm-hmm. . And so it also seemed for me that this is important. And over the time I realized actually it's not that important. Right? It's important if you are energized by what you're doing.

Yeah. If you feel good, and then you're getting also better at it. Right? Because if it's taking your energy, You can spend a lot of energy mm-hmm. , but because you're not getting it back, you know, it's, it's not, you know, it's not self, it's not sustainable, let's put it that way. That's absolutely,

[00:50:57] Nicolas: I fully, it's, it's mostly about energy management, not about time management or something, and.

I, I then also was thinking, what is the actual career progression? So I already didn't enjoy like being a manager too much. Mm-hmm. , like, what would be the next step? Maybe senior, senior manager or director. And I didn't see myself at all in this position. I like, it's, it's even more stress. I, I don't know how does, and any, everyone, like, even managers, do it, like how they can deal with it.

I, as I said, like I'm the wrong person for the shop, although, like I. At least to, to save myself a bit. Like I got good feedback. People seem to like me as a manager, and I hopefully did great work, at least based on the feedback. But I also didn't enjoy it. And then I said, I saw also you can do good work, but it doesn't matter really.

It, it matters like how you feel and yeah, so looking back at the engineering progression as a, as an ic, okay, maybe I could go to staff, maybe there's something above there, but I don't care too much on one side, but on the other side, , if I would be able to go get there, it's fine. Like I see this is still an individual contributor role.

It's a different chop. So I saw like, okay, career progression wise, I educate to go this letter instead of the other. Yeah.

[00:52:10] Michaela: Yeah. And I think I, what you were saying about it doesn't, it doesn't matter so much how good you are at what you're doing, but it's also important how you feel, right? Mm-hmm. , I was working in a nursing home when I was still back in school during the, the summer break.

I believe, that I was really, really nice to the people and I did a really good job there, but it was just breaking me. I was, I was sad every day. I, it was emotionally so draining and I probably was one of the nicest nurses there, right. and, and maybe did the best job, but I couldn't, I, I wasn't able to do it, and I always got.

I always got, oh wow. Sick. Really, really sick. Like high fever. So like the buddy telling me, you know, you can't go in there anymore. It's like, it's too depressing and too, yeah. And so, yeah, as you're saying, it doesn't mean that if you're not doing your manager job, That you are not good at it. Yeah. It just means that it wasn't the right thing for you.

Yeah. In, in that time. And I think that it can maybe change also over time if it's due to external factors, maybe. Right. Maybe you're not right now, not in the right place to do something. Right. And it absolutely, this could be not only a manager or in individual contributor role, but something else maybe.

Right. Um, where you have to travel. Right. Let's say traveling is part of your job, then sometimes it could be that. the right thing for you to do? I enjoy traveling a lot. Mm-hmm. , you know, a couple of years back and right now, you know, I, at one point I was also sick, a little bit of traveling, like being in these hotel rooms alone, , and then there comes a new time and you think like now traveling could be, you know, something that I enjoy again.

Absolutely. . Yeah. I also want to come back to something that you were talking about, and this is first I was so occupied with learning, you know? Mm-hmm. this new, mm-hmm. skills and what I have to do and so on. I think this is also extremely valuable that. It's not from day one that you know something, but you have to grow into that role.

And then you were saying, I took a step back. I think this is so important, right? So how, how was that exactly for you? Uh,

[00:54:15] Nicolas: it, it took vacation to, to get to this, uh, uh, step, actually. Yeah. In the, be, in the beginning. I am so grateful for the team. I, I started, uh, in this team. I knew nothing about the technology, anything.

And I just observed, I asked them like I, in the first second and the second week, I made a three pH long questionnaire for the team. Like, Hey, how is this actually working? And it are actually nice because this is the initial effect you have. You have no idea. And I'm, I like being naive. I like being asking this naive questions because I later, like half a year later, saw, oh, my questions were leading to something where we maybe should work on.

Yeah. Mm-hmm. . Yeah, so after half a year or something and I took a longer, longer break, like a two week vacation, and then I saw this immediate like stress relief and I was then like clearly seeing also with my partner. Okay. I'm feeling much, much better and happier now that I'm away, but from the stress and.

I, maybe I should rethink, but at this point I was still thinking, but that's what I always wanted. Like last 10 years I was always okay. I go for management at some point and breaking this mindset was, was tough for me, but I also saw it made me much more happier now and relieved after stepping back and back then when I went through the promotion, I still saw I have this impact.

Like I can help others, I can see them grow, I can help the team to be to work better maybe, hopefully, and. I saw like, okay, while I'm suffering somehow as, as I'm stressed, I also see like how much more impact that can have and how the nice parts of the roles are. And so I was still going for it because. I liked it.

[00:55:56] Michaela: My New Year's resolution for 23 is to really grow the podcast and make it more special and even better for you, and it would mean the world to me. If you could help me with that. Go ahead and send the episode to a friend if you enjoyed it. Uh, you can also rate it on iTunes, for example, on Spotify. Um, if you haven't subscribed and uh, you listen to.

Then why not subscribe to it and make sure that you really get it into your, uh, podcasting app, uh, regularly, if you have seen it. I'm now uploading also all the videos to YouTube and, um, so you can see me and my guests really, uh, during the conversation. I think that's also, uh, quite a nice format. And I redid the website.

So I put a lot of effort, as you can see into the podcast and the surrounding of it so that you get really a lot of value of it. And there's also a, a transcript for each of the podcasts that you can find on the website. Yeah. So, um, if you enjoy my show, Please, please, please help me spread the word. Send it to a friend, send it to a colleague, um, rate it on iTunes, rate it on Spotify.

This helps me so, so much and it's, it's really also the best support for me to be able to focus on the podcast and, and put a lot of work and effort into making it the best. Podcast that I can do. And I would also love to know what is your New Year's resolution? What is your big plan for 2023? Um, tell me maybe on Twitter.

Okay. Bye. I hope you enjoyed another episode of this Software Engineering Unlocked podcast. Don't forget to subscribe and I talked to you again in two weeks. Bye.