Welcome to No Compromises. A peek into the mind of two old web devs who have seen some things. This is Joel.

And this is Aaron.

You and I were recently discussing a, I'll just call it a situation, less than ideal situation dealing with a third party on one of our client projects. Where they were doing some design work and had to supply us the graphics and what we thought was, I guess, a simple request. Which is like, "Hey, can you give us those graphics in a web-friendly and ready-to-use format?" And we're on revision three right now and we're still kind of struggling to get what we need. And it just is like the inclination to jump in like, "Fine, I will just do this," versus pushing back and having somebody else do it. We were thinking this might be an interesting topic to branch out into some other different areas and how it affects how we work on projects.

My first question actually is if there's any designers, I'd love to hear from them and hear what it's like being on the front end of the projects all the time. Because one of the things that frustrates me, the reason I bring this up is because a lot of times we have projects you have to give an estimate on. So that estimate may encompass two different parties. So, it's a little bit easier if you're in the same company but for us, we don't do design ourselves so we'll work with another company that maybe does some design. And the end client, the business owner, they don't care and they certainly don't want any squabbles with people that are working. But they want to know what is the end, when am I going to get this thing I'm paying for and how's it going to help my business? All that kind of stuff. I mean, the reason I bring that up is because there's a challenge. I think the first challenge I want to talk about is how do you do an estimation when you are not in control of both halves of it. And what's very common for us developers is we're on the second half. So, if anyone goes longer in their half, like a designer takes a little bit longer, which, hey, estimations are hard and art is difficult, I can't fault you on that. I can't do it so who am I to judge how long it's taking? But when that goes longer, the client is like, "Okay. Well, someone's got to pick it up," and so a lot of times it's developers at the end. I mean, just to be fair, a lot of times developers don't do a great job on the design even when they have enough time. So, I'm not throwing shade one way or the other. But I think that that's interesting that you brought that up is like, it seemed like an easy task and if there's an estimate around this, how is that going to affect us if maybe that third party can't do that task in the manner that we expect it to be done?

Yeah. And I would clarify, there's actually two aspects to estimation that are affected here. One is, when will this be ready to use? And that's actually in this case what the client is asking.

Timeline.

Like timeline. And the other one is if you're billing in a way that reflects how much time it's taking and now, you're-

Level of effort.

... level of effort, you're burning extra time going back and forth and back and forth. So, both of these things... I think they're difficult to estimate even if you are the only person working on the project, right? This is just the reality of trying to predict the future, trying to have the same level of understanding at the beginning of a project that you will have at the end of it. But, yeah, when there's a third party, you know somebody besides you and the client, it's way harder. And something you touched on too or hinted at was the client is expecting a level of professionalism. It would be unprofessional, I think, if when they asked us, "Hey, when is this going to be ready?" We're like, "Well, these idiots over here, you know, it's their fault." Even though maybe it is, maybe it is their fault, but you can't just do that. We're going to have to work with these people again so I think that's a factor too. But then there are also the reality of how do you set expectations.

Well, I think the expectations is kind of where I was wanting to lead us next. Is, that's a difficult as a... But I can take some blame, maybe expectations. We didn't set the expectations either, there's a lot of assumptions that go around, right? So, I guess it seems like a normal safe assumption for me to say, I assume that given the split and the amount of time and duration or whatever, when I am responsible, my measurement of how this is going to work is going to be different than the whole projects. I mean, that's the first concern I have.

Sure.

It's like when you were in elementary school and one kid messed around and the whole class had to stay in for recess.

That's right, yeah.

It's like, I don't know what this is doing. I suppose it was supposed to be some sort of pressure on that person, but all that's going to do is... I mean, it just made me not like them, didn't make them change their behavior. But no, I went on a tangent here.

No, I think it's a good tangent. Because you're facing the realities of the situation and the thing I will... You just took a little blame on yourself, I'll take a little blame on myself. In this particular case, they sent us the files and I didn't even look at them right away because I'm like, "Well, I'll look at them when I'm ready to work on it."

Right. Me too.

And some time elapsed between when they sent it and when I actually looked at it and I could have maybe shaved some days or even a week off of the delay by looking at it right away. So, lesson learned is don't just assume the graphics will be what you need. Actually, vet them and spend a little time so if there is some back and forth, you just tackle it right away.

There's a very delicate line that I think we try to walk too. Which is, what is the expectations of our responsibility in the project compared to third parties? And where do our boundaries lie with getting the service out of that third party, even though maybe it isn't necessarily our contracted resource? At some point, you have to say, "Well, your contracted resource, which I did not pick, is dropping the ball and I can no longer save you." There's those difficult conversations to have. But then there's also the boundaries of like, if you say you're going to do this thing, we're planning on delivering our portion of it. We're not going back to you and saying, "Please stop doing so many designs because I can't code them." I'm going to code whatever you make, but then I expect that the thing that's delivered to me is something I can make use of. And where do I draw that line with, like, am I supposed to then, I don't know, teach someone else in a different company what to do?

That's right.

I don't mind as an open-source person. I don't mind doing that, that's actually part of our goal here in Mastering Laravel too. Is, let's train everyone, let's teach anyone, let's bring us all up. But when you're talking about the livelihood and I'm trying to get the project out the door, and I care a lot about this different stuff, there's a boundary that needs to be there and I just don't know where it is.

No, that's a good point. For me, there's what we said we were going to do, what we could do, and what we just refuse to do. So, if it's something we said we're going to do, we're going to do it. It's this gray area in between, like okay, this is the third iteration, the graphic is very close to what we need. Do we just bite the bullet and open an image editor and fix it to what we want? Or do we keep, like, "No, this is where our boundary is, you have to give it to me perfectly." That's a little squishy. If it was something like, "Hey, our email server is slow or down," that's so far outside the realm of anything we would have responsibility for. Like, that's clearly beyond the boundary. But this middle ground, it's like, "Well, yeah, I could do that." It's not really what I do, but I don't know. That's where I'm having a little trouble.

I think those are some interesting conversations. I'd love to hear from others who... and there's different types of positions too. Whether you're an individual contractor, you work in a contracting company kind of like we do, or you're working for the man in a larger company, in a team. There's all different ways that this affects you. I'd just be curious to know if there's any types of skill or skill sets that I'm missing here or tips and tricks that I can learn to be a more effective member of that team too.

Yeah, I'm interested as well. We're open question, we obviously don't have a clear solution here. It's a sort of a case-by-case thing, but if you have some feedback for us, we would love to hear it.

But if you're not going to do it, then stay away from me. So, I have a number of air purifiers around my house. And one of the things they do is they sort of indirectly alert you when you're cooking something that has a lot of particles in the air, right? So, if you're making a steak or something like that, and it gets in the air, you can smell it, it's great. But then the air purifiers are like, "Oh, there's many different molecules. We got to speed up." All right. The other day I tried a different way of preparing some vegetables. I tried roasting some broccoli, but I didn't oil it enough and I didn't put it on a high enough heat so it ended up kind of steaming. And then I took a walk. And when I came back in, I was like, "What has happened in here? Oh, it's horrible." It smelled so bad, just the worst. Like someone had some bad gas. And I walked up the stairs-

I mean, it is broccoli.

... well, I walk up the stairs and all the air purifiers are on maximum and they're like whirl. I'm like, "What is going on?" And it was just basically steaming broccoli in an oven is worse than cooking a steak in cast iron, I found.

Good to know.

Yeah. As developers, we really care about the products that we build, but I'm colorblind and Joel can't draw, so we're always looking for a good designer.

So, in this case, if you can help us, get in touch. We're at masteringlaravel.io and just use the contact form if you're a designer that's looking to work with somebody.