#84 - Tech Consulting and Upskilling Others Through Livestreams - Laurențiu Spilcă

[00:01:24] Episode Introduction

Henry Suryawirawan: Hello to all of you, my friends and my listeners. Welcome to the Tech Lead Journal podcast, the show where you can learn about technical leadership and excellence from my conversation with great technical leaders. Thank you for tuning in today listening to this episode. If this is your first time listening to Tech Lead Journal, subscribe and follow the show on your podcast app and social media on LinkedIn, Twitter, and Instagram. And if you are a regular listener and enjoy listening to the episodes, will you subscribe as a patron at techleadjournal.dev/patron and support my journey to continue producing great Tech Lead Journal episodes every week.

My guest for today’s episode is Laurentiu Spilca. Laurentiu is a development lead and trainer at Endava, a technology consulting company based in London. Laurentiu is also an author of multiple books and a frequent coding livestreamer on YouTube. In this episode, we will learn from Laurentiu on his experience working as a software developer consultant. He started by describing what a software developer consultant role is, and then provided his view on how to deal with people’s common expectation for a consultant or tech lead to know about everything in technology. Laurentiu then shared the importance of soft skills and why he thinks it is important for every developer to improve soft skills, in particular when doing code reviews and technical interviews. Laurentiu also shared advice on how to deal with toxic culture when consulting, and the importance of not having emotional attachments to the projects that he’s working on. Towards the end, we talked about Laurentiu’s YouTube channel and his coding livestream sessions, when he explained the reasons why he started them. He shared practical tips on how we can also produce and structure our content based on his vast experience publishing books, courses, and livestreams.

I enjoyed my conversation with Laurentiu, learning about tech consulting and improving soft skills. Having worked as a tech consultant for a number of years before, I find that Laurentiu’s advice is really useful for any of you who are working as a consultant or are thinking to become one. If you also enjoy and find this episode useful, help me share it with your friends and colleagues who would also benefit from listening to this episode. Leave a rating and review on your podcast app and share any comments or feedback about this episode on your social media. It is my ultimate mission to make this podcast and the knowledge available to more people, and you can play a part towards fulfilling my mission. Before we continue to the episode, let’s hear some words from our sponsor.

[00:05:01] Introduction

Henry Suryawirawan: Hello, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have a guest with me. His name is Laurentiu Spilca. He’s actually a development lead and trainer at Endava. He has a lot of experience becoming a Tech Lead also as a developer consultant. And at the same time, Laurentiu has actually a famous YouTube channel where he does sometimes a lot of live coding sessions and a lot of contents there. Laurentiu is also an expert in Java related technologies and in Spring technologies as well. So he wrote a lot of books on Spring. Really, a pleasure to meet you today, Laurentiu. Hope we have a good conversation today.

Laurentiu Spilca: Thank you. Thank you very much for inviting me here to take part of this conversation. Hi, guys. Thank you very much for watching us. As Henry already said, I’m a software developer but I’m also Java trainer, and I wrote a couple of books on Spring. I hope we will have an excellent discussion on several topics that Henry prepared for us.

[00:05:59] Career Journey

Henry Suryawirawan: So maybe in the beginning, if you can share a little bit more about yourself, maybe highlighting your journey or your turning points in your career.

Laurentiu Spilca: I think my journey start quite some time ago. So, when someone asks me about that, I have in my mind that sentence from Lord of the Rings says, “Been 3000 years, Gandalf.” So I’ve been there 3000 years ago. Basically, I have Bachelor degree in Informatics. Then Master studies in Informatics and Economy, and I kind of followed this track. So I started as a developer and my main business focus was on the economic systems, finance, credits, everything related to economy. One thing that I would like to say is that I always refuse any kind of projects in Defense. So anything related to military purposes. That’s one of my strong beliefs and I’m a pacifist. I also declare myself as a person who tries to raise education. So I invested a lot of money in education. I donate a lot of my money from the books that I wrote and everything in education because that’s what I think helps us grow better, have a better future and avoid situations which should not happen.

Of course, I started as a software developer. But then, I figured out that one of the things that is really important in this domain is sharing your knowledge with others, helping others up-skill. This helps me in two directions. One of the directions becoming a teacher, becoming a Java trainer, delivering courses, and then writing books. I started doing both professionally to earn money. But at some point, I also started doing that as help for community. And that’s why, as you said, in the very beginning, you will find that I have a YouTube channel with quite a lot of material to hopefully help the community. That’s the way I share my appreciation with the community as well. But that also helped me in growing as a technical leader, because what I found out is that the route of becoming a technical leader is helping others up-skill. So, I found out with time and experience that technical leadership is not about being important. It’s not about dictating. It’s not about knowing more stuff than others. It’s about helping others grow. So once you learn that helping others grow is your objective, then you become a leader. Simon Sinek is one of my favorite writers and he delivers presentations on the subject. I also share the same with his experience a lot, so maybe one of my recommendations, if you like, is reading Simon Sinek’s books as well. He’s not a technical guy, but he’s very good in leadership.

Henry Suryawirawan: I also always watch his contents as well. He’s very passionate, and you know, when he speaks, actually you can sense the aura. Thanks also for sharing your point of view about being a good leader. A leader doesn’t necessarily mean like you dictate people or everything. But actually, you care and want to up-skill or grow other people, either below you, your peer or just everyone. So thank you for sharing that message.

[00:09:06] Developer Consultant Role

Henry Suryawirawan: So you have been doing this for quite some time, right? In your role as well, you are now the developer consultant. I’ve never had this episode before where I cover this particular role, developer consultant. So maybe you can tell us a little bit more for people out there. I’m sure there are some developer consultants who are listening to this podcast. But for those who are just normal developers in a product company or just in an enterprise, what do you think is the distinctive characteristic of a developer consultant versus just a normal developer?

Laurentiu Spilca: So as a development consultant, what that means is that I’m not necessarily focused into starting and finishing a project and I’m not necessarily focused even on starting and finishing the task myself. What I’m doing in a team I work with, I might have several other responsibilities, but technically, is getting people out of mud when they need that. So, one of the first things I’m doing is that I’m answering questions where developers might get stuck, and I try to figure out a solution with them. Usually with this approach, they figured out the solution faster because I share with them my experience. So it’s sometimes even happens that I already have an answer for a question. In most cases, I will reach an answer faster because I have quite a lot of experience on a specific domain.

So what gives me value is that unlike a software developer who usually has a lot of experience in more technologies but not necessarily very in-depth, I just stay on a few, very small set of technologies, but I’m going very in-depth. For example, in my case, Java and Spring. People sometimes ask me, how can you be a development lead, but you don’t know anything about front-end? Well, I do know some things about front-end. I even touched some Angular, JavaScript and the TypeScript code at some point. But I can’t say that I did more than just maybe adding a button, creating a small page or stuff like that, which doesn’t make me a front-end developer and doesn’t make me a full stack either. So I’m focusing on a set of technologies where I continuously learn what’s new. By that, what happens is that throughout time I learned also what changed throughout time and what’s new. So I’m now able to answer questions on both old code bases and new code bases. Give advice on how to maybe upgrade your technology. Give advice on how to solve problems with this set of technologies with a code base that looks like 10 years or 15 years ago. I also have all the lessons learned. So when someone starts a new project, I can tell them, well, don’t do that because look what happened in one of the projects I had seven years ago. They did that, and it didn’t go well.

In very, very shortly, the difference is that I don’t necessarily implement features. I give advice. But the value that comes through my advice helps developers save many hours of work. And of course, those many hours of work mean money, which helps the project be more efficient in general.

[00:12:17] Knowing About Everything

Henry Suryawirawan: So you brought up a very good point, right? When you become development lead or technical leaders, or even a consultant, you don’t actually necessarily need to know everything. Sometimes this is a myth. When people look at consultants, they think, okay, they should know everything. Or if you look at your leaders, they think that you should know everything end-to-end, full stack developers, they say. Let’s discuss more about this myth. How do you become an effective development lead or consultant when you actually don’t know end-to-end stuff? Like you don’t know in-depth about many other things.

Laurentiu Spilca: Yes, indeed. There are a lot of myths in this domain and this is one of them. The truth is that the trust bond is the answer for this. You need to trust your team and they need to trust you. You work as an impediment resolver, but you don’t have to solve the impediments yourself. So you do rely on your team. When I know that I have a project, well, I have just keep it very simple, so I have a database. I have a server-side implemented with Spring and I have a front-end implemented with React, and maybe I deploy everything in a cloud environment with Kubernetes.

Then I know for sure that I will need people experienced in these four areas. I need someone who is experienced in writing procedures on MySQL database. I need someone who is an expert in the backend, or I can be myself in this case because that’s my area of expertise. But I will need an expert on the front-end and I will need an expert on the cloud. I’m not an expert in all these, and I will never be able to be because they are all of them, very large domains with larger number of technologies you would learn in all of them. So you have to choose the people you need that are experienced in those areas, and you do trust them and they do trust you. In the end, the thing will solve their problems. You will just be there to support, to find the way who can actually help you in solving something. That’s how I do, at least.

Henry Suryawirawan: This brings the next discussion I want to bring up. So let’s say, if you are as a consultant or a lead, so when you are maybe engaged with the customers. They come with a problem statement for sure, and they will ask you something that actually you don’t know. So how would you approach about it? Because this situation tends to happen for not just consultants, especially people who are working in a startup. They have never solved the problem before, or people who just graduated, they went into work and they don’t actually know end-to-end as well. How would you approach this problem when you actually don’t exactly know the stuffs that is being asked or trying to solve?

Laurentiu Spilca: That’s a very good point. So indeed, for everyone else, it might happen that I don’t have an answer to a specific question. Because again, even within your area of expertise, you might not know everything. So what you do in that case? Well, of course, you do rely on a solid foundation of knowledge. Fortunately, my case, so even if I don’t know, I’ve never seen that issue before. I do rely on a solid foundation of knowledge I have. So what I do is that I start investigating that.

One of the aspects I take always into consideration is also the business aspect. I want to know, first of all, why do they need that specific technical implementation? Why did they get into that specific technical problem? Because what happens sometimes is that they might not even choose the right approach, like technically. At some point, someone told me well, we have a problem with a scheduled process. Okay, what’s the problem? It’s this and that. And then I say, okay, but why are you implementing the scheduled process in the end? Well, we need to pull some data from there. And then I said, okay, but that’s not the right technical approach, anyway. So let’s quit that and start looking for some alternatives, like some message exchange.

So you have to be very careful because it happen very often that the problem you have, it might not be the real problem. You might be on the wrong track, anyway. You are looking into how to solve an issue, but you would have had to take totally different approach, anyway. And then if that’s not the case, and it’s still that you miss the right approach and you have that issue, then, of course, you start investigating what the problem is, relying on technical foundation you learnt throughout many years of experience.

Of course, how I do that? I’m a very practical guy. I do use all the investigation techniques I know starting from debugging logs, profiling, and I’m always, if it’s about a framework and I do advise people do that, go inside the framework as well. We do use open source. Open source frameworks are implemented by a community out there, by guys who spend the part of their free time to put their functionality. But that doesn’t mean that they can’t make mistakes. First of all, it might be that it’s a problem with the framework, or it might be that it’s a problem with you using that framework. But to find out what the problem is, you go and you investigate it using debugging, profiling, logging and so on and so forth. And of course, we all first rely on the God almighty, Stack Overflow, and other blogs like this, where we do share details about our problems, and we do read what problems the others had, and that saves us a lot of time as well. Well, everyone does that. So that’s how I do usually.

[00:17:33] The Case for Upgrading Tech Stack

Henry Suryawirawan: So you brought up also another interesting point about asking why. This is also another common case, especially for consultant. You are being sent to a customer project, then they will say, I want to modernize. I want cloud. I want microservice. I want whatever X technologies, Kubernetes and all that. It’s very common that people just expect you to implement some cool technologies. What will be your approach here as a developer consultant? Because sometimes you can actually see the Why doesn’t match with what they want to implement.

Laurentiu Spilca: There are different situations here, different scenarios. The truth is that to upgrade the technical stack, it’s not always the best choice. So I’m not the kind of consultant that starts from the very beginning, saying we need to upgrade. It happens sometimes that we don’t need that. Of course, it depends a lot on the scenario. It might happen that we need that, but we need to take it progressively. And sometimes, it even happens that you have to completely rewrite something because you can’t implement over it. Sometimes the worst diagnosis I would give in the end because rewriting some piece of code that is maybe large and old is very difficult. But sometimes it happens because unfortunately, due to many factors, sometimes application reaches a point where it’s more costly to implement over it than to rewrite it. In that case, of course, it makes sense to completely rewrite it to make it more efficient and be able to maintain it for the next 20 years, instead of using as-is.

Henry Suryawirawan: So you mentioned that upgrading is not always the best approach. You mentioned about cost. Apart from costs, when will upgrading tech stack actually make sense? Maybe if you can dive deeper, what will be the steps, or maybe the things that you should consider before you actually embark on this journey?

Laurentiu Spilca: So, first of all, if you start with an application now, you really need to schedule a continuous frequent upgrades. You start now with some microservices and you use Spring Boot 2.6. When Spring Boot 2.7 is out, you do upgrade, and Spring Boot 2.8 is out, you upgrade. You don’t do it a couple of years, and then you upgrade because if you do that, then upgrading will be a lot more difficult, especially if you don’t have solid tests.

The second thing is, of course, as you might have guessed, you do have to implement solid integration tests. Not unit tests. Integration tests, especially. Integration tests with the frameworks you are using. Are you using Spring Security? Then do right integration tests with Spring Security, because at the point you will upgrade, things might change. For example, the authorisation configurations you wrote earlier might be affected. Not necessarily by your application, but maybe by a bug in the framework. But you need to figure that out otherwise. Security is very important. You would end up with vulnerabilities and that’s something that you don’t want. Now. When is not wise? Of course, because some would say it’s always wise to upgrade, and that’s true if you can do that. As I said, some applications are very, very new-ish at least. My advice is you upgrade and start upgrading them frequently. Don’t allow too much time to be spending between two upgrades.

But when it happens that now someone calls me and they have an application written with Java 6 deployed in a WebLogic server using Java EE technologies from 15 years ago, then upgrading is a bit difficult. There are a lot of questions to be asked there. First of all, should we upgrade the current technology stack? Does it make sense? Maybe it does. Maybe not. Should we completely change the stack of technologies? Maybe it makes more sense to completely changed the stack of technology, start with Spring Boot. There is, of course, no one recipe that is perfect for all applications. So I don’t want now to say which is the best approach because it really depends on the application. Before taking such a decision, I do spend many days looking into the application, discussing with developers, discussing with architects about that, discussing with business people about that. Depending on many factors, including the cost, I can say, if it makes sense to upgrade, it can make sense to upgrade using the same stack of technologies, or if it makes sense, completely rewriting the solution.

[00:21:58] Importance of Soft Skills

Henry Suryawirawan: So, when you are outlining all this, you know, investigation, asking questions, troubleshooting and all that, definitely it highlights one skill that maybe everyone in the career should have, which is this importance of soft skills. So not only you need to be good in technical competencies, but especially for leaders or consultants, soft skills, I think, is also important. Tell us more about your viewpoint on this one, especially based on your real experience.

Laurentiu Spilca: So yeah, definitely soft skill is one of the most important thing to take into consideration. Whether we discuss about simple developer or a leader or a consultant, knowing technical stuff is important. But the biggest problems today, dealing with people is more difficult than dealing with technical problems in general. From that point of view, continuously growing your soft skills is a must. That means knowing how to discuss with others. Knowing how to be humble. Knowing how to persuade when there’s a need. Knowing how to express your ideas to make you understood. You might have, in a room, the best solution, and you know that. If you don’t know how to persuade the others and you don’t know how to describe your solution in simple words, to put the risks and the benefits clear on the table, then you will not convince anyone that your solution is the best.

That happens when you discuss with someone, with maybe your stakeholders. It happens also when you discuss with someone during a technical interview. And now, a lot of developers today attend technical interviews, because they want to change the project they are working on. They want to change their job. They want to change their position. It doesn’t matter. But we do attend technical interviews. To be successful in a technical interview doesn’t only require technical skills. You will be asked about a lot of technical stuff there. But the way in which you describe them, it might make a difference between you being accepted or not.

If you know how to express your ideas, the interviewer will understand you and will understand that you indeed know the technicalities they are asking you about. But if you don’t know how to express your ideas, you might be a very good developer, but you will not convince anyone that you really know that stuff. Not because you don’t know it, but because you don’t know how to express your ideas. So see, soft skills are really important, not only for leaders and not only for consultants, it is something important for each and every developer. Starting from the simple student seeking for their first job to the most experienced of developers.

[00:24:40] Improving Soft Skills

Henry Suryawirawan: So one of the, again, common myth, probably, right? When people are interested in software development world, they think they would only need to communicate through code. Like I just write the code, the code compiles, and that’s it. Some of my guests even also mentioned about this. Initially, they thought it would be that. You don’t deal with people. You don’t communicate. As an introvert person, most likely. But then over the time, you will learn as your journey progress, actually, the communication becomes more and more important. So maybe in terms of tips, how can people actually hone their soft skills even better? Because this thing largely is not taught in schools, especially in computer science. What do you think should people do in terms of brushing up their soft skills?

Laurentiu Spilca: So there are plenty of techniques here. I’m going now to raise again, one of the important responsibilities of the lead. Because again, the lead helps people up-skill, and that’s their objective. For example, one of the best way to help people up-skill in soft skills in general is to make them work together. That can happen direct way through peer programming. You just have two developers working together on the same task that can help. Even if they are too senior, they will learn to work better one with the other. If there is a senior and the junior, the junior we helped learning stuff about the technicalities they are doing there. If they are two juniors, they will help each other. So there is no way you can lose with that.

It’s a myth that you lose with pair programming. Someone says, if I have two developers working on the same task, doesn’t that mean that I spend two FTEs, how they call them, I’m using now a more manager kind of language, on the same task. Yeah, you do that on a short time, and then you gain a lot on a long term. So on the short term, you might lose your two FTEs, but then on the long term, you will gain much more, which is difficult to prove. But in my experience, it really happens. You can’t give numbers. If they ask for numbers, then you are in trouble because you can’t give numbers. But trust me, trust my experience. You will gain on a long-term.

An indirect way to help people collaborate and that’s something should always happen in any project is code review. Code review is not saying direct as having people staying one near the other, or working in today’s remote pandemic situation, having them chat together over Teams, Slack or whatever. Code review is indirect, but it still helps you communicate, raise problems. And then I have a question. Should everyone code review in a team? I had teams, I joined as a consultant and I don’t always give them only a technical advice. I sometimes give them also advice on leadership, advice on the process and so on. I’m joining them, and I say, “Do you have a code review process implemented?” And they say, “Yes, we have. This guy and this guy, they are code reviewing.” “How is that? I mean, you have a team of seven.” “Yeah. But we have only the seniors code reviewing.” Oh, that’s not okay. That’s not okay from many different purposes. First of all, is the point of trust. You need to build trust with all members of the team. You’re having two people who code review the others, that’s not trust. You create a hierarchical position, having those two over all the others.

Secondly, code reviewing is not only for senior people. Code reviewing is, I would say sometimes, especially for juniors, because they will have the most to learn technically out of it by reading the code. Guess what? Sometimes it even happens, they will find problems with your code. You, the senior. It happened for me and it still happens for me that I have juniors seeing, finding problems in my code. That can happen. That doesn’t mean that, oh, if they found problems in my code, it means I’m stupid or something. No, it simply means that you are a human. You make mistakes and maybe you’ve been tired. Maybe you had, in my case, I have a lot of meetings. I have to switch from one meeting to the other. I have half of an hour, try to write some code. Of course, when you are dealing with such a situation, you make mistakes even more frequent than others do. And then you have your junior developers reviewing your code. “This is your mistake.” And then, you have to feel very good that they found that mistake. Not because they found a mistake in your code, but because they found a mistake and that means that they learned a lot of things already. So you already help them up skill by only allowing them code review your code and finding the mistakes.

Henry Suryawirawan: So I think, yeah, you brought up two important examples actually, for people who just want to continue improving their soft skills or communication. It could be direct, either like pair programming, working together, or some people want to do mob programming for some certain problems. Or you can do indirect way also async, either pull request, merge requests or it could be design docs, document reviews and things like that. So definitely, those are the easy ways how to improve.

[00:29:26] Tips on Code Review

Henry Suryawirawan: And for people probably want to review, sometimes it’s on and off, right? Not all people want to do that for some reasons. Either like they think it’s not their area of expertise or the other thing is they think they have too many works to do for themselves. So how do you get this balance where people will be actively participating and collaborating on reviewing each other?

Laurentiu Spilca: Yeah, I do advice code review. And usually, with time, people start reviewing at least on their area of expertise. In my case, of course, I do code review. But I don’t code review, for example, front-end, and I wouldn’t start that unless I would like to start learning front-end. If I’m starting now, let’s say, starting tomorrow I’m going to learn more about React, then I will also start code reviewing React. Not because I want to maybe give some strong advice at the very beginning, because I’m just a beginner, but I will definitely learn from that.

Now, I don’t force anyone code review if they don’t want. Usually that comes with time, and if you apply an approach where you just throw the merge request, pull request somewhere in a chart with all the members and people will start reviewing it. Sometimes they won’t even say that they’ve reviewed it. And at some point, this will grow and then more and more people will start reviewing that. And I don’t even impose a number of how many approvals and stuff like that. I need to have one approval at least. It depends on the number of the members of the team, maybe two. But the idea is allowing as many people as possible code review. If it’s five of them that reviewed, that’s fine, even better. So I’m good with that.

[00:31:01] Outsider Treatment

Henry Suryawirawan: Another tough question. I used to be a developer consultant as well last time, right? It’s actually the treatment, as if you are a vendor versus the customer themselves. So depending on the culture of the customer, definitely sometimes this is more apparent than the others. So what will be your tips for people who are developer consultant out there as well, who are dealing with such customer that they treat you differently because you are treated as vendor, so to speak?

Laurentiu Spilca: I understand what you’re saying. So you mean you are freelancing, maybe? You work for company X. You don’t care about what companies. So you are building a solution for them, but you are seen as an outsider. Of course, that happened to me a lot of times. It sometimes can be difficult, and it depends on the company’s culture. Some companies have a very solid culture, very strong one. And in that case, you will not be affected. People will be friendly. You will feel they help you. They will not consider you are an outsider. They know you are an outsider, but they don’t care. They treat you as one of them because they understand that anyway, you only want to do good for their products. So why would they treat you differently? That’s the good part.

The bad part is, of course, what happens when you deal with a company where they don’t have a solid culture. Maybe people there start seeing you as competition. Sometimes it happens. I have a situation where people have seen me as I was that guy who might replace them, or might take their position, which was definitely not the point, but that’s how they see you. In that case, again, it’s one of the points where soft skills are very important. You need to find ways in which you make them comfortable. You need to find ways in which you make them trust you. How does that happen? Usually through interaction. Again, you do have to interact with them. You try to hold them. You frequently ask them their opinion about several things you implement. By that, you make yourself vulnerable. You show them you are vulnerable. They’re trusting themselves and they start saying, okay, this guy is not trying to actually replace me. They simply tried to collaborate with me to build a solution.

It’s not always that you will be successful, of course. Again, you try your best. At some point, if things start to be messy, then it even happens that I stopped the collaboration. I don’t collaborate with clients who don’t have a culture, usually. As an outsider, it’s very difficult to help them build a culture. So then you have to always make sure if you try to push into changing something in a company’s culture, you may have to make sure first that you are in a position where you can do that. Otherwise, you will simply burn out. You will try moving something very heavy with your bare hands, which is not possible. So it’s not your fault. And in that case, your health is always more important than any kind of project, than any kind of money. There are thousand other projects out there. You have to try first, make them understand. If that doesn’t happen in a short time, then maybe it’s time to go.

Henry Suryawirawan: Thanks for giving that practical tips. Because as you mentioned, it’s really important to gain the trust first, and not be seen as a competitor or threat for the employees within the company. I also could relate to your examples saying that some consultant tries their best to change the culture because they learn from best practice or maybe their previous engagement, and this is the best way. Sometimes, it may not be able to translate into a particular customer set up. Because of the culture, maybe because of the people who are there, or maybe it just doesn’t work. So yeah, thanks for raising the point. Don’t burn out yourself trying to do that.

Laurentiu Spilca: What I say is that as a consultant, just imagine you’re like a doctor. Some patient comes to you and you tell them, you have heart problems, so you should eat less fat, less sugar. If they do that, okay. They don’t do that. It’s not your fault. So you can’t stop them from drinking coke. If you tell them what they need to do and they don’t follow your advice, you can’t do anything. You don’t have to blame yourself for that. It’s their problem in the end. That’s what the consultant does. You try to tell them. You try to improve your soft skills as much as possible, and try to persuade them, giving stronger motivations why they should follow a specific approach that you want them to follow. But if they in the end don’t follow that approach, then you don’t blame yourself.

[00:35:35] Project Attachment

Henry Suryawirawan: This comes back to the attachment. How attached you are with the project that you’re working with, or the deliverables that you’re doing? So what happens if, let’s say, you are not attached at all? Sometimes this could happen. A consultant is sent to a project where they don’t have interest in, and at the same time also, they don’t have real expertise. I’m not sure this is applicable to your past experience. Sometimes there are consultants who are just sent just to fill the manpower. How would you advise people who are being in this situation?

Laurentiu Spilca: So I’m not treating a project like my baby usually. I don’t get really attached to a project. But doesn’t matter what the project I’m working into, I’m always giving my best. I don’t believe that I own the code. When I write some code, and I push it to the repository, it’s already not owned by me anymore. It’s part of the team’s responsibility, which includes myself.

So I’m not attached to code. I don’t tell them, don’t touch my code or something like that. But I do treat everything super seriously. So when I’m implementing something, I’m trying to do my best. And even if it’s not my code, if I’m writing some capability in an app and I find some problem, or I find a way where I can clean some code that hasn’t been written by me, I do that. That’s boy scout rule. So I try to simply follow the best practices throughout the project itself, but also in the collaboration.

[00:37:00] Starting YouTube Channel

Henry Suryawirawan: So one aspect which I want to go into which is coming back to your root, right? Up-skilling people, sharing knowledge, is your YouTube channel. You seem to have a lot of content there. So first of all, like how did you get the time? That’s always people’s question. How do you get the time to produce all these contents? And second thing is you actually have a lot of followers where people actually learn from you. So tell us more, how did you actually start this YouTube channel?

Laurentiu Spilca: Yeah. So I actually started not a long time ago. The YouTube channel is maybe three years. I don’t remember exactly, somewhere there. And I started it as my way to help the community. Because I know that many people maybe can’t afford to buy a lot of books and a lot of tutorials. I don’t say that might be those are the same good as, of course, the video tutorials you find on paid solutions. Because what happens is that, again, and you asked me, how do I find the time? I don’t edit them, for example. So in my case, my YouTube is like a gateway to the world to share my knowledge. But I shared the knowledge raw. I don’t lose time, and that’s why in all my YouTube channel, most of my videos are live events because that only allows me spare no time at all, no time before, no time after. I’m clicking the live button and saying what I have to say. And then I close the live and the video stays there forever. So that’s how I do that.

May I make mistakes during the video? Yes, it happened. I didn’t edit them. People, again, asked me why don’t you edit your mistakes? Well, because we do mistakes. You do mistakes. I do mistakes. So I want people to understand that it doesn’t matter how much experience you have, you make mistakes and you don’t have to be worried. That’s even another way I hope it helps people get more trust in themselves because I’ve heard some of my audience saying, well, I was watching some video series on a paid solution. I’m always looking at that guy or girl, and they seem to know everything. I’m looking at them. I will never know same as they do. Maybe they registered that five times, edited that, and what happened at the very end. So don’t worry. Everyone makes mistakes, even them. That’s why I don’t edit. So I don’t edit my videos for the people to see them raw as they are, which makes them lower in quality, of course. The learning is, of course, much better to edit and take out all the fat out of your learning material. But that would cost money.

I share my YouTube channel for free. I sometimes get some sponsorship, but that’s everything I gained from my YouTube channel. I don’t have even YouTube monetization open for my YouTube channel. You won’t see commercials. I do also have, however, paid material. I write books. The books are not for free. I write them in collaboration with Manning publications, and they help those who don’t like my raw materials, my raw videos. They take the book. It doesn’t contain fat and they can use it as a paid solution. So I have the opportunities for everyone. Those who want to pay, and those don’t want to pay for what I say.

Henry Suryawirawan: Thank you for sharing all this thought process. Definitely, the making mistakes part, even myself in producing this podcast. I do make mistakes as well. Although I edit my stuff. But different people have different preference. So the key learning for this content creation is that, yeah, you have to do what you prefer, right? Sometimes you don’t have time to do extra stuff, then I think it’s still okay. People are still finding it relevant.

[00:40:24] Coding Livestream

Henry Suryawirawan: So maybe for coding live stream, why do you think there are many people who need such livestream? Do they learn specific things? Especially if it’s one hour, two hours looking at people coding. What do you think are the aspects that people look for?

Laurentiu Spilca: Live coding, first of all, one of the essential aspects is that you clearly see exactly how that person recording the livestream thinks. Because they arrive to the solution line by line and writing code is not like writing poetry. You know, it doesn’t start from the top and go to the bottom. You switch classes, go to another class, go back to that class. That’s something that in my experience, these beginners find very useful because once you already work in the field, you’ll know some of the stuff and you have a feeling on how things work, and then maybe a solution that’s edited and shows you only parts without showing all this, which saves you time, because you already know everything about the switch. But seeing someone live coding, and even having problems, trying to solve their problems at some point. I think this helps, especially the beginners.

Henry Suryawirawan: And this aspect of livestream coding is actually aligned with what people call learning in public. So you actually solve a problem live and you actually publish it as well. Sometimes some people use these to learn actually for themselves, but also sharing it with the public. What are your thoughts about learning in public? Do you have any specific opinion about this?

Laurentiu Spilca: I actually think that this is one of the best way to learn. Teaching always helps you understand better what you are doing throughout time. You teach one subject once. You will understand something. You teach the same subject the 10th time, you will learn even at that point, something more. You will get questions. You will be asked questions that maybe you don’t think about. Because if you have an audience, all people think differently. And sometimes, someone asks you some question that you’ve never figured out is even possible, and think, okay, I have no idea but I will research them, tell you later. And then you go back, you research, you see what the answer is.

[00:42:35] Tips for Producing Content

Henry Suryawirawan: For people who are interested in learning by teaching or producing content, how do you actually give a tip for people to structure content? How do you even come up with an idea, okay, I want to do live stream on X, right? How do you do that?

Laurentiu Spilca: Yes, structuring content is indeed difficult. Even in many cases, it doesn’t work for me from the very beginning. I can’t say that I always get the right way from the very beginning, but what I learned by both writing books and creating video material is that whenever you deliver something, you need to make sure that whatever you deliver, relies solidly on the foundation you created before.

So when you start with, let’s say, the first chapter of a book or the first episode of a series. What you teach there has to rely on something that you call the MQS, the Minimally Qualified Student, and you define what that MQS is. Let’s say, if I’m starting teaching Spring, you have to be very specific, I assume my student knows how to work with collections in Java, how to work with exceptions, how to work with the generic types. You don’t say they need to know Java fundamentals. That doesn’t tell you anything. Java fundamentals can be defined as many ways for many people. You have to specifically point out what they need to know. How to write a SQL queries for CRUD operations? So whatever the exact points are that you need. And then you start the first episode or the first chapter of the book by that. You need to make sure that the first chapter solidly relies on what you put on that Minimally Qualified Student topics.

And then when you continue with the second episode or chapter, the second one needs also to rely on both the first plus the MQS and so on and so forth. So in one sentence, you don’t allow gaps. Because otherwise, it was at some point a joke on the internet with how draw an owl, and it was now there’s the circle, and then the second, it was all completely written. So if you do something like that, you will only create frustration because people will not learn. Why is that difficult? Because what I told you, maybe it doesn’t explain where is the difficulty in that? It looks like a very solid and easy process to follow, where it is not. Because you already know that. You already know it. So it’s very difficult sometimes to put it in the shoes of someone who doesn’t know that stuff.

At the beginning, you will have the impression that everyone knows some subjects, and that’s not true. So, you need to think about all the subjects that are needed. And some of them, even if they might look to you easy, like stuff that the students should know, you have to be very aware that some of that is not known by your students. So even if it looks simple for you, it’s something that you still need to teach. That’s how gaps usually get created. It’s actually a syndrome, and it has a name that I forgot at this moment, but it’s the syndrome that causes you believing that something is straightforward where it isn’t. Instead of you teaching it, you skip it and you create gaps. Something like that.

Henry Suryawirawan: Thanks for explaining this. I also don’t know the word for the syndrome, but I understand what you mean. Sometimes even as a leader, not just teacher, or people sharing content. We unconsciously think that the others understand what we are thinking about. So I think like maybe thinking out loud or sharing, even just the thought process, how you come up with the idea, I think, definitely super useful. So for people who actually want to go to Laurentiu’s channel, it’s on YouTube with his name. So there are plenty of content and livestream materials out there. I’ll make sure you can check out. I’ll put it in the show notes.

[00:46:13] 3 Tech Lead Wisdom

Henry Suryawirawan: So Laurentiu, thank you so much for being here and sharing your knowledge. But before I let you go, I have one last question that I always ask for all my guests, which is for you to share three technical leadership wisdom. So this is for people to learn from your journey or anything special that you want to share to the audience here.

Laurentiu Spilca: So first of all, the leader is on the same line with the team. Start by not considering yourself above anyone. Being a leader is just being a member of the team whose responsibility is to up-skill the others, different techniques and ways. That’s one of the things. Because I still see people making a confusion on this, on what the leader is in reality.

Then do invest time to upgrade your soft skills. To do that is not only by reading the books. That’s good. Attending conferences, again, Simon Sinek. I love his talks. But it’s also by simple interaction with people. Go out for a beer. Talk with them. Go out with your team. Learn from them. Learn their sensibilities. Learn about their personal lives, and that will help you understand people even better.

Third advice is don’t burn out yourself. Sometimes, by taking so much responsibility, and by the collaboration being somehow in the middle, in many cases, in the collaboration between your stakeholders and the team can impact you and can make you more stressed, or even work over the schedule. While this can be helpful for a short period of time, because you will simply get out of the comfort zone. If you keep it on a medium and long term, this will lead you to burnout.

So if you see yourself in a situation where you can’t draw a line between where you should stop and not, I even advise you create a schedule that forces you to do that. For example, in my case, I do schedule, I do force myself to take a break by scheduling stuff that I cannot postpone. For example, I have my piano lessons. Someone comes and helps me study piano. That should happen every Monday at 6:00 PM. So Monday 6:00 PM, I will be out of office whether I want or not. Because otherwise, I can’t attend the piano lesson and I cannot postpone the piano lesson because someone comes to my place to teach me piano, so it would be rude for me to do something like that. Even my live events on YouTube is a way sometimes to force me get out of work. If I have the live event at 7:00 PM, then I’m all out at 7:00 PM and I’m doing something else. So there are ways in which you can avoid burning out.

Henry Suryawirawan: Wow. Thanks for sharing that tips. Actually, it’s very relevant for me as well. As we all work remotely, working from home, sometimes you don’t have this boundary, what you call drawing a line. So it’s a very practical tip. Do book a schedule that force you to actually do it. Sometimes we book something but we don’t do it because sometimes it’s only a promise to yourself. So I think like maybe booking a lesson or just going out with people who are waiting or expecting you to be there, or doing livestream just like Laurentiu does. I think that will help as well. So thank you so much for your sharing, Laurentiu. For people who want to follow you, apart from YouTube channel, are there any other places?

Laurentiu Spilca: Of course. You can follow me on Twitter and LinkedIn as well and subscribe to the YouTube channel. You will get notifications about all the video events I create. Hope to see you and to hear from you. All your questions, discussions, I will be glad to find time answering them.

Henry Suryawirawan: Thank you for that. So good luck with all your live stream. Thanks for being here, Laurentiu.

Laurentiu Spilca: Thank you again, Henry for inviting me, and I wave goodbye for our audience. Cheers.

– End –