Tanaka headshot

Tanaka Mutakwa

VP of Engineering Names & Faces

Tanaka Mutakwa is a technology leader who is driven to help software engineers have fulfilling careers. He has a passion for technology, leadership, and building high performing teams.


In this episode, we talk about management and mentorship with Tanaka Mutakwa, VP of engineering at Names & Faces. Tanaka talks about the skills he looks for while hiring early career developers, what makes a good manager and mentor, and how one even goes about finding a mentor.

Show Notes


Printer Friendly Version

[00:00:05] SY: Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host, Saron. And today, we’re talking about management and mentorship with Tanaka Mutakwa, VP of Engineering at Names & Faces.

[00:00:20] TM: I’ve got a firsthand example of how impactful a mentor can be in your career. And it’s something I won’t forget now, like over 10 years into my career. I still remember just how useful that phase was.

[00:00:32] SY: If you have a question for Tanaka after listening, don’t miss The Ask Me Anything Session he’s hosting on the CodeNewbie Community Forum. Just head to community.codenewbie.org and you’ll find his thread on our home page and he’ll answer you directly in the comments. That’s community.codenewbie.org. In this episode, Tanaka talks about the skills he looks for while hiring early career developers, what makes a good manager and mentor, and how one even goes about finding a mentor after this.


[00:01:11] SY: Thank you so much for being here.

[00:01:12] TM: Thank you. Thanks for having me.

[00:01:14] SY: So tell us about how you got interested in code.

[00:01:17] TM: When I was in about grade three in primary school, which is about eight years old, our primary school got a set of computers and created a lab. There were about four to six computers in there. That was the first set of computers that the school had ever got. And they asked parents at the school if they were interested in enrolling their children for afternoon computer lessons. And for some reason, which I don’t know, my parents decided to enroll me, perhaps so that I’m not mischievous at home. And I started attending those computer classes. And we didn’t do anything complicated. I remember one particular program was like a typing tutor program where you had to like try to type in like a sentence in the fastest time and you’d have the record and everything. But as a result of being exposed to computing that early, later on as the school got more computers and computing became more common at schools across Zimbabwe, where I studied my primary school and high school, I was always good at it and better than most other students who then have got exposed to it later. Later on in my high school career, I started doing actual computer science. So actual coding. I didn’t get exposed to coding when I started doing computer science. And as a result, I gained because I had been exposed to computing and machines earlier. I was great at the computer science side of it, and I really got some good interest in it and that then obviously took me to studying it at university and everything, but the roots really come back to that small computer lab, which not everyone had the opportunity to go through to that. And my parents decided it would be probably useful for me to start doing computer lessons that early on.

[00:02:58] SY: Yeah, that was really great of them. So tell me how you got to VP of engineering today. What was your career trajectory like?

[00:03:06] TM: So I mentioned that I then went to the University of Cape Town for computer science. And after that, finishing that degree, I started working as a software engineer in Cape Town, and I worked at a company. The first company I worked at was an investment management company and I was a full stack engineer on the web team. And there I was a graduate engineer and progressed from graduate engineer to a mid-level engineer in that company. I worked there for four years before moving on to a FinTech startup called Prodigy Finance, where I then worked again for another four and a half years. But what happened is at Prodigy Finance, I was one of the early engineers. So I was like the fourth engineer at that company. And in the four and a half years I was there, the team or the whole company actually grew to over 200 people and the technology team had about 80 people in it. And later on in my journey at that company, because the team was growing so much and they needed more people to step into leadership roles or management roles, they were looking for engineering managers and I applied for the role and I got selected. I was always interested in leadership. I’d been a full-stack programmer at that point for about six and a half years in my career. And I thought I would try out the leadership side of things, the technology leadership side of things. And also because I had been at the company for a long time, I had enough domain knowledge to help people understand our systems at that company. I had helped, mentored new engineers who I’ve joined in that growth journey and it just felt like a natural progression for me to try out. So that’s how I sort of stepped into technology leadership. And I started managing five people while working along with them in a team. And my tech leadership space at that company was about a year and a half before I got approached by another startup that had just got funding and was looking for someone to run their technology team and help engineers grow their careers and manage them and ensure the tech team was delivering. That’s why they were looking for a VP of engineering. The company is called Names & Faces. And about just under two years ago, I started there working as a VP of engineering and I’m still there to this day.

[00:05:26] SY: So it sounds like FinTech was a big part of your career. Is that something that you were always interested in or did you just kind of accidentally fall into it?

[00:05:35] TM: I would say I accidentally fell into it. When I was studying at a university, my goal was to work at, I would say, an actual tech company, like either a software consulting house that builds products for different companies or a tech company that’s building its own product. How I ended up at the investment management company was through, in my final year, the university, the investment management company was looking for interns over a six-week period during a vacation. And I applied for that role just to get some experience in what real world work is like and also to make some extra money as a student. And while I was there for that six weeks’ internship, I actually then realized that even these sort of companies that you would think are traditional corporates, like investment management companies, actually do use a lot of technology and actually will not make like computer science graduates just like do basic IT jobs like fixing printers or anything, but you actually get to code and learn. And at the end of that internship, they were very happy with how I performed and were keen to hire me. And I was also very happy with how much I had learned and the sort of mentors I saw where the company that I could learn a lot from and grow from. So that’s how I sort of transitioned into that space and ended up in a financial company doing coding work.

[00:06:54] SY: Yeah.

[00:06:55] TM: And then of course, that ended to the following startup, which again was in FinTech and financial education. So Prodigy Finance was lending money to international students so they can study abroad. And because of the experience I’d had at another financial company, that of course I opt with applying for that role and then getting that role. So it’s not something I planned for when I study, but I think it just sort of shaped up through that internship and got me there.

[00:07:24] SY: What were your expectations if you had any of working in the financial industry and how did that end up being?

[00:07:31] TM: Well, like I said earlier, before the internship, I actually didn’t think there’s much, a lot of the technology or the work that you do was just basic IT where you either like fix a printer or the computer’s not working or we need someone to help us with Microsoft Excel or something. But once I got there, I realized that the whole business is actually backed and powered by tech. So with the investment management company, for example, the website, which the investors actually use to check how the investments are doing, to top up more money so they can invest more or to withdraw their money, it’s actually all coded up by the engineers at the company, and then all the systems that are supporting all those transactions and investments are all also coded up by the engineers at the company. So that I think was the major shift that I realized that actually software plays a big role in any big organization out there, not just FinTech in general. That was like one of the key learnings, but there were also like other interesting learnings. Apart from learning about finance itself, you also learn a lot about regulations and how you would have to build certain features to ensure you meet regulations, even if they’re not like the most exciting set of features, but then because it’s finance, you have to be regulated and. And then also just in terms of the quality of work that you need to do, because when it comes to people’s money, they don’t want to be very buggy, like where maybe you’re showing the wrong amount for the investment today, and then tomorrow you’re fixing it and it breaks again the next day. So also, just more around the quality of the work you do and making sure it’s well tested and correct.

[00:09:21] SY: What were the things that you enjoyed about working in FinTech?

[00:09:25] TM: Yeah. So I think one of the interesting things about coding is the domain you code in, you end up learning a lot about it because to code a feature, you need to understand what its purpose is for and how it actually works and what it does. And by the time I left, I was well-versed on how investments work and how I would want to invest my own money, because I’ve learned so much about it while I was at that company. And then I think for education-based startups or probably finance, what was interesting for me or exciting was also it very much aligned with my life journey, because I had also been like studying as a foreigner. I come from Zimbabwe to study in South Africa and I understood what it meant when like someone is trying to get funding to go and study in another country, and that’s a problem the company was solving. So it really aligned the impact of the company, really aligned with my life and where I’d come from.

[00:10:23] SY: And now you work at Names & Faces. Tell us about what the company does and a little bit more about what it’s like to be a VP there.

[00:10:30] TM: Names & Faces, we build a simple, fast visual employee directory that allows people who are working at companies to figure out who’s who at their company and where do they fit in. There are many use cases of it. A typical example is when someone’s just started at a new company, if their company uses Names & Faces, they'll be able to familiarize themselves with the people who they work with. The usual thing, you arrive at a company, people introduce themselves to you on their first day, and then you come back the next morning and you forgot everyone’s name, but you remember their faces. You can possibly then take out Names & Faces and just check and it will help you learn people’s names. But there’s many other contexts and people who have companies that have multiple different offices, perhaps you come from the New York office and you fly into Cape Town and you don’t really know the people in Cape Town, but you know you’ve got a meeting with Tanaka, you can quickly check on Names & Faces which department is Tanaka and why do I have a meeting with him and what does he actually look like. So that when he does come to the meeting, I can recognize him. So that’s what we do. So basically, we assess the app, our clients buy Names & Faces from us and then we set it up for them and they pay us a monthly or annual fee to have the app in place. And we integrate with multiple HR systems to pull the data because most companies already have their people data in HR systems, but then the HR systems don’t present it in a nice way or don’t even have a mobile app where you can access it. Whereas at Names & Faces, we’ve got a web and mobile platform for you to access your data.

[00:12:06] SY: So you first started out as an intern at a company, you worked your way up, then became a senior engineer then an engineering manager and now a VP of engineering. So you definitely have a really wide perspective on the ins and outs of the team structure and what the different roles are. Can you talk a bit about what it was like going from a senior engineer to an engineering manager?

[00:12:28] TM: That’s interesting. I think like I was fortunate enough. A lot of people end up in the role without enough preparation, which can make it very challenging. So I was fortunate enough to start with the company I was working at, at the time. So Prodigy Finance did prepare future leaders. So we had a leadership training program a year before I actually became an engineering leader, which I took part in. So that sort of prepared you for what does management actually look like, how do you show up as a leader, what are the basics, the fundamentals you need to be needing a set of people. But I also consumed a lot of content. So a lot of books and a lot of podcasts around tech leadership, because it was always a general interest of mine. And I also prepared for it by stepping up for roles that would expose me to leadership that would be quite similar to what I would end up doing if I did become a leader. So I actually then ran the Prodigy Finance internship at some point. So all the way from the start into how are we going to market the internship, running the interviews of the interns. Then once they came in, making sure they settled, they on-boarded and got projects to do and support them throughout that journey. So all those things helped me to land a bit softer when I got into the engineering manager role, because I was sort of prepared for some of the things that I had done them in an earlier space with learning them first of having the title. This is a topic I’m passionate about because I do know a lot of people end up in this role because perhaps they ended up best senior engineer on a team and someone just comes and tells them, “Okay, from tomorrow, you are now the manager because you’re really good and now you have to be the leader.” And what often happens is the roles are very different because you now have other responsibilities that you are not necessarily trained up for or are not have been really good at, which involve people. So now you have to solve conflicts between people. You have to direct the team. You have to have more conversations and build trust with people you actually work with versus when you were the best engineer, perhaps you only have people with technical challenges, and now you have this whole packet of people, things to deal with. And the people ended up having to learn in the role, but it gets frustrating for the people they’re leading because perhaps they are not as good at actually leading as they could be. So I think there’s a whole thing around how I actually got into it is a great way to sort of frame it for how I believe engineering leaders should be prepared by doing some of those things that I mentioned I managed to get before I became an engineering manager.

[00:15:05] SY: And let’s talk about going from engineering manager to VP. Being a VP, something sounds very, very fancy and sounds like such a big job title. What was that jump like for you?

[00:15:15] TM: In many ways, it was quite similar because I moved to a startup. So I didn’t end up in narrating like 400 people, a technology team as VP of engineering or anything. The startup is quite small. So in many ways, it was quite similar to the engineering management role. The big difference is being fully responsible for the whole of engineering. I think that’s the one major difference. Whereas previously I was responsible for a number of people within an engineering team and I actually reported to, well, at the previous company, it was the head of software engineering who served almost the same role I’m serving across there. So I think that’s the major change is like to sort of then see my scope as being more than just I’m managing the set of people to I’m responsible for the engineering team and its performance and its delivery and also helping the people grow their careers and also have a bigger interest in the whole company as a whole, like where is our product going and everything. I think it’s just a wider scope, but sometimes I think these titles differ depending on the company stage and you can have the same title, but then executing different sorts of roles or working differently depending on where your company is and/or what state it is.


[00:16:55] SY: So what are the core skills that you found that make some of the best developers on your team? Especially junior developers, people who are just getting started in the tech industry, what makes them the best developers?

[00:17:07] TM: Well, junior developers, the key things are someone who’s keen to learn the software engineering or software development fundamentals and master those. So less focus on, “Oh, I just want to learn this programming language and make things work,” but more things around, “How can I write clean code that is maintainable in the future?” Code is read more than it’s actually written. So being able to write in code that’s readable is useful. How can I write testable code or I can actually test my code? How can I take ownership? So people with ownership, like if I’m writing code, it’s my responsibility to ensure it gets all the way to production and it gets there and it’s working fine. So people have ownership and responsibility. People who are well-communicated. So team players willing to work well with a team, not just work by themselves in silos. And the first thing that came to mind when you ask the question of someone for a junior developer, in particular, someone who’s very curious and keen to learn and willing to ask questions. I think when you’re still at the junior level, there’s a lot of information to consume, but then there’s a lot of people around you that have knowledge, whether it’s at your current company with experienced engineers or on the internet, the communities on the internet. So being able to openly ask where you need help and then grasp and learn would definitely be like a very useful skill.

[00:18:35] SY: And what about a good manager? What are the things that developers should look for in a manager?

[00:18:41] TM: So the number one thing I think is important is someone who genuinely cares about their people. So someone who is genuinely keen to build trust with the people they work with. A lot of people you find when you talk to them are like, “I don’t want to talk to my manager or I don’t want my manager to see this. I'm scared of my manager.” When you’re working with a very good manager, it’s the opposite of that. Your manager is almost like a friend or a peer. Someone who you can have an open psychologically safe space with, to share everything. They know about your career journey, where you are currently, where you’re trying to go. They can give you good and critical feedback. And it’s all coming from a good place to try and help your career and help you grow, but they also know you as a person. They know what’s happening at home, that if you need any help outside just general life, you can almost rely on them to step in and help you with that. So I think that’s the route. With a manager, it starts at the human level where it’s like, “I really trust this person, is there to support me and really wants me to win and succeed.” And then everything else flows from there. You obviously want to have some sort of understanding of technology if it’s a technical manager, because that’s what they’re helping you out in. But those all come secondary to in my mind, the fact that the person genuinely is building trust with you and wants you to grow and can coach you to a place where after working with them for a few years, genuinely know where you started from and where you are, you’ve grown a lot.

[00:20:23] SY: How can managers best help early career developers get the most out of their positions and accelerate their careers?

[00:20:31] TM: There’s a couple of things. So there’s a bit about understanding the short-term and long-term goals of an individual. The short-term goals are up with our day-to-day conversations, just helping you figure out which direction you should go on a day to day, but the long-term helps with understanding where someone wants to take their career. I mean, everyone is different. Some people may want to be a manager like you, some people may want to just remain in the technical part, some people may want to exit coding at some point and become product managers or something else, understanding that can help with how you direct and plan the person’s long-term career trajectory. I think as a manager, you’ve got some tools that you can opt for. And for early engineers, one of the biggest ones is mentorship. So mentorship can come from you as a manager yourself or helping them find a mentor within the company or outside the company that can help them learn about that mentor’s experiences and guide them in their career and show them where to go. Then there’s obviously sponsoring the engineer. So helping identify projects that would help them grow and opportunities that align with where they’re trying to go and letting them know about them or actually advocating for them to be involved in something if you are a manager and you’ve got the power to get the person involved in a project that you know, that align with where they are growing. Those are the two main ones, mentoring and sponsorship, but it all starts from the very first bit, which is understanding, the person’s short-term goals and then the person’s long-term goals and using that to then guide the mentorship and sponsorship and your day-to-day career conversations and also checking and keeping them accountable, checking whether they’re progressing, keeping them accountable for what they say they will do and achieve by a certain time and helping them, if it feels like they’re struggling, just helping them be able to achieve what they’re trying to get to.

[00:22:38] SY: What’s your biggest piece of advice for early career developers to best use their managers and take advantage of the support they have at work?

[00:22:45] TM: I think one of the things that’s important is getting feedback. And sometimes some cultures, or in fact it happens quite commonly, a lot of cultures do not have a feedback-based culture. So you probably get feedback during performance review season only, which, depending on your organization, might be like twice a year or if you’re lucky four times a year, but you actually want the feedback to be more frequent because you’re working every day. And if you can get feedback as early as possible, it’s better. So one of the suggestions I have is to ask your manager for feedback as often as you can. If it’s as frequent as every weekly check in you have with them, ask your manager, “Do you have any feedback for me?” And note down what they say and if they’ve got feedback that’s useful for you, go and address whatever they’ve said and you can follow up on it in the next session. Another trick is, I say trick because it’s still useful. But basically, when you ask for a feedback, if you ask someone for feedback by just by saying, “What are the different ways I can improve? What are the things I’m really doing good at?” It’s so open-ended and it can easily lead to like some fluffy answers. So one of the suggestions is to be very direct and keep it scoped. So you can ask your manager something like, “What’s one thing I did well in this week’s team meeting? What’s one thing that I did well while I was building this feature?” So then you get very direct feedback on specific things that are more recent. So if you keep a scope, limit the amount of feedback you will be getting and keep it more recent. That can really be beneficial. But the key part is just to constantly ask for feedback and then use that feedback to learn and grow and also give feedback to your manager. So if there’s things that you feel like they aren’t doing or they’ve done very well, give feedback to them, because usually when you give feedback to someone, you can get reciprocal, so then they’ll start also giving you more feedback. If they see you’re constantly giving them feedback. Every time you give them feedback, they’ll give you back feedback.

[00:24:57] SY: So let’s switch topics and get into mentorship. So you don’t just guide folks within your company. You also mentor people outside of your company. Can you talk about how that works?

[00:25:08] TM: Yeah. So the people I’m mentoring have come from different places. One in particular I can think of is someone who once interned at a company I used to work at and then they’re now working at a different company and reached out to me a couple of months ago. And another one is through a friend of a colleague I was working with at a company and they said, “Oh, there’s this junior engineer. He would really like to learn and grow and I thought you would be a good mentor for them.” So you’re keen to mentor them. So out of those workers, because I don’t work with them in the same company, we meet less frequently. So my regular cadence with people I work with at Names & Faces or the current company is we all have a check-in weekly, but then with the people I'm mentoring outside of the company, we’ll meet for coffee once a month. It’s more open-ended. So generally, they’ll tell me what’s going on at their company, what progress they’ve made and what challenges they’re facing at the moment and we’ll sort of discuss different approaches they could use to overcome those challenges or any ideas I have, what they could be learning, books they could read, podcasts they can listen to or approaches they could take. Very much casual conversation, “Let’s talk about what’s going on at your workplace and in your career and where you’re trying to go.” And then I get to give them feedback and advice. And then a month later, when we catch up again, we just check in on what we chatted about last time, but then there’s usually the new things and we keep it going for as long as we both find it useful. So I found it’s useful for them to have someone who’s not in their company to help them and give them different ideas so that they’re just not boxed to people they work with. But I also found it useful as a mentor to just sort of hear how different companies, environments are like, and also how junior engineers are growing these days and different approaches in which companies are trying to grow them.

[00:27:06] SY: So it sounds like there’s some overlap between being a manager and being a mentor. Tell me about how you’d compare those experiences.

[00:27:15] TM: There are definitely overlaps. As a manager, your role has many layers or areas. At some point, you are a mentor. To some extent, you are a coach, but to some extent you are also the administrator of that person’s career at that company. So dealing with like the person who wants to apply for leave and you approve leave or not, which is more admin driven. So I think what I would say is being a mentor is a subset of management. Mentorship in itself, the main purpose is someone who’s less experienced is paired up with someone who’s more experienced and they learn through that person’s experience because the person who’s more experienced has been through a whole journey of a similar career. The mentee can learn from that person’s experiences in different ways. And that usually can happen with a manager because most likely your manager has more experience than you. But of course, sometimes as you go up the ladder as a manager, you may manage people who are more experienced than you. So you may not necessarily be their mentor, but more their coach, just asking, like leading questions to help them think of how to solve the problems they’re dealing with. So yeah, I think mentor-mentee relationship is really boxed into where I’m just trying to help you grow based on my experiences being aligned with the experiences you’re trying to get to.” And it ends there. So longer term relationship. It doesn’t have to be within the same company, for example, the ones I spoke about earlier, and there is no administrative thing to it.

[00:28:58] SY: Coming up next, Tanaka talks about what people should expect out of a mentor-mentee relationship after this.


[00:29:16] SY: So when we think about mentors, especially early career developers, I think we have this idea that having a mentor is going to fix everything. We have kind of this high regard for mentors and everyone seems to really want to find a mentor and it just seems like such an important thing. How important is it really? How influential is having a mentor, especially in your early years of your career?

[00:29:41] TM: Having a mentor will definitely help fast track your learning, especially if you have a very good mentor. So as an example, I actually had a mentor in my first six months at my first job as senior engineer who, not necessarily from just from his own world, had chosen me to be his mentee and I pay a program with him for most of my tasks for that first six months and he just took me under his wing and helped me settle down and understand what the technology career is about. And what I learned from him in six months would have possibly taken me a year or a year and a half to figure out.

[00:30:21] SY: Oh, wow!

[00:30:21] TM: I’ve got a firsthand example of how impactful a mentor can be in your career. And it’s something I won’t forget now, like over 10 years into my career. I still remember just how useful that phase was. So I would highly encourage any junior engineers to try to find a mentor. If they can find a very good mentor, it can really fast track their career and help them learn and have some fun and can guide them in their path. It’s not the only thing though. That’s the thing. Having a good mentor does not mean that your career is definitely going to be successful, because of course, there’s other things that you still need to do by yourself because you’re not always the mentor. You still need to be willing to learn and be learning from your team and within your team, but learning from other resources like reading books, attending conferences and meetups, pair programming with other engineers. There’s so many other things that shape up an engineer’s career and learning part, but mentorship forms a nice aspect into that. So to answer your question, mentorship is vital and important. It can help fast track someone’s career. But of course, it’s not the only thing.

[00:31:30] SY: So having a mentor sounds great. You definitely mentioned a lot of really great benefits, but how do you actually find one?

[00:31:36] TM: There’s multiple places you can look for a mentor. I encourage a lot of people that the first place they should look for one is at their current company because they already probably have the more experienced engineers working at your company. You already know them and have built up a previous relationship by working with them there. So it’s easier to ask and it’s probably easier to manage and set up like scheduled meetings where you’re chatting with your mentor and everything. So the first place I would say is at your current company. If you can find someone who you’ve already been looking up to, who you’ve already got a good working relationship with, that’s a good potential for someone to be your mentor. Of course, not everyone is working with a lot of experienced engineers or perhaps can’t identify anyone within your own company. That’s not the only place. There are other places, you could look at meetup communities and coding workshops, if you take part in any of those. After a while, if you’ve been going there frequently, you might meet people who inspire you and are interested in helping. Generally, people who do attend meetup communities or coding workshops are people who are willing to teach. They’re open to taking on mentees. You can also look in the open source community. If you’re involved in an open source project, after a while of helping how to contribute with that project, you also may build an online relationship with some of the people in that community, and they are also potential areas for mentors. And there’s also your friends. If you’ve got friends that work at other companies that are in tech, they may know a senior engineer, similar to ours. I actually ended up mentoring someone who was through a friend who knew that junior engineer who needed a mentor. So your friends can also guide you and help you with it. And then finally, yeah, there are online mentorship platforms now. Some are paid, some are free, which are targeted at helping people find mentors and then they can help you online. So Codementor and I think MentorCruise comes to mind as those platforms. And once you’ve identified someone, it’s a match-up asking. So if you let the person know that you’re inspired by them, you will learn a lot from them, could you possibly set up something more formal way? You can meet at a certain regular cadence and they can guide you in your career journey and then see what they say. I think I would also encourage people to not give up after the first attempt because sometimes when someone says, “No,” it’s not because they don’t think you’re worthy to mentor, but some people generally are busy. Maybe at that point it would be a disservice to you if they say yes and they can’t even mentor you. So don’t be discouraged if people say I’m not available. Just go ahead and find the next person who could help you.

[00:34:33] SY: And what should people expect out of a mentorship relationship? You mentioned that for your mentor, you were pair programming a lot and getting that hands-on coding experience. Is that generally what mentorship looks like? Or what are the different ways that it might play out?

[00:34:49] TM: I think that really depends on what you want and what the mentor feels more comfortable or feels strong at mentoring. But with a couple of examples, they could pair program with you on coding solutions, review some of your code, and give you tips and ideas on how it could be better or how you could improve it. They could give you resources that you can look at. So it’s always good to get like resources from someone who’s already read through certain books or listened to certain podcasts or taken up a certain set of courses. And they can just give you a list of these are the good books in this area, and you can go and learn from those. And there’s general career advice and life advice that you can get from someone who’s likely much older and more experienced than you that a mentor can give you.

[00:35:37] SY: Absolutely.

[00:35:37] TM: Yeah. So there’s quite a number of things. It just really depends on what you’re also looking for from the mentorship. I think this question points out something that I wanted to mention earlier, which is before you actually go and find a mentor, try and understand why you want a mentor and what you would want to get out from a mentor. If you are trying to really improve your coding, your actual execution on the coding side, then perhaps you’re looking for a mentor that’s going to be able to code with you or to look and review a code, but someone else could be looking more for someone who can help them be well-rounded in their life and career. And then maybe you’re looking for someone who will be more conversational. So let’s meet and talk. What should we be doing? How are you communicating with your team? Are you making sure you have a good work-life balance? Someone who can sort of guide you more on the life side of things. It’s really driven from what you want, but also what the mentors want.

[00:36:38] SY: Now at the end of every episode, we ask our guests to fill in the blanks of some very important questions. Tanaka, are you ready to fill in the blanks?

[00:36:45] TM: Yeah.

[00:36:46] SY: Number one, worst advice I’ve ever received is?

[00:36:49] TM: To not study computer science because other fields were better placed or with someone with the grades, but I’m happy I didn’t listen to that advice and continued on and pushed on in computer science and years later it has paid off.

[00:37:06] SY: That’s right. Good for you. Number two, best advice I’ve ever received is?

[00:37:11] TM: So this is something I read. I’m not sure where from, but it’s a quote I then kept on since I read it. So it says, “Even if you fail at your ambitious thing, it’s very hard to fail completely.”

[00:37:23] SY: Oh, interesting.

[00:37:24] TM: And that’s the thing that people don’t get.

[00:37:26] SY: What does that mean?

[00:37:27] TM: It means whatever you want to do, don’t fear failure to the point where you don’t start. Because even in failure, you learn a lot of things.

[00:37:37] SY: Right. Absolutely.

[00:37:38] TM: So you’re never exactly at the same place you were at when you try something ambitious. So it’s a sort of encouragement to step into things, even though success is not guaranteed.

[00:37:51] SY: Number three, my first coding project was about?

[00:37:54] TM: There was a point of sale system. I was in high school, the point of sale system for a shop.

[00:38:00] SY: Wow! That’s pretty complicated for high school.

[00:38:03] TM: Yeah. I think we made it very simple. We just made sure when you bought something, the stock updated and you got a receipt.

[00:38:11] SY: Okay.

[00:38:12] TM: Yeah.

[00:38:13] SY: Nice. Nice. Number four, one thing I wish I knew when I first started to code is?

[00:38:19] TM: For me, it’s to focus on the fundamentals of good software development. I think when I started coding, I focused a lot more on what particular programming language are we using. Yeah, I want to learn it thoroughly and also just on to make my code always work, but there’s a lot you can learn from just focusing on the fundamentals, which then can scale out regardless of whatever programming language you’re using or wherever your career goes. There’s just certain software development fundamentals that even over the last 20, 30 years have still stuck on that you just need. So things like writing clean code. There will never be a point I think where that’s not going to be useful and that’s not going to be something worth focusing on, being able to collaborate and be a team player and work on a team well. That’s just not going to go anyway. And mastering those and understanding those is more important than being a guru at C# or Python because I think a language, whenever you get into a new environment and you’re given enough time, you can always learn, but then you apply the principles that you learned from previous places in that particular language.

[00:39:34] SY: Well, thank you again so much for joining us.

[00:39:35] TM: Thank you. Thanks for having me.

[00:39:44] SY: This show is produced and mixed by Levi Sharpe. You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. Join us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.

Thank you to these sponsors for supporting the show!

Thank you to these sponsors for supporting the show!