Stepping away from the code... but not quite... - Wim Godden

Please welcome Whim God. >> Thanks. Um I'm surprised to see so many people who want to step away from the code. Or maybe not quite. I mean um so hi. Um let me uh yeah quickly uh tell you a little bit more about myself. I'm from Belgium. um best known for um Belgian beer and chocolate and other tasty yummy things. Um and this image may look a bit like I have a split personality but not not really. Um uh it's just that I started as a developer but I'm also well I run a business also. Um but I I started coding at age seven um which is a very long time ago. Um nowadays coding at age seven is not that exceptional anymore with all those tools uh that are out there for for kids. Um but in the 80s it was quite quite a bit different. Um in the '90s I built uh tools for uh bulletin board systems. If I talk about bulletin board systems most of you will think vulletin or PHPB. No, I'm talking about bulletin board systems. the thing you use a modem to use a dialup connection to to connect to and yeah use that kind of things. Um I built um a thing called GNET back in the '90s uh which was a search engine submission system that was before the days of Google when you still had to add your website to a search engine. Um and I built a Windows version even for it. This was on PHP 3.0. Um, and I built a Windows version that would interface with it using a an API. APIs didn't exist. So, yeah, you could imagine what that looked like. And, uh, I actually had well 50,000 57,000 members at some point. So, I thought, well, maybe I can make a business out of this. Um, in the meantime, I was trying to make some money running some ads. So, I ran a project called PHP ads new for a while. uh maintained that for a while which turned into other names and it's now called revive ad server and so I started thinking okay I can make a business out of this GNET thing maybe charge some money for it and yeah make something into it of course that all failed when Google started and they started browsing crawling the web themselves but anyway in the meantime I started a company called Cube which if you've seen me given give give a talk before you probably know that I worked for that company until the end of last year when I sold it to one of our customers uh called Mobile Locker and that's who I work for now as a CTO and we do mostly locker installations, luggage lockers, both fixed installations, train stations, airports, music venues, things like that, but also mobile installations for music festivals uh and so on. Uh and so we built software for yeah that runs on there. We built the hardware and everything else. Okay, that's enough about me. Um, quick show of hands. Who here is a developer? Okay. Well, I see a lot I see some people doing like sort of. Okay. Um, who here considers themselves a senior? And that does doesn't mean you have the title senior, but who says, "Yeah, I'm senior. I've I've been Okay. Uh uh who's a lead developer or a team lead? Yeah. Architect. Yeah. Okay. Who's a project manager or technical project manager? Okay. Any CTOs or CEOs or CEOs or any other seale? Okay. Now I wonder what the few people who were doing that were but anyway. Okay. Um I'm I I just want to put this image on the screen. Um because when I asked you to raise your hands just now um with one of those specific job roles uh most people would match them with a specific position here and usually on a linear scale from like the junior developer at the bottom all the way up to the sea level at the top. That's what most people would look at um would would consider this as a career scale. Uh I'll come back to this image later. I I'll explain why. Um so most of us start our careers as juniors and juniors well as juniors we need to learn. We need to be coached. We need to be instructed and when we do our our abilities improve um our understanding improves. Our the quality of our code improves. We visualize code structures better. We spot mistakes more quickly and so on. And the logic is to think that every junior will become a meteor developer and at some point a senior developer, right? First of all, that's not true. Um, everybody has their limitations and for each person that's different. Um, in each skill like I will never play in the NBA. I can play basketball, but I'm never going to be able to do that. And the same goes for coding. Some people will never reach the stages state of senior no matter how hard they try. Um doesn't mean that they're not doing their best but just everybody has their limitations. Um so what makes a senior a senior? It's not the number of years. I mean I've had people um applying for a job literally coming to me and saying um yeah I've I've done this job for 12 years. And I asked them, "What what did you do?" Well, I wrote on a Zen Framework one project for the last 12 years. Okay. And you're applying for a senior symfony developer position right now. Um while actually you're basically apply you're applying but you're a junior on the symphony level. So number of years doesn't make you a senior. So what does make you a senior? Well, it's what I call reflexes. Um, and reflexes basically are grown by doing many different things. Um, being on many different projects and working with many different technologies. Um, it's basically illustrated here by well the left person, the junior, he will look at an error and say, "Huh, I wonder why this is happening. I don't understand this error. which file should I open in my IDE, which which method is actually calling this thing and where's the data coming from and so on. Whereas a senior will see the same error and instinctively will be aware of where the problem lies um and instead of browsing through the entire code stack, they're already opening the correct file and already fixing the problem. Um, you notice it in technical meetings where the actually the actual most senior person in the room regardless of whether they received the title senior um will say things like, "Wait, this solution that you're proposing won't scale or this thing here that we're building um it's going to bite us in the ass later on." They have often without realizing it taught themselves how to predict the future, predict what kind of problems will come from this. That is seniority, not the number of years that you've been on the job doing a certain thing. Now, to be clear, the reflex that I talked about, um, the, you know, sensing things, those are skills that are perishable. So, um, they need to be trained just like any professional athlete needs to train in order to be able to continue winning at whatever they're good at. Um so when you go beyond coding on a daily basis when you spend less and less time in in code when you become because you move into you know an more architectural role or more management role that's what you also start to lose a little bit that reflex. But don't let that scare you. You might lose a bit of the coding reflex but chances are you'll pick up new reflexes. reflexes that might have to do with analyzing risk or systems architecture and so on. Things that are more for the job that you're doing at that moment. So you don't lose really your seniority, you just change the reflex that is being trained. Now you might think the hardest jump, the biggest leap to take is from junior developer to senior developer to lead to architect. Now usually that's the process that takes the longest because you have the most to learn over time. U but actually the hardest one is being is going from let's say an architect position or a lead position to becoming a CTO, CEO, COO, whatever. um seale management position there is um it's where you're not working in the code on a daily basis anymore. You're not actually looking at the virtual or the physical server server infrastructure anymore. Um you don't know how things are running anymore because you're not involved on it in it on a daily basis. um you're now juggling a lot of things, but those things are client meetings and budgets and board meetings and much more without having the day-to-day understanding of how the product that your company sells is built within. Um you might be juggling a ticking time bomb if they built it wrong. Who knows? Now a lot of people think that um any management level position um they care about two things um time and money. Meaning by when can we build and ship this thing on the one hand and how much money will it cost and how much money will it make? Those are things that PE management uh thinks about most. But that's leaving out a valuable third variable, people. Um because behind the time and the money, there are things like technical debt, uh missing tests, um limits that you hit in terms of scalability, architectural decisions that are all being made by people. And these seem like purely technical problems at first. Um things a CTO doesn't need to be concerned about, but they're actually not. And that's why actually a CTO who doesn't come from a technical background usually that doesn't work out very well because they don't understand the technical things be behind it. And let me illustrate that with a very simple example that we saw at a customer a couple of years ago. The sales team sold a feature. Okay. They sold the feature to a customer and the thing was supposed to go live on a Saturday evening at 8:00. Yeah. Perfect timing. That's when all the technical people of course want to be online to check if things are working. Yeah. Um so the new feature is launched. Um the load on the machine increases and now there's 15 million people trying to hit that application. Nobody told technical people there were going to be 15 million people. They weren't even told they were going to be 15,000 people. So of course critical limit reaches at some point the whole platform collapses. You could say this is a technical failure because the system goes down, but actually it's a communication failure. Um, somewhere on along the line, somebody didn't pass along the information. And it it's similar to the game you might have played as a kid where you're in a circle and you tell a story to the person sitting next to you and they need to tell the story to the next. What comes back after it's gone through the entire circle is a completely different story. It starts with a story about dinosaurs and it ends up being about, I don't know, space or something. Um, it's basically the customer telling the sales department, "This is what we want." And the sales department asking the CTO, "Can we build this?" and the CTO thinking, "Yeah, I built something like that back when I was a developer. Yeah, sure. We can build that." Them going to the product owner, going to the project manager and asking eventually the developer, "Can you build this?" Um, sure. But you see, there's a bit of a gap between the CTO who said, "Yeah, I'm sure we can build this," and the developer who actually has to build it. So that means there is a distance between them but there's no direct feedback loop and that's a very dangerous thing. So as the CTO there has to be a new reflex to push back or at least to ask more questions but in very in many cases to push back early and it's actually not just the CTO that needs to be able to push back. Sometimes it is your job to say no. Um as a CTO, as a product owner, as a project manager, as an architect to simply say no, no to oh this feature, we want this extra button and when you click it, a rocket has to launch. I don't know, some kind of thing that makes no sense because it is illogical because it would overload systems and so on. uh you want to say no to oh we want 15 million people to be able to use this tomorrow unlimited scaling no there needs needs to be a certain amount of constraints uh unrealistic timelines I don't have to tell any of you that if you're a developer you know that that happens all the time um so even if these things that the sales team would like to sell would make an enormous amount of money the reality Reality is it would cause things to fail, cause instability, which leads to people burning out, people leaving the company, which leads to more people burning out because now there's fewer people to handle it and so on. So dare to say no, that's not a problem. Um, does that mean that thinking about that ladder that I showed before, the higher you go up that ladder, the more you become detached? Well, yes, on some levels, absolutely. Um, you don't review every line of code anymore. You're not involved in that anymore. You don't discuss the latest framework functionality around the water cooler with the the cool kids, the developers. Um, but and here's the important thing. Although you don't discuss the technical details and you don't see the code anymore, the goal must be to remain involved in important architectural decisions as a CTO or as an architect. Obviously, um you want to be close enough as a CTO to understand what the project architecture is like, how it is built generally, but at the same time, you want to stay far enough away to let go, which is very hard. uh you want to be able to let go, not dive into the code, not give comments on certain things that might not look 100%. That's not your job anymore. Um and you want to let the people who know how to code do exactly that. That's the tricky balance. Um that grows over Yeah. over a long time. Let's go back to that ladder. I said I was going to come back. Um, most people think they assume that going up the ladder means success and going down the ladder means failure. I say that's a myth. Um, a career is not a ladder. It's it's more like a landscape. It flows. Um, sometimes it goes up, sometimes it goes down. And neither one is better than the other. So you could be going up and having a senior position and maybe next time you take a technical project management role and your next job might be back as a senior developer position and that is just fun. Um, so when you go back from being one of the higher on the ladder to one of the lower on the ladder positions, um, it's not a regression. It's it's just aligning with what feels right to you. And yes, you might have lost some of those coding reflexes. Reflexes come back. You might feel a bit rusty at first, but soon you'll feel sharp. Your instincts will return. The hardest part about this isn't technical. It's not about um I cannot code anymore. That will come back. The hardest part is basically ego. It's saying, "Oh, I but I was a project manager. I can't go back to being a developer." Well, there's no reason why you can't. um brings me to um another topic. We try to optimize our career and the company we work for and the products that that company builds um everywhere around the world. We build for performance, for cost, for competitiveness and so on. But there is one thing that we do not optimize for. It's happiness. Um the real question is not how far can I climb the ladder. The correct question is where do I feel the most alive? Where do I feel the best in place? Some people thrive on things like strategic decisions and money and power and they will go up the ladder as far as they can go because that's where they thrive the best. Others feel on feel better when they can dig deep into their craft um where they can write the best architectural things where they they they thrive on things like precision and so on. Neither one is superior to the other. Um there is no there is no dashboard that measures happiness. You may reach the top of the ladder, but if you hate the job, that's not success. I would call that a bug. You reach the top, yeah, you're a bug. Um and this is something I can relate to very much. Um I ran as I mentioned before I ran cube for 25 years. In the early days I ran products and services. Um then I was a freelance consultant for many years going from senior to leading a team uh of 15 16 20 25 uh to being an architect and so on and it all made sense and then at some point I started hiring people and then everything changes because when you hire people well you become responsible for them at least when you do the job right like I wanted to do. I felt responsible because it's not just you have to pay their salaries but you're responsible for their well-being. But even for things like there needs to be well there need to be drinks in the fridge or the toilet needs unclogging or uh the door is stuck in winter when it freezes um and so on. As a business owner, if you do your job well, then there is no rest. It's a 24/7 job, so it's not for everyone. Uh, for me personally, it was great. It was fun, but it wasn't always the happiest time. So, that's a choice you make, which is why, hence the title of the talk, sometimes, you know, you go in the direction of stepping out of the code, sometimes you want to go back a little bit. So the more you move upwards on the ladder, the more distance there will be between you and the code. That distance will give you a different perspective. Too much distance will give you also a little bit of a makes you blind on what is going on which you don't want. So you want to stay away from the code but you want to stay aligned with the architecture obviously. So whichever mo direction you want to decide to move in your career forward back in a circle it's okay to step away from the code. It's okay to move back into the code as long as the place that you're in makes you thrive and makes you feel right at home. And sometimes you want to re-evaluate after six months and another six months. So forget about the latter I showed. Find your place of comfort and happiness and yeah, you'll be just fine. That's sort of my message. really good talk. Thank you. I said to Whim, this is the talk that I've been looking forward to the most. You shouldn't have favorites, but that was one that I was definitely excited by. So, thank you. Um, there aren't any questions, but I kind of have a question for you. Um the the coach that we have at work uh was talking about kind of finding your place within a company and deciding should you go up the ladder, should you like go down the ladder, so to speak. Um but ultimately what his advice was was that it kind of comes down to figuring out what problems you want to solve? What difference do you want to make? And I thought that was a really good way to distill essentially that. But if you could summarize your entire talk into one sentence as one piece of advice, what would you say is the most important bit? >> Um, well, find the thing that gives you the most joy at the end of the day. You know, if you're doing a job that ultimately you're looking forward to Friday evening, you're not in the right place. And and that's okay if if it's if it's for a short time, if it's for a couple of months. And that's why I said re-evaluate every couple of months. Don't don't if if if you're going through a rough stretch, that's okay. Sometimes you just got to bear down and go for it. Um and and and work hard, and that's okay. But if after 6 months you still feel like that, maybe re-evaluate if this is the right place for you to be. Maybe it's the position in the company, maybe it's the company itself. Um, but I would say if ultimately you're not happy at the end of the day, at the end of the week, you're not in the right place. >> I would agree with that as well. Yeah. Um, there are no other questions, but we have five minutes if anyone wants to shout one out because not everyone has Slack. I have a question. >> Okay, good. That would have been all good. >> What was the best period professionally for you since you started in the 90s? >> Um, personally, so what was the best period for me? Um, I think the time I enjoyed most was when I was doing um I worked for an ISP in Belgium called Tilonet for about a year and a half. And in that year and a half, I did about 25 to 30 different projects. And that was incredible because the amount of knowledge you absorb in such a short moment and the reflexes you you breathe basically you gain that was incredible. Um so I think the diversity that that that gave me and and and the amount of knowledge that's that that was the most fun part. Thank you. >> I made a noise. That was weird. >> Thanks. Um I just wondered um uh what kind of conversations have you had with other people in the seauite that might have caused push back on something you were developing or pushing forward? >> What were the conversations like? You mean in saying no or >> Yeah, you just mentioned like it's to be ready to say no, but obviously in a situation with senior leadership quite often you've got maybe a minority in that situation. >> Yes. Um so well, as I mentioned, we recently transitioned, but I I've been saying no for to a number of things for years, and they've been they've been getting used to it. Um but um it takes time. The first time you say no, they will not usually not take no for an answer unless you can prove like on paper I am right. Um they will not take no for an answer and they will learn from it because things will go wrong. And so usually it takes a bit of time and then they will learn that what you're saying is true and they will learn to listen. But very often it takes a crash. It takes something going down in the weekend um before they realize. Uh it's a matter of respect and trust that you have to build up over time. Um and that's that's yeah that's the way it goes usually. >> Don't say yes to everything. Exactly. >> All right, we've got time for one more question if there is one. >> No. >> That's a good one. >> I like it. >> You're qualified. >> All right. Thank you very much, Whim. >> Thank you.