Your project is not special

This isn't meant to be an insult. It's actually a good thing that your project isn't completely unique, and you can benefit from what other people have already learned.

Creators & Guests

Host

Aaron Saray

Host

Joel Clermont

What is No Compromises?

Two seasoned salty programming veterans talk best practices based on years of working with Laravel SaaS teams.

Joel Clermont (00:01):
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.
I have kind of a, I don't know, controversial thing to say to you, Joel.

Joel Clermont (00:21):
Aaron, those are the hot takes.

Aaron Saray (00:23):
I'd say that none of your projects are really that unique or interesting.

Joel Clermont (00:30):
Mmmh, can you elaborate on that?

Aaron Saray (00:32):
I'm glad you asked because a lot of times you sound like a jerk.

Joel Clermont (00:34):
You're right, yeah.

Aaron Saray (00:35):
No, I was thinking about this the other day as I was working on something and I saw a lot of overlaps with other projects. And I think there are a couple different ways to look at the fact that all of our projects are similar. So from more of a technical point of view, we talk a lot about design patterns. So what are design patterns? They are these sort of patterns or ways of doing something that were invented many, many years ago that kind of say, "This is how you would build software architecture." Some of these are like Singleton or Adapter pattern, or things like those. Those are all design patterns that are implemented differently in every language but the idea of what they're trying to accomplish is the same.

Joel Clermont (01:23):
Okay. Yeah, sounds a little boring but... I mean, I prefer to just reinvent everything myself but I joke.

Aaron Saray (01:30):
I mean, I think I ran into that the first time when I was working with a dental insurance company that had 40 RPG programmers that they basically work on AS400. We were working together and they started talking to me about programming and I was this hotshot PHP web developer and there was nothing I could learn from them, right? Because I'm the way to the future and they're using green screen. Then as they started to share some of their code with me, I mean granted they printed it out, which I never understood.

Joel Clermont (02:03):
Okay.

Aaron Saray (02:03):
But they shared the code with me and I started recognizing things that were very similar to what I was doing. I asked questions and they're like, "Oh, that's the so-and-so pattern," or, "design pattern." I'm like, "Wait, you have patterns?" And that's when I learned as a PHP developer, "Oh, people have solved all the problems of programming basically already, you know. And we can follow these patterns and apply them to our own languages." So that really got me thinking about, "Where else do we see that in our projects?" The reason I call your projects boring or all of our projects boring, or whatever I said is, if you start to look at the core of what you're doing the businesses themselves may be different but a lot of the stuff that we're doing is the same no matter what project.

Joel Clermont (02:53):
Yeah. And just to throw some color on this. Like, I think when you say boring you're saying that as a positive thing, right? It's not boring like, "oh, this is all the same," and like, "I hate doing this." But more boring like, "It's not this new novel thing that you have to forge new research on." But that you can kind of learn from the past and learn from other people, am I understanding that correctly?

Aaron Saray (03:16):
Well, I think you're actually putting it in a better way than I am. When I say boring, I was just thinking like, "Well, there's nothing new about this." You know, us programmers we want to go for the shiny thing and learn something new but with your project, like you said, boring could be good. It could be something that you could learn to do better. I've always been a fan of sharpening my skills, making them better and better and better. So these things that are really the same, they're repetitive, actually help me get better and better at doing that thing.

Joel Clermont (03:47):
Yeah. And maybe it even kind of shifts where your creativity is. Like, I'm going to use an analogy and I don't know if this makes sense. But if you're building a house, the person constructing isn't like, "I wonder how we should frame this wall," or "You know, I wonder what structure we should use for the basement wall." Like, there's some pretty obvious patterns depending on like where you live and what your budget is and things like that. But the inside of the house you can decorate it however you want. You know, you still have a lot of creativity and freedom. Like in the code, maybe the user experience is the cool thing or the place where you try to differentiate yourself, but accessing a database or you are communicating with other services or doing things like that, probably don't need to forge new ground for most projects is what you're saying.

Aaron Saray (04:34):
Yeah. I think that's something you learn if you do many different projects. Like we as consultants move in through different projects but also if you just talk to other team members and learn about different businesses there's something truly valuable about doing that. Now, if you're building car sales software and you go, "Well, what does this herb selling platform have anything to do with what I'm building?" Well just talk to them anyway and just learn about their business and learn how they're solving the problems. What I've seen from that is, as these people may be doing a different business have implemented some of the same patterns that I do but in a slightly different way. Could be worse, but more often than not it's something different and better that I can learn from. When you look at it from the surface, you're saying, "Well, that's something completely different, there's no overlap in these two businesses." But when you get down to the code, you're like, "Wow, we are actually doing the same thing."

Joel Clermont (05:27):
Yeah, I think that's a good observation.

Aaron Saray (05:30):
That's one of the reasons too why you can see a lot of value with going to conferences, things like that. Because there's tons of different businesses there but they're all doing that same language or they're all learning similar things. And when someone goes and says, "I'm from AWS, I'm going to write this testing stuff," and you go, "Whoa, actually that does apply to me a little bit."

Joel Clermont (05:51):
I like this, Aaron. I guess maybe one of the things I would add to this is there's the opposite side of the extreme where you got to... Like, "How many patterns can I put into my project?" So I know you're not saying that but I wanted to call it out. But really a lot of times I think the first time I read a design pattern book or became really familiar with the concept, I just recognized these were things that I had already kind of been doing in some cases but they had a name now, or maybe they had more details about the benefits of doing it that way versus other ways. So this isn't like some new thing, like, "Okay. Go rewrite everything with design patterns." But just an acknowledgement that these things exist for a reason and you're probably doing it to some extent already. But I like that idea about not isolating yourself or feeling isolated. It's really just kind of a positive thing like, "Hey, you can learn from more people than maybe you thought before, previously."

Aaron Saray (06:53):
Yeah. I guess I don't want to be wishy-washy and then go on the opposite side and be like, "Well, don't copy other people in different businesses," you know? But there's a limit to what is the overlap and what is the amount of design patterns you should implement or whatever. But I've just found in my travels that we need to acknowledge more that we can benefit from learning more about these design patterns and that a lot of our stuff is actually very similar. I really like your analogy, like stop trying to figure out what is the best, you know, way to frame the house. We kind of know how to do that.

Joel Clermont (07:28):
Right, yeah.

Aaron Saray (07:28):
That's kind of where things like Laravel come in. Like, Laravel has tools like eloquent for the database access. We've solved all the access to database, settle down. Stop trying to put something else in there and just use the tools and then build that special sauce on top of that.

Joel Clermont (07:49):
Yeah. I like that way of looking at it.

Aaron Saray (07:58):
All right. If I had unlimited money which would be very bad, right? Because I have a lot of different weird thoughts in my head. But you know how when you buy LED lights or smart hue lights they have a little chip in them or whatever?

Joel Clermont (08:14):
Mm-hmm (affirmative), okay.

Aaron Saray (08:14):
I would invent a light that between ten seconds in like seven minutes or ten minutes or maybe a couple hours, would randomly just blink and then maybe do two beeps or something. And then install those in all of the light sockets when I moved out of my apartment.

Joel Clermont (08:30):
Oh boy.

Aaron Saray (08:31):
Hey, can you imagine? Because especially if it's like 10 hours, you'd have your light on forever and be like, "I promise you, it does blink and beep." And you're like, "Yeah, right." As soon as someone leaves all a sudden it's like, beep, blinks.

Joel Clermont (08:45):
I think if you want to really put it out there have it be like a dog bark or something really random instead of just a beep. So they're not even sure if it's a real noise coming from outside the house. Or, like a duck quacking. Like, "What?"

Aaron Saray (08:57):
Or if someone is saying, "Hey."

Joel Clermont (09:01):
Oh boy.

Aaron Saray (09:01):
You imagine that. It's nighttime, you have your lights on, all of a sudden you hear someone from the other room, "Hey." What?

Joel Clermont (09:07):
2:00 in the morning? Oh boy. That would be very unsettling.

Aaron Saray (09:12):
Well, why'd you have your lights on at 2:00 in the morning?

Joel Clermont (09:14):
Oh, the light has to be on for this timer to be running?

Aaron Saray (09:17):
Oh, I suppose. I would assume, yeah, because they have to blink. I thought noise or blink the light or something. Just enough weirdness that it was, "What?"
Speaking of things that people have already done before, we've written a book.

Joel Clermont (09:34):
And it's full of patterns. The topic of the book is Laravel validation and how you can master validation rules. Find out more at masteringlaravel.io.