Joel: Welcome to No Compromises. A peek into the mind of two old web devs who have seen some things. This is Joel.
Aaron: And this is Aaron.
Aaron: So, as a programmer and a businessman, it's important to read stuff and educate yourself on your craft, but it's also important to broaden your horizons a little bit.
So when I'm talking to other programmers and stuff like that, I'll say, "Hey, it's great that you're reading the newest thing about Laravel," or "you're keeping up with TypeScript but read something else." And they usually think that means, "Oh, read about a different technology."
I mean, let's go a little bit even further, read something outside of technology. It's sort of what can broaden your mind a little bit and maybe help you be better at technology. So I take this to account, I listen to a lot of business books that are even beyond what we're doing as our business, just because it's interesting, and it helps me think.
I was reading a book about mergers and acquisitions, not something that we're doing, but it's a interesting concept. And one of the things that they talked about was, I'm not going to get too much into details, but they talked about how a lot of mergers were failing, and all of the research says it should be successful, but they failed.
And why is that? So, as you're digging in, they start basically saying that once someone, whether it's a business person or anyone really, gets an idea in their head, a human gets an idea in their head and they start to own that idea and believe in that idea, you start introducing confirmation bias into all your decisions.
So those CEOs and stuff thought the merger's a good idea, then they started taking all of the information that came in and started applying it to the merger as a good idea to support it. Or if it's bad, throw it out. So you end up getting this idea of once you know how something is meant to be or how you think it should be, all the information that comes in and starts to support that. That make sense so far?
Joel: Yeah. I'm tracking.
Aaron: So that really got me to thinking again about how we write our code and how we test our code. A lot of times, we'll talk in our tests specifically about writing additional tests, edge case tests, or adding in new data, things like that.
I think that has a lot to do with undoing confirmation bias. So I will see a lot of times when we write, well, when anyone writes a test, you know it's got to be a logged-in user and they're going to submit this form. So you'll write the test for the logged-in user submitting the form.
Well, that's perfect test, it passes. Code is covered, makes sense because that's what you think it should do. But if you stop there, start not going to those edge cases, it's not really a successful test, is it?
It's just a confirmation to you that the code that you probably executed by hand is also working.
Joel: Yeah, I can see the trap.
Aaron: So this was really cool. Reading another book reminded me, again, as a programmer, like "Hey, I have to make sure that I'm being defensive in my programming. I can't assume the users are going to use something the way that I think it is."
So be defensive and then write better tests, write tests that cover all different edge cases and things like that.
Joel: I like it. And you know I'm a fan of reading all sorts of random things. So before we started talking, you would not tell me the topic, but you're like, "You'll like it," and so I do. So I just wanted to share that with you, Aaron. But let me just ask you something.
Because one of the thoughts I had as you were talking is, for sure, I agree with the advice. Like, don't just be laser-focused on Laravel or even programming. There are things to learn in other aspects of life.
But I'm just wondering, have you ever thought about... could you go too broad? Like, "I'm interested in everything." Like, I'm going to do this and that," and spread yourself too thin too. Because I feel I've even done that in my lifetime within programming. I want to learn Elm, Haskell, and F#.
Aaron: Oh, yeah.
Joel: I've gone all these different places, and it was cool, and I did learn some things, and I think it made me a better programmer. But, I don't know, is this on topic or? That was what occurred to me as you were sharing this advice.
Aaron: Well, that's a great point because you mentioned that you need to actually get some benefit from those. But it was really about keeping them then in line again. One of the things I didn't say is, I didn't say read every other thing.
I said read something else, just read one thing else, read a thing or two. So I would say that you were maybe successful in that way because you picked a programming language and you spent some time with it, and then you killed it.
So you learned what you had to learn from it. Now, if you were coming to me still and saying, "Hey, Aaron, we going to do everything in Elm yet?" I'd be like, "Hmm."
Joel: I never said that.
Aaron: "I think you're now learning too much."
Joel: Yeah, if it's actually... I'm trying to draw a line on this. If all of a sudden, I'm trying to go out and get Elm projects and it's becoming a distraction to the business, that could be going too far, and you're spreading yourself too thin.
Aaron: You're kind of going a little bit too far into our niche again, though, in that example. That's really an easy area for people to understand. It'd be if you were suddenly interested in real estate or being a realtor, that doesn't make a lot of sense with most of the stuff that you do.
Joel: Sure.
Aaron: So you might want to look into it and then say, "Okay, well that's enough." And holding onto something that maybe is too far.
Joel: Yeah. Okay, I like that. Just one other thought here. And not to be too funny about it, but there's this LinkedIn phenomenon that I see where somebody's sharing a really heartfelt story. And they're like, "And this is what it taught me about business analytics."
And I'm like, is there a trap to try to always draw application? Or sometimes is it just these are things that spark, so you're not reading the mergers and acquisition book to be like, "I wonder how this would improve my testing."
But it's just like, oh, your brain makes this isolated connection. And that's kind of cool when that happens, but it's not necessarily an explicit goal when you're sitting down to read or listen to a book that day.
Aaron: Yeah, I agree. I think so. I think it's also the way that people present that information too. Because I did take enough time explaining the book and everything but that wasn't the focus of that. And I didn't mention the book and I don't really want you to read the book. I mean, you could but it doesn't matter.
Joel: I'm not going to.
Aaron: The point is how it connected that thought in my brain, like you said. So I understood the topic in the book, I felt the connection in my programming, I pulled out my voice recording thing because I'm walking and listening.
I recorded my voice, thoughts about what I just heard, and then I put it away, continued reading with my book. And the next day I came and I listened to that voice recording and I'm like, "Oh yeah, I remember that. And that applies to my programming. Oh, that'd be a great podcast topic."
Joel: Yeah, I like it. And there's just a little side tangent, it was an active learning. Because you're not just consuming and stewing on it, but you paused and recorded something, and then you came back to your recording.
So, that's another cool thing too. As somebody who geeks out on how the brain works and learning, I think that's another nice tip that you just shared there, Aaron.
Aaron: So basically, the end result of all this is I'm saying that you should read something else besides just programming or just besides what you like. Read something very different every once in a while.
Don't go too out of your area of expertise or your area of comfort, but just to push yourself every once in a while. And that will bring in things that makes your core area even better.
Joel: I love it. Aaron, have you ever come to depend on something having a particular color that doesn't need a color? I'm going to give you an example. A grape popsicle is purple, right?
Aaron: Mm-hmm (affirmative).
Joel: It could be yellow. It's food coloring, but it just would be wrong if it was a different color. Have you experienced anything like this?
Aaron: Not really. Because I feel this like you know, but I am red-green color-blind.
Joel: So is purple a bad choice?
Aaron: Well, there's quite a bit of colors that don't necessarily mean anything to me.
Joel: Okay, fair enough. I'll share one more with me because this is what made me think of this the other day. And it just made me think like, "This is really dumb."
Aaron: I can tell the difference between those two. Between a purple and a yellow, I could tell.
Joel: Okay. But the one other one I want to share is blue. So I was cleaning a toilet, and you know, the toilet bowl cleaner, my whole life it's bright blue. And this one, I don't know where it came from, was a weird light yellow, almost the color of pure bleach.
And it was fine, it worked. But I'm like, "I don't know if my toilets is clean." It just felt weird not seeing the nice shiny blue coating the inside of it. And then I'm like, "Oh man, what?" What does blue have to do with toilets?
And it was just a weird tangent my brain went on that I wanted to share with you.
Aaron: You're the guy that those commercials for fast food are made for. Where it's like, "Oh, yeah," It's boom, boom boom, a huge hamburger. And you're like, "Yeah, that's how it's going to be."
I know I told you to read a bunch of other stuff, but really, you should only read our programming books.
Joel: I agree a hundred percent. If you want to check those out, head over to masteringlaravel.io and click on books.