[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 how to make sense of the testing landscape with Sergei Egorov, Java Champion and Co-founder and CEO of AtomicJar.

[00:00:22] SE: When you see a lot of test failures, one of the first things that you should check is whether the failures were caused by your test setup or by the implementation.

[00:00:33] SY: In this episode, Sergei talks about how he got into testing through game development, the different major types of testing, and some classic types of failures that are revealed by each type after this.

[MUSIC BREAK]

[00:00:55] SY: Thanks so much for being here.

[00:00:56] SE: I’m so excited to be here, Saron.

[00:00:59] SY: So tell us about how you got started. Where did this journey begin for you?

[00:01:02] SE: This journey began for me in Siberia, in the cold part of Siberia, and we aren’t very active outside, but rather inside, and that was the case for me. I was locked inside. You spent lots of time with your computer, and that’s how I got into programming. I was just clicking through some random files, some Visual Basic Script files in System32 folder. And apparently, I realized that some of them I can change, and that’s how it all started for me.

[00:01:30] SY: So you were playing around, kind of messing around with stuff. What was your reaction to that? Why were you messing around and what did you take from that experience?

[00:01:39] SE: First of all, to answer your question why, because I got bored with games. I run out of games on my CDs. Yeah, I didn’t know what to do. So I was like, “Okay, what else can I do with this powerful machine in front of me?” People talk about computers and computers can solve big challenges, big problems in the world. But apparently, I had no idea how they work and what they do. So that was my why, it’s why I started taking these files without having any clue what they’re doing. And just something clicked in my head that, “Hey, when you change them, you modify the behavior.” And it was my very first interaction with the concept of programming. Apparently, it can edit some files, it can edit some texts, but then it will result in some behavior being changed.

[00:02:24] SY: So how did that first exploration, that curiosity, how did that get you to where you are today?

[00:02:30] SE: I actually relatively quickly transitioned from trying to understand programming into trying to do some hacking because of movies and other things and I grew up in the ’90s, I’ve been watching some of these hacker movies. So I was like, “Okay, I want to become the world famous hacker.” And I started learning how hacking works, like how people break into systems. And while I wasn’t breaking into any systems, I didn’t want to cause any harm, but I just wanted to understand how it works, like how people do that, ended up being sort of a white hat hacker. I mean, a beginner won’t be someone who would break into Pentagon or something like that, but discovering some JavaScript injections and SQL injections and stuff like that, something that I was enjoying doing and then reporting back. But at some stage, I realized that, “Okay, I need to understand the systems behind what I’m trying to break into so that I can do it better.” And it became so exciting that I was like, “Okay, I don’t care about hacking anymore. I just want to build the systems. I don’t want to break them.”

[00:03:39] SY: Interesting. Okay. And how old were you? What age are we talking about here?

[00:03:43] SE: Thirteen, fourteen years old.

[00:03:45] SY: Oh, pretty young. So let’s fast forward from that to the first job. How did you get that?

[00:03:50] SE: Relatively soon after, I started learning the programming, since I was still connected to the gaming industry and still playing some games. I realized that, “Okay, for some of the games I’m playing, I could do something and apply my programming skills.” And I started writing both for one of the online games that was very popular in Russia and eventually one of the online clans and it’s a bit specific to online games, but still they reached out to me and asked me whether I could create a bot for them that would sell their in-game currency to their users. And that was my very first job in IT. I just got paid for creating a bot for a game, online game, and it was fun because I did not expect to be paid. I was just enjoying what I'm doing.

[00:04:34] SY: Tell me about your learning process. How did you level up? You started just from kind of poking around and looking around. When it came time to teaching yourself for a formal job for the thing you actually got paid to do, what was your process for learning and leveling up?

[00:04:49] SE: So when it comes to learning, the biggest principle I’m using is this cannot be like that. So sometimes when I struggle with something, I always change it and think like, “Okay, there is no way someone has never solved it already,” because that’s the reality we are living in. The IT industry, it’s so wide, it’s so mature now that we have so many solutions to almost every problem we’re experiencing. And what I learned that works the best for me is to first check how the problem I’m trying to solve was previously approached by someone else already. And most of the times, you will either find an answer or someone’s resolved that resulted in nothing but at least you can follow the process and shortcut and save some time, not wasting this time yourself, but learning from other’s experience. But this was very helpful. And in many things I’m doing today and many things have been doing in the past, but also what I’m doing today also as part of our company challenging the status quo is always helpful when it comes to learning. The second part, like how I earned the knowledge, this one is interesting because while I did start by learning books, nowadays I’m not really reading books because the domain I need to research almost all the times develops much faster than the books get written.

[00:06:11] SY: Yeah.

[00:06:12] SE: You resort in reading either some basics that would apply no matter when the book is written like 40 years ago or today, but some modern stuff. Like if, for example, I want to read about, I know something really fancy, off the top of my head, like something about Kubernetes and something new they just released, obviously I will be struggling finding a book. But reading social networks, especially Twitter, is surprisingly a great way to discover knowledge about things. Who would think that microblogging platform would help with that?

[00:06:46] SY: So take us to AtomicJar, which is where you are today. You are the co-founder, the CEO. What is AtomicJar and how did you get started?

[00:06:55] SE: So AtomicJar is a result of us spending five years working together. By us, I mean, Richard North, original creator of Testcontainers, Kevin Wittek who joined us later as a maintainer and myself, and also our wide community of Testcontainers’ contributors and users. But we’ve been working together on this open source library for five years and Testcontainers has become something incredibly popular being used by the biggest companies out there. But we never thought about monetizing it. We never thought about taking commercial. We had our day jobs, we were paid well, and we never had the problem with that. But at some moment, we realized that we’re enjoying it so much that we would like to turn it into something full time. We would like to be spending our time working with this library because that’s what gets us excited the most. And although we never had a chance to work with each other at a company, we were always employed by different companies, additional motivation for us to start a company was to be finally able to work together, and I’m very excited about it because this moment when you turn from, okay, just a bunch of fellow open source developers doing something on their spare time and trading their family time in favor of contributing a new feature to an open source project that is being used by the largest enterprises in the world into something that eventually will pay off and into some things that will let you stay with your family while also being happy about the progress you’re making with the open source library.

[00:08:33] SY: What has been your experience being not just a developer working actively on the product, but also just being a CEO and having to run the business? What has that experience been like for you?

[00:08:44] SE: It’s a very interesting experience. I’m a developer. I’ve been a developer my whole life, and now I have a lot of things to learn. The good things at the same approach works like would be wrong to start doing things without learning from others. And that’s what I’m actively doing in my role. And this is why it was so critical for us to find the right investors and advisors, by the way, because these are the ones we’ll be learning from the most, and they really help. But it is interesting because at least being CEO of a dev tools company is obviously not the same as being a CEO for social network, let’s say, or something else.

[00:09:22] SY: Right. Right. Your users are a little bit more demanding, I assume.

[00:09:25] SE: Demanding, but also you understand them much better. You understand them because they’re also developers.

[00:09:30] SY: Okay. Yeah. Yeah.

[00:09:32] SE: You can shortcut so many conversations and you can shortcut so many decisions because, well, I know what they want because that’s what I would want to have. And that was major contributor to the success of our library, containers, but also what we do in our company right now kind of reflects the same ideas that understanding your target audience and your users is crucial to the success of your startup and our advantage that we are a dev tools startup and this is why being a developer, CEO means that you can actually be successful because, yes, you need to learn some other things, like how to operate the company, especially finance is part of this thing. There’s so much to learn. But on the other side, at least I don’t need to spend time learning how to understand our users. We came to a conclusion to start the company because we already understood our users and we knew what they wanted.

[00:10:29] SY: That’s a great point. So now I want to get into understanding the testing landscape a little bit more. I know this is your sweet spot. This is what you guys are all about. Let’s start with the very basics. What is testing and where does it fit into the developer ecosystem?

[00:10:47] SE: In our case, our company, we are focusing on automated testing, but there are various types of testing and clicking through the UI and starting the application, just doing it manually is also one way of doing the testing. It’s just manual testing. And the way I tend to think about automated testing is that developers are lazy. They don’t want to do repetitive actions. And as anyone lazy, we would rather spend five hours automating something that we can do in one hour by hand. But it sounds like a joke. But on the other hand, the positive outcome is that if we automate something, then we can rerun this optimization. And the beauty of automated testing is that those actions that we would be doing otherwise, every time we need to verify that our application is working now can be delegated to the machine, to the computer, that we no longer need to spend time doing repetitive actions. But instead, we can run the test and test is literally just a piece of code that would do what otherwise you would be doing. And if you as a developer, previously if you were running your application and checking that, “Okay, if I’m designing a calculator and if I entered 2, then if I pressed plus, and I entered 2, then the result should be 4. What I described is a test case. And this test case can be done either manually or by writing some code that would be entering these values. And that’s what we are focusing on. How developers not spend time doing repetitive actions or what can we do to make it easier for them to write their tests because we believe that this is the right thing to do. As developers, we have so little time and so many things to do and doing repetitive actions isn’t the right investment of developers’ time.

[00:12:48] SY: So talk to me a little bit more about the benefits of testing. As a developer, you said, “We don’t have a lot of time. We got lots of stuff going on. We got lots of bugs and squash. We have features to build, users to respond to for customer support kind of thing. Why bother with testing at all? Why should we do it?

[00:13:07] SE: I believe testing is an investment in the future. Today, I may just confirm that the application is working, and okay, like that’s a short-term win and we already know that the application’s working. What’s the point? Right? Why should we invest into testing? But as anything else in the world, applications are being changed. We always get new requirements. We always deliver new features. And as part of the process, we should always have the confidence that, “Okay, what we just changed won’t break the way it worked before.” And now we are talking about spotting regressions and spotting regressions isn’t an easy thing to do because it requires some prior knowledge, it requires writing something proactively instead of just listening to the users who tell you that, “Okay, something is broken.” And writing tests, and I believe the biggest value of having a test is to be able to understand the current state of the application as compared to some previous assumptions that were previously made and the best way to express assumptions and let them stay is to write a test case because test case will be the representation of the assumptions and certain requirements for the software you are working on.

[00:14:27] SY: And when did you first get into testing? When was the moment that for you, you said, “Man, this is an investment that I need to make and this is something that I want to work on and take seriously”?

[00:14:37] SE: Quite early, I would say. Maybe 10 years ago. I’ve been working at the GameDev company. And the thing is when you’re working in GameDev, usually you have very rich clients. In our case, it was an application in social network. And eventually, I had to spend like 10 minutes progressing through the game just to get the support that they wanted to test manually. And let’s say you need to test something like some edge case. You need to test them when you reach level 80, which is the biggest level in the game. And it takes like five years to get to that level. You can do certain actions. You have two options. You can either shortcut by adding some special codes that would make your profile look like you’re level 80, but it cannot guarantee that your users will go through the same process. What else you can do? You can write a test for the particular part that you want to test without having to do something in the UI. And it clicked with me, like, “Okay, why should I do some actions in UI if I need to test our backend? Why can’t I just start our backend and do some tests in our backend?” It was a moment of realization for me that, apparently, I don’t even need my whole system to pass what I want to test.

[MUSIC BREAK]

[00:16:11] SY: What are the different types of software testing? You mentioned automated testing, which is kind of what we’re focusing on, what the focus is of your company. What are some of the other categories of software testing within that?

[00:16:23] SE: So I’m not sure whether we can say is that let’s say KELS testing, performance testing, and others are in the part of automated testing because I really see it as manual testing versus any other type of testing. Because any type that is not manual, you can repeat. It means that you can automate it. It means that it’s automated testing. So I would say two categories. But then automated testing is a rich category with so many subcategories. One of the most popular ones is unit testing and that’s where you start. Let’s say you’re a developer and you need to test the implementation of the calculator, that functions that performs the calculation. And the function is so-called pure. Its behavior never changes as long as the inputs are the same. And it isn’t the case with calculator. No matter what the weather is or no matter which time of the day it is, you’ll always get the same result if you enter 2 and 2 and plus. So that’s the case for pure functions. And now we want to test it. We want to test it 2 plus 2 equals 4. So that’s what we do. We wrote a test that would call our original function, plus 2, 2 and plus as arguments and we asserted the result. We just check what this function returns and we write code to test code. There is an interesting question who would test the test, but that’s another story.

[00:17:54] SY: Yeah. Right.

[00:17:56] SE: Unfortunately, I would say the only way to test your test is to do manual testing, also known as code review because someone else will look at your test and say, “Hey, why are you assuming that 2 plus 2 equals 5?” Why? It isn’t the case, but of course business requirements help with that. But this is a very simple way of testing and it’s extremely fast. This is why it’s so appealing to developers. The downside is that sometimes or most of the times our applications aren’t as simple as calculator. In fact, most of modern applications are tiny wrappers around database access to transform. Let’s say the result of an SQL query into some JSON that they return to the client. Some REST API or GraphQL maybe. So we could test that piece of code that transforms this from one source to another work, but then there’ll be a lot of logic behind the queries we send to databases. And this is why we cannot just unit test everything. We need to test our application with something real, something that behaves exactly like it would behave in real environment when we deploy it to production for our users. And for many years, the default approach was to do end-to-end testing by let’s say doing browser testing. And in that case, if you’re lucky enough to have a browser application as part of your product, you could just open a browser and use something like Selenium to click through the browser, to click through some buttons and verify what you see on your screen. That would work for a browser-based application, such as social network, Facebook, let’s say, but then it won’t be covering everything because if you think about it, we can only do the actions that are allowed by the UI. We can never send negative value to the H field because we have input validation. But what if someone, some hacker and you see how I’m connecting it to my hacking.

[00:20:03] SY: Yeah, bringing it back.

[00:20:06] SE: Yes. So let’s say a hacker sends a negative value to the H field or even not in negative, but some SQL query to hack the system. Obviously, we need to test that this works as well. We need to test that our application won’t break, but we cannot enter these values through the browser. So we need something in between, not as non-real as unit testing, but also some things that would let us do things that we cannot do with browser testing. And this is where developer folks are testing in a form of integration testing arises. That’s something in between. What if we write a test similar to how we do unit testing, but we start our application with a real database? And instead of using so-called mocks or stubs in our code, when we do unit testing, we will actually be sending queries to real databases. So that now which acts that if someone enters some malicious value to some field, our application won’t return the passwords for all our users.

[00:21:11] SY: What are some common things that testing helps catch? Are there kind of common categories of things that we might miss or issues, bugs that might surface just from getting in the routine and the habit of testing?

[00:21:26] SE: I would say it helps getting rid of assumptions because we developers who make lots of assumptions, not because we are doing something bad, just because the way we think, we think that things will work perfectly fine, for example. We expect computers to work the way we expect them to work. But in reality, things may differ and there are so many assumptions when it comes to using a database. And one could think that, “Okay, I will just send this query and I must be getting this result.” Right? Because that’s what I learned about this database from the books. And then apparently, you aren’t using the same version of the database. It wasn’t the books. And instead, you’re getting some completely different result because the database has made some changes, some breaking changes maybe, and you’re no longer getting the same result as you expected. And by running tests, especially integration test, one can convert assumptions into real facts about the behavior of their application and then no longer operate on assumptions but on facts.

[00:22:34] SY: So are there specific types of tests that everyone should implement based on their features or what are we testing exactly? You mentioned kind of assumptions. But is it really as we build out different features, we write the list of assumptions and test based on that? Or what does that process look like?

[00:22:55] SE: It is one type of test that I recommend everyone doing. it doesn’t really matter what kind of applications they’re developing or what this application is back end or front end or what’s not. But if I had to pick one test that should be in every test code base, then I would say an empty one. And it may sound surprising, but the point I’m trying to make is that a test that doesn’t have anybody, like any scenario to check any assertions, just an empty test, by writing this empty test, you aren’t testing your application. You’re testing your test setup. You're testing that your application starts and you're testing that your application is ready to perform assertions. And this is very underrated type of a test, it’s a tree you’ll want to have. But then Day 2 experience with testing, when you see a lot of test failures, one of the first things that you should check is whether the failures were caused by your test setup or by the implementation. And then if you see that that empty test is failing and obviously it should never fail, right? It doesn’t really matter how you change your application. An empty test should never fail. And if it fails, then we have a problem with our test setup. So we don’t need to spend time picking out what we broke in our application because we are not ready to assert whether our application is working correctly or not because our test setup isn’t correct.

[00:24:30] SY: Who should be doing this testing? Do you feel like developers who are part of the team, who are working on the features, do you think they should be the ones to work on these tests? Or do you feel like we need a designated testing team to take this on?

[00:24:46] SE: What we’ve seen is progress as part of the DevOps moment where a lot of ideas were shifted to the left, where a lot of activities were shifted to the left is the developers because that’s where it all starts, is developers on the left side. We noticed that testing rapidly getting moved to the left as well, because in 2010, it was common to use browser testing and to have a dedicated team of QA engineers, those who spend their time writing tests and running this test and not features. And it was fine. It worked for companies and nobody even thought about it as a problem, as a problem of their process. But then with the transition to DevOps style way of working on modern applications where more and more responsibilities are shifted to developers or at least align it with developers, people start to realize that, “Okay, but why do we have a dedicated team of QA engineers? Why can’t our developers, those who create the code, the original code, why can’t they test their code?” And I know that there are many jokes about the QA mindset. Usually the idea is that QA engineers, they have a mindset that helps them testing better because there are some jokes like QA engineer and there’s a bar and then he orders one beer, five beers, 9,999 beers, minus 3 beers and so on and so forth. And while I understand the joke, it’s important to test all the possible inputs. And when a developer writes a test, usually you would see like, “Okay, 2 plus 2 equals 4,” instead of testing, like what if I divide it by zero? What if I multiply it by negative value? What if something? But on the other hand, when developers started testing their own code, they realize that they don’t want to spend this what-if, what-if. What they want to do, they just want to randomize the inputs. They want to use something like property testing to be able to automatically detect possible values that would be entered that they don’t need to.

[00:27:00] SY: Tell me more about property testing. What is that?

[00:27:03] SE: So the idea is that you define the subject under the test as something that takes inputs according to a certain definition, and then the behavior of the system should be reflected by these inputs, by these properties. And trying to find a simple explanation because that’s a new concept even to me.

[00:27:26] SY: Yeah. Yeah.

[00:27:26] SE: But I would say in a simple form, when you think about it, you define your test not as something like 2 plus 2, but something that takes two numbers and provides a result. And then as soon as you define this as inputs and outputs, you can run an automated system to provide various types of inputs and assert the outputs without you having to log specific ones, like let’s say just 2 by 2 or something like this, but rather any number with any other number should be resulting in this number.

[00:28:05] SY: Yeah.

[00:28:06] SE: I’m not sure if someone from the property testing community will later blame me for this definition, but what I want to say is that I really appreciate this approach because I think that’s a great way to improve the coverage of your test or improves the quality of your test. And that’s what matters.

[00:28:23] SY: So where’s a good place to start? Because with testing, it can get really in depth, it can get pretty complicated. It can be very sophisticated, how far you can go testing. What’s a good place to start? What’s like the starter kit of testing?

[00:28:37] SE: My biggest suggestion would be to identify what you do to develop the software. And most probably, it would start with, well, I start my application and then I query this endpoint and then identify the scenarios and turns them into code. Just write code for that and it will be failing because you have nothing to start yet. So we need to figure out how to start your application. Then you need to figure out how to query some endpoints. But this will come with time when you’re working on your test. But the good thing is to not try to write everything at once. Let’s start simple. Start with something small, something that you’re already doing as a software developer. Just identify processes that you can automate and automate it with your test because that’s where the value of testing is, and that’s also how you understand how to follow the process. And eventually, you will be adding more and more tests just because you learned this process of automating the testing process, something that previously you were doing was manual testing. And as I said, we all do testing. It’s just a question of which one you prefer, manual testing or automated one.

[00:30:02] SY: Coming up next, Sergei talks about some of his favorite testing tools and resources after this.

[MUSIC BREAK]

[00:30:19] SY: And what are some good resources to get started, to learn a little bit more, get more comfortable with the lingo, get more familiar with some of these concepts before jumping in? What are some good places to dig in a little bit?

[00:30:31] SE: So what I can say is that Martin Fowler from ThoughtWorks would be a great source of inspiration about understanding all these various types of testing, how are they compared to each other, what’s the true definition of let’s say integration testing, what it means and how it applies. And there is an enormous amount of knowledge in his blog. And I definitely recommend everyone who thinks that testing is something they want to either learn about, where they want to improve their knowledge about testing, my recommendation would be to go for Martin Fowler’s blog.

[00:31:11] SY: And tell me about Testcontainers project, which is something that I believe you are a core maintainer of, you and your co-founder built it together. Tell me more about this project. What is it and how might it help people with their testing?

[00:31:24] SE: So Testcontainers, that was a project created by Richard North, my co-founder and our CTO, and start it with a simple idea. He noticed that while he was working on Deloitte Digital, he noticed that there’s quite some amount of repetitive actions that are required for the testing setup to be done among their customers. You start thinking what they can do to automate the test setup because it has a test but one big challenge of integration testing is how to start everything, how to configure your environment, how to get to application under the test running, how to get the system under the test running. And back then, six years ago, Docker was becoming more and more popular and also people weren’t ready to run Docker in production yet as compared to today. More folks started realizing that, “Okay, Docker is actually a great abstraction for setting up databases, brokers, browsers, and literally anything else that can run in Docker container.” And you know where we need this the most? Testing. So that’s what he did. He loves the idea of using Docker for testing, for setting up your test environment. And fast forward to today, it changed how we test software really. Because before Docker, before Testcontainers, it was common to assume that, “Okay, the best we can do is some unit testing and maybe tiny bit of integration testing, but then it would require us to install on our databases, on our developer’s machines and CI environments,” and nobody really wanted to do that. So we knew that this is the right thing to do, integration testing, but we always had this feeling that, “Yeah, it’s the right thing to do, but I don’t really want to do it because it takes a lot of effort and I would rather write yet another feature that may or may not work, I don’t know because I’m not writing my test.” But with Testcontainers, it becomes as to you as just making sure that you have Docker available. You have Docker somewhere and Docker becomes the only requirement for running integration tests and this dramatically improves the situation because it is much easier to convince someone to have Docker in their machines as opposed to all these databases that need to be written on their computers. And that was six years ago. And slightly less than one year since we started the project, I was working in ZeroTurnaround, a dev tool company in Estonia. And we kind of have our own Testcontainers but internally. We had the same idea. What if we talk to Docker directly from our tests and I keep repeating this story, but I really like it that it has this amazing feature, like I really like this feature. It’s one of the underappreciated features of GitHub, is the networking mechanism where you look at some issue and you see references from some other issues. And this is how you discover other open source projects. I have so many open source projects that I’m using daily now that I discovered from GitHub just by looking at these references from other repos. And I was looking at one of such issues with Docker and there was a reference to Testcontainers. And I was like, “Okay, I’m looking for a solution for my Docker-related problem for testing.” And I see a reference to Testcontainers. It does look like something I should check and I checked it and I was so happy to discover it as a library because what it was doing is basically the same as what we created, but we created internally and test container was an open source project, and I’m a big fan of open source. So a few days later, we started contributing to Testcontainers and eventually just migrated fully to Testcontainers and have been doing more and more contributions. And Richard invited me to join him as a co-maintainer. And ever since then, we’ve been working together and later Kevin joined us as well on this beautiful library. And when you think about it never, ever, ever changed since day one. It was always focused on one simple concept, how to help developers setting other integration testing environment so that they can focus on writing tests and code instead of spending their time talking to sysadmin how they can get Elasticsearch running with their CI environment because they need it for their tests and it shouldn’t be blocked by some system requirements or by some ops problems.

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

[00:36:22] SE: Yeah, I think so.

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

[00:36:27] SE: To stay low. It started at school really, and I grew up in Russia and the Russian teachers sometimes tell you that, “Okay, don’t be the one everyone is talking about. Just be like anyone else. Just be part of this group of people. Don’t be an outsider. Don’t be someone people notice.” Because they always think about it in a bad way that you won’t be the one who will be noticed for something good, but rather something bad. And the thing that was the bad advice, and I’m happy that I didn’t listen, I didn’t listen to many advisors when I was young, but the bad part about this advice is that it stops creativity. And it makes you start looking for ways how to not be unlike others, how to not be creative, how to stay low. And this isn’t good because we’re all creative and we need to unlock our creativity. And that’s what helps us be successful and progress in our lives.

[00:37:24] SY: Number two, best advice I’ve ever received is?

[00:37:28] SE: The best advice I received, I received from my parents, challenge everything around you, and this is related to my learning process as well. I mentioned that I challenged current status. I challenged the way it is and I think this is what helps us to innovate. It helps us to create new things. And without this idea of challenging the current implementation, let’s say, we would never get iPhones where we just get rid of the keyboard or its NUM pad. It was something typical for phones back then, but then someone famous said, “Hey, let’s just get rid of it. Let’s just make it the single touch screen.” And nobody would think that’s a great idea. And now every single phone out there, it’s just one big touch screen.

[00:38:18] SY: That’s so true. Absolutely. Number three, my first coding project was about?

[00:38:24] SE: Doing a 3D game in Borland Pascal.

[00:38:29] SY: Oh, cool!

[00:38:30] SE: Yes.

[00:38:30] SY: That sounds hard.

[00:38:31] SE: I know. But I was able to render a queue and I was so happy about it because it required so many formulas that I had no idea how they work, but it is what it is.

[00:38:45] SY: And number four, one thing I wish I knew when I first started to code is?

[00:38:50] SE: That it isn’t about code. It’s really about people and soft-skills and interactions and understanding people better because this was crucial in making progress in my career that okay, I can learn every programming language in the world, but unless I know how to communicate with people, be it learning English or learning people’s emotions, I would never be where I am today. So unfortunately, coding isn’t about code, but of course, some part of it is.

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

[00:39:27] SE: Thank you. I truly enjoyed the conversation.

[00:39:36] 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