Joel Clermont (00:00):
Welcome to No Compromises, a peek into the mind of two old web devs who have seen some things. This is Joel.

Aaron Saray (00:08):
And this is Aaron.

Joel Clermont (00:15):
Developers always need to learn new things. It could be a new version of something that they already use, it could be a completely new tool that's being introduced to the project. Aaron, as a developer I want to ask you, how do you learn something new? Do you have a strategy that you use?

Aaron Saray (00:36):
I stopped learning things back in 1992 when I learned BASIC, so I'm probably not the right person to ask.

Joel Clermont (00:44):
All right.

Aaron Saray (00:44):
I'm just kidding. One of the things that I'm a big fan of... Well, there's two different steps I do. I read about something and I practice that thing.

Joel Clermont (00:56):
Okay.

Aaron Saray (00:56):
I think the first thing that's pretty important in my book is documentation.

Joel Clermont (01:02):
Read the manual? Is that what you're telling me?

Aaron Saray (01:05):
Yeah. I mean, that's the first thing. But we don't want to just stop there, right? So you read the manual and then you start to apply some of the things you've learned. I was talking with another programmer the other day and we were talking about why we need to practice things. And I said, "When you read the Laravel manual in the Eloquent section, and it says, 'HasManyThrough.'" I mean, it was obvious how that worked, they wrote it down there in plain English and all of the code I needed was right there. I'll tell you, the first time I wrote a HasManyThrough it didn't work. It wasn't Laravel's fault, it was my fault because I didn't really know how to do it. I read it, it was in documentation. But I needed to practice it, I needed to put what I've learned into practice and do it more than once to get it right.

Joel Clermont (01:52):
Yeah, I'm the same way, I have to do it. I will say that HasManyThrough it might be kind of an interesting example because that might be one that I go to the docs more than I care to admit. But you're right though, you read something and you're following along, you're kind of mentally tracking like, "Yeah, this makes sense. This is cool." Then you sit down to try to build something and you inevitably hit one or two things that you either don't remember from reading the docs or that weren't covered in the docs, and it forces you to sort of stretch your knowledge a little bit. But, for me, that's where the best learning takes place.

Aaron Saray (02:27):
I think some programmers take it a little too far in the other direction though. They think, "Maybe I don't even have to read anything and I'll just take this code out and start messing with it." I'll be honest, I've done that too. You look at a readme real quick and you're like, "There's a code example, I'll just copy that example," and surely through magic osmosis, "I now know how this all works. And if it doesn't work based off of something I made up in my head, I get really upset." And it's really like, "Maybe you should read it too."

Joel Clermont (02:55):
Yeah, there is a balance. You probably don't want to... Like Laravel, let's take that as a specific example. You wouldn't tell somebody, "Sit down and read the entire manual before reaching for PHPStorm to try something out." Or, where was your-

Aaron Saray (03:14):
Right.

Joel Clermont (03:14):
Right.

Aaron Saray (03:16):
Okay. I understand your question here. It's a kind of a thing that I did with the PHP manual as well. What I would do is I would look up a function and I'd find that function and find the instructions, I'd read through. Maybe I'll read a couple of the comments and then giggle to myself over the arguments that appeared.

Joel Clermont (03:36):
I like to read the -10 comments. All the ones that says, "-10, -20."

Aaron Saray (03:42):
Don't dim these out on me, I want to see them.

Joel Clermont (03:45):
It's good stuff there.

Aaron Saray (03:48):
But then once I'd finish that and I have my solution, I might even apply it, but I haven't closed that tab yet. I usually take another minute or so and say, "What are some of the other suggested functions that are on this page?" Or maybe if you're on the string functionality, there's usually, on the right-hand side, there's a huge list of other functions. I'll click through on one other one and kind read about it. So I think there's a middle ground there too, which is to say, you don't have to read the whole PHP manual in order to do PHP programming. But you can invest a little time here and there and learn more things.

Joel Clermont (04:22):
Knowing you, you would say it's not unreasonable to, at some point, have read the whole thing. It's not so huge that you can't get through it and there's value in just sort of exploring it and having read it to completion to know all the things you don't know. Unless you've done that.

Aaron Saray (04:40):
Yeah. And there's different ways to read a documentation too. I think we've learned that as programmers we may read over all the code or you read over all the documentation to know generally what's there but maybe not all the specifics. So when I say, "Read all the documentation on Laravel's website," I don't mean sit down for the whole entire day and read line by line. But I do mean click through each one and kind of scan over the stuff. Look at the headlines, look at a couple examples, and get an idea of what's there. And then later on if you run into something you have a general idea that, "Oh, that probably might have been covered in the documentation, and I'll go look and read it specifically. And after I've learned that one thing, I'll go read one other thing real quick."

Joel Clermont (05:22):
Okay. All right, that seems like a reasonable approach. When it comes to learning, the hands-on portion of it, we talked a little bit about the docs, any advice on where you should practice that? Like, should this be your main production app at work? Is that where you should try out some of these new things you're learning? A little bit of a softball question there.

Aaron Saray (05:43):
Whenever I learn new things I always test it out in production. I don't even use version control, I just go right to the server. Just, "Yeah. This is something new." No, I think obviously in the way that you've so gently served that question to me, the answer's kind of a given. But I think it's good to test out things you're learning but not necessarily as part of a critical path of your production application. That's why sometimes programmers will have side projects or even side little tools at work. If you've written a script to do a quick thing that helps you with your main job, maybe you quickly refactor that script with new technology so you can put that in practice.

Joel Clermont (06:28):
Yeah. I know some people have a little pet project and that's the thing that they try when they're learning a new language or framework. The famous one is the ToDo app, where there's a hundred different ways to build that. Shout out to a book that I like. It's made by Pragmatic Press and it's called something like 57 Exercises For Web Developers. They're not whole projects but they're like little things you could use to kind of kick the tires on a new language or a new framework. And I've sometimes pulled that out, randomly picked something because they're non-trivial, but it's not like a week-long project to build something. It's just some nice ideas if you're like, "Huh, I wonder how this would be..."

Aaron Saray (07:07):
It's not foo bar, it's actually something that's worthwhile?

Joel Clermont (07:11):
It's real stuff. Yeah, it's a neat reference. I would recommend checking that out if you're at all interested in learning new technologies and finding fun ways to get some hands-on with it. The book itself is technology agnostic, like doesn't deal with it at all. It's more like, "Here's something you might try to build to," like figure out how to parse strings or how to handle an HTTP request or whatever.

Aaron Saray (07:34):
We talked a lot about learning a new technology, but there's a lot of things that we use that are constantly updating and stuff too. Any tips that you have, Joel, for maybe when a new release of your favorite software comes out, how you can kind of stay current or what you should do?

Joel Clermont (07:51):
Sure, I just went through this myself actually. Laravel recently had a major release, version 8. I will generally go first to the change log just to get an overview. Now, in Laravel's case, the change log or the upgrade guide, they call it, it's not meant to be a complete documentation of what's new, but more gotchas to have in mind as you're upgrading. But the way I work, I like to know those things in advance and it's generally a pretty quick read. There might be a handful of high-level bullet points and it'll just give me a sense of like, "What's new?" in a breaking way. But then I'll click around the docs and I'll find things in there.
And sometimes I'll even read something and be like, "Is that new or did I just not know about it?" They have the little toggle for the version number. So current version is 8 I'll change it to 7 like, "Oh wait, that was still in 7," but it's new to me. But, yeah, I will go back to the docs and go through it again and pick up on those things. And it's amazing what you pick up on that's not listed in, "10 Great New Features of Laravel 8," or the announcement talk at Laracon. There's some real gems in there that you'll find only by just kind of playing around in the docs and finding them for yourself.

Aaron Saray (09:09):
Yeah, I think that's a good point. That the change log kind of summarizes things that have changed or been newly added. The migration is things that you need to know that changed the way this functionality worked from a previous version. But there's really not a great summary of, "This is the detail of the change log." You get top-level bullet points, maybe, "Hey, there's 3 new collection methods and they're called this." But it doesn't really necessarily explain how they work or what they do, you have to go to the documentation to actually find that then.

Joel Clermont (09:42):
Yeah. I mean, I know some people will look at the diffs, right? This is all open source, so once version 8 is tagged and out there you can diff it to the last release of version 7. But that's a lot of information and it might lead you, like you said, to points in the documentation like, "Oh, what do these new methods do?" Or, "Why did that signature change? What's going on here?" And most times stuff like that is covered in the docs.

Aaron Saray (10:06):
Cool. When you're reading documentation and maybe there's a mistake or it's just not good enough, speaking of softball questions, what can you do then?

Joel Clermont (10:16):
Well, it's not so much as it's not good enough, but sometimes not every detail is listed in there.

Aaron Saray (10:22):
Sure.

Joel Clermont (10:23):
I was, again to use Laravel as an example, researching something recently when it comes to when you have a form request and you can use arrays in there and there's this dot syntax that is a signal to Laravel, like, "Oh, this is an array field that's going to come in." Well, what happens if you actually have a dot in your field name and you don't want to change it for some reason? I dug in to the docs because I didn't see anywhere in there that it explained it. So I looked in the source code and I'm like, "Oh, well you put a backslash before it." But then I'm like, well, "Why?"

Aaron Saray (10:58):
So you escape it.

Joel Clermont (11:00):
To escape it, right. It looks like you might escape it in a regular expression, but the deeper I dug into it, it's like, well it's kind of using that syntax but it's not actually regular expressions. So you can't just blindly use other regular expression type things in there. But anyways, I spent maybe an hour poking around in the framework and figuring it out and then I wrote it up in a blog post to share that knowledge. But then I went a step further and I submitted a pull request to the Laravel docs, which took me all of about five minutes. It was a sentence or two and a code sample. And then I shared that, so now if you go to form request page on Laravel docs you'll see my little note that I added there.

Aaron Saray (11:44):
Nice.

Joel Clermont (11:44):
But I bring this up not to focus on that point, but as you were leading me to share with people, the documents or documentation can be a collaborative thing. It's open source just like the code is open source, so are the docs. Now you may think something's really important in the docs and they don't, the project doesn't think so and they don't want to add it. Well, you know what, you still have a blog for that but share something. If it tripped you up and it wasn't there and you couldn't find it, then odds are it'll trip somebody else up and it's good to take a few minutes to add that.
Aaron, as you may know there are a lot of living creatures in my house. We have four kids and we have a lot of pets. We have pets representing the mammals; dog, cat. We have fish, reptiles, amphibians. No birds because that'd be crazy. Anyways, there's a lot of things in the house and I'm kind of weird and I really like to mess with people, especially my kids. So I've developed certain imitations of some of our animals. Okay?

Aaron Saray (13:00):
Okay.

Joel Clermont (13:01):
So I'll make a noise that one of our pets may make and then a kid will be like, "Are they down here? Is the cat down here? What's going on?" I'm like, "Ha-ha, it was me. Got you." For example, we have an old cat that makes this weird noise before it's going to throw up, "Meow, meow, meow." You don't know how accurate that is.

Aaron Saray (13:24):
I don't feel like that's right.

Joel Clermont (13:26):
It's right.

Aaron Saray (13:27):
That sounds like something from Mr. Roger's neighborhood.

Joel Clermont (13:30):
No, it's exactly how the cat sounds. In fact, I expect one of my kids to run into my office right now to look for the cat. But we just got a new kitten and so I've had to raise my pitch and to kind of get some of those kitten noises going too, and I've been pretty successful. But, Aaron, I'd like to ask you, do you have any pet impressions that you can make for us?

Aaron Saray (13:54):
Well, I don't think I have any pet impressions, but I do have a tremendous pet story if that will work.

Joel Clermont (14:01):
Let's hear it.

Aaron Saray (14:03):
So when I had a puppy, her name was Lily. You know, when puppies are little they evacuate all of their stuff on your carpeting and I had somehow trained this dog to be kind of afraid of me. You know, trained it. Then at one point I remember I was sitting by my sliding door on the floor and she was maybe like six feet from it. And she looks at me and she just gives me those eyes and she goes, "Bah". And I'm like, "What?" And she, "Bah." And I'm like, "Oh, she's going to ralph." I look at her and I say, "No." And she goes, "Bah." And I said, "Lily, no." And she kind of like goes, "Bah." I'm like, "Lily, no." And I just growled as low as I could and then she kind of said, "Bah." So then I slowly got up because I was like, "I don't want to scare her into, I don't know, fear of vomiting."

Joel Clermont (15:04):
Running across the living room?

Aaron Saray (15:04):
When I put her chain and slowly walked to the sliding door and she's going, "Bah, bah," the entire time and I said "No." I opened the door and she went outside and I said, "Okay," and she. "Bah" all over the place. It's a story I love to tell because it was amazing. But it's also almost hard to believe, like I just basically talked a dog out of vomiting on the floor.

Joel Clermont (15:29):
That's impressive.

Aaron Saray (15:30):
I don't know, man.

Joel Clermont (15:31):
Well, if this programming thing doesn't work out there could be some animal training in your future.

Aaron Saray (15:37):
To answer your question, yes, I can do a pet imitation. "Bah."
Documentation isn't just for reading, you can write it too. Do you need help developing a documentation plan for your application or team?

Joel Clermont (15:50):
We can help. Contact us for a free consultation on our website at nocompromises.io.