[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 essential skills you’ll need to be successful in your coding journey with Fernando Doglio, Data Engineering Manager at Accenture and Author of the book “Skills of a Software Developer”.

[00:00:24] FD: Pick one that’s already been done. Don’t reinvent the wheel or don’t try to be original for your projects. You’re not trying to disrupt the industry. You’re trying to learn something.

[00:00:35] SY: If you have a question for Fernando 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 threat on our homepage and he’ll answer you directly in the comments. That’s community.codenewbie.org. In this episode, Fernando talks about the importance of learning computer science fundamentals, misconceptions early career developers have, and how to tackle the personal side of coding after this.

[MUSIC BREAK]

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

[00:01:15] FD: Thank you for having me.

[00:01:16] SY: So Fernando, tell us about how you first got interested in coding.

[00:01:19] FD: I got interested in coding almost 20 years ago, essentially because I started browsing the web with the modem I had, and I was 14 years old. And essentially, I started learning and read about hackers and what they did and fell in love with the idea of hacking. And the more I learned, the more I understood that I had to learn how to code to be one. I started picking up any and all tutorials and anything that will teach me or give me some guidance as to what should I learn and how to code and what could I do with it, and eventually just forgot about everything else and kept on coding.

[00:01:58] SY: And how did you go about learning to code? What resources did you use? How did you start that process?

[00:02:05] FD: It was a hit or miss to be honest. Back then, the internet to me was really new. We didn’t really have Google actually, if I remember correctly. It was a lot of Yahoo and AltaVista as well. And what I did was, again, look for whatever I could find in Spanish because I didn’t speak English back then, and trial and error, lots of it, to the point where I started reading about programming languages, trying to pick the right one to start with. And I learned about low-level languages. So I thought, “Well, if it’s low level, then it’s for beginners.” So I started with assembly language.

[00:02:42] SY: Wow!

[00:02:43] FD: Yeah, the opposite of what you want to do.

[00:02:45] SY: Yeah. That’s a place to start. Okay.

[00:02:47] FD: Yeah. Yeah. So I kind of ate one huge manual about it that talked about it or registries and processors. Eventually when I finished it, I think I wrote like a Hello World, very basic Hello Word with a lot of lines. Then I kind of picked up from there C and I started actually coding in C. So that was my first love, essentially C. Then I did a lot of “game programming” back then and I did a few games in C and then tried other game development specific languages and kind of did my coding journey through those until I guess I was 18 when I started web development, which I was creating HTML on and just went down the hill from there.

[00:03:33] SY: Now take me through the process of getting your first job in code. What was that like?

[00:03:38] FD: It’s scary. So I was lucky enough to start my professional journey coding. Right? It’s not like I had to have other jobs and then go from there. But back then, there weren’t really any show portals. And if there were, there wasn’t anything that I didn’t know about it. So essentially it was me every Sunday, checking the newspaper for ads, companies looking for junior developers and trying to figure out any of the skills that I had to pick up from those ads. And then if I knew enough of them, I will just send my resume over email. I remember I had a Word document with my resume, and because I didn’t have any experience, but the idea was I also created the HTML version of my resume.

[00:04:21] SY: Oh, cool!

[00:04:22] FD: Yeah.

[00:04:23] SY: The original LinkedIn, the OG LinkedIn. Yeah.

[00:04:25] FD: Exactly. So I would zip both and send everything, hoping they will get an interest. Eventually, I got a reply. I went to my first job interview. It was interesting. I was honest. I had no experience. I had no idea how much they would pay me. I was completely honest. I didn’t get the job. They’d said no. And then a week later, they called back and say, “Well, actually, you know what? We’ll hire you.”

[00:04:50] SY: Okay.

[00:04:50] FD: I’m sure they do because they realized they were missing an opportunity on cheap labor.

[00:04:57] SY: They did some market research and decided this was a good option. Yeah.

[00:05:02] FD: But I mean, it was a start of my journey. I mean, I learned in that company, eventually I learned I had to leave as well, but I made a lot of friends there as well. So it was a really nice start actually.

[00:05:13] SY: Where did school fit into all of this? I know you said you started in code and kind of first got interested at 14 and you’ve been doing this on your own. Where did formal education fit into your journey?

[00:05:25] FD: By the time I actually reached college, I thought I already knew how to code. Then I realized I didn’t. I mean, I had written a lot of C, but I had no idea how pointers work. I was using HTML, but I didn’t know what it really meant. I just knew what my few tests have given me. So I threw my few years of college. I learned a lot to the point where I got my first shot, which is the one we were talking about. Eventually, I dropped school. I couldn’t deal with college and a full time job at the time I wrongfully thought I knew enough. I’ll drop school and then I’ll continue working and learn everything on my own because I don’t need the college title. I did learn a lot through my experience in that first job, but eventually I realized I was still missing things that I wasn’t able to pick up on my own. I’ve always been good at learning on my own through experience, but because I have one specific project or what goal is something that gets me through that experience. So I pick up knowledge in between, but if just learning because there’s a topic I’ve never seen, that’s not something I know how to do. So I decided a few years later to go back to college, get my degree and get that formal education essentially and pick up those concepts that I wasn’t getting on my own. And I never worried actually. It helped me in my confidence actually as a developer. It helped me grow as well. It humbled me essentially. I was thinking that I could build my career on my own, I realized I actually needed that extra boost.

[00:07:15] SY: So I want to dig into that a little bit because that’s an ongoing topic of debate, conversations on our show of, “Do you need a computer science degree? Do you need to get a formal education for this? Or is this something you can do on your own?” And what I have heard from people in the past about getting that computer science degree is that it is mostly about confidence that most of the value of the degree is about being confident as an engineer and moving forward into your first job, into your career, knowing that you did it. You have that degree. You have that certification and you feel confident in what you’re doing, but I’ve also heard that when it comes to things like you mentioned pointers and kind of other behind-the-scenes, low-level concepts, when you actually work in the industry, you’re not dealing with pointers most of the time, right?

[00:08:09] FD: No.

[00:08:09] SY: Like you’re dealing with things that are a little bit more higher level. And so the education doesn’t directly translate into a job. So I’m curious, what was your experience and what might your advice be to people who were considering, “Should I go back to school? Should I learn on my own?” What are your thoughts on that?

[00:08:24] FD: Right. My experience and what I believe is you don’t need a formal education to get started as a developer. You can just pick up coding from a YouTube video. Whatever works for you, a tutorial, whatever, you’ll be coding in an hour, two hours, and you’ll start picking things up on your own. From there, it’s completely possible and you don’t need a bootcamp. You don’t need anything. But if you want to know the basics, if you want to have that strong foundation that gives you that confidence to go out and discuss technical subjects and create architecture or a scalable platform or grow and scale to the point of being able to hold the conversation with anyone honestly. That is where formal efficiency has a huge place. I’m not saying you can’t do it without it. I mean, a lot of people can and they’re very capable and very smart, but I believe that the average Joe will need it if they want to take that next step. And to your point, you don’t need to learn React in college. You need to learn programming. You need to learn coding. You need to learn the basics that everything else is based upon. Or in turn, you’re not going to deal with them unless you do some very low-level coding in your day job.

[00:09:42] SY: Right.

[00:09:43] FD: Algorithms and data structures like Rust or linked list or something like that, you don’t really deal with them. But the point of learning them is for you to practice abstraction. We as coiners are constantly taking real world problems and concepts and attracting them into imaginary things. There’s no such thing as a variable. You can’t grab it and pick it up. It’s on your head. And the more practice that you have abstracting and thinking obstructions and solving problems through abstraction, the better at coding you get. That’s I believe why we have to go through those. Even in high school, you’re learning math and you’re thinking, “I don’t like math. Why am I going to learn how to solve a third-degree equation? I’m never going to use that.” That’s true. You’re never going to use that. But the exercise of solving it is opening up your mind and giving you that mental flexibility that you need for real world problems and the same applies to that kind of basic and low-level learning that we do at college. But when I was studying college in Uruguay, the first language that we will pick up was Modula-2. It was kind of a PASCAL kind of language, but you couldn’t find it in any system in production. It was just meant for learning. And from there, I think it was Modula and Modula-2 and then eventually you move out to C. In the industry, you’ll work with PHP, JavaScript, and other people were complaining that you didn’t learn anything practical in college so that you could directly map it into a job, but that wasn’t the point. The point was you learn the basics, the foundation, and then you can pick any language to be honest. If you learn proper object orientation, you can pick any OOP language. If you learn functional programming, you can pick JavaScript, you can pick Python, and go through them and follow that paradigm. The foundation is what you need to take that next step, and I think that is where my vision comes into place.

[MUSIC BREAK]

[00:12:06] SY: So let’s get into Skills of a Software Developer, which is your book. What was the inspiration behind writing this book?

[00:12:13] FD: The inspiration for that book was actually an article I wrote on Medium. There were nine lessons I learned through my area essentially. It covered things like learning to control your ego as a developer, understanding that the last 10% of our project is like 90% of the work. And that article got nice reception from other senior developers. Eventually, I guess it landed on the monitor of the recruiting editor in Manning and they contacted me and see if I wanted to turn the article into a book.

[00:12:47] SY: Another benefit to blogging. You might end up being an author.

[00:12:49] FD: Absolutely.

[00:12:51] SY: Nice. So what are some of the big misconceptions that early career developers have about being a developer? Where do they kind of go wrong?

[00:13:00] FD: Well, I mean the requirements to get into the industry, a big misconception, that association that everyone hears about where you say you’re going to need a lot of math to become a developer or the fact that you need a formal education and you’ll have to go through four or five years of education to become a developer. Those are big ones that I don’t personally agree with. The full set of skills, essentially, that you need to become a successful developer are not technical. Technical skills you can learn and you can learn through reading CC compared to learning how to solve problems or learning how to learn essentially. These are skills that you’re going to need throughout your career and you can’t really read a book and say, “Well, now I know how to learn.” You may get the theory, but you have to go through it and you have to essentially kind of switch your mindset to it. That’s kind of why I also discussed in the fifth chapter of the book about these misconceptions and what I think about what you really need.

[00:14:06] SY: And what are some of those big things that people need to know when they first start their coding?

[00:14:12] FD: Usually start with a goal, but if your goal is not about building something, then you have to start picking up whatever catches your eye and just your interests. If it’s web development, game development or double-level programming, whatever, robotics, you have to not know things, but you have to be interested in creating essentially. If you’re into creating things, if you’re into solving problems, if you’re into learning, then those are the things that are important to me when it comes to assessing someone is going to be a good developer or not. Not that I do that, but if I had to, I would value a lot more someone who’s very interested in those kinds of skills than someone who just read a PHP manual and now knows how to write PHP, but that’s what we get from it.

[00:15:03] SY: I think one of the most difficult parts of becoming a developer is navigating the learning process because you mentioned back then that it was really hard to learn on your own. With these days, it’s almost overwhelming how many options there are to learn on your own. There are so many books, websites, tutorials. A lot of them are free or a lot of them are just very cheap. I’ve heard from a lot of people that they get decision fatigue, they get into tutorial hell, the issues, it’s just a lot. So when it comes to navigating the learning process, what are some things that might be helpful for new developers to keep in mind as they figure out how to learn and how to develop those skills?

[00:15:43] FD: Well, I think that the key is, instead of finding that tutorial and then trying to build something around it, I would go about it the other way, decide on what you want to build and then hit the first wall and try to find a solution to that problem, whether it’s through a course, through an article, through a video or whatever because that way you can reset that for your learning. You don’t get that many choices then because you have to figure out the first step of building a web server. Then that’s what you look and you’ll get very specific solutions for that problem. You pick one and move forward until you hit the next wall. And that way you progress faster, you have less indecision as to where you go next. And once you’re done, you pick the next project. And the key here is that trying to figure out what’s the best project to learn. And it doesn’t really matter the project. In fact, I usually recommend pick one that’s already been done. Don’t reinvent the wheel or don’t try to be original for your projects. You’re not trying to disrupt the industry. You’re trying to learn something. So what better option than to copy someone else's project or usually don’t go and copy their code, but copy the idea and try to reverse engineer how they wrote the code. You have every single feature already done. So you know how they work. You know the extent of the project. You don’t have scope creep, if you will, trying to add new things that or knowing exactly where to go from where you are right now, you have already a preset path. You can get all of those skills for free. If you’re more of a learning through courses kind of person and you’re actually willing to pay, there are sites that I think that will give you a path.

[00:17:32] SY: Those are really helpful.

[00:17:33] FD: Exactly. So you also have a preset set of courses that you will take. So the indecision or the analysis paralysis, if you will, gets removed and you know where to go for the next step.

[00:17:46] SY: One of the parts about getting a job that’s really scary for new developers for that first job is the idea of working with other people. When you’re alone, you’re by yourself, no one knows what you know and what you don’t know. Right? It’s very safe. You can have a lot of knowledge gaps and it’s not a big deal, but when you have to code with other people, that’s when it becomes really scary. What are some things that people might want to keep in mind when working on a team for the first time, maybe doing a pair programming session or maybe doing a code review? What might be helpful for them to keep in mind when they’re in that situation for the first time?

[00:18:26] FD: It all boils down to remember that you’re not alone, you’re actually with other people. So everything has to be done around that idea. Coding needs to be done around the idea that other people will read it. So I always say that code needs to run in the machine, but be read by people.

[00:18:45] SY: I like that.

[00:18:45] FD: If you’re not doing both things, then your code is wrong. So that implies keeping away from cryptic one liners, writing actual readable documentation or even comment, co-commenting is something that we tend to assume is not needed, but it’s actually a lot of help, especially for you in the next three days or for people in the next five months, someone else coming in and trying to maintain your code. I used to have a coworker that said, “You have to go like a crazy person. It knows where you live essentially and then I read your code.” So you want them to be happy about it. You want them to understand everything you wrote so they don’t go looking for you. In Spanish, it was funnier, I promise. That’s my first advice, always thinking about others, not just you, and then coding reviews, that’s a huge issue. And for people just getting started, it’s very scary as well because they take it personal. And the first advice here is understand that a proper coding review should not be personal, they’re not attacking or your intelligence or anything. They’re just trying to give you ideas as to how to improve, show you the mistakes you probably made, and that’s completely normal. Making mistakes is part of the learning process. And it’s for you, as a developer being reviewed, it’s a full learning process, that review alone. So the more lessons should come out of it, the better for you as well. So it should be something that you look forward to. Not something that you’re scared of.

[00:20:19] SY: That’s a big ask, looking forward to a code review.

[00:20:21] FD: I know. I know. I know.

[00:20:24] SY: I don’t know if a senior developer is looking forward to code reviews, but I do like that because I think that whether we’re new or more seasoned developers, if we look at code reviews as a learning opportunity, I think that might help. If we kind of reframe the idea more from a critique or maybe not so much a review, but a lesson, an opportunity to see how we did and see how we can improve and take it as more of an educational opportunity, I think that might be helpful. So let’s talk about soft skills. So we talked about making sure that you keep in mind that these are people reading it and that you want to make sure you’re not too clever or trying to be too smart and end up writing things that are too abstract or just too difficult for humans to read. What about soft skills? What are some soft skills that people need to maybe work on or develop when it comes to joining a team?

[00:21:23] FD: You would essentially need to, first, if you’re not a social person, to be social with your team. And I’m not saying you should go out and party with them. Connect with them at some level, especially when you’re new and starting in a new company, even if it’s your first job, your first company. Usually the very best are scary bunch sometimes, especially looking from outside, but they tend to be open. They tend to be welcoming to new people. So things like the lunchtime. Don’t go out to a corner and eat for yourself. Go with the team. Try to ask questions or don’t stay with monosyllabic responses of yes or no when they ask you questions. They want to know you. Let them. And I know it’s a big ask and I’ve been through it. It took me probably 10 years to understand that one, but it’s key to joining a new team, especially a big team when a lot of relationships and other roles, essentially social roles are preset. So that’s one thing. And one thing that I tend to also recommend that will help in that regard is to write alone. The average developer, I don’t want to internalize, but the average developer will have a harder time speaking in public than writing. We know how to write code. Going from writing code to writing a technical article, it’s a very smaller step compared to going into a meetup or a conference and speaking up in public. So I try to recommend writing to every developer because through their writing, through the exercise of explaining the concept, accomplished concept so that others can understand it, you develop your vocabulary, you learn how to express yourself a lot better than you can without that exercise. If you only write code, I’ve met a lot of developers that are kind of machines essentially and you can interact with them to a certain level and no more. It’s not like they don’t want to. It’s just that they don’t know how to communicate with other people. They feel more comfortable with the computer and that’s because they just focus on the code and they didn’t open up to other ways of expressing themselves. I believe that through writing and it doesn’t have to be books, you can just open up a medium account and start writing technical articles there. And the point is not to get money. It’s not to get views. It’s not to get followers. The point is to practice that way of expressing yourself, even if it’s just through writing. Next time, you’re going to be speaking up. Even if it’s just to a colleague, I believe you’ll have a richer vocabulary, if you will, and it’ll help you to express whatever you want to say to them. On the social site, that will help you and in professional side as well because you’ll be able to explain not just to your colleagues, but to your manager and potentially clients, whatever you have to do or whatever the team has to do, and that’s also very valuable. Not a lot of the developers know how to correctly express themselves. So that’s a very rich skill to have.

[00:24:56] SY: Coming up next, Fernando talks about what developers need to know about working well remotely after this.

[MUSIC BREAK]

[00:25:20] SY: So let’s talk about what working well with others means when it comes to working in today’s times, which is largely increasingly working remotely. And now our primary form of communication with our peers is often Slack and the occasional, hopefully occasional, video calls, Zoom calls. And so when we talk about working well in a remote environment where you can’t see people’s facial expressions, you can’t tap them on the shoulder to ask them a quick question, at least not in the same way. What does working well mean? What does it look like in a remote capacity?

[00:25:57] FD: Being conscious of the fact that you’re remote and that not everyone is probably sharing your time zone. That’s a big first one. Depending on your team, you may be all sharing the same time zone or you may be working with people from all across the world. So if that is the case, then you have to figure out the kind of communications you want to have with them. Is it synchronous or asynchronous? Are you okay with sending an email and getting a response the next day? That kind of dynamics is meant to be defined by the team or the manager or the company even before can you reach that team, but you have to adjust to it. You can really send an instant message to a person on a time zone where it’s 2:00 AM right now. That is social courtesy, if you will. Then you said you can really see someone’s facial expression. It’s true. A lot of people, me included, we don’t like to use a camera, but if you’re joining a new team, if you’re getting to know people, you need to use a camera, even though we are remote, we’re still people. We need that extra communication. Communication experts actually say that whatever you say the message that you're transmitting through whatever medium is the smallest percentage of the overall message. I don’t know if I’m explaining it correctly, but you see a lot more through nonverbal communication than through your words, essentially. So if you block that part, when people are trying to get to know you, they’re going to have a lot of hard time doing so. So my recommendation also for people showing in a remote team and getting to know their teammates is even if you don’t like the camera, just have it at least for the first week, week and a half, and then you can just put a nice picture there and then close it. And the biggest recommendation I have is respect other’s times, not in the sense of respecting the time zone, but the meetings. We go through a lot of meetings and we tend to hate meetings because they tend to be a waste of time. But that is because we don’t or not just we, but everyone, misuses meetings to catch up on people or talk about things instead of using the meeting for whatever the meeting was meant to be. If the company’s remote friendly or even remote first, they’re going to have social gathering through meetings, kind of like weekly coffees or whatever. So you can use those kinds of minutes to socialize, to catch up with people. But if you’re having a call with someone else on the other side of the world, try to be on time, first of all, a few minutes earlier if possible so the meeting can start on time and then restrict yourself to speaking about whatever is the subject of the meeting. So everyone at the end of the time slot reserved can close that connection and say, “Well, actually we did something. We progressed, whatever, probably solved the problem we had.” If you don’t, if you digress and talk about other things, then the meeting meant nothing honestly. The perfect example is daily meetings. We know daily meetings, they’re supposed to be really short and the stand-up is supposed to be like 15 minutes or less, but I’ve had daily stand-ups for one hour and they’re not really helpful. The two people who are actually speaking are paying attention and the rest is doing something else. That is not a valid use of a meeting.

[00:29:22] SY: Yeah. Absolutely. So I want to talk about a couple of other chapters in your book dedicated to unit testing and refactoring, which are kind of key things that we might not do when we are learning on our own, when we are practicing to get our first developer job, but on the job can be very important. Tell us about first of all what these things are. What is a unit test? What is refactoring and why you dedicated a couple of chapters a decent amount of space in your book about them?

[00:29:51] FD: Right. So the book doesn’t really cover technical aspects other than this. And the reason why I picked them was that kind of what you said. I mean, they’re not specifically tasks that you would pick up on your own when you’re working or trying to learn the few skills that you need to get the first job, but they are crucial and they are very powerful tools that if you don’t use properly, you can make amends with them. So for our unit testing, what I cover is essentially what it is. You’re testing a section of your code and what a unit means and what it means to test code that depends on other things like a database or a file I/O or a disk I/O or even a third-party API, how you will go about it and best practices around how to write proper unit testing. I actually cover as well what a mock is, what a stab is, what a spy is.

[00:30:47] SY: Nice!

[00:30:47] FD: Everything you need, essentially is an introductory because it’s just one chapter within a full book and there are four books about unit testing, but you should know enough to head to your first unit testing task and actually go about it the right way. Not just winging it thinking that writing a unit test is just as writing a feature. There are differences. There are some best practices. There are different things you have to take into consideration. So that’s why I try to cover it. And the same goes for refactoring. Refactoring is not just about changing a piece of code. There is a planning process involved. There is a way to do it if you’re actually doing it while the rest of the team is working on the same piece of code that you are. So there, again, best practices and considerations to have when doing this. So I try to cover these. I try to cover things like dependency injection, actually for testing as well, things like DRY and SOLID principles, things that give you an idea of why you will refactor code, what to look for when you’re trying to improve your cost through refactoring and when you should actually not refactor and avoid that.

[00:32:04] SY: So you also have a chapter in your book called “Tackling the Personal Side of Coding.” What do you mean by the personal side? And when does that come up in your coding journey?

[00:32:15] FD: From Day 1. So coding can become your life if you let it. So there is a big problem with burnout. People, especially actually when they’re working remotely, because they just never stopped working. They have to do their tasks for the company. Then they have to learn something new. They’re working on their side project and then they go to sleep and start over the next day. There’s a lot of work-life balance to take into consideration when you’re trying to get your first job, pick up a lot of new skills and improve the ones that you have, how you learn, where you learn, how to tackle side projects in a way that they don’t consume your free time, and those are the things I try to cover in that chapter and then how to keep your mind healthy while still improving your skills.

[00:33:17] SY: You know, 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:33:24] FD: I am.

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

[00:33:28] FD: Don’t take that job, my first job, the one we discussed. Like I said, they want a cheap labor. So the salary they offered was very low. I mean, it was a lot higher than I was making because I wasn’t making anything. But still, I mean, it was actually my father who gave me that advice. He told me, “Don’t take it. Just keep waiting for the next one.” And I’m lucky enough that my girlfriend convinced me to actually take it. “If you’re not doing anything, you’re getting a better experience through it even if it’s for a very low salary.” She wasn’t wrong.

[00:34:03] SY: Best advice I ever received is?

[00:34:06] FD: Best advice was leave your problems at the door. I actually got that one on the first job as well, same company, but from a very angry businessman who was just tired of us, junior developers, not being able to separate personal issues with our coding tasks and are causing issues. So I honestly heard that one. It clicked on me. You are not meant to make those things. And if you do, I mean, that’s where you start going down the route of not being able to stop working and your problems in your work or in your project affecting you and the other way around, problems that your social group or personal life affecting your work. You are a single person. You are the same person acting in both places, but you should be able to mentally separate those things so that you can work and be proficient in your work without letting the outside things affect you and you should be able to deal with whatever you have to deal in your personal life without letting the work affect you. I mean, those are very simple things that can affect your social life, everything. So that’s one I always try to use especially to young and junior developers.

[00:35:27] SY: Number three, my first coding project was about?

[00:35:30] FD: So my first coding mid-size project, because I went through the whole Hello World thing, so it doesn’t really count, but my first medium-size project was a graphics library meant for game development written in C. Like I said when I was learning, back then they didn’t teach you the things like that. So I started learning little things with graphics and change the video mode in the video current, things like that through coding. So I started like grouping things and trying to come up with a toolset that will let me then create video games. So I kind of wrote my first library that way. It was a really fun time.

[00:36:15] SY: Very cool! Number four, one thing I wish I knew when I first started to code is?

[00:36:20] FD: Keep learning new things. Right now, I’m always trying to learn new things and I’m the first one to tell you, even if you’re working with JavaScript, it doesn’t hurt to know how Ruby works or how PHP works, I don’t care, or assembly. Anyway, you’re not going to use it. But you're going to get a fresh view of how you can solve the same problem that you’re solving right now and challenge people or whatever with a different language, and that might give you ideas or insight into a whole different world that you never knew about, a different paradigm even. But when I started working, I spent probably three to four years just with PHP. That was all I knew. I didn’t even think about learning something new, because that was all I needed, the company I was working for who are using PHP. So that’s why I had to learn. Eventually I went out and got another job for another company and it kind of flipped my mindset and I started learning more. I even picked up 11 languages and I kept on learning and I saw the potential of it. So that’s why now I tell everyone that even if you’re not doing, I don’t know, functional parameters, you should know about it from a practical point of view. Just figure out what it’s all about. Pick up an easy language that works with it and do some tests. That’s all you need, but it’ll give you a different point of view essentially that you didn’t have before, and that’s very helpful.

[00:37:49] SY: Yeah. I like that. Well, thank you so much for joining us, Fernando.

[00:37:52] FD: Thank you for having me. It was really fun.

[00:38:01] 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.