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:16):
I recently attended a conference and conferences are kind of exciting because you hear new ideas and you talk to people in the hallway and hear how they're doing things on their projects and in their company. A lot of times the speakers are sort of authoritative on a subject and you're listening to them. I just had this thought personally as somebody who gets excited about technology that, "There's probably some benefit to not just diving in." If you attend to talk on some new way of testing that you don't get back to work on Monday and just dive right in. You know what? We're changing our test suite over, we're doing this, that's a new thing. I thought, "I'm probably not the only one that has that tendency or that itch to do something like that." And maybe we could talk through kind of how we actually try to approach these things in the real world and strike a balance between excitement about new things, best practices, new techniques, but the realities of a real production project and work for a company.

Aaron Saray (01:22):
Yeah, so I thought I'd give a couple thoughts. First from my experience, a lot of times being managers of developers who I send off to a conference and then they come back and they tell us we're doing everything wrong. When you are in a project for a long enough time, the first thing you start to kind of develop is, "I know where we're doing the things wrong." When someone finds out how to do something better in a different way, which is something we're going to talk about a little bit here, the first thing when you come back try not to just say, "We're doing that wrong." Because it's like, "Yeah, we probably know that." Then I'll also say from a manager point of view, I send developers off to learn new things so that they can put together a better case to do that new thing not just immediately do that new thing.

Joel Clermont (02:11):
Sure, yeah.

Aaron Saray (02:12):
Then I have to work that in with all the other business needs that we want. Because what they learned can't save the company money but it can save the company money down the road. Whereas you want your paycheck next week?

Joel Clermont (02:25):
That'd be nice.

Aaron Saray (02:25):
We have to keep we have to keep doing the things that we're doing right now in order to get that to keep working? Right away when you say that I get this flashbacks to being the boss, sending some devs out and them coming back and be like, "We're doing everything wrong. We have to change." And I have to be that bad guy and say, "Yeah, I know that and also we're not." They look at you and be like, "What's wrong with you?" It's like, "No, there's a lot of things you have to balance in with that." But I think one of the things you were kind of getting at was more so like, I think in a kind of overlap is, maybe it's time to evaluate what this next best practice thing that I learned means in the context of our application and our skillsets.

Joel Clermont (03:08):
Yeah. Because, let's just start with the assumption that the best practice being preached actually is something beneficial for our project. There's probably 10 new beneficial things you could do, so you also have to weigh which one will have the most impact? Which one will actually address the problems that hurt us the most right now? So that's a factor to consider as well. But I also think that not everything labeled as a best practice or to even extend it not everything that big company X does is really a good thing for your three-person team that has an app that a thousand people use. Versus big company X which has millions of users, right?

Aaron Saray (03:56):
Mm-hmm (affirmative).

Joel Clermont (03:56):
That's the other thing to try to figure out as a developer too is like, does this really apply in our situation? Even if it is a good thing, maybe it's not objectively good across all times and places.

Aaron Saray (04:07):
Yeah. It's a good point of view too when you think about like, what is the size of my team and what's the output that we need? I've worked with teams and help development teams grow from two to three people. And you might think like, "That's just another person, what's the big difference?" Well, there's a huge amount of difference between two and three people on a team and there's a much larger difference between 10 and 100 people on a team. When you start looking, and it's not just the amount of people it's all the different processes, you start to see these processes that maybe make this app faster by 20% if you have this microservice than that, or whatever.
What you failed to see is that they had 100 people on that team and six of their jobs full-time was to manage those microservices. They can do that because adding developers two, three, five, seven, you don't get seven times as much then you start to lose some of that. So even if you had 100 developers, you don't have 100 times as many things being done, so you actually have wasted work. So instead of wasting that work, we can put some of those people on different types of tasks and those different types of tasks help manage those larger systems. So the size of your team really does matter and the type of technology you pick as well.

Joel Clermont (05:26):
Yeah, absolutely. More on the idea of, "Is this good for us?" I think one thing that's very easy to lose sight of when you're in that post-conference glow of information is that any new practice or best practice there are some trade-offs. If you're going to adopt this new thin, or you want to use this new package or this new way of deploying your app, it may solve 10 problems. But it may also introduce like two different problems than what you currently have. And it's so easy in the excitement to not even consider, "Well, what's the downside of doing this?"
I've personally bumped into that and I've come to the conclusion that with some of these things it really is good to approach them as a trial. Like, "Hey look, instead of taking our main customer facing revenue generating app and using that as an experiment for this idea, what about this little back office system that like three people use once a month? Could that be a good test case to see, 'Does this make sense or not?'" Maybe you'll evaluate and be like, "Whoa, I'm really glad we didn't just roll that out into a much larger project." It's like a safer bet when trying something new out.

Aaron Saray (06:44):
You brought up tests too and I can use another concrete example. Let's just say that you have a decently large application, you have a lot of work and you don't have any tests whatsoever. And you really don't know that that's the thing, so you've learned this at a conference that I should start testing.

Joel Clermont (07:02):
Okay.

Aaron Saray (07:02):
Some of the challenge there is that when you come back and start looking at implementing testing, one of the trade-offs is it's going to take longer to write your code but only in the beginning. That's the other thing that we need to keep in mind too is, some of these things are going to be more painful and have more expense in the beginning and then they'll slowly start to tapered and you might get more benefit or you might change. When I think about when I first started writing testing, I just saw all my applications start taking twice as long to write. I said, "Well, I get it. It's going to stop bugs but I'm so good I don't need tests. I don't write buggy code," which of course is silly. But I also noticed that the longer I practice that discipline, the faster I got just typing and things like that. But it also changed the way I started writing code so that my whole process was much better and faster too. I think when you talk about some of these things and you talk about the cost of them, it's an important understanding even further beyond the first test or trial, it's like, "What's the ongoing cost and will this affect change in our organization?" and stuff like that.

Joel Clermont (08:03):
Yeah, there's a lot of things to calculate and weigh but that's another. Good example.

Aaron Saray (08:09):
Another one that I ran into was integrating some sort of continuous integration platform to check for errors and then stop the release if there was errors in there. We had to keep in mind that for a trial when we ran it, it was great. We ran it on some of our dev branches but we had a QA team and they didn't necessarily know what that meant when a branch stopped, when it went to QA, because one of these automated things failed. It wasn't even just trying it out and seeing if it worked for us, we had to now alter another department's workflow based off something that we wanted to use.

Joel Clermont (08:50):
Yeah. The bigger the team, the more sorts of those interdependencies you're going to have.

Aaron Saray (08:55):
Yeah. I mean, you hear that Robinhood programmer, "I got that background with hundreds of programmers, so I'll just do whatever I want." I'm like, "No, no, no. Hold on."

Joel Clermont (09:09):
I like this topic mainly because I'm battling this exact thing right now. So in my case, some of it was stuff I was talking about and it's like, "Oh, we could use this and this project and that project and this other project." But the reality is you have to approach it in a balanced perspective and you really, especially if you're not a lone dev, you have to get buy-in from the rest of your team. Otherwise you're just going to irritate people and maybe it is a good idea and you'll just turn them off to it because of the way you introduced it too.
Was going through a fast food drive-through the other day. We were getting some McDonald's for the kids and my wife was-

Aaron Saray (09:55):
For the kids or for everyone?

Joel Clermont (09:56):
Just for the kids, I wasn't eating anything. She was relaying to me the order, so I'm placing the order and she's whispering it to me. She's like, "Get four piece nugget meal," or something like that. But I said, "I will have the four piece chicken McNugget meal." Just the fact that I said the whole phrase, like trademark, she freaked out. She's like, "Why do you have to say McNugget?" I said, "No, I said chicken McNugget." Like, sometimes I'll do things to be annoying or to try to be funny. In this case legitimately it's just the way my brain processes it. I'm looking at the menu, that's what it says, "Chicken McNugget meal" and so that's what I said. And I was like some sort of monster for actually saying the product the way it was supposed to be ordered.

Aaron Saray (10:43):
I don't know about you, when I go into the drive-through too I guess I get the same thing. We've talked about this as you get when you menu too. You go through a drive-through, you're like, "I know what I want." You look at the drive-through sign, you suddenly go, "What? What are all these things?" Then I saw new McDonalds has the big displays so technically they changed them. And so I'm not a creature of habit I'd be like, "Oh, I know I want a whopper which is not the same place."

Joel Clermont (11:13):
No.

Aaron Saray (11:13):
But I don't know Big Mac, I don't really eat there anymore. I want a Big Mac but I know that I can't order it without staring at it, I don't know why. So I look at it and suddenly it's like, "It's a chicken McRib," or whatever. I don't know.

Joel Clermont (11:29):
It's definitely not a thing either.

Aaron Saray (11:31):
Where is this thing? But I don't know if you remember, there used to be a place called Hot Now.

Joel Clermont (11:39):
Mm-hmm (negative).

Aaron Saray (11:39):
Basically it was just the cheapest hamburgers possible, this is probably back in the '90s. It was like you could get a hamburger with nothing on it like some pickles and ketchup mustard for the 39 cents. That was a good deal. So we'd go through after going shopping for a long trip or something. And I went with my grandma one time and I did not realize that she can't yell but she also thinks she has to yell. She was always losing her voice already for some reason. Then so we went there and she pulls up and she rolls down the window and she goes, "Hot [inaudible 00:12:20], seven hamburgers." I'm just sitting there going, "What is happening?" They're like, "Excuse me, ma'am." "Seven." That was the first time as a young person and the only time I just yell, "I'll take seven hamburgers."

Joel Clermont (12:38):
Yeah, like a whisper yell.

Aaron Saray (12:42):
Yeah. She could talk, she could yell at me perfectly fine. "Aaron, damn it," but when it come to yelling for something else it was like, "Hah."

Joel Clermont (12:52):
Too much pressure.

Aaron Saray (12:54):
Yup.
Do you feel like maybe you just know Laravel and haven't mastered it yet?

Joel Clermont (13:02):
You're not alone and that's why we made masteringlaravel.io. Check out this site to learn more.