Decrypt Development with Ines Kenova from nmible

Listen on:

• Spotify
• Apple Podcasts
• Amazon
• iHeartRadio
  

In today’s episode, Developer Advocate Liz Moy sits down with nmbile Technical Lead Ines Kenova to talk about how she went from co-founder to software engineer, to technical lead. Ines shares her insights both as an individual contributor, leader, and also as a coding instructor. She also shares her approach to security and some of the ways that she integrates security into her own programming practices.

A few highlights from their conversation include:

• 4:30: Working at startup and encountering tough problems challenges you to find the best solution
• 8:00: Challenges shift when you become a technical lead or manager, from finding the best solution yourself to supporting and coaching your team
• 15:30: Teaching coding is often about helping people drill down into what the actual problem they are facing is
• 25:00: It’s easy to want to quit or ask yourself “should I quit” when you’re getting into tech, because the challenges can feel overwhelming. But if you know what your motivation is and why you want to do it, it can help you keep going.
• 33:00: Thinking about security as a part of the software development lifecycle — paying attention to vulnerabilities, patching, finding ways to work it into CI/CD processes — is one of the best practices an engineer can focus on today.

Listen to the full episode on YouTube or wherever you get podcasts. You can find Ines on LinkedIn.

Liz: Hey everybody. Thanks for joining us today on the Decrypt podcast. We've got Ines here. Ines, thank you so much for being here. Would you mind introducing yourself and telling us a little bit about what you do?

Ines: Thank you very much for your invitation. Yes, so I'm Ines, and currently I'm technical team lead in our company called nmible. I'm pretty new at this position. I was [00:00:30] pronounced as a tech lead this January, so it's pretty new to me.

Liz: Amazing. So you're new to being a tech lead, but you've been in development for a little while. Can you tell us about how you got into tech?

Ines: So this is kind of a funny story because I've never wanted to be in tech. This was never my intention. I had a friend who started a company, a startup company, [00:01:00] and because I was really interested in psychology back then, he suggest why we do not start it together and basically I'll be the person who's responsible to see if the people will be fit in our company and if they're going to feel well in the company and he will be responsible for the technical part of stuff in the interviews. During the interviews, I was in these interviews basically, and I was really annoyed that when he was asking them questions around strings [00:01:30] and big connotations and stuff, I do not understand what he was talking about. Something I didn't understand. So I decided to start learning programming so that I can understand a little bit better what we're talking about during interviews because I didn't realize that it's really hard actually to be in tech and there's a lot of knowledge that you have to gain.

So I started learning programming back then and in a couple of months, [00:02:00] maybe probably a year after we have started, our front-end developer left because of his personal reasons. My co-founder suggest me to be the front-end developer because I was still learning stuff and concepts because I was pretty interested in what I've been learning. So I started as a front-end developer, not a good one if I have to be honest, because I was still learning concepts and stuff. So basically this was my first job working as a front- [00:02:30] end developer and after that I've discovered that my passion is actually a backend and a little bit part of a DevOps. So I transferred during the last few years as a backend developer.

Liz: So you got into tech, you decided to start learning about the strings and the arrays and the different things that you started talking to your friend about. What was the first big development project that you worked on? Was it when you were working on the startup with him?

Ines: [00:03:00] So it was the main project that we were working on at that time and it was related of a bit of a data science project, which one of my best friends currently was working on the AI part and on the data science part in general and also the backend and I was the one who was involved in the front-end part. It was a really great project where we were taking data from the internet, basically scraping data. [00:03:30] This data was transformed and then it was showed in a really nice way with graphics and tools that can visualize better the engagement of the audience of different people. So it was really challenging for me not because the project itself was that challenging. It's not like we are doing the ChatGPT, but it was really interesting for me because it was the first big project that was actually exposed to the world and people can [00:04:00] see it.

And a lot of the concepts that I have learned in programming started there because when you had a problem then you have to find a solution. And it's because it's a startup and there was really few people working in this startup, basically you are alone to solve problems, which you can learn a lot from that because you can learn how to find solutions, how to decide if these solutions are actually the things that you're looking for because there's so much [00:04:30] information. So many people telling you so much different information on the internet, so you cannot be sure what exact approach you have to take and which one is the best one for your current situation.

So this was a bit challenging just because this thing exactly showed me that it's going to happen with mean tech because I was there, I was really affected. Sometimes I felt really bad because I couldn't solve problems with days, [00:05:00] like days and days. But I was there and I did not quit, which I think is the first sign that showed me that I could be something and something useful in the tech.

Liz: Yeah, absolutely. I hear that a lot from people starting out in programming and I had a similar experience where when I started out I had a good number of people that I could turn to ask questions from, but I was honestly so nervous to ask a lot of questions. [00:05:30] I was so worried about asking a question that didn't seem smart, and I think there were definitely times when I maybe spent a little bit too much time trying to rock it on my own. And so that's one of the number one pieces of advice I give people now is just ask for help sooner than you think you'll need to. But I also think there's a lot of value in working at it yourself and trying to come to that conclusion because that's a big part of the learning process [00:06:00] too, is just banging your head against the wall until you figure out the one thing that actually makes sense.

Ines: Exactly. And I think the chances that you're going to hit the same problem and solve it from the second, you see it are increasing right now because if someone actually points exactly the point where it's wrong, the chances are if you have similar situation but with different context, you won't be able directly to go into it and recognize that it's the same [00:06:30] pattern. But if you have solved it by your own, that is making really strong connections in your brain, let's say your connections in your brain, which actually help you recognize another pattern of the same kind really quickly and solve it really quickly. So as you said, yes, sometimes it really seems like a waste of time, but most of the times helping the person itself to actually grow and really start being productive [00:07:00] in the next couple of months.

Liz: Yeah. I guess in that same sort of problem solving area, I'm curious to know what is the hardest problem you've ever had to solve or the hardest challenge that you've ever come up against in your tech career?

Ines: This is really funny because I think of my career as different parts, different chance. And the first chance when I [00:07:30] started learning programming, the greatest challenge was a recursion, right? I did not just get that. It was so many days I have spent trying to understand why I need to do it this way or when I need to do it this way. Or when it's convenient to do it and when it's actually a waste of memory and efficiency of the program. So it depends, and now it seems really funny, so I cannot [00:08:00] exactly say what was the biggest challenge. Probably from my new perspective as a technical lead, which as well has some management in it, is probably to allocate tasks to specific people and explaining really well clear and articulated what exactly is required from the ticket and making sure that these people as well understand what you think you have said because these are two different things, right?

Liz: [00:08:30] Absolutely.

Ines: So I think I'm still learning that and I think that will have a great benefit in my personal life as well, not only in my working life to accept that every person is different and every person hears different things according to their previous background and they're shaping stuff according to what they think and they understood and their actual background. So this is the greatest challenge [00:09:00] that I'm still solving right now, even though it's not technical, because the technical... I have a lot of mentors in my working career right now, which I can go and talk to. So even if something that I'm not really aware how it should be done or I have some doubts, I can go and talk to them and it's not already that much of a challenge for me, especially the last few years, but from different side of... Like different perspective, [00:09:30] the management perspective, it's really hard for me. Probably a manager, for example, a manager from 10 years now, they will be laughing at us because the recursion for them, but for me it's still a challenge. So I'm still learning there.

Liz: Oh my gosh, I can totally relate. When I finally figured out how recursion worked, I remember using it constantly. I would use it in places where you were saying it was just totally unnecessary [00:10:00] or using uploads of memory, but I was just so excited that I understood how it worked. I way overdid it, but I think that's one of the exciting things about learning is when something clicks, then you're suddenly thinking of all these different ways that you can use it. And then as you mature a little bit, you're like, okay, maybe I don't need to use this every single time.

Ines: And then when you learn about golden hammer pattern where if you have a hammer, not [00:10:30] everything is something that you can use it on, right?

Liz: Exactly. Yeah, and it is so fascinating to think about what those problems will be coming down the line. We were talking a little bit about AI before we started this conversation, but it's kind of amazing to wonder and think about what the programmers in the next decade will be using as compared to what we learned. But I also think that fundamentals [00:11:00] are really important just as exciting as new frontiers and new tooling is. I think that some of those fundamentals really matter as well. So yeah. I'm curious for you, is there any... Since you kind of came from this maybe I guess people call it non-traditional background, which I do as well, I didn't get a CSS degree or anything, but was there anything that you had to do yourself on the [00:11:30] side or any supplemental learning that you did that helped you get to where you are today?

Ines: Oh, there was constant learning. It was like I hadn't had the concept before of work-life balance because everything was work for me. I'm pretty happy right now that it's not the case, but previously it was the case. There was no Saturday and Sunday that I haven't worked. There was no [00:12:00] evening after work that I haven't worked as well. It was really, really interesting because if I have, let's say one working place, I'm at least working at two other places, one after my regular working time and one on the weekends. And this has taught me a lot because I had to do so many different things in so many different projects that I had to do [00:12:30] it. I just had to do it right and I just had to read and just had to go through courses, multiple courses. I had to go through multiple articles, ask a lot of stupid questions on the internet and people answering them, bothering my husband constantly with questions because before he started his own company, he was really great developer on his own and CTO of a big company here in our country.

So basically constantly bothering him, he was sick and tired of me constantly asking [00:13:00] development questions because all day long people are asking him this, at the end, I again start asking him this. So this was my approach actually never stopped working until I felt a little bit more comfortable, until I realized that I'm doing heavy tasks in no time and actually with good quality and good performance metrics after we release them on production and I see [00:13:30] they're actually working and we do not discover any major stuff that could be bothering us. So that is when I have decided I can take a little bit of a rest and I can start actually learning for the management perspective.

Liz: Yeah, I'm curious. I feel like that's such a big question that a lot of people come up to in their career, whether they want to stay on the individual contributor path or they want to transition into [00:14:00] the managerial path, or maybe they do one for a little while and then they switch and then they go back. What was it that made you decide you wanted to explore the management path?

Ines: So this is a really interesting question because as I shared, I am just some kind of a lead from two months now officially. So basically I don't know a lot of stuff and I cannot be sure that in the next six months I won't [00:14:30] change my mind. But I feel like it's something in my nature in general that I like to talk to people and I like to take decisions together and I like challenges in general. So when someone comes to me with an actual coding problem, most of the time I'm really able to resolve, it doesn't matter, it's in my field, like the backend field or it's on the front-end field [00:15:00] or it's on the DevOps field. Not that we have a need to resolve any DevOps problems currently, but basically. So that is why I've decided this is the right track because I've been teaching a couple of years from now as well here in institution here in Bulgaria.

This teaching actually helped me to be really passionate and understanding what exactly people need because sometimes they express something that [00:15:30] is not the actual problem, but how to talk to people, how to understand the actual problem. And this is just the new challenge. So how do I know? I know because this is something that I've, I always felt that it's going to be this way, that it's going to be working with people at the end, helping them with the tech perspective of the sites. I know a lot of people which are overwhelmed with meetings [00:16:00] and that is why they choose to return back to just a normal coding job and with no manager responsibilities. I think that could be managed, and I think the meetings are something that the organization in general could control and basically could decide as a problem. Sometimes yes, I know their emergency situations that require people to be there and people [00:16:30] talking, but if there is just a constant needless meetings, people can initiate that process of actually reducing them and it's not going to happen for a month and two or two.

But I think with the right approach, people can reduce that and if this is the only reason for people to quit the managing side perspective of things, this is something that could be resolvable. There's another aspect of this, which most of the people consider themselves as introverts and they say they [00:17:00] prefer to work alone without any unnecessary communication to other coworkers or to clients even. So this is something that is internal and I don't think this is a bad thing. It's just very great and very admirable that the people knows themselves and the actual other parts is really great for them and they feel happy, so they're more productive at work. So I think that's fine as well, but everyone should try it because you don't have a way of knowing what exactly [00:17:30] you like if you don't try it, and if you don't try to change what you don't like. And if that fails, you can go back each time.

Liz: Yeah, exactly. It's funny, whenever I speak with people that are really early in career, another thing that I see a lot and I guess I experienced myself to an extent is this need to know exactly what you want to do and like, oh, if I choose this, then I have to do it forever. And I really think [00:18:00] that obviously we never know what life's going to throw at us, but a lot of us will have many years to try different things and figure out what we like and what we don't like and what works and what doesn't work. And so I totally agree with you that I think it's important to just try something and then again, if you just want to go back to what you were doing before, it's always going to be there.

I'm curious, you mentioned that you're backend developer and I'm wondering what programming language was [00:18:30] your first programming language and then what language you currently work in or languages you currently work in?

Ines: So I started learning in Java, which is funny because after I have learned a couple of concepts in Java, I've never go back into Java, not because I don't like it, but because I hadn't had the chance to actually work with Java. So my second language was C#, and then I transferred to Python and never look back. [00:19:00] So basically currently it's Python and I'm planning hopefully that I'll continue developing with Python. This is the language I feel like home.

Liz: I completely agree. And it's funny because I feel like JavaScript it's so versatile. It's a great language, and I think I reached a point in my career where I realized that I needed to know JavaScript better than I did, and I kind of made it a priority to get better at it. But whenever I have [00:19:30] to spin up a quick demo or something, I always do it in Python first always.

Ines: It is funny because from tech experience, of course, I had to have this JavaScript and TypeScript experience, and even though that was my first working language, when I started working, I actually started working with Angular directly, which enforces TypeScript. So basically I started with this, but still if I need to do something, I'll always do it in Python, even though the JavaScript [00:20:00] was the first one that I have started working on. So yes, I really agree with you, every demo, every explanation will be on Python.

Liz: Yeah, I think I noticed also that you actually do some teaching as well. Is that right?

Ines: Yes. So I teach Python. These are general programming concepts like data structures, algorithms, and frameworks at the end, because this is a school for programming basically, [00:20:30] and this school has a couple of different main languages that they teach. One of the main languages is Python and there is a whole process of actually learning Python. The people there are learning something around year and a half, maybe two for web development. There is AI as well, but I'm not involved there. So basically we are just at the end, we're teaching as well a framework, and currently I'm teaching Flask. There is Django and I have a course for Fast API [00:21:00] as well, but everything is Python.

Liz: Nice. Is there any question that you feel like comes up really often when you're teaching one that you hear students ask kind of over and over?

Ines: So I have noticed a couple of main problems that people hit. The first one is the while for loop. Interestingly enough, when they first start learning programming, [00:21:30] they're not that overwhelmed with the For Loop, but they're really overwhelmed with the while loop. So this is the first breaking point for them.

Liz: They get into that endless loop.

Ines: Yes, of course, they're always someone who is actually in an infinite loop. That's the first thing that I'm showing so that they know what's happening. Because if you don't know much about programming, how you would know that you're in infinite loop unless you wait for a bit longer and see your terminal is saying that. But people [00:22:00] as well tend not to read the terminal. This is something really interesting because at the beginning I think there is a scary feeling inside them when an error occurred over the terminal because it's red and it's big and there's so much stuck in this error. So they get overwhelmed with them, they learn and they feel more comfortable of course.

The second thing is lists and more like a concept array because yes, in Python [00:22:30] we don't have a built-in array directly, but as well we need to understand what's the different between lists and array. So I think array is a concept as well, which is a breaking point. And of course, object-oriented programming. Yes, this is a concept which totally requires you to switch off your way of thinking and writing code so far and everything that you have learned with the new syntax. So I'm really happy to [00:23:00] show each time on my... There's no lecture when I do not show debugging. And basically I think this really helping people understand concepts because when you debug, you understand how the code is working and you learn actually how to talk to this code because this is again, a great problem. People think they say and write some code, but actually it's not exactly what they think, right? It's something else and they cannot see the difference between what they think they are and what actually they have said and written.

[00:23:30] So this is an interesting breaking point. And then we have of course the resistance against the database itself because it's a concept, but I think this is the more critical points and the question that often comes up is, how do I know I should stay? How do I know I should stay? It's so much harder for me. I see other people just flying around, just learning new concepts without [00:24:00] a problem. And this is really hard because I can relate so much to these people. I was there and I was crying constantly for six months when I start learning programming because I felt so dumb. And I'm trying to explain to them, I even wrote some really small book of 25 pages for my experience just to show them that even though I'm here teaching now, I was so dumb. And I always say to people with the new concept, I'm so dumb. [00:24:30] If I change the field, if I go to a different field, I'll be the worst person there. But over the time, this is my quality. I just get one of the best.

So this is the thing I try to teach them because the questions are always related to the hard points. How do I know when I will go index out the French exception or something like this. But these are more related to the programming. The constant question that I'm getting is how do I know I [00:25:00] do not quit? How do I know I do not quit? And often with this, I'm asking about their motivation to enter into it-

Liz: Yeah.

Ines: ... because I think this is the important thing, and I think this is the key to their answer, if they have to quit or they actually have to try. And yes, I know this is not exactly the tech related question, but it is the truth or is what I'm seeing years and years now of teaching. This [00:25:30] question constantly continues to repeat itself, every course, every time, every module, almost every student.

Liz: And it makes sense because I think that... I guess there's two thoughts that I have around this. The first is that there's a lot of different aspects of tech. There's a lot of different things that you can do. Maybe you end up really loving design. You want to be [00:26:00] a product engineer, you want to do more of the front end stuff. Maybe you love doing the backend stuff and you feel really comfortable there. Maybe you end up becoming a demo engineer or working on documentation. And I feel like learning to code just opens up so many doors for people. But when you're starting out, you don't always realize there are a lot of drifting directions that you can go and it doesn't have to look this one certain way. I definitely also [00:26:30] have worked with some just incredible amazing engineers, and I would look at what they were doing and be like, oh my gosh, I can't pick up stuff as fast as them.

I can't do what they do. And I got to a point where it was like, oh, that's actually okay. That's amazing that they're doing that, but it doesn't mean that I have to do that same thing. There's still a place for me here, but I also think it does take a little bit of grit and a little bit of determination and [00:27:00] deciding even when this gets hard, I'm going to keep trying and I'm going to get back up when I get knocked down. As dramatic as that seems, there are just those moments where it's really hard.

Ines: Yes, I totally agree with you. It is hard and it'll always will be. With the new challenges. I think the only thing that I'm most proud of myself is that I'm okay with that right now. When I feel them, I'm okay with it and I start from there and I start learning [00:27:30] and this is not bothering me anymore. And actually I get even excited. This is a Manhattan syndrome or something like this. Oh, you actually feel excited to feel dumb and use this on someplace so you can actually learn something new. Going outside of your comfort zone is not pleasant for anyone, especially at the beginning. But after that, if you just think how much you can gain, it's totally worth it.

Liz: Oh my gosh, I [00:28:00] completely, completely agree. Before I came to Evervault, I frankly didn't have much experience in security or privacy, but it's a space that I've been really interested in for a long time. And when the opportunity came up, I was like, okay, let's do it. And then I remember the first week on the job being like, what are any of these terms? What is a confidential container? What is homomorphic encryption? And it [00:28:30] was so overwhelming, but it's been so honestly thrilling to learn about these things. And I think it surprised me a lot too because I had this perception of the security space being very sort of, I don't know, hard to crack a little bit like, oh, you're gate-keepery almost maybe. And I haven't found it to be that way at all. I think people are really excited to share what they know and [00:29:00] really excited to get other people into the industry. So I've been very pleasantly surprised by that.

Ines: I think this is a general thing in software industry that people tend to really truth and happy to share information. And this we can find on the internet as well. So many free resources that you can find actually. And when I talk to my friends that are working [00:29:30] in different fields, for example, I have a friend who is a doctor and he said, "No, people do not like to teach you. They're afraid that you're going to take their places after that if you become better than them." I don't think there is such a thing in the tech industry. Of course there are people who are afraid of that and do not want to share a lot of information, but most of them are actually doing it and teaching people and want [00:30:00] them to be great and they're happy when the person became even greater than the teacher.

Liz: Yeah, absolutely. And I think the whole sort of open source ethos and movement is really wonderful to see. I think there's such an environment of wanting to just move everything forward together and doing that in a really open and public way. That's been really, really nice [00:30:30] to see as well.

Ines: Yeah.

Liz: So I would be totally neglecting my job if I didn't ask you just a little bit about how you think about security as a developer, how you approach security when you're building what you work on in your day job, or even when you work on things on the side as well.

Ines: I am not sure you're going [00:31:00] to believe me, but I have dreams about security. I have dreams where something could be hacked. I have dreams about if I have any doubts that I have visited some shady website without actually taking the necessary measures to share that this is not something that could steal my personal information or worse even. So basically I'm taking it really seriously. One interesting [00:31:30] thing is when I was in a big corporate, because previously I have worked in a big corporation, let's say a big corporation, I didn't tend to value the security trainings that they were assigning to us. I was just like, okay, just another training that will waste my time instead of me going and doing my coding task. But our company just recently gets certified for ISO 27001, which is [00:32:00] the security certificate standard. And we have another one recently for ISO 9001. So yeah, we are quality well.

So basically when we started, I became really passionate about security because it's one thing to actually just watch some trainings in a platform that they have assigned to you. It's another thing to audit the whole platform and see if there is any security bridges that you can think of because I'm not a hacker, so [00:32:30] I cannot assess if everything is directly secured, but at least according to the documentations and guidance and guidelines everywhere, monitoring your platforms, understanding if there is an not right access, because some of the companies even cannot understand if they have been gained privileges or something. And there's so many stuff that I'm learning right now because as well, we started talking about PCI DSS compliant, where actually Evervault comes in to play a really [00:33:00] serious role in our software.

So I really as well like this part, an encryption. And I started learning and reading about encryption. So everything that I do, my first question is that secure? Is that secure? And I'm like just a security freak out there who's constantly asking, is this secure guys? Are we sure this is something that we want to produce? So I even implemented recently a CI step [00:33:30] where I'm auditing the packages in the CI build of ours where I'm actually can see all the third party dependencies in the code. And there are third party dependencies as well. If they're vulnerable, if they have, of course known vulnerabilities, not unknown because I do not get to the dark web to ask these questions.

So basically I'm just saying if there are any known vulnerabilities, constantly patching and trying to patch everything. Now when my Chrome browser says it needs [00:34:00] to update, I'm constantly updating. It's like most of the people do not even bother to see that there is a prompt saying, please update Chrome or relaunch Chrome so that we can set some updates. My computer says there is a security update, directly install it without waiting. I could be how full in my task, really focused on something. If I have such notification for a new version of the software, either my phone or computer is directly installed without any delay.

So I could say [00:34:30] I'm taking it pretty seriously and I'm really trying to learn and understand concepts. I acknowledge how much I do not know and how much I have to learn. And even if I try to do it all my time, there will be always amazing people at hackers who will doing some really sophisticated hacking in no time. So I'm trying to take it really seriously and I'm doing my best, but I'm still learning.

Liz: But [00:35:00] this is such a great conversation. Thank you so much for taking the time to chat with us. And is there anything else you'd like to add or any place people can find you online?

Ines: You can find me on LinkedIn.