The Scrimba Podcast

Patrick Akil (00:00):
Especially early on I was like, these people are on a level that I will never get at and I still know these people and they are still on a level that I will never get at. But the difference is that back then I thought I needed to get to that level and now I realize I am on my own path. I know what they appreciate of me and it is not necessarily technical excellence.

Alex Booker (00:20):
Hello and welcome to the Scrimba Podcast. On this weekly show, I speak with successful developers about their advice on how to learn to code and get your first junior developer job. My name is Alex and today I'm joined by Patrick Akil, an experienced engineer, teacher, and host of a podcast called Beyond Coding, which I really like because we've often said on this show that to have the best chance of success as a new developer, it's not just about your coding skills in isolation, your job hunting strategy, soft skills and how you position yourself can make a massive impact. My guest today, Patrick, is pretty much an expert on this, but what I think you're going to find refreshing and maybe a little bit surprising about this interview is that Patrick isn't just regurgitating cookie cuts and self-help career advice. He's really opening up and applying his coding career wisdom through the lens of his own story as he figured out his career. I think this could be a shortcut in your journey, so stay tuned. You are listening to the Scrimba Podcast. Let's get into it.

Patrick Akil (01:28):
I didn't always have my eyes on coding. I wanted to make video games, and then I made a poor choice of a, I think high school electives basically because I couldn't do game design. I couldn't be a programmer. I couldn't pick the university that allowed me to be a game developer, so I picked something that was still adjacent to tech but also was kind of more business related in a study that's called information studies. Some people call it information science, but in there I learned a lot about business development, business studies as well as a little bit of programming skills. That's why I picked up the first programming language, which was Python in doing more data science related things. Now in there there was also a course with regards to web development where I touched on like HTML, CSS and PHP at the time, but that was really my initial phase figuring out programming languages that I liked as well as kind of dabbing my feet wet into the landscape there.

(02:16):
Then when I got out of university and I got my bachelor's degree, I still didn't know exactly what I wanted to do. I had a lot of struggles with that actually as a kid, but I picked a job which was really broad and I started off in operations. Now in a more traditional sense, you don't have that a lot currently, but in a more traditional organization, you would have the development organization or the part of the business unit that would develop the code and then would pass it onto the operations people to put it into production. So that was my role, that was my responsibility and the accountability that I had in there as well. But that also came with a lot of frustration because in production I could see some behavior that wasn't what it was supposed to be, and I knew from my previous experience what exactly went wrong.

(02:58):
I could see the code, I could browse through the code as well, but I wasn't responsible and I didn't have access to fix it, which kind of led to more of a frustration. So within the organization, I tried to move to the software development unit and I eventually did so.

Alex Booker (03:11):
How come you couldn't do game development at school?

Patrick Akil (03:13):
Yeah, maybe it's specific to the Netherlands, but throughout your high school journey you're going to have to pick some courses, some varying degrees in math when it comes to difficulties in the courses you'll take, and that will also kind of limit the university studies that you can do out of the box. Now, I also didn't want to have any delays in my educational journey. I wanted to get out of school as fast as possible and get to the real life job part of things, so I didn't want to do an extra year, for example, to get the courses in.

Alex Booker (03:40):
Why did you want to get into the industry so quick?

Patrick Akil (03:42):
Yeah, maybe it's because I was just impatient. I wanted to earn money as fast as I could. That was kind of my mindset and I didn't like learning things that I didn't really care for that much. I thought the most experience I could have is by actually experiencing things. I'm not a big reader. I still don't read as often as I should be. I only read when it's necessary. I mean, that's kind of why I started the podcast. Also, instead of writing blog posts. I like talking way more than I like reading, and I thought the fastest way for me to grow and to experience was to actually get a job and start experiencing things, learn from there, see what I like, see what I don't like and still grow and keep growing on there.

Alex Booker (04:18):
I mean, to me that sounds very sensible. I'm not sure what it's like in the Netherlands, but in many countries you have to pay to go and do education and figure out what you want to do, but I always encourage people if they have the option and the aptitude to instead get paid to learn and go into the job market essentially and start working on real life projects.

Patrick Akil (04:37):
The education in the Netherlands is quite good. I haven't had any education in other countries, so take this with a disclaimer, but through governmental support, you actually get quite a substantial study budget and at the end your debt is not as large, for example, as it would be in the US. I came out of university, I had two jobs for most of it, but I didn't have any debt coming out of it, so I was quite proud of that and that's actually pretty normal also when you get a bachelor's in the Netherlands.

Alex Booker (05:02):
Nice man. Yeah, we get a little bit of support in the UK, but it's still quite expensive and I think in America as well, it gets quite costly even if you're to get things like student grants or what have you. So obviously you kind of experienced school and you did some programming, but you developed a huge amount once you entered the "real world" and started working closer with projects and code and things. Looking back at it, how'd you feel about education for programmers? Do you think university is a good path to take?

Patrick Akil (05:30):
The industry that we are in is amazing, first of all, because of the community and also the community that puts out the information. There's a wealth of information that is out there, so when you've already been on a career path or you're starting, the information that is out there is rich enough and there is enough for you to pick up that information and start practicing and start trying on the path for where you want to go. If that's coding, that's completely fine. If you're looking for your junior job there, you can get a lot of traction with the information that is out there. When I look at my personal path, and this really has to do with where I came from and where I grew up with, I'm one of the first people in my family to go to university and I also have a lot of siblings, so the expectation for me was there to go to university, but in there I don't regret it.

(06:14):
I went through it and I got the degree and I got the piece of paper because I wanted it and it was also partially expected of me and I wanted to set a good example. Now, I didn't learn programming as much at a university because I didn't do computer science necessarily. What I did learn was a lot of the teamwork, a lot of the soft skills that are related and that will allow you to thrive when you land a junior position, but it had a lot to do with people. Basically you get kind of a vague problem and you are enabled in a way that allows you to fix that problem. When you do the research, when you work together with people, when you do presentations for example, when you're not afraid to fail, learn from there and pick up and grow from there as well.

(06:52):
It allowed me to kind of cultivate this mindset of proactivity and I think especially because I started in operations that proactivity allowed me to get that first job as a junior developer. I wouldn't have gotten that if I didn't stand up for myself, if I wasn't proactive, if I wasn't hungry to grow, and I think going through university really taught me that, and I think that's a life skill that university might teach you, but it depends on your country, depends on your own journey as well, as well as your mindset, I guess. It's a difficult one.

Alex Booker (07:18):
I'm not sure exactly where you started your career as a developer, but I saw that you were a software engineer somewhere called Xebia Academy and then for a few years you went on to work at a few different companies and now it looks like you're back at Xebia as a consulting software engineer. What's the story there, Patrick?

Patrick Akil (07:36):
I'll start from the start. I joined in operations at a company called Blokker Holding. Now that's a holding company of a lot of the retail organizations you'll see here in the Netherlands and then throughout operations I was like, I read a lot about DevOps and I was like, "This is what I want to do, develop." It's a difficult one, build it, you ship it, you own it. So I searched for a way that I could actually do that within the company that I was in because I think a lot of people, a lot of times will seek within a company instead of immediately going outside of the company because you already have your network, you already know the people that might help you to go on the path that you want to. So I talked to a lot of people and they introduced me to some other people that were responsible for the software development unit that we had, which was more so related to the e-commerce side.

(08:16):
Now, I had a lot of conversations and I initially landed a job as a junior enterprise service bus developer. I had no clue what I was going to do there, but I mean the promise was, I was going to learn about software engineering. Really quickly I learned that the person that was responsible for transferring knowledge to me was only available for three or two days a week, and with that he still had responsibilities for developing actual working software and even so, that was not a lot. So I went back to my manager. I was like, "I got this role, I really don't know how to fulfill it. There is almost no work and with regards to knowledge sharing, there's just not enough time for this person to do so. Isn't there any other alternative that I can do that I can still kind of tread this path of software engineering and learn from there?"

(09:00):
And they were like, "Yeah, I mean we have the e-commerce side of things and they're building a new platform and there's a lot of consultants there that at some point have to scale down because we want to be able to do this internally," and it's also more cost effective and it's better for the organization if we have the internal people to do the things that we want to. He said, "I'm going to put you next to them and I'm going to give them the tasks to transfer as much knowledge to you as they can and you're going to go from there. So I started off next to the consultants. Coincidentally the consultants were from Xavier, but they really showed me how to build the right thing the right way. They basically said, "Well, this is what we're building. This is the way of working.Have you figured out GIT yet? Do you know what it is?" Initially I was like, "I mean I've heard of it." And they went through the basics with me until I had my first pull request.

(09:44):
I was really, really proud of that and then I got 40 or 50 remarks and I was like, "Man, these people really know what they're talking about," because I didn't think of any of that. Then I iterated and I iterated and I iterated until I merged my first pull request and I was like, I figured out that I'm in an environment where I'm allowed to fail, where I can grow and these people really know their stuff, so this is the environment for me. And through that, my growth curve just accelerated. I was really fortunate to be in that environment.

Alex Booker (10:09):
It sounds like you were the benefactor of just some awesome mentors and I think there's some actionable advice in there for people listening as well, which is when you're interviewing for roles, oftentimes you think it's a one-way street. Like they're there to interrogate you, but actually you are meant to learn about the company as well and evaluate your growth opportunities and what kind of mentorship you might be afforded. I think they should look for something like you got Patrick where it's an environment where they're allowed to fail and grow, but they can also work with and learn from knowledgeable people that are generous with their knowledge and can spend time leveling you up.

Patrick Akil (10:41):
Yeah, absolutely. I mean the people around you are going to define your growth curve as much as you are going to define it, basically. So if the people around you are really people who you look up to and take you under their wing and for example, do pair programming with you and really teach you on the fly, that is the fastest way for you to level up and grow from there. Now, I was really fortunate because I didn't know any of that when I started in that position. I kind of bumbled my way into there, but looking back now, that is really what I appreciate about that time period.

Alex Booker (11:09):
I always have an issue with the word "lucky" or saying anything was "due to luck," and at the same time I totally get it. We look back at our experiences and we think it was so fortunate to be in the right place at the right time, but then imagine you're listening and you're thinking, "Oh, I'm not a very lucky person." How much of your success is in your own control versus luck?

Patrick Akil (11:29):
I think the circumstances that I ended up there might have been lucky, but I very much pushed for it and that was in my control. I went to my manager, I said, "This is what I want. Is there any way for us to do so?" And I got the first option. Now I wasn't happy with the first option, so I went back and I was like, "Listen, this is why it's not working. Is there any other thing that we can do here?" And if he would've said "no," I could've had two choices. I could've been like, "Well, I'm going to stick with option one," or, "I'm going to look outside of the company." But because he said "yes," we went for option two and option two turned out to be way better, andI was in control. I opened up that conversation.

(12:03):
It wasn't comfortable because he was just newly my manager, but I felt it was the most important step and the right step for myself, for my own career path, and I still think you are responsible for your own career path. The people that you meet along the way can be coincidental, but the way you move along your own path, you're in control.

Alex Booker (12:22):
I think oftentimes it's better to feel uncomfortable confronting that reality that basically this wasn't working for you than putting your head in the sand. You're going to be very uncomfortable one way or another because if you end up going down a path that you resent or regrets, that's not a great feeling either. Sometimes you just have to push yourself and it's bad to do it upfront then regret it later.

Patrick Akil (12:42):
Yeah, absolutely. A lot of conversations are not going to be comfortable, but the way they get a little bit more comfortable is if you just have more experience and more practice with them. So instead of avoiding them, just figuring out how to deal with them and experiencing them is going to allow you to grow more and have more of those conversations and get better at them as well, because at the end of the day, you can't go on with your life or even your career path, avoiding the difficult conversations. The difficult conversations are going to allow you to grow. You have to be in an uncomfortable position to grow as well.

Alex Booker (13:13):
Do you ever read a whole book and then you don't exactly remember what you were reading except maybe one or two things stand out and stay with you forever? For me, that was actually a book called Crucial Conversations. The tagline is tools for talking when stakes are high. The one sentence that I always remember is that you need to be 100% direct but also 100% respectful, and I really like that because you should never feel sheepish about advocating for yourself, but at the same time you have to approach it in a way which is tactful and respectful.

Patrick Akil (13:44):
I like people that are humble and honest and critical and direct, and I try to be like that as well. I've heard from people that they appreciate that, that we don't bullshit around when it comes to our feedback, but we still are critical and we keep being objective and we don't let our emotions get kind of out of the way of what is the essence here. I had a conversation in my team where people were just arguing and it was kind of a right or wrong thing and I had to step in and be like, "It doesn't actually matter. What matters is how we operate as a team, how we are effective and who's right or wrong sometimes doesn't really matter."

Alex Booker (14:16):
I think these are all very powerful communication tools. When you're looking for advice about how to get into the industry, oftentimes you hear that yes, you need to be the best coder you can be, but your communication skills are actually going to play a big role in your success, especially when you're a junior and you don't have that many coding skills to trade on. You might be standing out a little bit by being an excellent communicator, but by the way, I remember in school they made us make a resume at a time when nobody had any skills because they were teenagers and everybody put on their things like, "Oh, I can use Word, I can do email," and everybody said like, "I'm an excellent communicator." Everybody puts that on their LinkedIn today, I feel like. But it's not always obvious what that means. It should never be on a team a question of who is right or wrong. You are on the team to serve an objective. It could be to fulfill your products mission or to achieve a metric.

(15:06):
It could be to do right by your customers, and really the thing to align on is like, will this thing we're debating bring us closer to our objective and that's the only lens for which to see it, I think. But it's interesting you mention it because to me that's a really good example of an actual thing that makes you a good communicator and a good teammate.

Patrick Akil (15:22):
Yeah, communication is kind of a big thing and to me it was really vague. So I like how my friend Summi Gupta called it, he's like, "Communication. You can break down in different conversations that you're going to have and the conversation with your manager is one of them." And when you actually have a leadership position, the conversations with the teams are going to be another variant of that. A job interview is a conversation you're going to have and throughout your journey you can pinpoint those conversations. You can also pinpoint the conversations you're already good at and the ones you're less good at you can focus on and really hone that conversation and get better at that because the more you grow, the more variance of conversations you're going to have. So focusing on those and getting better at those is going to allow you to grow at a non-technical side, which is also very important.

Alex Booker (16:06):
Patrick and I are going to be right back in just a second, but first Jan, the producer and I had a quick favorite to ask of you.

Jan Arsenovic (16:13):
Hello. Word of mouth is still the best way to support a podcast that you like. So if you're enjoying the show, please share it with someone. You know what, this is the episode number 100 and we want to get to do at least 100 more. So if you like what we're doing and you want to make sure we get to keep doing it, show the podcast to someone who is also at the beginning of their coding career. You can talk about the show on LinkedIn, on Facebook, on Twitter, on Mastodon, on Discord, or you can tell somebody about it in person. Oh yeah, also subscribe. We have a new show every week and we interview both industry experts and recently hired new developers. Next week on the show, Trecia Kat from South Africa will tell us how she started with coding.

Trecia Kat (17:05):
It's something that I've stumbled into a little bit late in my life. My father has always thought that would be great for me to start getting a career in IT, but I've always had passion about something else. So yeah, it's something I never really intended to do. Passion does not equal ability to do a great job. I initially wanted to be a pharmacist or someone who works in medicine basically, and I didn't get that because I'm terrible at math. If I had a great teacher, someone who was passionate teaching the subject, I promise you, maybe I would have not been here today. Maybe I would be at the hospital doing something.

Jan Arsenovic (17:46):
That's Trecia and she is next week on the Scrimba Podcast and now we're back to the interview with Patrick.

Alex Booker (17:53):
I love how the conversation has come to this point so quickly because in your bio and with the content you're creating, you explained that you talk about mental health and life, in other words, the things beyond coding, which is also the name of your podcast and I'm excited to learn a bit more about that afterwards. But yeah, mental health, life, communication, a growth mindset, why do you think these things are important to talk about?

Patrick Akil (18:21):
That's a huge question. Let's take mental health for example. I spoke to Stacey Cashmore on my podcast recently and I love the way she put it. She says, "Everyone has mental health, everyone, but they become mental health issues when you don't take care of your mental health and that can vary from person to person." I know I am very critical about other people. I am even more critical about myself and one of the things I'm really bad at is first of all taking a break, but also acknowledging the things that I do well, acknowledging the things that I have done well in the past, celebrating the small victories and being aware of that has allowed me to do so to accommodate for that. And that just eases my mental health more and more.

(18:59):
When I take on too much workload, I have to be like, "Okay, we are doing the right things. We are accomplishing things." That helps me and eases my mind to a state where it's healthy and if you don't give it the proper attention, it could be a different example for other people it becomes a problem. Being aware of that is step number one because then you can accommodate for your own mental health and I think topics like that that are rampant in our industry are really important to discuss about, to have that conversation with, to give perspective for others to learn, and that is kind of what the podcast is about as well.

Alex Booker (19:30):
That's such a fantastic point. Which guest was that again? So we can link it high and proud in the show notes. That sounds like a great interview.

Patrick Akil (19:36):
Stacey Cashmore.

Alex Booker (19:37):
It's interesting the way you describe it, like you said that you're harsh on others, but even harsher on yourself. I feel like it's almost the curse of ambition. You know want to be always pushing your comfort zone. You always want to be demanding more of yourself. On one hand, this is the mindset that has made you successful so far in life, but on the other, it can lead to things like burnouts and as you described, they can be quite taxing on your own mental health. How do you generally balance that? I know it's something that people listening sometimes struggle with because, of course, they might be on this path of learning to code or getting a developer job and it's something where you really have to sustain yourself for a while and just not quit, right? Because if you quit you definitely won't be successful and you're at risk of quitting when you start to burn outs or you find you're taxing on your mental health. How'd you sort of balance these things today?

Patrick Akil (20:24):
I think one of the biggest things that comes to mind is I have to let go of the notion of perfection. Everyone has to let go of this notion of perfection. It's something that is unreachable and especially in the software engineering industry, when you write your code, no one is going to tell you this is perfect. You're not even going to think yourself that this is perfect. So aiming for perfection and perfectionism in there is something we need to let go of.

(20:47):
What we should focus on instead is progress and be better every single time, incrementally. It doesn't matter where you start. You will improve as long as you keep on this path, as long as you keep honing your skills, you will get better. You might not notice it now or tomorrow, but in a week from now, in a month from now, time may vary but you will get better. Even if you don't notice it yourself, your peers will get better. They will give you the feedback that you did get better and I think that is a very important thing to let go of. Don't try to be perfect but focus on your progress. Me and my personal space, I have people that know when I take too much on my plate and that also keep me in line, which helps a lot and it's kind of a cop out answer because I'm not really doing it myself. It's the environment that I am in, but the relationships that I have built up have allowed the people to feel comfortable about saying things that kind of keep me on the right path.

(21:38):
If I do three conferences back to back and podcasts and I still have a consultancy job, they're like, "Ah, isn't this too much? We haven't spoken to you," or, "You're working in the evenings." Those words just go over and over in my head and I'm like, "They're right." So we have to put on the breaks because you don't want someone to burn themselves out in that way.

Alex Booker (21:55):
You also dictate your environment to some extent, and I think that's a powerful idea, sort of creating a system that does not rely on motivation. Motivation comes and goes, but your friends, your family, your partner, whatever, will always be there to sort of objectively support you. I like the way you put it too that you just made them feel comfortable communicating this to you. The other elements of mental health and balance that I wanted to ask you about was comparing yourself to other people. I think, first of all, great advice to let go of this notion of perfection because perfect is the enemy of done, it just can't be a attained. Everything's a little bit of a trade-off. But then when you're an ambitious person, and I think everybody learning to code is ambitious by the way. I think it's a huge feat and I think you've got a very lofty worthwhile goal at the end of it. It's the very hard not to compare yourself to other people and think that maybe they're ahead of you. Is that something you've experienced?

Patrick Akil (22:46):
Yeah, absolutely. Especially early on I was like, these people are on a level that I will never get at and I still know these people and they are still on a level that I will never get at. But the difference is that back then I thought I needed to get to that level and now I realize I am on my own path and through the feedback that I've gotten, I know what they appreciate of me and it is not necessarily technical excellence or technical superiority because you don't have to be the best on a technical front. You don't have to be the best on how we do things. You can focus on what we do or why we do it or in the way we're doing it or with the team that we're doing it.

(23:21):
There's so many facets in the space that we're at that you can contribute to that and you don't have to be the best in any of that, but they are the tools that you bring to a team and they are the tools that you bring along your journey that help the end result of the product that you're building be better because of that.

(23:37):
And once I realized, I don't have to be the best in everything, it made it so much easier. It put my mind at ease. I could focus on what I love doing, what I am good at that I can be even better at. And I found a way to contribute to a team on a non-technical front, which is also needed. And I think if you figure out what you like, doesn't even have to be, especially what you like, you can also figure out what you don't like, but those are the tools that you bring along with you and they don't always have to be technical.

Alex Booker (24:04):
If you had to assign a percentage, what is more important for your success as a developer, coding or the other biz soft skills, for example, communication skills, collaboration?

Patrick Akil (24:17):
For me, it's the other side. If it's a 50-50 split, my contribution lies more in the non-technical side of things. Maybe it's because I started later in my career path with the technical side, but I know where my limitations are. They are consciously there because I like to be good at 70% of a thing. This is just an arbitrary percentage, but when I really need that last 30%, I know the people that I need to go to or to bring in to solve this problem and that is a skill in and of its own. But that last percentage, that last 30%, I think I'm going to spend way more time getting to that, than the initial 70%, bringing in the right amount of people and focusing on what I am good at hopefully. Initially I never thought I would be good at this, but I think communication and the soft skills side of things, that is my forte. That is what I bring to a team and I really focus on team effectiveness instead of technical excellence.

Alex Booker (25:06):
You've probably heard this thing I think is Pareto principle where the last 20% takes 80% of the effort and time.

Patrick Akil (25:15):
Yeah, I agree with that. I mean I don't know in which context I saw it, but yeah. If you want to reach that level of perfection, even though you're never going to reach it, that's going to take a lot of time. So I think that is an accurate estimate. I haven't tested it myself.

Alex Booker (25:28):
But at the same time, the reason I say it is because when I put it like that, it sounds like getting 80% of the way there is only 20% of the task or the job and it's a bit of a biased way of looking at it because, well, let me introduce people to this idea of the nine Belbin team roles. It's a really, really interesting just webpage with nine sort of profiles of different contributors. So one of the roles is team worker, which is described as someone who helps the team gel using their versatility to identify the work required and completes it on behalf of the team. And so it says their strengths, they are cooperative, perceptive, diplomatic, they listen and avert friction, but then they also have some allowable weaknesses. So they're allowed to be indecisive and they are allowed to tend to avoid confrontation, for example.

(26:13):
There's another role which I can't find quickly, but it's something along the lines of a starter. Someone who doesn't need a detailed plan, they will explore it, they will investigate it, they will shape it initially. They don't mind operating with that uncertainty, but then don't be surprised to find that they're really bad at finishing and polishing stuff. And one of their allowable weaknesses is that they might fail to consider all the details because they're just trying to erect this project quite quickly.

(26:37):
And then what you also have as part of these team roles is the complete finisher and there are more, and people can check this out. The complete finished is most effective at the end of tasks to polish and scrutinize the work for errors, subjecting it to the highest standards of quality control apparently. And the strengths are painstaking, conscientious, anxious, they search out errors, they polish and perfect.

(26:59):
But then I've seen this, by the way, complete finishes who this is an allowable weakness. They just never [inaudible 00:27:05] the door because it's like never finished. They're looking for what you described, Patrick, like this impossible to find perfection. Anyway, what I'm getting at, and I think building on your point is teams come together to make up for each other's weaknesses and you need people who have certain attributes to get the projects started. You need people who sets and attributes to finish the project and everything in between and more likely a broader collaboration on things like making it a good product for the users, marketing and selling it, all these kind of things. What do you think of this idea?

Patrick Akil (27:34):
It's interesting because when you were going over those roles and responsibilities, or at least the characterization of that, I was thinking about in the team that I am in now, it's quite a big team. We have about seven people in there, me included. And for example, the finisher. I immediately thought, "Ah, I could see that in that person at that moment." If I were to think about myself, I focus on team effectiveness, whatever that may be. At the beginning of a sprint, we focus on a goal, we align on a goal and I want to make sure that everyone contributes to that goal. If that is not the case, I will either talk to them and make sure we're aligned or it's going to be a retro point and I'll make sure we're aligned on the next sprint.

(28:11):
But for me it's very important that if I am in a team, the team is also effective because if the team is not effective, I can focus on personal effectiveness, but I know I'm not going to be as motivated. I get really motivated when a team is effective and I am contributing to that effectiveness. Don't get me wrong, but when a team is ineffective and me myself, I'm still effective, that still kind of demotivates me in a way. The team needs to be effective and I'm contributing to the team. So if the team is not effective, that's one of my responsibilities to make sure that the team is effective. That is 100% like engraved in my brain and I don't know how it got there. That's the weird part.

Alex Booker (28:46):
Hey, I mean we're all individuals and none of us really know why we are the way we are, but your point is playing to your strengths and also being able to appreciate other peoples'. I think that's so important. What else is key to effective teamwork in your opinion? What are some of the key things you look out for and try and make sure operating smoothly?

Patrick Akil (29:04):
Whenever a team comes together, the expectation is there to function as a team, but that's not how it works out initially. You come together and you're a bunch of individuals. Sure you have the title of a team, but you're still individuals. And one of the ways you can get to that team level is to get to know each other, not even on a technical level, but maybe even on a personal level. You need to know what someone is already adequate at or what they want to learn because that to me is way more important than what you're already good at. I want to know what you're good at. I want to know what you want to learn so we can accommodate for that. And I want to know you on a personal level because knowing each other on a personal level makes the bridge to ask for help a lot smaller. And if you ask for help, all of a sudden you're collaborating, you're sharing your knowledge, you're sharing a mental model that is actually reflected in the code base and you're working together as a team.

(29:51):
But before we can kind of remove those hurdles, we have to know each other on a more personal level as well. And that takes time. It takes time, it takes experience, it's going to have friction, it's going to have confrontation. Don't avoid those, learn from those and grow as a team.

Alex Booker (30:03):
Why does knowing someone more personally make it easier to ask them for help?

Patrick Akil (30:08):
I think when we come together, we don't know the other person. There's kind of a hurdle in, for example, asking for help, but when you're stuck for five or 10 minutes, the best thing you can do is ask for help because it's way more effective to actually move on to a next topic and to figure out what you have to. And if you're stuck, the only way to get out of that is to either figure everything out yourself, spend four or five hours figuring it out, for example. But when you do know a person knows your answer, just ask for help. And the gap is there if you don't know each other. If you and me are in a team, Alex, I mean we've talked a bit on the podcast, so I know you and I like you, so I'm a bit more comfortable in asking for help. But if I didn't know you, would I feel comfortable enough in asking for help or is that going to make me look like, I don't know. Maybe that's what's in people's minds.

(30:51):
I don't know what it is, but it's just when you don't know someone, you're more opposed to asking for help. That's at least my experience. I don't know if that really answers your question.

Alex Booker (30:59):
No, 100%. I think it comes down to trust. Can you trust this person to not judge you harshly for being stuck on something, for example, that's so important.

Patrick Akil (31:09):
It's our own insecurities, right? Relationships take time to build, relationships with your parents, with your siblings, with your partner. Like relationships take time. Only then can you trust them and it is the exact same thing in a team. We need to build on those relationships, then we can trust each other. Sure, trust comes out of the box, but you can hone that trust even more and then you can collaborate. Those insecurities will wash away and you can form that team that you need to be.

Alex Booker (31:34):
I guess the flip side of this is work-life balance. Some people would say that maybe don't get to know your coworkers so well because... Keep your work and your personal life separate, and I think that's fair and I think you'll probably agree. But then there is this idea that when you bring your whole self to work and you know you're vulnerable a little bit in talking about your personal life and your issues, it also helps your team to trust you and it also helps them to understand your circumstances.

(32:02):
For example, maybe you are underperforming in some way for a period, but they also understand that you've just had something happen in your personal life, like a health issue for example, or a bereavement or maybe for example, your neurodivergence for example, you might have ADHD and that does not hinder your ability to contribute at all. You might just go about it in a different way and just allowing people to sort of understand you a bit better can help them empathize better with your situation. Of course, that's on them as well, but you're at least giving them a chance.

Patrick Akil (32:33):
It's a hard thing to do, bring your full self to your work. First of all, for me, I'm going to speak for personal experience. It fulfills me more that I can be my true self, that I can bring all of my virtues, all of my values from outside of work, also into work. And I think that reflects in the relationships that I have with my colleagues. Now, sure, it's a danger because my colleagues are also going to become my friends and I'm going to have a certain level of empathy, which is beneficial, but in certain conflicts it might not be beneficial. I haven't really run into that situation, so it's kind of hard to argue the other side. But for me it really helps with collaboration. And at the end of the day, when I want my team to be effective, I'm focusing on collaboration. We can empathize with each other if we know more about each other and we need to empathize to collaborate better.

Alex Booker (33:17):
I can't stop thinking about what you said earlier when you said you were critical of others, but you were even more critical of yourself. It does sound like a lot like ambition. Where does this come from?

Patrick Akil (33:27):
I think it might be ambition. That's the hard part. I try to be the best version of me, but also as fast as possible I guess, which is really hard. And when I see others, and I first of all try to appreciate what they're doing well, but I also want to allow them to be better or be a better version of themselves, I guess, in the feedback that I give. I try to be as objective as possible, try to be as honest as possible, but I am direct as a person, so it might come off as critique, but for me it's critique in a good way. And I do that to myself as well, which is probably why I do it to others, but to myself probably the most because I want to be and I want to grow to a better version of me. But that might not be as healthy if I do that too much.

(34:06):
It's a hard thing to balance. And sometimes I need to get a mirror put in front of me and say like what you're saying right now is unhealthy. I can give you an example. I did a conference talk. Was my first conference talk. Was internally. We had a Xebia XKE TED style, which is basically a TED style talk. It's five minutes and you talk about something personal to you. So I talked about being comfortable in uncomfortable situations. Now I did the whole five minute talk. I got applauded and afterwards people came up to me not on stage, but after with the drinks. And it's a great talk, great conversation. People I didn't know yet, and the only thing in my head was, I compared myself to the other talks and I thought, "Oh, the content, the essence of my talk could have been better.

(34:44):
So every time someone came up to me and gave me a compliment, I said, "The essence of my talk could have been better." And then someone called me out. They were like, "Why are you saying that? Why don't you just accept this compliment? You did a really good thing. You should be proud of this." And I was like, "Yeah, they just caught me being too harsh on myself or too critical of myself." And I was like, "Yeah, that's true." Sometimes I do it, I'm not mindful of it, but when someone calls me out on that, I really appreciate that. But the people need to know me before they can do that. And that's the hard thing.

Alex Booker (35:11):
Giving and receiving feedback is a really fine skill, in my opinion. Delivering tactful feedback at the right time with the right contacts and the right balance whilst also being direct. And I totally take your point from before that when you start to build personal relationships with coworkers, being so direct in some ways can be easier because you trust them and you can approach it in more of a friendly bantery kind of way instead of doing a performance review or something super serious. But then obviously if there's actually a really big problem, something that's really crucial but difficult to talk about, that could maybe come at the cost of the personal relationship. And that's a difficult one.

(35:47):
But what I wanted to ask you about specifically is receiving feedback. It's sometimes hard not to take it personally or it's hard not to take that criticism as an attack or something. Maybe you've worked on a project and you're just actually super proud of some bits because you've really pushed yourself. But there are just a couple of things that could be better. At the same time, by the way, I wanted to point out, if you're walking around the streets and your zipper is undone, you'd probably appreciate it if someone told you that it was undone. Sometimes not getting the feedback is more dangerous because you'll go down a path what doesn't serve anybody, including yourself, and might even be a little bit embarrassing.

Patrick Akil (36:23):
I mean, you made me reflect on this, but one of the things I hold a lot of value in was regular feedback sessions. And I had really had that with my manager joining this company, Xebia that I'm at now, where we talked every two weeks. Every two weeks something was scheduled and if I didn't have anything to talk about, we wouldn't talk about anything. But it was scheduled there. The position was there, the agenda was already blocked. And I actually made use of it probably every single session. I talked about conversations that I had or doubts that I had in my mind or potential regrets. And we went over it. We went over and over and over it, and I think I got better because of that. They allowed me to ask questions to myself. They asked questions. They allowed me to reflect and get better because of that.

(37:01):
And through that I also did that with my colleagues. I can give you an example. We would have a difficult conversation. I would come out of that and I would wonder how I came across to other people. So I would take one of my colleagues, which I trusted, and I would ask them, this was really hard for me. I tried to be objective, but I did give critique like, "How did I come across?" And they could have been like, "Oh, it felt a bit emotional," or "Off. I think you handled it well," or "Maybe you should have thought of this." And through that, I really learned what I'm good at. I really learned about how I come across, how I influence. And with that, I think my skills of communication just got better because of that.

(37:37):
The feedback that I got from there and that opportunity and those instances allowed me to grow. And communication is also an interesting skill because that is a life skill. You're going to take that with you in whichever role you're going to do. So getting feedback on how you come across and how you communicate is going to add value in any essence in your life.

Alex Booker (37:56):
When you are getting your first job as a developer, there's like the interview phase where you're meeting these teammates for the first time and maybe your manager, and then there's obviously the period where you're on the team, and that's a super difficult time, super challenging. I can only hope that you've found somewhere that is supportive, and I wish that for everybody. I think that's so crucial. But regarding these ideas around communication, presenting yourself, soliciting feedback, and bringing your whole self to the table, how can you apply these things during the interview process without going over the top?

Patrick Akil (38:27):
I was really bad at interviewing, coming off a university or even switching from a first to a second job. I interviewed a lot because I was really bad at it. And again, I can read a lot about interviewing, but for me, the best way to experience and to grow is to actually experience those interviews. So I interviewed, then I interviewed, then I interviewed, and I must have said the tell me about yourself 100 times before it got to a point where I was like, "Okay, this is really solid now and I think this should be good enough and I can focus on other things of the interview aspects." And with that, I learned that people really appreciate when you ask questions. Ask questions about the team, ask questions about the organization, ask questions about the career path of your manager, how they got to that position.

(39:09):
They would love to tell you about it. And it forms a bond immediately on the interview spot as well. When they say, "Oh, do you still have any questions?" Usually my first question is, "Okay, I know we have five minutes left. How much time do we actually have left because I have a lot of questions." That's a good one. And then they'll be like, "Oh, we can do a little bit longer," and then I'll just fire over and over question and question. And each and every question I come up with during the interview and also with the preparation I had before then I would just fire off one by one and see how they would react based on the question and just keep on asking and learning from there. Because what we often forget is that the interview is a win-win or that it should be a win-win. When you get a job, it's a win for the company and it's a win for you because you have a job, but it shouldn't be a win-lose.

(39:54):
That doesn't sound that great. That's what we often forget. And because of that, we think, "Oh, we should be lucky enough from the interviewer position to have that job at the company." But the company is also lucky to enough to have you as a developer on that team. So if you don't feel like it's a win-win, then it might not be the organization for you. So I would just say interview over and over and over again until you get more comfortable doing those interviews. And at some point you will land a job. You just will.

Alex Booker (40:19):
Totally. And I think we might have stumbled upon a bit of a mindset tip here. I'll tell a little story of my own and it's directly related to the Scrimba Podcast and one of my previous guests because I was very fortunate to interview Scott Hanselman on the podcast. Very, very busy guy, works in Microsoft, big influence on me and a lot of people in the tech community. And we finished the episode and I'm so proud of it.

(40:41):
I think the conversation went brilliantly. I don't have a recording to prove this, but at one point just kind of jokingly, he said, "Alex is a great engineer," or something, and I was like, "Oh, I've got that on recording. I feel amazing about that." And I say, "Scott, thank you so much for your time. I'm just going to hit stop that." I hover my cursor over to the button that normally says "stop." And it says "record." And I'm like, "Oh my God, I'm so sorry. I can't believe like this faux pas." And I'm thinking it was just due to me being a little bit nervous maybe to interview someone I look up to so much.

(41:11):
And yeah, Scott said something that resonated with me and I think we can maybe makes his advice and yours head to come across a mindset set. But he said, "Just because it wasn't recorded doesn't mean there wasn't value in the conversation. It doesn't mean that we didn't have a good time, that we didn't learn from each other." And I wonder if applying that kind of mindset to the interview is really helpful because if you approach it more like a conversation and a dialogue, then that kind of ticks off all the boxes per your advice., Patrick, sort of turning it into a conversation, looking for that win-win, having questions about the company, and it also, I think, removes a bit of the pressure.

(41:45):
The only success of an interview is not a yes. Another type of success could be that you learn something. It could be that you refine your answer to a question, like, "Tell me about yourself." People always say like, at the beginning they're like, "Oh, well I grew up in this village and I had free pets." And eventually you learn what they're actually looking for, which is a bit of an elevator pitch about your value and your journey so far. What do you think?

Patrick Akil (42:07):
I love that right? There is value in holding those conversations, even though you don't get the end result. Sometimes you have a huge goal and a milestone in your head. For example, I wanted to have 1,000 subscribers on YouTube because that was just a huge number in my head, and then I hit it and nothing changed. But I had so much fun along the way getting to that number, and that was the value, that was the essence. That was what I learned. And reaching that milestone was just a tick in a box that didn't really do anything at the end of the day, crossing that milestone didn't do a lot. Sure I could celebrate it, but the value was the journey along to get to that milestone, to actually reach it and achieve it. And I feel like the journey to your first job or to your developer job is the same, right?

(42:47):
That journey is going to have the value and finally landing the job, sure that's the cherry on top because you finally achieved it, but the value is in the journey. As long as we are mindful of that, then rejections are not going to be as harsh, I feel like. And they're fine and they're just a step in the right direction to get to where you're actually supposed to go.

Alex Booker (43:05):
Goals are interesting like that because we only encompass some way to align something to shoot for. Goals also, delay your happiness because whenever you set a goal, there's like this implicit idea of it, "When I reach that goal, I'll be happy." But when you got 1,000 YouTube subscribers, congrats, by the way, your breakfast tasted the same. It was just another day and probably what's the next thing you did? Set a new kind of goal. It's a really tricky one because I also acknowledged that looking for a job is very serious and these are great mindsets to have. I love reading about stoicism, growth mindset, all the things we spoke about today. What I recognize is the challenge is applying those mindsets during stressful times. Maybe you've got the clock ticking regarding savings or a commitment to get a job in a certain window of time. It's really hard not to let rejections chip away at you.

(43:57):
But the truth is, I think we've both been there. We've both been in uncomfortable situations, and it's because of that that we've managed to get jobs in tech or whatever else we happen to set our goals on. And actually now I think about it sounds a lot like what you presented on in that talk, right, being comfortable in uncomfortable situations.

Patrick Akil (44:15):
You make me reflect on my own career path. And one of the things I didn't mention yet is, when I exited Blokker Holding, I was looking for a software engineering position because that was what I really set my eyes on, that was what I wanted to do more of. So I got in contact with the recruiter and they mentioned this company and everything was beautiful, lots of knowledge sharing and quality without compromise. Really strong values that I stood behind. And then they said, "Oh, the company's in Hilversum." And then I was like, "Oh, okay. I worked with a company in Hilversum. That's Xebia. Like that's the only company that I know is really good and strong in tech and is in Hillfason. So I was like, "Oh, that's the company."

Alex Booker (44:49):
Hilversum is a town on the outskirts of Amsterdam, right?

Patrick Akil (44:52):
Yeah. Sorry about that. Thanks for the addition. That was the only company that I knew that was in Hillfason. So I was like, "Okay. I never applied there because I didn't think I was good enough." But the recruiter said, "No, no, no, you are good enough. We're going to put your resume forward there and we're going to see if we can get an initial conversation." And when I landed that initial conversation, it was really hard for me because I still had that notion of, "What am I doing here? I've worked with these people, I am nowhere near as good as what they are and what I've worked with. What am I doing here?" And then throughout the first conversation, they really like me. Then I got a take home assessment, should have taken about eight hours. I spent about 10 to 12 on it and I still didn't finish it.

(45:29):
I was like, "Man, this is ridiculous. I'm just going to submit this. If this is not enough for them, that's fine. I know then that I'm not a good enough yet. That's fine." But they said, "No, what you delivered was fine. It was good." And we had the discussion about what I delivered and the trade-offs that I made. And I made some decisions here and there, which I wasn't comfortable with, but I vocalized it and they appreciated it that I took risk in an assessment as well. And I landed a job. There was another round meeting the team, but I eventually landed the job. And what was really interesting when I landed the job, I could see the internal communication about my job application process.

Alex Booker (46:06):
Oh, you're kidding. So you could be a fly on the wall and see it all?

Patrick Akil (46:06):
Exactly. And the reason why I got the first conversation in the first place, the reason why I got to the table at the first place was someone put in a good word for me. Someone I had worked with in the past said, "Patrick, on paper does not have the work experience we usually require." I had not even a year worth of work experience when it came to actual software development, but they said everything he brings to the table next to that is valuable. So have an initial conversation with him and you won't regret it. And man, I went back to that person. I said, "Listen, I wouldn't be here if it wasn't for you." So your network is really going to vouch for you if you do the right thing. If you are yourself and if you allow people to grow close to you, it will pay itself in the future as well in returns.

(46:47):
And it did. I'm so fortunate to be here, but it's also because I met these people along the way that apparently I left an impression to them and apparently it was good enough for them to vouch for me. It was just amazing to see that internal communication afterwards. I'm really happy they did that. They took the extra step, right? They didn't have to do that, but the fact that they did makes it so I am here now and if I wasn't here, I wouldn't have started the podcast. I wouldn't have grown as much as I have. So that was just a small step for them and it's been huge for me. So I really appreciate that.

Alex Booker (47:15):
Patrick, that would ordinarily be just an incredible note to end on. I love that anecdote so much and it's so inspiring. If anybody doesn't want to hear about podcasting, because I did want to spend a few minutes at the end of this interview talking a little bit about podcasting and talking in public with you. Thank you so much for listening. Every week I interview a newly hired developer, so you can look forward to that next week. Don't forget to subscribe and check out the archive. But Patrick, while I still have you, I really want to learn a bit more as a fellow podcaster about the Beyond Coding Podcast. What was the kind of catalyst and motivation behind that podcast and yeah, tell me a bit about your guests and how it's been going over the last year or so.

Patrick Akil (47:54):
The Beyond Coding Podcast, we actually do a lot with regards to knowledge sharing already, internally as well as externally. So a nice edition, someone thought was, let's do a podcast about anything. And this person was in marketing and they said, "I will facilitate everything that you need. It's going to be your vision, whatever you want." And that sounded like music to my ears. I had already been listening to podcasts for the last 10 years, always envisioned myself having a seat at the table, being part of the conversation and not leaving any question unanswered.

(48:24):
So I immediately jumped on that. I was like, "Pick me, me, me, this guy." So I reached out to him. I was like, "I 100% want to do this. This is my vision. I don't want to talk about stuff that is too technical because I think we have a lot of podcasts, a lot of content on there already on YouTube and even more blog posts. I want to talk about everything around coding, working together, leadership and the skills that are involved there. Coaching mental health, life skills, communication, anything you can think of that is still involved in creating software. But it is more related to people and humans because in the end we create the software."

(48:57):
So with that in mind, we started. We literally said, "Okay, let's do a brainstorm of episode names." It was almost called Suits in Hoodies. And we have a promo image of that. Imagine me, like 50% suit and 50% hoodie on the other side. That was going to be one of the options. But we eventually went with Beyond Coding to do justice to the vision that I had. And I didn't want to compromise on episode cadence. I said, "We're going to air weekly. I don't want to compromise on biweekly or anything. If we're going to do this, we're going to do it right."

(49:25):
I also wanted to do it in English because I'm not a native English speaker. I'm natively Dutch. I grew up in the Netherlands, but I wanted international reach. I wanted to have a diverse group of guests, as diverse as I could. And I also wanted to bring it out to the world, not just to the Netherlands. And nothing wrong with that, but still I had huge dreams. Also nothing wrong with that. So with that in mind, we recorded the first five episodes. I asked colleagues, people I admired, people I looked up to be my guest on this podcast, to come along in this journey with me. And the first few episodes were really bad, especially if I look back now. They were, I wouldn't say horrible because I was really proud of them, but they were not as good as the later ones. And I just kept on growing. I kept on learning and I really feel honored to be able to do this and it's been a blast doing this. Yeah, I wouldn't trade it for the world.

Alex Booker (50:12):
And man, I just love your setup over there. If any video is curious, check out the YouTube recordings. Patrick has a physical studio totally giving me something to shoot for and inspire to hear on the Scrimba Podcast. It's really cool and we've had some similar guests, like you've had Anna MacDougal on and so have I and Kevin Powell. At some point it just becomes like Pokemon. You got to collect them all and just share guests and interview everybody.

Patrick Akil (50:37):
Exactly.

Alex Booker (50:39):
You found some gems in there as well. People you might not have heard of, but have just some wicked advice to share, like the guests you spoke about, mental health, you mentioned earlier. Well, Patrick, man, thank you so much for joining me on the Scrimba Podcast. It's been a pleasure, man.

Patrick Akil (50:50):
Thank you so much, Alex. I really enjoyed our conversation. Being in the guest spot, I'm not normally on this side of the table, but it's been a true blast. Thank you for having me.

Jan Arsenovic (51:00):
That was the Scrimba podcast, episode 100. If you're made it this far, subscribe and if you're feeling extra supportive, leave us a rating or a review on your podcast platform of choice. The show is hosted by Alex Booker. You can find his Twitter handle in the show notes. If you're posting about the podcast on Twitter, make sure to mention him because he does read it all and he also replies to it. Check out the show notes for all the ways you can connect with Patrick and make sure to check out his podcast, Beyond Coding. I'm your producer Jan, and we will be back next Tuesday. See you.