Planning out a week of work

Continuing our series on "how we work", today we finally get to the dev work. How we organize it, plan it, and communicate with the project stakeholders.

I heard this site is cool: masteringlaravel.io

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: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):
Here we are, another episode of how we do our work, kind of picking that series back up. And everything so far has kind of been leading up to the thing that most devs think about which is doing the work. Building whatever it is that you were hired to build for the project. There's a bunch of different ways of doing that, I know I've experimented with many over the years. I know even you and I working together have kind of slowly refined a system. But I thought it might be useful to sort of share how we set that up and then as each week progresses, kind of like what a normal week looks like for us.

Aaron Saray (00:53):
Yeah. I think when I started working with you, you were just a crazy cowboy and I said, "Settle down, Joel."

Joel Clermont (00:59):
Yeehaw.

Aaron Saray (00:59):
"Let's get boring and put everything in the tickets."

Joel Clermont (01:04):
That doesn't sound like me at all but I will agree that the process has definitely been formalized when you have to coordinate with another dev. We use GitHub for our source code so our ideal scenario and kind of what we settled on is also trying to use GitHub for work management. Now, that's not to say that other systems don't work, but I just kind of like having everything in one place. We make use of GitHub Issues, GitHub Milestones, GitHub Projects, and honestly it's pretty simple. In fact, there's this new, what is it called, Issues Beta or something that it's almost like GitHub wants to be Jira. I opted into it, I'm one of the repos, and then promptly never used it. This is just the vanilla kind of boring, simple way of doing stuff, but we'll walk through it.

Aaron Saray (01:56):
What you meant is it's new or it's been here for three years depending on when you're listening to this episode.

Joel Clermont (02:04):
That's true. Okay, yeah. Maybe it's been around for 30 years, "Hello, time traveler." Where it starts is the issues and as you alluded to we kind of write everything up as tasks. And generally speaking, I mean, sometimes the tasks will start out bigger and then as we work them we might decide, "Oh, this is kind of big. I'm going to split this into like two or three different tasks." But generally speaking it's a unit of work, it's a feature, it's something that we're going to either do or deliver as part of executing the project. For each issue, obviously we have a description of it, you know a title and a summary in any supporting documentation. But some of the important things we also like to do, or at least I do, I don't know if you care about this, Aaron, but I like to tag things with labels.
On some projects depending on how we work we might even use like a size label; small, medium, large. You know, it's not meant to convey hours of work or anything super granular. But just kind of like a rough sense like, "Oh man, I don't have a lot of time today. I want to make some headway on this project." I'll grab a small one. Or, "Boy, I got a whole day ahead of me I'm going to grab a large one." Just those sorts of things. And then there's a few buckets of labels that we assign to a task. You know, maybe something is a feature, maybe it's a bug, maybe it's documentation, maybe it needs design, maybe it's a setup task. You know, like, "Okay, let's deploy this to a fresh environment." But we don't go nuts with it. I think we use maybe a total of seven or eight different labels plus those size labels. And that's enough to kind of get a sense for like, "What is this ticket?" and helps categorize things later.

Aaron Saray (03:51):
Yeah. I think it also depends on the tickets that we create kind of depending on the client we have and how we want to communicate with them too. Most clients want to know in general where something is in the pipeline but they don't care so much about the details, so we kind of adapted ourselves to that work too. For example, if you have a client, it's like, "What would you say to that client that you're working on and that's the actual ticket?" And then inside of there you could put check boxes or whatever for more of the technical things.

Joel Clermont (04:21):
Sure.

Aaron Saray (04:21):
So you might say, "This is in progress," and you start to check through the things that you're working on.

Joel Clermont (04:25):
Yeah. And I'm glad you mentioned clients because I think we discussed this in our earlier episode, but this is a client-owned GitHub organization/repo so they have visibility. Whether they use it or not or care about it at all is a different topic. But most of our clients, even some that were kind of non-technical, have expressed like, "Hey, that's kind of cool that I get updates," or, "That if I have a bug I don't have to call you or email you. I can just write up an issue and I know you'll massage it a little bit to make it more technical or the way we need it to be for work." But it is collaboration and it cuts down on a lot of unnecessary communication because it's that central point of truth.

Aaron Saray (05:04):
I think also understanding that we own the labels and all they have to do is add in something just real quick. Because I've worked with things like Jira too with complex workflows.

Joel Clermont (05:17):
Oh, yeah.

Aaron Saray (05:18):
And then started noticing that my stakeholders weren't using it anymore because it was like, "Well, to fill up this ticket you have to check 27 different boxes." And they're like, "I used to be able to just call you." It's like, "Well, don't but also I understand that this is frustrating." So we try to keep that simpler for them and then we handle the rest of it.

Joel Clermont (05:35):
Yeah, very low friction. Let's just say we have all the issues kind of stubbed out for what we want to work on. Generally speaking, we'll organize those into a project. I think it's pretty rare for us to have more than one project in a repo. It has happened occasionally but for the most part we have a single project we are working on in a repo and we will bring the issues that we've created into that project. The project, if you've never seen them in GitHub, there's different ways of setting them up. But generally speaking you kind of have different columns for, is this something we're going to do? Is this something we're currently working on? Is this something that's needs review? And is this done?" Kind of like the four basic columns.
And then within the issues and the project... the project is like a board you can look at and get a sense, "Okay, here's everything we've sort of committed to and is in the pipeline." But then we'll go a step further usually and also use a feature called milestones, which essentially are arbitrary buckets of deliverables. So a lot of times we'll do it weekly. You know, we'll just have week one, week two, week three, based on the calendar year. That gives an additional layer of like, "Oh. So there might be 30 things in this bucket for the month of whatever, but these 10 are going to be week 27, these 5 might be week 28." It just kind of helps somebody to see a little more at a glance whether that's us or the client, "Here's the general flow we think things are going to follow."

Aaron Saray (07:08):
Yeah, I think that's right. One of issues I ran into in the past was trying to figure out how to use milestones and everyone has their own sort of way of doing it. But just to double down and clarify, our big project that we're doing for the client is The Project and then the milestones are the steps to that project. So I've seen a lot of people use milestones for features of a project. You can do that but I think the whole time-based thing knows better because although we don't bill per hour, people still care what's happening what week.

Joel Clermont (07:44):
Right, yep.

Aaron Saray (07:44):
So our experience has been too, it's just been easier to communicate to people looking at the week milestone saying, "This is what happened this week," or whatever. Versus saying like, "Well, we're two-thirds through releasing the feature of X, Y, Z," and they're like, "Yeah, I don't know how long it's going to take or care."

Joel Clermont (08:00):
Yeah. I think part of how we settled on this use of milestones was based on some constraints in GitHub. You know, in Jira you have all sorts of date fields. Due date, estimated time remaining, all these different things, you don't really have that in GitHub. We kind of settled on milestones being time-based because it gave us just sort of like a bucket of rough time, not specific due dates. Also, I know I do it this way, I think you do too, I kind of plan out weekly, right? I sort of look ahead to what I'm going to work on this week and just having that line up with the way things are configured in GitHub has been really useful.

Aaron Saray (08:38):
There's one thing that me and you do that I found super useful with projects and stuff like this that maybe other people might run into too. Depending on our project we might either be working, developing both at the same time or one is handling more of the customer communication and signing off on sort of our feature work, and the other person may be doing more of the programming. One of the things that we'll do is let's just say who's developing this ticket, they'll move it through the columns and when it's done they'll put it in a done column but still leave the ticket open. And then the person who is signing off on it or merging a poll request or whatever, they'll see stuff in the done column and then when they agree it's good to go, then they'll close the ticket.
They'll still remain in the done column but it'll have a different checkbox, or whatever like that. That's been really nice because we can say, "Yeah, I've finished this. It's ready for you, Joel, to take a look at." And then when it's done you merge it in, close the ticket, it's good to go and we still have a nice listing of stuff that we've completed. And then that kind of leads into how you give updates to the client.

Joel Clermont (09:45):
Yeah, that's kind of where my mind was going next. You know, we generally communicate weekly with a client. I know some teams have daily standups and things like that. I try to minimize those formal meetings, especially real-time meetings when you're on a phone call or on a Zoom meeting or something like that. But we'll do it once a week and generally it's over email. You know, "Here's what we did last week, here's what we're going to work on this week," and maybe, "Here's something that's blocking us." You know, something that requires special attention or outside input to help us keep moving. But we can just look at the GitHub board to be like, "Okay, what did we do last week?" As long as everything is captured there, it makes it really easy to send those updates.

Aaron Saray (10:29):
I wanted to, just a tiny little aside from my background as being a development manager. I've done a lot of daily standups and I tell you I never really liked them but I had to do them for two reasons. And then when I tell you these two reasons, maybe it can help you not have to go do them if you're a developer.

Joel Clermont (10:46):
Okay.

Aaron Saray (10:46):
One is just the culture of the organization where I would get pinged or asked multiple times a week on the status of certain things. And that was partly my fault for not setting expectations right and that's partly just the culture of the company and that can only change so fast. Sometimes it's a little beyond what you can like, "Yeah, it's great but I need to know these things because someone's asking me every day." And then two, the larger reason, I've ran into this many times is, developers don't like messing with tickets. They don't like updating them and making good commit messages and all that kind of stuff. When you don't do that, then I have to have a meeting with you. So if you don't want to have a daily standup meeting, write better tickets, keep your tickets up to date before you leave for the day or before you're done, update your ticket. That way when I know I can finally trust those, then I'm going to stop wanting to have meetings with you because I just want you to work.

Joel Clermont (11:41):
Yeah. No, that's a good way of looking at it. One other thing to mention just as long as we're talking about meetings. So with the weekly check-ins, generally it's over email but it is good to still have kind of that either face-to-face or real-time communication. What we usually do is once a month we'll have a monthly planning meeting with the client. And that's where we can kind of set the goals for that month, set the priorities and kind of figure out what's a reasonable amount of work to do.

Aaron Saray (12:09):
It's best to do it around the time when they're going to be paying you too, so if they don't pay you they have to face you.

Joel Clermont (12:15):
Ooh, I like that.
The house I live in was built in the 1970s and apparently a thing people did in that time period was instead of just putting a doorbell on the front of their house, they also put in an intercom system.

Aaron Saray (12:39):
Oh, yeah.

Joel Clermont (12:40):
So if you want that experience of living in an apartment building but you have a house I guess this is one way of doing it. When we moved in the intercom system was already gone. But I was recently doing some work in the basement and I could see all these wires that appeared to go nowhere and I figured out these were for that old intercom system. There was one going to the front door, there was one going to the kitchen, there was one going all the way up to the upstairs bedroom. I'm like, "That's kind of dumb." Like, if the doorbell rings this house isn't so big that you couldn't just walk to the doorbell, open the door and talk to the person, right? It seemed like kind of a stupid idea. I should probably add that the thing I was doing in the basement was running wire to one of these new video doorbells that I bought. And this was a whole ordeal in itself because I'm not really good with electricity. Like, despite my family thinking because I work on computers I understand electricity. I don't know how that works. But anyway-

Aaron Saray (13:43):
I just want to follow your logic real quick though.

Joel Clermont (13:47):
Okay.

Aaron Saray (13:47):
The house is not too big so you don't need the intercom but it's too big to just look out the window?

Joel Clermont (13:55):
Yes, it is too big for that.

Aaron Saray (13:57):
Okay. So that's why you need the video doorbell because-

Joel Clermont (14:00):
Well, and the video doorbell is like also a camera, so there's other security benefits to it. But, yes.

Aaron Saray (14:05):
That windows would not provide? Yeah, I understood.

Joel Clermont (14:08):
Got it, got it. I finally got all of the stuff figured out with the doorbell. The doorbell's working, I was testing it out with my son. You know, one of the features of this is a two-way radio and I'm like, "Ah, crap. I just put another intercom in my house." I was making fun of these people from the 1970s installing intercoms and I basically just installed a fancy intercom.

Aaron Saray (14:33):
Yeah, everything just goes in cycles.

Joel Clermont (14:35):
Yup.

Aaron Saray (14:37):
Here is where I would say something funny and possibly pithy.

Joel Clermont (14:41):
And that would make you want to visit masteringlaravel.io, which is full of all sorts of Laravel goodness.