Key Competencies for Software Engineers - Marco Ziccadi

All right, well, they say a picture tells more than a thousand words. What about a video that gives even a better nice introduction impression of Amsterdam Tech? So welcome everyone, I'll be your host for today for this first in a series of what we call TechMind Series. With me today is Marco Ziccardi. Yeah, bear with us, it's the first thing, so some things might go a bit glitchy or might go a bit wrong. That's what you have when you do something live. So nothing is pre-recorded. We'll just take it on the spot. Marco has 16 years of experience in software engineering leadership. He's also a mentor and he's coaching at Plato and working for MentorCruise on top of being the host of another podcast called Spaghetti Code, discussing engineering management, diversity, and inclusion in tech. A warm welcome, Marco. Nice having you here in the show, I would say, in the TechMind Series webinar.

Thank you very much, nice to be here. Thank you for the invite.

You're welcome, thank you. So we've prepared a couple of questions for you, and the one I'd like to start off with is, yeah, what do you do at PLATO, MentorCruise, SpaghettiGoat, and also how do you combine all of that in a very busy work week?

Yeah, for the one— for the people that don't know, uh, Plado and Mentor Cruise are two platforms that provide mentorship for people that want mentorship and are seeking advice, or, you know, different type of experience and learning from different people and different type of experience. So I'm doing mentoring there for people, and Spaghetti Code, obviously, as you said, is a podcast. Um, so how do I combine everything along with my, my my job, right? Um, so, well, first of all, I wake up very early in the morning, obviously, because I need hours to do a bit everything. But what is really important, job aside, is, um, is time management, you know. And I need to be very strict with how I manage my time and, you know, how I prioritize different tasks that I have to do during the day, you know. So what is urgent, what is important, and so forth. There are different techniques that can be used, you know, the quadrants, uh, what is important and not important and so forth. But you know what I do, I decide what needs to be done during the day and then, you know, I execute on those, on those tasks. But you know, diligence, I need to be very diligent in doing that.

Good.

Yeah, and you need to be good in context switching, I think, from one to another. But I can imagine that's also what excites you, that that's—

yeah, well, that's, that's a bit something, uh, um, that you have to learn to do as a manager, right? Usually as an engineer, you focus on specific tasks and, you know, there is deep focus on that task for a few hours. As a manager, you don't have that kind of luxury. So if I can usually focus on something for 30 minutes, oh, it's already a blessing for me. It's already a lot. So I need to be able to switch and, you know, to jump on different topics suddenly and be proficient and efficient in those topics immediately.

Amazing. Nice. Can you also tell a bit more about, about what you do there? Like, what specific technical competencies or fundamental skills do you believe are essential for individuals who are aspiring to join the Stefan van Eerde software engineering team and maybe over time also lead the team?

Yeah, so first of all, I will say that what you really need is passion. I know it seems like banal, but is reality. Um, passion for solving complex problems, uh, in the tech side, but, you know, as a manager, in the people side as well. So, you know, when working on complex project problems, there are some skills that you need to develop, and like problem solving, obviously. So how to break down a big problem in smaller chunks and how to make them manageable so that you can solve them effectively. But also critical thinking, you know, think out of the box. Not just go with the recipes. There are no recipes usually to solve a complex problem. You just need to analyze it. So many times I, you know, I spoke with people and many of them told me that formal studies are not useful because, you know, they are based on theory and they don't teach you what you do in the real world. I disagree with that, to be honest, because, you know, when you join a team, when you work as a software engineer, many times, if not most of the times, you have to deal with problems you know nothing about, you've never seen before. And after 20 years, so you said it, after almost 20 years, I still find myself working or facing problems that I never seen before, that I don't know how to solve. So how I'm gonna solve them if I never seen them before? Well, the only way to do it is to acquire some basic knowledge that will help me to analyze those problems and find out the solution on this problem, right? Well, when we talk about technical, of course, if you want to be a bit more specific on the technical skills that we need, there are things like data structure. So understanding how data structure works, algorithm theory, you know, how the algorithm work, all the algorithms that there are for sorting, versions, and so forth. Big annotation that helps a lot when we talk about efficiency and performance in programming. You know, those are some crucial skills that will help you then to analyze and to understand the type of problem that you are trying to solve. Well, you know, one of the, actually, the thing I was thinking a lot and, you know, Not everybody learned this at the universities, design patterns, software design patterns. At least I've done it. You need to consider that I've done my university 20 years ago. So, I think it changed quite a bit, the university, since then. But at the time, there were really few universities that were helping engineers to understand how software patterns worked and why they were important when you were writing software. So, but if you— in my opinion, when you go around it and you look at all those different topics like cryptography, algorithms, and so forth, they all boil down on mathematics, on basic concepts of mathematical, uh, like mathematical proofs, right? Like deductive arguments to prove a mathematical statement and so forth. And those are the things, in my opinion, that I used a lot in my daily work to solve the problem. The way of thinking, you know, how to approach a problem, how to analyze a problem, but also how to learn. So I learned to learn at the university, which for me this is invaluable because, you know, in 20 years I had to learn so many things that I didn't know before. And the only way that I can do it with the time I have, as we said before, is time management, but also being able to use that time that I have in the best way as possible. And if I'm not able to learn, I won't be able to learn within those few hours that I have every week to learn.

So it's about learning, about becoming more efficient, about, you know, sort of practice what you preach and apply the knowledge that you've acquired at university throughout all the challenges that you will face and all the new projects that you, that you run into over over the time that you work, right?

Yeah, absolutely. Yes.

Yeah, very nice. Thank you. When it comes to maybe an example that you have of a project that software engineering team members work on and the skills required to bring these projects to completion, how would you do that? How can you do that effectively?

Yeah, I can give you actually an example. That I faced a few years ago in a company I was working with. I was— the goal was of my team, the goal of my project was to introduce end-to-end encryption within the main product. Well, end-to-end encryption is, let's say, a technique where only the sender and the receiver of the message, of the encrypted message, can actually read the message. So, I have access to the key to decrypt the message. Um, so we were introducing this, this technology within the, the products, and, uh, if you don't have basic knowledge of cryptography, it's not intuitive to know how to enter and encrypt works, right? Um, you may not know why we were using, for instance, symmetric and asymmetric encryption for performance reasons, you know, the big O that we were talking about before. So what happened at the end is that some other teams that were in the company that were using the tool that we were developing that basically there were SDK for that we were providing to the rest of the company to introduce end-to-end encryption in the part of the product that we're developing. So, what was happening, long story short, is that they didn't know that they had to share the keys to decrypt the messages with the other parts. They were kind of assuming that, you know, once you encrypt it, then the system is able to decrypt it somehow. So we ended up with a lot of messages kind of lost, right? Or just being accessible by one part of the, of the parties, right? Just by Bob, for instance, rather than Alice. And that was a big disruption in the service, of course. And we had to kind of instruct or, you know, help them to understand how those type of technology how it was implemented, how it worked.

Of course, you know, it was difficult because not knowing how those basic concepts work, you need to have a lot of groundwork, right?

A lot of pre or prerequisite knowledge that you need to have.

So as I was saying, how symmetric encryption works, how the asymmetric encryption works, those are basic knowledge and basic skills that we had to that we applied in our daily job, but many people didn't know, so we had to teach them how they needed— they were working. And it takes time, of course, right? And this is kind of the cost of the efficiency of the work that we were trying to do.

So, you know, I always say, like, uh, it's funny because, you know, it's like if you are a civil engineer and, you know, you say, okay, I will deal with structural mechanics when I'm gonna build the building or the dome.

That's not how it works, in my opinion. You need to know the structural and mechanical first, and then you go and build whatever you have to build, you know, the bridge or whatever, not the way around. And I think in software sometimes we have this kind of approach.

We say, okay, we will learn about it when we get there.

And it's true for specific language, for instance, but not for the basic concept like memory management. That's, that's something you can apply everywhere and it's transversal.

So you have some, some modular things that you can apply everywhere because the logic remains the same regardless of the situation, and then you have some, some new insights and, and, and maybe some new SDKs and other things that are happening that you need to adapt and apply to the situation.

Exactly, that you can build on top of those basic knowledge that you have because, you know, Technology changes, it changes tremendously since when I was, uh, 20 years ago, right? I was saying when I was younger, but 20 years ago. And so you can think that when I started, we had no smartphones. So you can imagine how it changed, the technology, since then.

Yeah, we're already that old, I'm afraid, Marco. We know the time prior to cell phones and, uh, and that you could look up everything, uh, you know, you had to, you had to go, uh, to your PC, yeah, right, to check Google Maps where you, where you needed to go and then memorize the root because otherwise you would end up somewhere in the middle of nowhere.

Yeah, exactly.

Yes, interesting. Um, thanks, Marco. When it comes to the final question I have, and then of course feel free to, uh, to ask anything that you may have still, um, what is the best tech stack for software engineering teams according to your own experience? And yeah, why is one better than another when it comes to the languages, the frameworks, or the SDKs that you, uh, that you're familiar with?

Yeah, that's a, that's an interesting question. I've been asked this a few times, and I have to, you know, I will say, I will paraphrase something, the quotes that is actually attributed to, uh, to Lincoln or David Sillinger, which is an American author, which says a person's leg should be long enough to be able to touch the ground. So what I want to say, I want to say basically that there is not a perfect stack. There is not the ideal stack. There is the right stack for the type of problem that you are trying to solve. So it's like a— it's a bit like a car, right? And that's what we were saying before. You need to know the basics. You know, once you know how to drive the car, then, uh, you know, you can change the car. You need maybe to adapt the size of the car, the sensitivity of the brake, to how you change gears, if it's automatic or manual. But you know how to drive a car. It's going to take you a while, but then you know. So there is not really much you need to relearn once you know the basics. Now, I understand that I'm not answering the question yet.

It's a smart way of steering a bit away from it. As an Italian, you have a favorite car, right? So you might also have a favorite language or a favorite way of doing things.

I can tell you that, you know, what I would suggest is to, again, learn the basics. And there are some languages that are less abstract than others. That will help you to learn those basics. So we are talking about languages like C, C++, Rust, or even Java. They will, you know, since they are not so abstracts like Python or Ruby or other languages, they, you know, you need to deal with stuff like memory management, like in C, right? And that will help you a lot to understand how programming language work, how the machine are used, and how to use efficiently the type of power, the machine power that you have that are available to you. And I will start from those type of languages because then from those ones, you can build up and you can learn more abstract languages. This is what I've done. I started from Java, well, C at the university, but then in a working environment, I started from Java and then I moved into Ruby and other languages, TypeScript and so forth. So I would start with something basic, but, you know, having said that, it depends a lot on the type of medium and long-term goal that you have. So it's difficult to provide a holistic answer, you know, and a very straight answer to this. It depends a lot on what you want to do as an engineer, you know, what type of field you want to work in. If you want to work in AI, for instance, Of course, Python is one of the most complete in terms of libraries and community language.

There are things in other languages as well, like C++, but Python probably at the moment, it's kind of the fact standard.

And so a lot of depends on what you're trying to do. So I always say select the stack, depending on the type of code. That you want to achieve for yourself and the type of trajectory or career growth that you want to have.

Great.

Thank you, Marco. Related to that, related to Python or other languages, would you be an advocate of adding one of these languages to the curriculum of education? Because right now you learn English, you learn maybe French, maybe you learn Spanish, maybe even Chinese to some extent. But so far, coding is not really part of the curriculum, I would say, for a lot of, at least more traditional universities. Would you say that needs to change? Instead of Spanish, you should be able to choose Rust or Python or something like that. Would that be a good idea?

Well, I think it depends on the university, right? When you, you know, for a technical, we are talking about like computer science. Yeah, um, yeah, I don't know what you use nowadays. I think there is still a lot of C and C++ and Java, I guess. Yeah, those are the ones. Yeah, I think Python probably is a good choice, uh, especially because AI is taking over and it's not gonna go away. It's not gonna go anywhere, right? In the sense that it's gonna stay and actually will develop even more. And since Python, as we said, is the de facto language standard to work with AI, but also with LLM and so forth, then I think it would be very competitive advantage, you know, for the market to know already the language for sure.

Fantastic.

Good.

I see we're running out of time. I'm checking now with the back office team if there are any other questions still pending. No, I think we're good. Do you have a, you know, maybe a final recommendation for the audience or something you still like to ask or something you'd like to state that I didn't ask?

Oh, I think it's, um, I hope I was clear with some of the answers. I know that, you know, a lot of depends, but this is one of the things that you learn when you get older, you get more experienced. That the more you know, the less you know. And the more you know, the more you see all the difference, that everything is contextualized. So everything depends on the context of where you apply your knowledge, where you are trying to deliver something, what type of context, what type of market, what type of sector. So it's a lot of contextual situation that you have to deal with. So there is not a right or wrong answer. It always depends. What you're trying to achieve and where you are trying to achieve it.

Fantastic. Yeah, it depends is an answer I hear a lot as well, also in the software company I work for. So yeah, thank you, Marco. Thank you for, uh, for being here. Thank you also for, uh, for spreading your, your experience and knowledge among future software engineers and people who are considering joining this beautiful field. And, uh, yeah, thank you for your time and thank you for being here. Uh, at the TechMind series and being the first to kick it off and to be so bold and clear about your own vision and your answers in that. Thank you.

Thank you very much and good luck to everybody.

Thank you.

Bye.

Bye-bye.