React Advanced London 2022 #ReactAdvanced #GitNation Website – https://reactadvanced.com/
Follow the link to watch the full version of all the conference talks, QnA’s with speakers and hands-on workshop recordings → https://portal.gitnation.org/events/react-advanced-conference-2022
Talk: A Career As Software Engineer
Typically I talk a lot about deeply technical concepts like TypeScript, type systems, (im)mutability, MobX, Immer etc. But this time it's going to be personal and I'll share lessons, good and bad, about growing as an engineer. I've been leading open source projects, short lived projects as a freelancer and I went through the transition of engineer to tech lead twice. Both at a young startup and at Meta. This talk will be about personal experiences, unpopular opinions and even actions, and anything else that might be counterintuitive. Join for some take-aways for anyone aiming at an engineering focused career. Probably I will be wrong about most things, so don’t miss the opportunity to follow up afterwards!
This event would not take place without the support of sponsors:
🏆 Platinum Sponsors Sourcegraph → https://about.sourcegraph.com/
Ag Grid → https://www.ag-grid.com/
Toptal → https://www.toptal.com/freelance-jobs
🥇 Gold Sponsors Kontent.ai → https://kontent.ai/
Shopify engineering → https://jobs.smartrecruiters.com/
Prisma → https://www.prisma.io/ Launchdarkly → https://launchdarkly.com/
Storyblock → https://www.storyblok.com/ AWS Amplify → https://docs.amplify.aws/
🥈 Silver Sponsors Formidable → https://formidable.com/ Stream → https://getstream.io/ imgIX → https://imgix.com/ Callstack → https://www.callstack.com
Modus Create → https://moduscreate.com/ Chromatic → https://www.chromatic.com/ Softescu → https://softescu.com
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 result in the brexit. Sorry for that for sadly I'm not living alone with anymore. But we definitely had a greatest year here. So happy to be here. The committee asked me to talk a little bit about having a career, a software engineer and sharing some lessons I've learned along the way with you. I've worked for a couple of years at the start of Goldmandix. 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, like with emailbakes and a bunch more. And so I will share some of the personal lessons about it. 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 lots of business people in the room so you ought to know who this is. Can I hear a shout? Brunel. Yes, exactly. It's eisenberg kingdom brunel. It's probably the most famous engineer ever. At least he has the best name and best outfit. So we'll be talking about him a bit as well. And so 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 move my code in something that is very idiometic. Certainly after a while you learn that reality kicks in. There's always this annoying customers that ask for features that don't fit in your abstractions and things get big 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 byproduct 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, someday he had this wonderful idea of like why does a coach need a lock motive 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 a hyperloop and it 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 year they gave up on the ID and they took the distance from it. And I think that's also an important lesson we have to learn as engineers that we're not too attached to the things we built, how we implemented. I've seen quite some conflicts over time where people were like too built in to the way they solved the problem and they were having all kinds of flights over basically nothing like semicolons or something. So we have to be slightly detached from whatever we are building. And it has 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 organization to multiple departments. And I looked at it and it was pretty okay, but it was 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 is 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 try to keep the fact that code is passionable in mind when I'm reviewing PR from other people. And the reason for that is basically I want to make concessions on solutions rather than relationships. Most codes live from maybe a couple of years. Relationships and business can last longer. So I want to make sure that with the person that 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 and I think that's fine. And if there's too much rest, 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 the subtle. 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 Scrim world, that people bring up testing as a separate story. I don't think it works that makes it the management problem while it's basically an engineering problem. At Georgia goal 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 and as your product lives longer and becomes more successful, the risk will automatically increase, which also will justify make a more cost. But as in 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 becomes. You have more test data, et cetera, et cetera. So just work on a culture where that's the default. But again, testing is also imperfect. So one thing you can really distinguish yourself as an engineer is becoming really good at debugging. And I think this is an often underestimated skill. So a few really practical tips around that. One is a lot of people still use console of lock as debugging. I don't think that's a very good approach. I don't have anything against console of logs, it's just you don't need them. The tooling nowadays can handle that for you. Take, for example, the Graph 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. And then we go from there. It saves you, the recipient, the reloading step. It just adds a live consult of log statement for your code without changing it and it's missed faster. And I'm always surprised how few people know about it. Welcome. So, yeah, this is not very clear advice, but it's so practical, your story benefits. Here's a more complicated scenario. Often we try to figure out how did you end up in the state? For example, why is the plugins in a 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 getran setter around it. Put a debugger or a breakpoint in the setter and you exactly know where a change is coming from. Very simple, very practical. But the most important dipping tip I have for you is to basically just let it go. What I mean with that is that like, if I'm running for a couple of hours into a problem and I cannot put my finger on it, where it goes wrong, I stop trying to solve the problem. And 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 moments where you wake up the next day or the moment you step out of the tube and you're like oh, of course, this system is probably sending messages over there and going there and something very complicated but your subs consciousness 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 have 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, right? But there's no question, at least initially, you ask, that's fine, so can jackshave at your harsh content. But the second lesson I had to learn is that, like, 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 specialize. It we specialize that 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 Pendington Station here to the west of UK. But here's the interesting thing. The computer 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 Question 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 was a small bottle 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 was about going to the United States, to the Americas. And so they basically established a vision which has, like many unknown parts in between. You don't only have to figure out how to do the real life stuff, also how to do the sheer building stuff. And actually, Brunello knew about that as well. It's quite an amazing guy, but I think that's an exception. So often when we try to set out a bigger vision, we started starting to rely on other people, filling in the gaps where we don't know all the answers. At first, when I started to grow from senior engineer to attack leads, and I did it at both competes, it felt very uncomfortable because, like, 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 fake direction, you put out this ID. I think this server can talk to that system over there. Not sure how, but it can achieve something. And someone built 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 infrastructure 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, if you'd use it, it would be mature. I need customers to make this mature and have good test cases, etc. And so you have this sketch 22 where you try to find an option for something that still is very imperfect and the only way I found to deal with that is just taking all the ugly shortcuts you can find. It's not a satisfying answer. But if I have to build a new UI library and my first customer needs a checkbox another radio button, I give him a checkbox another radio button, that's just a shortcut I will take. And two years from now some will say like how can this be? A serious UI library doesn't have a radio button. That's so stupid. But that's often because people missed 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 Pentaton station, right? 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 and neighborhood of Liverpool before you tear down half of the city of London. And so this is actually a real live case from this. This was a slide I received last year and it talks about this project we started in 2010 which was basically enterprise service bus. I'm not sure why we didn't use something existing, but we did with our own, right? We wanted it to be perfect. And then four years later the computer grew so much that the skill 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. So I left the code base like riddled with comments like over here in this, in 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 picking a problem, ended up in the comments and were like oh, he knew. What about it already? Why didn't he fix it? But that's the Catch 22 problem. And so all those comments with temporary solutions which are very permanent, will also be essentially consistently true. So it's a lot about the things you don't do, the problems you don't solve, solutions that you don't build yourself, even abstractions you don't build. So maybe at this point you're like, okay, this is a little bit of a sad story. 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. Like, look at our civil engineers. They design Elizabeth line very complex, very big. And yes, they go over time and the famous go over budget, but right. They don't think halfway 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 Brunel. 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. And 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, lest the progress of improvements tomorrow might be embarrassed or shackled by recordings or registering as law the prestigious of errors today. He was also quite elegant as well, but he's basically saying, like, civil engineering was young at the 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 eslin drill to your config. Thank you. You.