A Career As Software Engineer

Good morning folks. It's good to be in London and also welcome everyone on the live stream. Me and my family last summer did the most British thing ever. We went to the Lake District. And there we had our own little leave or remain campaign. That resulted in the Brexit. Sorry for that. So sadly, I'm not living in London anymore, but we definitely had the greatest year here. So happy to be here.

The committee asked me to talk a little bit about having a career of software engineer and sharing some lessons I've learned along the way with you. I've worked for a couple of years at a startup called Mendix. I've been working for a couple of years now at Meta, and I also had my consultancy business for a while. But most people will probably know me from all the open-source business happening, along with Emer, Morbix, and a bunch more. And so I will share some of the personal lessons about that. So probably you don't need them, but I needed them. So that's what I talk about.

And when I think about software engineering careers, you can basically think in those three different directions. I wasn't really interested in the top one, so I won't be talking about that one. And since I think it's fairly awkward to talk a lot about myself anyway, I'm going to talk also about this guy. And I'm just wondering, we have a lot of British people in the room, so you ought to know who this is. Can I hear a shout? Yes, exactly, it's Eisenbart Kingdom Brunel. It's probably the most famous engineer ever. At least he has the best name and the best outfit. So we'll be talking about him a bit as well.

The first big lesson I had to learn is that code will be imperfect. Fresh from university, I was always like, I'm going to build this perfect stack, use the best library for UIs today, that is React. I will use the perfect ESLint rules that mold my code and something that is very automatic. Sadly, after a while, you learn that reality kicks in. There's always those annoying customers that ask for features that don't fit in your abstractions and things get ugly over time or people don't get exactly what you're doing. So the first big lesson I think to grow as an engineer is to learn that code will be imperfect.

In fact, you could even say code is not just imperfect. It's just a by-product of what you're trying to achieve. In short, code is perishable.

And Brunel is a great example of thinking about perishable concepts. For example, some day he had this wonderful idea of why does a code need a locomotive in front of it? What if he just put it on a pipe of air, put some pressure on it and move the wagons back and forth? So basically he invented the hyperloop. And that was like roughly 200 years ago. And he built it, and it worked, but it didn't work well enough. So he was satisfied, and after half a year they gave up on the idea and took their distance from it. And I think that's often an important lesson we have to learn as engineers, that we're not too attached to the things we build. How we implement it. I've seen quite some conflicts over time where people were like too built in to the way they solve the problem and they were having all kinds of fights over basically nothing, like semi-colons or something. So we have to be slightly detached from whatever we're building.

And there's also upsides. A while ago I was asked to look into this product that was built by a very different department, and they wanted to scale it up across the organisation to multiple departments. And I looked at it, and it was pretty okay, but it wasn't entirely semantically correct, it could be faster. And so I went to the original team that was already maintaining it for two years, and I was very hesitant about it, because I wanted to basically propose to rewrite the core of the thing. But I made my case, and actually, to my positive surprise, they were really happy with it, and it resulted in a really good collaboration. But the only way that could have worked was because they didn't feel too attached to what they were building, and were still having a clear sight on what they were trying to achieve, rather than what they were writing. Similarly, I also tried to keep the fact that code is perishable in mind when I'm reviewing PRs from other people. And the reason for that is, basically, I want to make concessions on solutions rather than on relationships. Most codes list from maybe a couple of years. A business can last longer. So, I want to make sure that, like, wherever the person is I'm interacting with on the other side of PR, we do maintain our relationship. Sometimes people won't solve problems exactly the way you would do, I would do. Everyone approaches things slightly different. I think that's fine, and if there's too much stress, you can make a mental note of it, but in general, I think we have to care about relationships around the code a lot. And I think that builds long-lasting relationships. Or to slightly paraphrase someone more famous, love code a bit and others as yourself. That reference was to Sapo. The other way to deal with imperfections is to think about testing.

The code will be imperfect, so we have to have a clear testing story. Sometimes I see, especially in the Scrum world that people bring up testing as a separate story. I don't think it works. That makes it a management problem, while it's basically an engineering problem. It's your call to figure out whether you want to test something or not. Tests are always an estimation of what is the effort versus what is the risk being covered.

As your product lives longer and becomes more successful, the risk will automatically increase, which also will justify making more costs. I see many cases where people don't go through the initial hurdle of setting up enough tests to make it cheap to add more. The first tests are really hard and expensive to write. The more you write them, the easier it becomes. You have more test data, et cetera, et cetera. Just work on a culture where that's the default. But again, testing is also imperfect.

One thing you can really distinguish yourself as an engineer is becoming really good at debugging. I think this is often underestimated skill, so a few really practical tips around that.

One is, I don't know if people still use console.log as debugging. I don't think that's a very good approach. I don't have anything against console.logs. You don't need them. The tooling nowadays can handle that for you. Take, for example, the Chrome developer tools. You can just in your browser go to a source file, figure out the thing you want to inspect, and add a log point. It saves you the compilation, the reloading step. It just adds a live console.log statement for your code without changing it. It's much faster. I'm always surprised how few people know about it.

Welcome. So, yeah, this is not very creative, but it's practical. Here's a more complicated scenario. Often we're trying to figure out how did we end up in this state? For example, why is the plugins in the state where I didn't expect it to be? One simple trick to find out where that thing is being changed is simply wrapping a get run setter around it. Put a debugger or a break point in a setter and you exactly know where a change is coming from. Very simple, very practical.

But the most important debugging tip I have for you is to basically just let it go. What I mean with that is that if I'm running for a couple of hours into a problem and I put my finger on it where it goes wrong, I stop trying to solve the problem. Instead, I go to a different kind of mode where I just start observing the system. I interact a bit with it quite at random. I browse a bit through the source code. I go a bit through the logs. I don't really try to understand it. I just try to get information in my head. And then I let it go, go away, do something else, go home, sleep well and so often those wake up the next day or the moment you step out of the tube, and you're like, oh, this system is probably sending messages over there and going there and something very complicated, but your subconsciousness is really smart and there's tricks to learn to leverage it. So that's the first part about learning to accept that code will be imperfect and we better set ourselves up to deal with it. So I basically think when code is perfect, you probably had too much time on your hands.

The only cases where I could get close to quite perfect code is when it was on open source projects, because it was my time, I had to justify it to anyone, well, until I had a family. And then you can get to perfection. But there's no customers, at least not initially, you have to satisfy. So you can check shape at your heart's content.

The second lesson I had to learn is that not just my code will be imperfect, also at some point your knowledge will become incomplete. As a senior engineer, we can often have this domain where we very specialized in it, we know exactly what's going on, if someone comes with a request, we know where to go to fix it. But then, maybe we grow to something bigger. Let's take the Great Western Railway as an example. I think it still runs from Pennington Station here to the West of the UK. But here's the interesting thing. The company was established in 1833, and our guy Brunel was involved in it as well as an engineer. And so this is one of the ads of the Great Western Railway, and I've seen some outrageous software ads, but this one is an interesting one as well. It talks about a train from New York to London. Last time I checked, there's a small puddle in between. And here's another one. The Great Western Railway features a ship. That's strange, right? But this was the vision the company had. The western part was about the West of the UK, and it was about going to the United States, to the Americas. And so they basically established a vision which has many unknown parts in between. You don't only have to figure out how to do the railway stuff, also how to do the ship building stuff. And actually Brunel knew about that as well. He's quite an amazing guy. But I think that's an exception. So often when we try to set out a bigger vision, we're starting to rely on other people filling in the gaps where we don't know all the answers. And at first when I started to grow from senior engineer to a tech lead, and I did it at both companies, it felt very uncomfortable because you don't know about the problem domain and you have to rely on others. But then I discovered this interesting thing. It's also extremely satisfying if you don't know about something. You set up a vague direction. You put out this idea. I think this server can talk to that system over there, not sure how, but it can achieve something.

And then someone builds it, and that's even more satisfying than doing it on your own. It does change a few things, though. So where your favorite tool as an engineer could very well be VS Code, suddenly you start using other Microsoft products. But that's the transition into tech leading.

Another interesting lesson I had to learn here is that infrastructural projects, whenever you have a vision for a new project, there's always a catch-22 problem. And it often goes like this. Your customers are like, oh, I'm very excited about your project, sounds really cool. However, if the technology was mature, I would be using it. And you're like, yeah, yeah, if you'd use it, it would be mature. I need customers to make this mature and have good test cases, et cetera. And so you have this catch-22 where you try to find an option for something that still is very imperfect. And the only way I've found to deal with that is just taking all of the ugly shortcuts you can find. And it's not a satisfying answer. But if I have to build a new UI library and my first customer needs a checkbox and not a radio button, I give him a checkbox and not a radio button. That's just a shortcut I will take. And two years from now, someone will say, like, how can this be a serious UI library? Does it have a radio button? That's so stupid. But that's often because people miss the context that there was a time where the thing wasn't established yet. And they just take its existence for granted. And then you have different expectations. It's like the Paddington Station. That wasn't the first station to be built. It's a beautiful one. But first you have to prove the concept of a railway and station with something ugly in neighborhood of Liverpool before you tear down half of the city of London. And so, this is actually a real-life case from this was a slide I received last year. And it talks about this project. We started in 2010, which was basically an enterprise service bus. I'm not sure why we didn't use something existing. But we built it our own. We wanted it to be perfect. And then four years later, the company grew so much that the scale became too large.

And we were like, okay, this is risky. It's a single point of failure. We should get rid of it. And then I received this slide another seven years later, where they had finally migrated it out. And people... So I left the Cat codebase like riddled with comments like... Over here, in this and that case, this will eventually break down. And there were quite some of that.

And it happened in quite a few cases where people started to pick a problem, ended up in a comment. And were like... Oh, he knew about it already. Why didn't he fix it? But that's the Catch-22 problem. And so all of those comments with temporary solutions, which are very permanent, will also be eventually consistently true. So it's a lot about the things you don't do. The problems you don't solve. Solutions you don't build yourself. Even objections you don't build.

So maybe at this point, you're like... Okay. This is a little bit of a sad story. The code will be imperfect. I have to accept that. My knowledge will be incomplete. I have to accept that. It's no wonder our industry has such a bad rep. Look at those civil engineers. They design the Elizabeth line. Very complex. Very big. And yes, they go over time and they very much go over budget.

But they don't think half way through... Oh, let's use this new framework and build a Hyperloop instead. Right? They have a plan and they execute on it. But to just leave you assured, we will be okay. And I'm going to explain why with a last quote from Grunell. So, remember, that guy was building bridges. And if he did it wrong, people would die. That's basically what happens if you're building bridges. So he had this quote about bridge building. I am opposed to laying down of rules or conditions to be observed in the construction of bridges. Because the progress of improvements tomorrow might be embarrassed or shackled by recordings or registering as la, the prejudices of errors today. He was also quite elegant as well. But he's basically saying, like, civil engineering was young at a time as well. They didn't have everything figured out, and so they didn't want to chain themselves up. So, please keep that in mind next time you add a new ESLint rule to your config.

Thank you. Yay. Thank you so much, Michelle. Before I invite you into my office for a couple of questions, I want to remind everyone that you can go on the Slido, S-L-I-D-O, with the code 2124, and put in your questions for Michelle, which will ask him, please step into my office, sir. Isn't this nice? It's like a little talk show. I feel very Oprah right now.

How are you doing? Good. Pretty good. Yeah. Thank you for that talk. That was very interesting. The first thing I want to talk to you about is teams. I think a lot of what you talked about applies a lot in the real world to people who work in teams. Also, sometimes open source people are teams. How in a team can you be as generous with others' code as you are with either your own or yourself? Like you said, it's not perfect. I think often you have to build a trust relationship, and that means that the more you know someone and the more you trust your starter, the more feedback you can leave. At Matter, we have the saying, like, feedback is a gift. And it truly is. But it only becomes a gift once you start to appreciate it. So, when you're reviewing code, and someone is either new to the team, or new to the Opsource project, the first thing you try to figure out is, like, what part of this code is actually risky, right, which would break the product. That's what you comment on first. Then, if it's there, not too much there, then you can go into the more nitty stuff, and how much of that you leave, I think, primarily depends on how long you have been working with this person. Sometimes, I'm like, okay, I have already ten comments on this PR, I leave it with this. I would have done even more things slightly different, but, hey, I can also bring it up another time, or keep just a mental note in the back of my head and come back later if it becomes an issue. So, not all feedback we have has to be expressed.

That's a great point, and actually relates to one of the questions we got through Slido, which is, Michel. As a software engineer, would you also read or modify code from other engineers, and do you have any learnings there besides writing your own tests and your own code? Yes, definitely. I think people should feel very free in the company in general to touch our code. You don't own code. It's not yours.

And it should make sense to everyone. And if... Well, I mean, don't rewrite a piece of code of someone else just because you don't like the style of it without achieving anything. That will be very annoying and not be good for relationships. But in, I think, in general, files shouldn't have ownership of a person, right? It's a team that owns a piece of code.

Would you say... You know how there's two types of people. The people who are like... If it works, let it in. And people are like... No, let's be consistent. So that there's... Certain elements of style and the team can all know... Which side of that spectrum are you on? I've been always fairly pragmatic, I think. But I've definitely gone over time more in the direction of like... It works. Let's leave it. Right? I've come to more and more realize how short-lived code actually is. How perishable it is. So you can change it to perfection. And then next week, customer comes along, needs an abstraction that totally doesn't fit in, and you have to overhaul it anyway. So you're more like... If it works. You're not like a... This is a tab, not a space. Exactly. I'm more like... If it works. And I mean... If it's to make it faster or test it more, then that's fine.

And we have prettier now. And we have prettier. For all the before time. Yes. Let me just make sure. We don't have any questions. We asked that one.

Okay. What, if any, tips or resources would you share with someone who is trying to maybe go into like a tech lead role, or some leadership role that is dealing a lot with codes and that kind of thing? I think growing through the controls is not so much about resources, I think. It's just being there for a while. Like, I see quite some job hopping in our industry, it makes quite a lot of sense often. But I think tech leading is often based on knowing the context very well, knowing the people around you very well, also, that are not in your team. So I don't think job hopping a lot is beneficial to growing into a tech lead role. So I think that would be like my primary benefit, like, stick around for a couple of years or more and it will make it way easier. Almost as if relationships are very important in coaching. Almost as if, yeah.

Thank you so much, Michel, for joining us on the Q&A chair. You are free to go now.