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.

Being a developer is full of many decisions where you have to decide between doing something the right way and, "Do I just do it the easy, expedient way for now?" We deal with this all the time. And a lot of times it has to do with code, but I'm going to talk about it from a different perspective. Which is sort of like project setup and infrastructure, and all that. And specifically when we're working with a non-technical client, who's never... before they talked to us, they wouldn't have no clue what GitHub is. But we use GitHub, we need to have a Git repo. This is one of those things where it's like, "All right, do I walk them through creating an organization and inviting me to it, and then I work in that? Or should I just create the repo and at some point, I'll transfer it to them? I'm not being malicious, I'm not trying to retain control, but I just want to get coding on this project." How would you think through that sort of decision?

Well, it sounds a little bit you just answered it there. I mean, there's two options. Do it the quick and easy and maybe not right way, or do it the right way. I'm going to go with the right way. I think that's what you're asking, right? Let's do it the right way, Joel.

All right, you passed the test. No, I bring this up because that particular example probably isn't the worst. In fact, with our clients, I even have a one-page PDF that I send them that walks them through setting up a GitHub org and inviting me to us. And even the most non-technical client has not had trouble doing that so that's one is kind of obvious. But I think it's worth bringing up because that's one example of a lot of different things that come up in the life of a project. Where it's like, "Do I pause and involve this other person where I'm going to have to help them because that is the right way to do it? Or, do I do the easy thing with the intention of coming back?" It's almost like technical debt, but at the project setup level.

I think that's a good way to question it. Is it, are we adding on technical debt? That's a good way because as programmers we always say, "Oh, they're making us have this technical debt." It's often times the business that's pushing us forward when we want to fix stuff. So you have the choice at the very beginning if you want to do stuff the right way or do you want to start with technical debt? And that's assuming that you'll remember to move that over there, that's assuming that the client then can continue to pay you... You can part ways with them amicably and still have control of their code if you did it the wrong way. So there's a lot of reasons why this would be a problem to do it the quick, easy way right away.

Yeah. You know, I'm framing this because I wanted to talk about it. And just to be clear, we do set this up the right way. We have our clients set it up, we don't own any of the important assets. But at the same time, we do join projects where it was not done this way and it causes problems. Most developers are not like, "Oh, I'm going to do this so I can retain ownership and hold something over their head if they don't pay me." Maybe some people do that, but in my experience, that's not what it is. It's probably more like, "Oh, I just haven't gotten to that yet. I want to be writing code, I want to ship the first demo. I don't want to even waste an hour trying to walk them through setting up a GitHub org for me." So I think it's worth calling out. And I like the idea of tying it to sort of just taking pride in your craft and doing it the right way and even explaining to the client who may not even want to do this. Like, "Why are you giving me this homework?" "You know, I'm doing this for you, and here's why. I know you love me and you're never going to want to not work with me. But you are going to probably want to not work with me at some point, that's fine. This is going to make all that easier down the road," you know? It shows you are looking out for their interests and it actually builds trust even though it could start as a little bit of an annoyance that you're giving them a task to do.

I see. The other direction is, my experiences with majority of clients don't know to even be annoyed that I'd be asking them to do this because they wouldn't know that they were supposed to, and they wouldn't know that they have to play any part in the role whatsoever. So when you're saying, "Well, they might be annoyed and that's kind of what it pulled off." I think it's that, my experience has been developers don't think about it, maybe we'll do it later and clients never know to ask for it.

Absolutely not. They don't.

I don't think that they'd be irritated. I think that they'd be like, "Oh, okay, this is part of the test." The way I would approach that instead when I began, there's no discussion about whether it's better for them or not. This is what happens, you don't have an alternative. Like, "Oh, you're giving me this work?' "Yeah. This is the beginning of the project. You do this part and I'll do the rest. Thank you."

No, that's a good way. Because there's other things, again, to tie it back to technical side. Where, "This is non-negotiable, this is how we work." Like, it's not an optional line item when we're bidding on a proposal. I like framing it that way. Like, "Hey, this is the work we have to do and it benefits you and I'm going to make it easy for you to do because I've walked you through it step by step."

What's very interesting there is you kind of mentioned it as almost like an opinion. Like, "This is an opinion, but it's really close to a non-negotiable." I want to just force it one more step and say, "No, it's non-negotiable. I'll never have your code under my name, they'll always be under your name." It's not a non-negotiable, it's just how it has to start.

So while you were talking, I was actually thinking about a long-time client of ours that I was having a call with them about something else and something came up. It's a great relationship, there's no tension, nothing. But they were kind of hedging around this question of, "What if you weren't here anymore?" Like, how would we keep going with this? So they were basically trying to ask, "Hey, are we dependent on you for everything that we need?" Because the app we built them essentially runs their whole business. So what was great was being able to answer them. In fact, we were on a call on Zoom and did screen share. I went into GitHub. I said, "By the way, remember this is your GitHub, you invited me to it." And in the README, it was literally step by step. Here's how to run the project, here's how it's deployed. And they're like, "Oh, that's so great. I'm so glad you did that. That's wonderful." It was, maybe even a little education, not just on the account ownership and things that but even the technical knowledge around the project and how it all works, we got your back. Speaking to the client, "We have your back on this. We don't ever want to be in a position where you feel you're stuck working with us."

Yeah, this all makes sense. And really when you said, "Is this a move past or move me out of the project or whatever?" The client was probably asking more about disaster recovery. Like, what if our programmer just got hit by a bus? And so it's not always trying to tell the client, "We want you to move me on and get rid of me." Sometimes it's just the world happens too and the client wants to be prepared, they're doing their research.

Yeah, they absolutely should care about those things so you shouldn't be offended if they ask the question. And I wasn't, you know. In fact, I was kind of having a little fun with it because I could tell they were uncomfortable. I'm like, "It's all right, guys. These are good questions to ask." So maybe just kind of a wrap-up thought. You know, thinking about the sorts of people that listen to this podcast. I think especially if you are a solo developer, you're an independent and you work with a variety of customers. Because I've been there, I've been in those shoes for many years. It just sort of a plea to really take this seriously. And even though your intentions are good, just kind of double-check yourself. Like, "Are you really making sure the client owns everything if you become unavailable for whatever reason?" You go on vacation, you get another job somewhere, or the bus thing that Aaron mentioned, would they know what to do? So it can really even set you apart as a professional and more interested in the client's best interests than just kind of being interested in the code and the tech stuff, which is what comes naturally to us.

So, Joel, today let's talk a little bit about politics.

What now?

Yeah. There's dill and bread and butter and various different types of pickles that you can order online and you can get in your store and everything. I really just enjoy trying to find the best pickles I can.

What does that have to do with politics?

Nothing. You know, people are so afraid to mention politics on podcasts and stuff, I thought I'd start out with that. But no, I just really want to talk about the pickles. Are you a fan of pickles?

I am, absolutely

I've been going on this whole pickle experience or experiment, I guess. I have now kept a spreadsheet of 30 different brands of pickles that I've tried.

Oh boy.

I've ordered them all over. So this is kind of my plea to everyone else there. I really a nice garlicky dill, not spicy pickle that doesn't taste sweet. And a lot of times I think that there is some either sugar or the way that the vinegar kind of ferments tastes a little sweet. I don't that sweet taste.

And not spicy either.

Not spicy either. Because sometimes people use that to cover it up. I just want a nice dill pickle-y, sort of maybe a little bit of garlic in there, and that crunches. Oh.

Are we talking about whole pickles, spears? Does it matter?

It doesn't matter. I think one of them there's a Clawson's brand that's spears that I really love. They're nice and firm and crunchy and just dilly enough. They come in the refrigerator section. But yeah, I'm open to any suggestions on how I can make my pickle experience better.

I'm with you on that. And I just also want to commend you that you stuck with a spreadsheet and you didn't go straight to building a SaaS app.

As a solo dev, it can be hard to get more tips and tricks besides what we just have in the podcast or in the newsletter.

Head over to our website, masteringlaravel.io. Click on community and check out another option for solo devs and Laravel developers to get support.