Loc Nguyen, full-stack developer at Productify talks with Relicans host Ali Diamond, about learning processes and what has allowed him to be able to master various programming languages, what is currently missing in developer education, and things he does personally to be the most productive developer he can be.
Should you find a burning need to share your thoughts or rants about the show, please spray them at email@example.com. While you’re going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you’d like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @PolyglotShow.
Jonan Scheffler: Hello and welcome to Polyglot, proudly brought to you by New Relic's developer relations team, The Relicans. Polyglot is about software design. It's about looking beyond languages to the patterns and methods that we as developers use to do our best work. You can join us every week to hear from developers who have stories to share about what has worked for them and may have some opinions about how best to write quality software. We may not always agree, but we are certainly going to have fun, and we will always do our best to level up together. You can find the show notes for this episode and all of The Relicans podcasts on developer.newrelic.com/podcasts. Thank you so much for joining us. Enjoy the show.
Loc Nguyen: Yeah, so I'm Loc. I've been in software for 16 or 17 years now. I'm currently working at Productfy, a Fintech startup. And I program in a variety of languages, and these are languages that I've picked up over the years at different jobs. I think what's great about being a polyglot developer is it lets you express your ideas in multiple ways, and it builds a lot of empathy too. As I learned different platforms and languages, I started appreciating the, I guess, design patterns you see in other languages. I started out in Java, and a lot of people say it could be heavyweight and verbose, and they're probably right. And I went to Ruby on Rails, and it was the complete opposite. Everything is so really beautiful and opinionated, and it's just easy to use. But even when I was deep into Ruby on Rails, I started missing some of the things I had in Java that verboseness made it very easy to onboard. The typed language made it easy to have incredible tooling. By moving from platform to platform, gave me a lot of perspective and it made me appreciate any decisions that language designers had made.
Ali: I totally understand what you're talking about. My first language was also Java. And then from Java, I went to Python, and it was a huge shock because I was sitting there reading over these files, especially coming from Java, I was like, what type of variable is this? I don't understand. What's going on?
Loc: Yeah. And why are the variable names so short? It's not like do this and that with this permission. The variable names were always shorter and the function names were always shorter, and it's always easier on the eyes.
Ali: Yeah. So one of the things I thought was interesting from your intro was you talking about empathy. And I was wondering if you could expand on this empathy that you're talking about.
Ali: Yeah, I totally get it. I know the frustration of just sitting there and looking over someone's code and they're like, “Oh yeah, it all makes sense,” when people are self-documenting code.
Loc: Right. Yeah.
Ali: No, it's not self-documenting.
Loc: It can be frustrating because you know in Java I used to always complain why are these names so long in Java, or why do I have to type every argument? And when you don't have that, then you start appreciating those attributes of a programming language. And if the code is self-documenting in Java, then maybe the Java docs aren't that important. But Ruby docs are going to be important or JS docs are going to be important where languages don't have that typed information.
Ali: I will say though, the Java docs, specifically the Java API, when I think of a well-documented API, I always like, look at the Java, look at the Java documents.
Loc: Yeah, it's really amazing. And it's really relevant because in my current job, I am getting back into Java and I couldn't remember all the string APIs, and I just clicked on MID, and here pops up the full documentation, and I could read everything. That developer experience is amazing.
Ali: It's so good. It's so under-appreciated. And when I think of good documentation, I think Java documentation. And talking about looking through all these different languages, I'm curious what have you found to be helpful for transitioning from language to language especially this being the Polyglot podcast. How to write in many different languages is really, really awesome but transitioning from language to language has a lot of effort that you have to put into it. So I'm curious, what do you find helpful? What do you find makes it an easy transition? What have you found to be a repeating pattern? I'd love you to talk about that experience more.
Ali: So you create a full, functional, secure login system.
Loc: Yeah. I don't know how secure it actually is.
Loc: Yeah. It gets me pretty far. And once I can figure out how to make that user management API, then I can start building on top of that. So now it's like I'm building a project’s API or a list API. So it's more than a to-do list.
Ali: Yeah, that's actually a really great idea. That's super actionable and replicatable. And say you're someone just trying to learn as many languages as possible, you could literally just write a spec doc and build it out for each language. I had this friend in college who was convinced that the way to impress recruiters and also learn a language was to write ‘The Game of Life’ in every language and put it on your GitHub.
Loc: Wow, that is a lot of work.
Ali: And they had it in six languages on their GitHub and they're like, “Yeah, it was easy.” And I'm like, “What? Okay.” Touching back onto something that you said earlier, you talked about the learning process, and I would love to dig in more into your learning process and what has allowed you to be able to master these various languages, and what have you found to be universally applicable?
Loc: I know everyone has a different learning process. Some people learn just by watching videos or reading books, and I'm really jealous of that. For me, I have to grind through it and actually write the code, use the language, grind through the documentation. Giving myself a real project helps me retain the information, and it helps me really explore what the language can do not just the language but its ecosystem. Going back to that user management/authentication example, when I do that, I'm learning. I'm going to have to do a lot of research about what kind of HTTP libraries are popular in the language so whether that's Node like Express or Hapi and Node or Gin and Go, or Sinatra or Rails in Ruby. It lets me explore what the ecosystem has. And then it's kind of a rabbit hole, but I'd read a lot of that documentation then I start applying it. And now I have a template for any language I want to learn.
So first I want to look for what libraries are popular. How do these libraries process Post Bodies? How do they deserialize JSON? How do we get these attributes or the data into these models? How do they persist the database? So I know I want to persist data to a database. Now I got to look up how developers make database connections. Do they like to use ORMs, or do they just like to use SQL builders? There's so much. So now I've got the database connection made. Now I'm thinking maybe I want to write some integration tests. So how do developers in this ecosystem write their tests? There's just so much you can do just by trying to, at least for me, to solve a well-known problem. I think it's a common problem wherever you go; you got to have user management.
Ali: That makes sense. One of the things that I personally I’m not frustrated with but I see a gap in education when it comes to learning to be a developer is what you'll get is they'll tell you “Go do these tutorials, “but the tutorials will be like how to think like a developer in the sense of you go you do an intro to Python course, and it tells you how to write for loops and how to write if...else statements. But then you're like, okay, now where do I go? Where do I start? And you look for the next in the build, and they don't actually teach you the concepts. They just teach you how to get to the final destination if that makes sense. They'll tell you “Hey, type this in.” But if you're making a to-do list, they'll be like, “Hey, type in an input and then use this input and store it in your database.” But they don't explain to you what's going on in the sense of how you're storing to this database. What are these HTTP methods that you're using? What's the GET request and the POST request that you're using and how these concepts roll over and the deeper level of understanding. Say you're writing in Node.js, what are the routers and how do those concepts roll over to other languages?
Loc: I think what's missing in developer education is sure, all these tutorials tell you exactly what you need to do, but there's no one there to tell you why you do it. And I think that's probably a big missing piece is why are there verbs? Why can't we just have one verb? Why is there JSON, and why is there XML? I think that's an important part of developer education that's missing when you're just going through these tutorials.
Ali: I don't expect an exact answer because this is a question that has plagued my mind for years. Since 2014, I have been thinking about this issue, and I've made zero progress. I know this.
Loc: Whenever I'm learning something like a new framework or a new language, I do find myself asking the whys. Why does React do this, or why does Vue do that? And I don't have someone sitting next to me who can answer that question. And it's almost like I need a mentor or someone to pair with right next to me the whole time I'm learning, which I know isn't realistic, but it would be great if I did have that person. Having that person explain it to me helps me map what I know from my past experiences to the new experience I'm trying to learn.
Ali: Definitely. I definitely understand. If you don't have that person next to you, you're sitting there you're like, okay, there's this word I don't understand. And you search it on your search engine of choice and then all of a sudden, you're down this really complex rabbit hole that's talking about the way the language is interpreted and running all these commands that you've never seen before, and it's just breaking that first layer is hard. And I really want to dig into that more especially given your experience across so many languages.
Loc: Yeah, and it feels inefficient the way we're doing it. I remember going from Angular to React. It was hard but over time and through much, I guess, reading, I was able to map concepts to Angular, but it shouldn't have been that hard. I feel like if I had that mentor sitting next to me just explaining it as I go, it would have been so much faster. And I wonder why can't that be the normal thing we have where we have someone to always guide us or chauffeur us through to that new language or new environment? Now that I've been able to do that multiple times, it gets a little bit easier and easier over time, but it's still inefficient. If I was to pick up Rust, I'd be asking myself the same questions. Why does it happen this way? Why are we doing it this way versus how we do that way in TypeScript or Go or whatever?
Ali: To feel proficient enough to write in a language professionally so for your job, what level of understanding would you recommend someone having to be able to walk out and be like, “Yeah, I can do that for you.”
Loc: I think if you start solving the problems in the language and you feel sufficient with navigating the documentation, like being able to write a test for it or communicating your ideas to someone who's going to review your code, that's probably a good sign that you're ready to use that language in production. Maybe you don't want to take on the most complex task in your backlog, but I think when you can navigate documentation and explain your ideas that you wrote in that new language, I would say you're ready to start contributing.
Ali: So then you sit down, you're at your computer; it's day one in a new job. What are you setting up in your computer to make sure that you are successful?
Loc: I'm going to probably reach for my favorite IDEs. It's either VS Code or any of the IDEs by JetBrains.
Ali: Is there anything you do to ensure you're the most productive developer you can be?
Loc: I think as developers our work requires a lot of collaboration but also requires a lot of focused time. I know that whenever I’ve got to take on something pretty technical, I need to block out my calendar. It's this trick I learned from earlier in my career working in consulting where a lot of clients want to talk to you so then you just start blocking out each other's calendars so you can get ‘real work’ done. Now my tactic is to plan my day ahead. If I know I've got to work on something pretty complex, then I'll block out half the day and not let anyone schedule meetings during that time. And then after that, now comes the collaboration part. Right now I need the code reviewed, but now I also have to take into consideration your schedule. Are you ready to take time away from your focus work and work together?
Ali: So you talked about mapping out your day-to-day. What does your average day-to-day look like to keep you the most productive you can be? Are there any tools that you use to help ensure that? So for example, this weekend I finally downloaded Alfred. Everyone was like, “You should get Alfred. Alfred's great.” I’m still trying to figure out what to do.
Loc: What does Alfred do? I've never heard of it.
Ali: Oh my God. I think it's basically if this, then that for your computer, or it's hot commands that you can program.
Loc: Oh, that’s neat. Wow. I guess at this point in my career, I'm involved in a lot of meetings but also doing a lot of code reviews as well. So if I was going to do purely technical work, I almost want to put away messages on Slack or even shut it down, close down my inbox, close down Twitter, close down everything and just try to focus on the problem in front of me. Because for me, I feel like I need that time to do really deep technical analysis, and I try to understand the problem I'm trying to solve and also trying to simplify it too because you don't want to put out a complex solution for a problem that could be solved with fewer intricate solutions.
Ali: So when it comes to solving a problem, are you a perfectionist or an iterator?
Loc: I'm definitely an iterator. I think that comes from the feeling of not being good enough or smart enough. So I'll try to put out something small and ask someone to check up on it “Hey, did I do this right? Did I understand the concept? Did I meet your expectations?” So I always have this feeling of not knowing enough and not being good enough. So let's get someone to check it off like five times along the way.
Ali: Do you feel like that strive for perfection is affected by the industry in which you're writing code? So specifically, for example, you mentioned that you are working on Fintech tools and Fintech there's a lot of rules and regulations. So, do you find that you hold yourself to a much higher standard and to a much higher bar?
Loc: I think I do and that's because I think with Fintech, I'm moving people's money around. And aside from the rules and regulations, there's also that customer empathy side, where Ali, if you're moving money, I want to make sure that the money gets to whoever you send it to. Or if you're supposed to get money, you might be in a bind, and you need the cash. So I'm like, I got to make sure the system's not down while that's happening, and it's really amazing how our payment systems work. We buy groceries or buy gas and if the system backing that is down, we never know it just works. So in my current company, that’s what I'm striving for. So I build that into how I develop and how careful I am and how much time we spend reviewing code. And it's probably the same for people who work in medical devices or if they're working on putting rockets into space.
Ali: As someone who's worked in the tech medical field, yeah, there's a lot of making sure everything is HIPAA compliant. I totally know what you’re talking about.
Loc: Yeah. It keeps me up at night, and it makes me nervous. I'm not just saving a word document. I’m trying to get money across the wire.
Ali: I totally understand what you're talking about. What specifically about developer productivity do you think interests you the most?
Loc: I think it's because, at this point in my career, I'm an engineering manager and coder. So I see developer productivity, developer experience as related and part of it is team retention. It's so hard to bring on new engineers. It's so competitive out there, and it's so hard to on-board. And every time you lose someone on your team, it's also a hit to morale so one of my tactics for team retention is just making it a really amazing system and place to work and an amazing team to work on.
Ali: Would you be willing to share some of those secrets?
Loc: We'll see. [Laughter] Yeah, it’s something as simple as really tight feedback loops for CI or making sure your tests are separate. You’ve got the unit tests that run really fast and you've got integration tests and Selenium tests that can run off the main process because integration tasks can take a while and Selenium tests are even worse. You don’t want them running every time but people want the feedback. So maybe you have them run at the end of the day or twice a day or whatever and making things really pleasant to work with, making systems really pleasant to work with. The whole process, the whole life lifecycle should be pleasant to work in. From the time you open your editor to write a code, to commit, and opening a PR, I just hope my team is happy at each step.
Ali: That makes sense. I think it's very interesting that you see developer productivity as a way to keep your team productive because there are so many people right now when you're like productivity, they're talking about their work stacks and using Alfred and Notion and putting all these pieces together to make sure that they shave off that extra 30 minutes of time a year where they hit that inbox zero. So I think you're very fundamentalist when it comes to productivity. It's not about what fancy, and feel free to correct me if I'm wrong, it's not about the fancy tools you put together but instead just making it work the best that I can.
Loc: I think so. I try not to get too focused on tools. I really try to focus on either how I feel or how the people in my team feel at the end of the day. Did they accomplish what they wanted to accomplish? And if they did, were they happy while they were doing it, or was it a total grind to get there? Day in and day out, I think that's what's going to happen. Are they going to get out of bed and be excited to turn on the computer and continue working on the problem? Or is it going to be I'm going to turn on the computer, commit code and wait an hour for my build to come through, and wait two more hours for the next reviewer to hop on and look at my code?
Ali: Yeah. I feel that.
Loc: It's like a more, I don't know, maybe a more human way to look at it and maybe promote empathy among team members. We all want to be amazing developers. We all want to commit code and see our features pushed out and see customers happy.
Loc: That’s a really good question. Thinking back to my entire career, developer productivity goes back and it’s tied to tools or languages or architectures, monolith versus microservice or opinionated versus non-opinionated. Gosh, it's a hard one. And I feel like it's a pendulum that swings back and forth probably like most things it's somewhere in the middle. I think productivity if it's not going to be on either extreme and it's going to be in the middle, I think that requires your team to get together and really hash it out and decide what the best process or tools are for everyone to be really happy and productive.
Ali: How do you make sure that you and your team are staying up on the newest tools? And at what point do you say,“Yeah, let's start looking into this.”
Loc: Not everyone's on social media, not everyone's going to conferences. What I personally try to do is I try to surface that information whether it's news articles or blogs or YouTube videos or new courses on Udemy or Pluralsight or whatever. I try to push it out there to the team and let them consume what they think is useful. And a lot of times I'll start that discussion thread in the chat and be like, “This sounds really cool, and it’s something we should adopt. What does everyone think? I really need your opinions.” And I'll start bugging people for their opinions because I want it to be a group decision. And I think it's important to get buy-in from everyone. I don't think everyone's going to agree to everything, but we do want to make sure the team can commit to something and not do it in a half-baked way.
Ali: You're doing Vue versus React. What do you think in the grand scheme of libraries, which one do you enjoy working in?
Loc: Yeah. I think it's amazing to see technology evolve.
Ali: So I just wanted to say thank you so much for taking the time to hop on our podcast. Do you have anything you want to plug, share your Twitter, anything of interest you want to let everyone know?
Loc: You can find me on Twitter @locn. It's just my first name and last initial. You can also find me on the Productfy website. That's productfy.io. We're building the AWS for Fintech. So, if you're trying to build your next payment company, come check us out.
Ali: Awesome. And I'm Ali. You can find me on Twitter @endingwithali. Thank you so much.
Loc: Thank you again.
Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. Right now, we're running a hackathon in partnership with dev.to called Hack the Planet, where we're giving away $20,000 in cash prizes along with many other fabulous gifts simply for participating. You'll also find news there shortly of FutureStack, our upcoming conference here at New Relic. We would love to have you join us. We'll see you next week. Take care.