Why you should consider learning Ruby

[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 Ruby with Jay McGavren, Author of Head First Ruby and Head First Go, and Web Developer at Kajabi.

[00:00:20] JM: If you need to prototype something or if you need to build a really large, complex application quickly, Ruby is going to be the easiest place to do that.

[00:00:31] SY: Jay talks about the pros and cons of using Ruby, what coding and Ruby looks like, and if it’s a good language for beginners to learn after this.

[MUSIC BREAK]

[AD]

[00:00:48] SY: TwilioQuest is a desktop roleplaying game for Mac, Windows, and Linux to teach you real world developer skills. Take up the tool of software development, become an operator, save the cloud. Download and play TwilioQuest for free at twilio.com/quest.

[00:01:05] Heroku is a platform that enables developers to build, run, and operate applications entirely in the cloud. It streamlines development, allowing you to focus on your code, not your infrastructure. Also, you’re not locked into the service. So why not start building your apps today with Heroku?

[00:01:22] Cloudinary is an end-to-end image and video management solution with a powerful API that lets developers upload, store, create, optimize, and deliver your media with ease. They have a generous free plan as well as advanced plans with enterprise configurations. So check out Cloudinary today at cloudinary.com.

[00:01:43] MongoDB is an intuitive, flexible document database that lets you get to building and MongoDB Atlas is the best way to use MongoDB. It’s a cloud global database service that gives you all of the developer productivity of MongoDB, plus the added simplicity of a fully managed database service. You can get started free with MongoDB Atlas at mongodb.com/atlas.

[AD END]

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

[00:02:14] JM: Thank you, Saron. So before when we start digging into Ruby, tell me a little bit about your coding background and what you’re working on now.

[00:02:22] SY: Long story for my background is I’m a self-taught, been a web developer since web applications became more popular, and last decade or so I’ve had some opportunities to teach other developers in the form of writing books and teaching online courses, and I’ve taken them. It’s been a lot of fun.

[00:02:41] SY: How did you first get into coding?

[00:02:43] JM: That was a long while back. My parents enrolled me in a summer activity program where they taught kids how to program on Commodore PET Computers. So I learned Commodore basic and I’ve kind of been hooked ever since.

[00:02:56] SY: What kinds of things did you make on the Commodore?

[00:02:59] JM: With silly things, like you could animate a flapping bird using texts. I did that sort of thing.

[00:03:03] SY: Nice.

[00:03:04] JM: Print your name out repeatedly, but for a six-year-old that’s plenty of motivation. I was hooked.

[00:03:09] SY: Yeah. So were your parents technical people then?

[00:03:12] JM: Not really, no. I think this was just a program that was available at the time and everybody was talking, “Oh, computers are the wave of the future.” So mom signed me up.

[00:03:21] SY: So I think those summer programs and afterschool programs are really interesting because I did one of those programs. I think I was maybe 12 or 13 when I did a summer program where we did some coding, not exactly Scratch, but kind of similar to Scratch, and we like soldered, an LED heart is what I made for my mom, and I did like some tech stuff. But after that course was over, it was kind of a one-off thing. It never really occurred to me that, “Oh, this is a thing I could keep doing or something I could study in school.” You know what I mean? Like I just never made that connection. So tell me about how that connection came about for you going from that one program into actually being a develop?

[00:03:59] JM: Yeah. This was the ’80s, you know, and I think people kind of had stars in their eyes about computers at the time saying, “Oh, yeah, this is the wave of the future. This is where all the jobs are going to be.” So now I was subscribed to magazines like Inter when I was a kid. I kind of have found ways to steep myself in that culture pretty much through my whole life.

[00:04:21] SY: So you said that you were a self-taught developer and I imagine back then it was probably harder to self-teach than it is today. I feel like nowadays there are just so many courses, so many books and resources to help you teach yourself. What was it like to learn by yourself back then?

[00:04:35] JM: Yeah. I would definitely say there was a shortage of resources. There was that Inter Magazine I mentioned, which was targeted at kids, but that just had little toy programs. Maybe you could do a full game occasionally, if you were willing to type in five pages’ worth of code. I would say I did not get too serious about development until I actually started doing so on the job.

[00:04:57] SY: Tell me about that first job.

[00:04:59] JM: I was actually employed in data entry at the time, so copying hotel listings from one database into a terminal that controlled another. And this was not designed to be friendly to automated entry. So they still needed human beings to do this. Well, I figured out a way to automate it.

[00:05:18] SY: Nice!

[00:05:18] JM: I think I started out with visual basic running inside Microsoft Word, because that was the only tool I had available on these data entry machines. Eventually, I convinced them to allow me to install Perl because I had a coworker who was actually employed as a developer who encouraged me to check that out. And that was an amazing tool, Perl was. And I was able to do some pretty impressive things with it as far as the automation. But yeah, I learned through the book, Programming Perl. That’s a magnificent resource. It teaches you not just the pro language, but the entire Unix philosophy. And that is, I think, when I really started to get serious.

[00:05:57] SY: Well, that’s a nice segue into our conversation on Ruby, since Ruby is based on Perl, at least that’s my understanding of it. Can you tell me a little bit about the history of Ruby?

[00:06:06] JM: Perl and Ruby are definitely kindred spirits. They’re both considered scripting languages. And if you get into the Programming Ruby book, if you were to compare that to Programming Perl, you’d see they cover so much of the same things. And there are little details in the Ruby Interpreter that maybe aren’t that heavily used by most Ruby programmers, but definitely you can see similarities to Perl lurking in there.

[00:06:31] SY: When was Ruby created?

[00:06:33] JM: I forget exact days, but it was the early to mid-90s, ’92, ’94, somewhere in there, Yukihiro Matsumoto, a.k.a. Matz, and yeah, he basically created this as a tool for his own use on the job and eventually it grew to a point where he was ready to share it with the world.

[00:06:51] SY: What do you think made it so popular?

[00:06:52] JM: Definitely Rails was a strong factor, the introduction of Rails. I think that’s what Ruby really took off. For most of the ‘90s, it saw very little usage outside of Japan. There wasn’t that much documentation in English. Then Programming Ruby came along and suddenly English Ruby users had a resource they could go to.

[00:07:11] SY: Who wrote Programming Ruby?

[00:07:12] JM: That was Dave Thomas and some coauthors as well. So that was a big boost to its popularity, and then of course Rails comes along and Rails just made web development so much easier and more integrated than anything that had come before.

[00:07:28] SY: And what is Rails?

[00:07:29] JM: Rails is a library. It runs on top of Ruby. It basically combines a web app needs to communicate, not just with the web browser that’s making a request to it. It also usually has to talk to a database, right? And it needs to compose a response page with HTML using data retrieved from the database. That’s a complicated process, but Rails integrates all of that. And that’s a good part of what made it so popular is just Rails made the repetitive busy work of creating a web app and just automated so much of it.

[00:08:02] SY: What makes Ruby so different from the other languages that were around at the time?

[00:08:07] JM: Well, you probably heard me classified both Perl and Ruby as scripting languages. And this has changed a little bit over the lives of both languages, but at first, they were interpreted. Basically you load the program in from a plain text file at the time you’re going to run it and it gets interpreted and maybe portions of it get compiled just right there on the spot. And what’s next nice about that setup is that you can load new code at runtime and interpret it on the spot. So that enables things like making changes to your model or your controller in a Rails app. And without restarting the app, you can just reload the page and load your modified code in and run the new version. It’s a very tight feedback loop. So you can make changes to your code and see the results very quickly, much more quickly than you can with many other programming languages.

[00:09:03] SY: One of the other things that I’ve heard about Ruby and why people like it so much is that it is very much like English and it’s just a lot of fun to write and it’s a lot, I don’t know if easy is really the right word, but just something that is more joyful is how I’ve heard it described. Would you say that’s true?

[00:09:22] JM: Yes. You can definitely write Ruby in a very expressive style, which if you want, you can make it look a lot like English. So you’ll find that Ruby code often doesn’t have as many comments as code and other languages and that’s because you can make the code itself so clear and easy to read.

[00:09:38] SY: Can you paint us a picture of what coding and Ruby looks like? Like when you say it’s expressive and even words like joyful, what does that mean? What does it look like to code in Ruby?

[00:09:47] JM: I usually refer to it as the language getting out of your way. It’s a very flexible language. So you can declare new methods dynamically and call them. For example, you can call methods that you haven’t even directly written in your code. That’s using a technique called metaprogramming. You can actually call these methods and the interpreter will figure out how to turn that into how to access the correct portion of your code based on that method name that you’ve defined on the fly. So Ruby is just a really flexible language.

[00:10:21] SY: So you used to code in Perl. Now I think Ruby is kind of your thing. What sold you on Ruby?

[00:10:26] JM: Perl in the mid 2000-2010 decade, it was kind of starting to sputter a little bit. Perl had been on Perl 5 for quite a long time. Perl 6 had been promised, but it wasn’t really coming out. And Perl 6 has been released now, by the way. But a lot of folks had to move off of Perl because it really wasn’t that popular or that actively maintained anymore. And Ruby is, like I mentioned, just very much a kindred spirit to Perl. So it seemed like a natural place to go. And again, like so many other people, Rail sold me. It was just a really cool framework and I felt it was something I just had to try.

[00:11:04] SY: So thinking about Ruby and comparing it to other languages, Perl, JavaScript and others, what would you say Ruby is best at?

[00:11:12] JM: Ruby is best at starting new applications. So if you need to prototype something or if you need to build a really large complex application quickly, Ruby is going to be the easiest place to do that. Now the other side of that coin is once applications get really large, then you’re missing out on some of the niceties of compiled and statically-types languages. So you’re not going to be able to load up your IDE and immediately list all the places that a function is called, for example, because of those dynamic functions, it’s very difficult to determine where a component of your code gets used.

[MUSIC BREAK]

[AD]

[00:12:09] SY: Explore the Mysteries of the Pythonic Temple, the OSS ElePHPant, and The Flame of Open Source all while learning the tools of software development with TwilioQuest. Become an operator, save the cloud. Download and play TwilioQuest for free at twilio.com/quest.

[00:12:27] No one wants to manage databases if they can avoid it. That’s why MongoDB made a MongoDB Atlas, a global cloud database service that runs on AWS, GCP, and Azure. You can deploy a fully managed MongoDB database in minutes with just a few clicks or API calls. MongoDB Atlas automates deployment, updates, scaling, and more so that you can focus on your application instead of taking care of your database. You can get started free at mongodb.com/atlas. If you’re already managing a MongoDB deployment, Atlas has a live migration service, so you can migrate it easily and with minimal downtime then get back to what matters. Stop managing your database and start using MongoDB Atlas.

[AD END]

[00:13:18] SY: So what would you say Ruby is not good at? It’s not good when you’re dealing with larger applications?

[00:13:23] JM: Yeah. When applications get older and get really big, they do become a little more difficult to maintain in Ruby. This is something that you’ll see over and over. If you have diligent developers, if you have a good suite of unit tests, automated tests for your program, it absolutely can be done. That’s my day job is maintaining a very large Rails app that is a good five years old. We do it. You have to be diligent and it does take a little bit of extra effort.

[00:13:52] SY: So that’s interesting because if I pick Ruby as a language to start with, because it’s so easy to start with, and then hopefully my project, my app grows and hopefully it scales and Ruby is no longer the best language to kind of follow that growth, what do I do? Is there kind of a point where I should rewrite my app in a different language or how do I resolve that?

[00:14:15] JM: Some companies have done that, some companies have taken portions of their Rails app and rewritten them in Java, in Go, in other languages like that. Really the first thing you should do when you start having scaling issues though is just make sure your web app is as optimized as it can be. Do you have indexes on your database tables in all the right places? Are you doing unnecessary operations? Are you loading lots of data into memory where you shouldn’t be? Usually there are lots and lots of optimizations you can make to Rails app long before you need to consider moving to another language.

[00:14:53] SY: And if you were just getting started and getting comfortable with the Ruby language, there are plenty of resources and books to show you how to get started, but I don’t know if there are that many to show you how to optimize your code. If I were to look at my Ruby code that I’ve written and I want to make it better, make it faster, more performant, how would I know where to start?

[00:15:12] JM: Yeah. I don’t know if I know offhand any one stop shop or sources that you can go to for that immediate level stuff. And that’s a problem in the software development field in general is that yes, there are lots and lots of beginner resources. For intermediate level stuff, you have to shop around quite a bit more. There are, of course, lots of useful blog posts out there. The first place I always go is Google. Google very often takes me to Stack Overflow or maybe to a random blog post, but definitely Googling is a skill that developers have to build.

[00:15:47] SY: Are there diagnostic tools that can help me narrow down where the performance issues are in my code?

[00:15:54] JM: Not that I use heavily. There definitely is. There’s a profiler available that’s built into Ruby where you can call a function, a method repeatedly and see how quickly it’s able to run. There’s commercial tools out there as well. There’s new Relic, which will help you identify, especially in a Rails app. It will help you identify controllers that are taking a long time to respond. So yeah, there are tools out there. Again, no real one stop shops. You kind of have to, when you encounter a problem, just exercise your Googling skills.

[00:16:33] SY: Okay. So when you yourself encounter a problem in your code or maybe you’re looking for the source of that problem, what do you do? What do you Google for? Where do you start?

[00:16:43] JM: What I personally do is I’m very reliant on unit tests. So we have tooling setup at Kajabi, and these are pretty much off-the-shelf tools and libraries too that will identify the unit tests that take the longest run. Those will often point to areas of your main code that take a long time to run. So if you’ve got a unit test that’s taking half a second to complete, which is a long time for a unit test, that probably points to an area of code that you need to optimize. Like I say, that commercial tool, New Relic, that points to controllers that are taking a long time to respond to web requests. So generally speaking, I look for that test or that slow controller method, and then I follow the program flow, see what classes and what methods are being called by that code. And generally speaking, when I go to look at those methods, I’ll see one that’s really long, that’s really complex, and it’ll just kind of jump out to me as something that’s unnecessarily complicated and in need of optimization.

[00:17:51] SY: So we talked about how Ruby isn’t necessarily the best language at scale. And I’m wondering what is it about Ruby that makes it less performant?

[00:18:00] JM: It’s the fact that it’s a dynamic language. Basically when you call a method in Ruby, it will look up where to invoke that method, and all languages have to do that to some degree, but dispatching those methods is a little slower in Ruby because it doesn’t have a nice binary compiled list of method locations. So it’s kind of that same flexibility while you’re developing. That is also kind of Ruby’s downfall as far as speed.

[00:18:31] SY: So what do you think of Ruby as a language for people to learn? Is it something you’d recommend?

[00:18:35] JM: Absolutely. I think it’s fantastic language to learn with. I really like Ruby because it’s so conceptually consistent. So many different parts of the language work in the same way. You don’t have to learn many, many different kinds of syntax. Once you learn the basic concepts, you’re able to apply and reapply those everywhere in the Ruby language.

[00:18:59] SY: I love Ruby. I’m a Ruby developer myself, and I love just how easy it is to express yourself. As you said, it’s very expressive. But I’m also wondering if you start with Ruby. Are you making it almost too easy for yourself? Is it better to pick a more complex language? You can kind of learn more about the fundamentals of programming? Are you doing yourself a disservice by picking something that’s easier to pick up?

[00:19:22] JM: I feel like there are so many different languages that are all okay places to start software development with. Really the concepts you learn are going to be applicable no matter what language you wind up switching to. So no, I’m not going to say that Ruby is leaps and bounds ahead of other languages as a first language to learn. I’m not going to say that other languages are better either. As you progress as a developer, there definitely are difficult lessons to learn and really the only difference between languages is when you have to learn those lessons. Do you have to learn everything before you’re even able to write a hello world program? Which with Ruby, no, you just type, put as “Hello World” and you’re done. Whereas something like Java, you have to write a class definition. You have to write a method definition. You have to write all these key words like private void and a method name that you probably aren’t going to understand right then. You just want to write hello world. So Ruby definitely makes it very, very easy to get to hello world.

[00:20:31] SY: So you wrote a whole book on programming with Ruby. What was the impetus for writing it?

[00:20:35] JM: So yeah, my book is called Head First Ruby and I have always had huge respect for the Head First series. I had read both Head First Java and Head First Design Patterns prior to even approaching my publisher to write Head First Ruby. But it always bothered me that there wasn’t a Ruby book in that series. And I just had an opportunity to talk to O’Reilly, the publisher, and I seized on my chance. I was like, “I’d like to write Head First Ruby for you.” And they’re like, “Great! Submit an audition.”

[00:21:05] SY: So tell me a little bit more about that process. You approach them and then what happened?

[00:21:10] JM: Yeah. So I actually got to work with an O’Reilly editor on a project to learn the R statistical visualization language. So I just finished that project, working in collaboration with the O’Reilly editor. It had gone really well and I just kind of seized on that chance. Because I said, “Wow! This is a unique opportunity. I’d better make my proposal.”

[00:21:32] SY: And they had you do an audition. What does that mean in the book world?

[00:21:36] JM: It’s a little unusual. I think that may be unique to the Head First series, but basically they just had me teach them a topic.

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

[00:21:46] JM: Yeah. I picked something from Ruby that seemed applicable and I can’t even remember what specific topic. I chose blocks maybe. And I just taught it to them as best as I was able. I think I threw together slides in keynote actually, and exported that to a PDF. They didn’t really care what my chosen format was. I just picked something that was as expressive as I could. The Head First series is a very graphical set of books with like annotations on all the code, lots of diagrams. So I chose a format that was going to let me mimic that. And this audition, I learned so much while writing the book. This audition was terrible compared to the finished book, but I think they must’ve seen promise in the way that I taught the topic. So yeah, they said, “Yup. Here’s the contract. Let’s write a book.”

[00:22:37] SY: Yeah, I love the Head First series. I remember many, many, many years ago I read, I think it was just Head First HTML and CSS. I think that was the book. And I just really appreciate how different it was. Like you mentioned it was full of diagrams and annotations and little worksheets and it was just so active. It was a little activity book for learning. It was awesome. But I’m wondering for Ruby, what kind of diagrams would you include for a programming language like Ruby? What does that look like?

[00:23:03] JM: Basically when you’ve got a complicated concept, especially something where you’ve got a series of events happening over time. That is something that can be useful to express what the diagram. There are a lot of folks out there and I would consider myself among them who consider themselves to be visual learners. And so any time you’ve got many components communicating back and forth with each other, Rails model view and controller, for example, would be a great place to include a diagram because you need to show the flow of control for the web request as it goes back and forth between those different components. It’s a great spot for a diagram.

[00:23:44] SY: And what kinds of things did you end up learning about Ruby from that book? I imagine you may have had to brush up on a couple things. Maybe explore some topics you weren’t quite familiar with.

[00:23:52] JM: I don’t think I had to learn anything entirely new. I definitely had to refine my knowledge of stuff. I thought I knew, but that I was confused about the little details of.

[00:24:03] SY: And what kinds of things were those?

[00:24:05] JM: I’ll give one of the most basic examples. I had been using the terms parameter and argument interchangeably. And I got corrected, a draft of the book got corrected on this point. I did not realize that parameter refers specifically to the variable in a function definition that receives a value that’s passed to it. Arguments are what you pass when you’re calling the function. So parameters receive argument send. I was not clear on that point when I started writing this book.

[00:24:34] SY: Interesting. I think I’ve been interchangeable using those as well.

[00:24:37] JM: I think most folks do.

[00:24:40] SY: Yeah. Yeah. So what is it like to actually write the book? You mentioned that you got corrected. Does that mean your editor is equally knowledgeable than Ruby and giving you that kind of feedback? Or how does that process work?

[00:24:51] JM: No. Many O’Reilly editors aren’t actually super technical. The editors themselves are approaching it more from a layperson’s point of view because the goal of the book is to teach programming to a layperson or to a person who doesn’t really know that material yet. So more often the editor themselves, they’ll come back to you and say, “Hey, this point isn’t really that clear to me. Can you expand on that a little bit?” And I’ll do so. That feedback from my editor was absolutely invaluable when writing Head First Ruby and it’s a much better book for it. As far as corrections on the technical side aspects, at least for the Head First books and I believe for most technical books from most publishers, there is a panel of technical reviewers and the more technical reviewers you can get for a book, the better it will turn out. Hopefully, you’ve got a couple complete beginners as technical reviewers who will point out when things aren’t clear to them, but you’ve also got a couple experts in the domain, in this case. So I had a couple experts in the Ruby language who said, “You’re wrong on this point,” or, “Oh, you should probably expand on this a little bit.” Or, “Oh, did you think about covering this other aspect of this?”

[00:26:03] SY: That’s really great. So what kinds of topics did you get into in the book?

[00:26:07] JM: Basically, my goal was to take people from hello world all the way up to programming a simple web app. So I don’t actually cover Rails itself in Head First Ruby. Instead I cover Sinatra, which is a much simpler web app library. And when you have that end goal in mind, the set of topics you need to cover basically decide themselves. Because if you’re going to explain a Sinatra app to a complete beginner and have them really understand it, well, they may not know what a method is or how to call one. They may not know what a block is. So Sinatra app uses blocks to define how to respond to some of its web requests, for example. So you’ve got this list of topics you have to teach all laid out for you once you decide on your app.

[00:27:00] SY: Coming up next, Jay talks about Ruby’s robust community and what resources he’d recommend for people who want to learn Ruby after this.

[MUSIC BREAK]

[AD]

[00:27:22] SY: Images and videos are the heaviest resources users have to download when they use your site or app. Achieving great experience with media was a complex and tedious task. But with Cloudinary, there’s a powerful API that employs sophisticated algorithms, machine learning, and automation to deliver great media experience on any device for any framework in web or a mobile app. At Dev.to, we’ve been impressed with Cloudinary serverless API platform and recommend it to developers as the one and only solution they can use to solve all their media problems.

[00:27:56] Over nine million apps have been created and ran on Heroku’s cloud service. It scales and grows with you from free apps to enterprise apps, supporting things at enterprise scale. It also manages over two million data stores and makes over 175 add-on services available. Not only that, it allows you to use the most popular open source languages to build web apps. And while you’re checking out their services, make sure to check out their podcast, Code[ish], that explores code, technology, tools, tips, and the life of the developer. Find it at heroku.com/podcast.

[AD END]

[00:28:36] SY: So one of the big benefits of learning Ruby isn’t just the language, but it’s also the community and it’s known to be one of the most friendly communities, the most friendly programming communities out there. Have you found that to be true in your experience?

[00:28:48] JM: Yes, I would definitely say so. There’s lots and lots of developers out there who are looking to help beginners get started in Ruby. I would say that the internet at large has definitely been working on its culture towards helping out beginners. So other programming languages are starting to catch up with the Ruby community. As far as helpfulness to newcomers, readers may have seen if they’ve been following Stack Overflow, for example, all the changes to the community guidelines and things like that. Answers should be friendlier or answers should be more helpful, things like that. So I think everybody’s working on that, but Ruby started in a great place in that regard. One of the mottos of the community is, “Matz is nice and so we are nice.” Yukihiro Matsumoto was nice enough to share this wonderful programming language with us and so we’re going to be nice to others in helping them learn.

[00:29:42] SY: So besides your book, which sounds wonderful. As I mentioned, I’m a big fan of the Head First series. What resources do you recommend for people who want to learn Ruby?

[00:29:50] JM: Definitely the place I learned is that Programming Ruby book that I mentioned by Dave Thomas and company. Great, great resource for the core Ruby language. There’s also lots of great resources. A lot of the Ruby jobs out there are working in Ruby on Rails. So learning Rails is going to be essential as well. So yeah, just any top five list of the best Rails books is going to include the Rails way. New additions of that seem to get released for every new version of Rails. Definitely I’d recommend going there if you want to learn Rails.

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

[00:30:35] JM: Absolutely.

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

[00:30:39] JM: I don’t know that this is advice that I’ve ever received directly that’s been directed at me, but there are a lot of folks out there who suggest that use code libraries that are half finished or buggy or not actively maintained. So you’ll ask a question on Stack Overflow, “How can I do this?” And somebody way down in the answers list will chime in, “Oh, well, you can try this library. It does that.” But they haven’t really researched it that carefully and they haven’t made sure that the library is really ready for common people to use other than the person who developed it. Anytime somebody suggests that you use a library, you need to look at that library critically. You need to ask yourself how many people are using it. So you might look at how many stars it has on Stack Overflow, for example, how long has it been since it was last updated. If it’s two or three years old, unless that library is very, very simple so that it could be considered done and very few libraries are ever done, they always need security fixes and bug fixes. If it’s been two or three years since the last commit to that project, you probably don’t want to use it because it probably has unfixed bugs.

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

[00:31:50] JM: Probably to learn unit testing. So automated tests for your programs. Very, very important, because manually trying out your program after you make a change is just not going to be good enough or fast enough once you have a full-fledged programming job. But if you have tests for every function in your program, then you can make changes to it freely and just run the tests and you’ll be confident that nothing broke and that’s going to be really important when you’ve got an issue on your production server, for example, and your customers and your boss are all waiting on you to fix it. You want unit tests that you can run and say, “Yes, this code is complete. It’s working. Let’s deliver it.”

[00:32:28] SY: Number three, my first coding project was about?

[00:32:31] JM: I was a paperboy as a kid. So I had customers that only needed delivery on certain days of the week, customers who absolutely did not want me to walk on their grass, things like that. So I wrote a simple program to track their preferences for customers on my newspaper route. And I might’ve used a spreadsheet or a database if I’d known those programs existed, but all I had was Apple basic. So I wrote a program to track it all.

[00:32:56] SY: Very cool. Number four, one thing I wish I knew when I first started to code is?

[00:33:02] JM: There is a big difference between the little toy experiment programs that you write on your computer for your own use and web apps with lots and lots of users. So things that work fine on your own computer, they can potentially break when they’re on a web server being accessed by thousands or even millions of users at the same time. Now there’s no need to panic over that. You don’t have to change what you’re doing because you have to write those toy programs in order to learn the basics, but understand that you’re going to need to keep learning after you get your first programming job. You’re going to need to learn how to optimize your code better. You’re going to need to learn how to work with databases more effectively. You’ll still be learning your whole career. I know I am.

[00:33:43] SY: Is there anything we can do to prepare for that? Is there anything we can do in our own time after work in the evenings to get used to that scale? Or is that just the kind of thing that you really only learn on the job?

[00:33:55] JM: Definitely the most effective way to learn it is to be thrown in the deep end. It’s a little scary, but that’s definitely how you learn the fastest and how you learn specifically what you need in order to do your job more effectively. If you want to prepare, definitely just look up resources on database design, because any good book on database design, you’ll be able to find resources out there specifically for PostgreSQL. That’s a popular database program. You’ll be able to find resources out there specifically for MySQL, or you can find generic resources, but getting really strong with databases will get you really far.

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

[00:34:36] JM: Absolutely. Thank you, Saron.

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