One of the best tools we have for building a productive development team is setting up their optimum environment and process for the coding aspect of their job. Now we've already talked about meetings and flow state, minimizing interruptions and other higher level environmental ideas that help your team feel safe and supported at work. But now let's talk about code version, control workflows and code processes and more.

But now let's talk about code version, control workflows and code processes and more. The goal of any development process or setup that we come up with is to enable developers to write and deploy good code. That's it. And if a process isn't enabling this or worse, if it is detracting from this happening, it's not a good process and that's it. You can evaluate everything against that. And there's a ton of common examples for processes

You can evaluate everything against that. And there's a ton of common examples for processes that purportedly help us out but are actually harming the ability for developers to write and deploy a good code. Usually things that serve the business' micromanagement and need to control everything at the expense of actual productivity. Things like uh, excess excessive standups. I would say even daily standups planning meetings

Things like uh, excess excessive standups. I would say even daily standups planning meetings with 20 people for a single feature. Um, having to attach your commits to every single Jira ticket, excessive time tracking requirements, and then more if we focus instead on enabling individuals and small teams to quickly build out small pieces of code test and deploy them, ship it to production, and then just do that over and over

test and deploy them, ship it to production, and then just do that over and over and over again iteratively until we're done. That is the way we are creating systems that are most effective towards our teams, our companies, our organizations, uh, to deliver value, uh, to the end user. So let's talk about some tools, systems and processes that will enable our developers to build and ship great code.

and processes that will enable our developers to build and ship great code. First off, gi, If you're not using GI yet, you will be absolutely gobsmacked by how much it improves your workflows. And this is not true just for larger teams. It's even true for an individual. And this is true about all version control. GI is just emblematic

And this is true about all version control. GI is just emblematic of version control these days 'cause it's the best out there. But I will do wanna say specifically that Git is by far the most flexible, most capable and most supported version control system out there. There's no reason to use anything else and there's no comparison. And if you're an old head, you might have familiarity with using older version control systems

And if you're an old head, you might have familiarity with using older version control systems that got bigger and bulkier. The more work that you had, if you lost connection with your external system, you were stuck because you didn't have a local copy. None of that is true with gi. You have a local copy of everything up and running, it's super light, it's only storing the diffs. It's the best out there If you've never tried it,

and running, it's super light, it's only storing the diffs. It's the best out there If you've never tried it, you gotta give GI a chance. I couldn't imagine writing code without GI today. Now if you work with gi, you do have to choose some kind of a centralized host to have any kind of modern development tooling. And people may hate me for this, but I'm just gonna say it straight out. There is only one reasonable choice when it comes

but I'm just gonna say it straight out. There is only one reasonable choice when it comes to a centralized GI host and that is GitHub. Now Bitbucket is the one of its biggest competitors. It's run by Atlassian who makes Jira. And I think that's literally the only reason anybody uses Bitbucket is because they like Jira, which is a problem in itself. But regardless of whether or not you're on Jira, Bitbucket is pure garbage.

But regardless of whether or not you're on Jira, Bitbucket is pure garbage. Don't touch it. The other primary competitor is GitLab, which has some things to offer some things going for it, but it doesn't come close to GitHub when it comes to building out the user experience and developer experience for modern productive development teams. The few dollars you save by uh, using anything other than GitHub is completely burned

The few dollars you save by uh, using anything other than GitHub is completely burned by the amount of extra work you have to do by choosing to use a subpar tool. And if you're saying, oh, well that's really nice for you to say, but give us an example as I could do an entire video just about this. But for starters, just compare the poll request workflow between all the different tools. For starters, GitHub actually invented the modern pull

between all the different tools. For starters, GitHub actually invented the modern pull requests we know about today. Uh, prior to that there was a concept called request pull, which was very manual. It didn't look at all what we're looking at. So the actual pull request first of all is a GI GitHub invention. And second of all, GitHub, GitLab and Bitbucket have done poor at best jobs

And second of all, GitHub, GitLab and Bitbucket have done poor at best jobs of mimicking their work all the while GitHub was slowly but consistently refining the experience and the feature to be better every year. Okay, so your code base is on Git, preferably using GitHub. Now it's the best branching strategy. That's usually one of the first questions you get asked. There's a lot of different popular strategies. There's GI flow, there's GitHub

There's a lot of different popular strategies. There's GI flow, there's GitHub flow and there's lots of others. But here's what we prefer at Tighten at minimum, and we've used this across hundreds of code bases and I'm really big fan of it. So for starters, you have your main branch which holds the kind of core identity of like this is what our application actually is and later we'll talk about this,

what our application actually is and later we'll talk about this, but it should be the thing that automatically deploys to production and your CD workflow. Then you have a developed branch or staging, whatever you wanna call it that is the active underdevelopment should be working in general. But this is where we're kind of moving fast breaking things kind of work.

But this is where we're kind of moving fast breaking things kind of work. And that should again automatically deploy to staging from the developed branch. You wanna make feature branches and these are basically individual features that should last for days to maybe weeks. Um, if you want to, you can do individual staging environments per feature branch or just do one staging environment on

you can do individual staging environments per feature branch or just do one staging environment on staging or develop whatever you want. Um, that's totally up to your team configuration, but eventually you're gonna get to the point where you merge those feature branches back into your development branch. And then merging that developed branch to Maine is how you push from staging to prod. If you need hot fixes,

how you push from staging to prod. If you need hot fixes, those are gonna come off the main branch and so you're gonna do a little hot fix branch right off the main branch. You're gonna hot fix it and you're gonna merge that back into Maine and then into develop either by merging the hot fix branch into both or by merging the hot fix into branch into main and then merging main up to develop.

or by merging the hot fix into branch into main and then merging main up to develop. It is similar to GitHub flow but it's just a little bit simpler. And GitHub flow is simpler than GitFlow. Uh, most teams don't need GI flow or even GitHub flow level of complexity. And so with this you have a really great default that you can start from and you can modify this on a team basis or on a project

that you can start from and you can modify this on a team basis or on a project by project basis if you have specific needs that aren't well addressed by the system. But I can tell you right now, this is a really solid base that covers the vast majority of teams and projects. Alright, so we've got our GI branching set up. What about good get commits? This is something I see very few companies implementing other than if they're requiring you

This is something I see very few companies implementing other than if they're requiring you to attach your GI commits to Jira tickets, which I'm not a big fan of, but I do think that good commits are very helpful for understanding a code base, especially after the fact. So a good get commit uh, contains a single kind of piece of work that's done and we can talk a little bit more about that in a second. But the get could commit messages, uh, contain uh,

a little bit more about that in a second. But the get could commit messages, uh, contain uh, almost an instruction on what this thing does. And if, if you look at the commits that GI generates by default, they're all in the imperative tense. They're not I did this thing, they are do that thing. So you can look at your history of GI commits as basically like a set of instructions and if you open up any individual item in the instruction, then it tells you the what and the how.

and if you open up any individual item in the instruction, then it tells you the what and the how. But the list is just do this, then do this, then do that. That's kind of how we wanna build ours as well. Uh, they should be things maybe like um, add or write column to the dashboard or allow users to log in with GitHub OAuth and there's a little movement of people in our section of the world who just wanna write WIP or work in progress for all their commits.

of the world who just wanna write WIP or work in progress for all their commits. And that's fine as long as no one ever needs to look at back at your code history to figure out why something happened or when it happened. And the thing is, when you're thinking about that future person, it might be you or it might be another developer or it might be someone who wants to buy your tool or is considering it in the future.

or it might be someone who wants to buy your tool or is considering it in the future. So even if you don't need those commits today, imagine what you might need in the future. And I would make the argument that unfortunately even though I have written a WIP commit or two here or there, it's really worth avoiding them and taking time to write good commit messages. So like I was saying, I think the best, the best commit you can do is large enough

So like I was saying, I think the best, the best commit you can do is large enough that it contains a meaningful moderation to the functionality of the code base. So it's not, you know, change two lines of code that don't actually, you know, like those two lines don't do anything unless you do other things. It should actually kind of be a a as of a whole even though the tests don't necessarily have

It should actually kind of be a a as of a whole even though the tests don't necessarily have to pass for every single commit. It doesn't have to be large enough for that. Um, but it should be meaningful, right? But it should be small enough that you wouldn't ever wanna roll just part of that commit back. And that's kind of my internal rule is, is um, even if it's um, you know,

And that's kind of my internal rule is, is um, even if it's um, you know, maybe we're rolling back only a little bit of this feature but we need to roll back this one particular implementation choice, hopefully that whole rollback will be one commit, not just part of a commit. It's not a huge deal like get allows you to do these partial changes. Um, but it's just kind of the guideline I use for figuring out the size of them.

Um, but it's just kind of the guideline I use for figuring out the size of them. I would mention that a lot of older school get users lean towards larger commits where they're doing one full feature per commit. And if you work that way, that's fine. I personally like commits that are distinct pieces of a hole. And then the pull request kind of pulls together that hole for a great read on how to write a get commit message,

And then the pull request kind of pulls together that hole for a great read on how to write a get commit message, check out the article, um, by the name on Chris Beam's website, how to write a get commit message. It's a lot of great stuff that I pulled a little bit of this from and can teach you more about what a good commit message looks like. I mentioned already that GitHub introduced the modern pull request, but the concept of request pull has been

I mentioned already that GitHub introduced the modern pull request, but the concept of request pull has been around since before GI even existed. Basically in either of them you're asking, Hey, can you take a look at this modification I made to the existing code? Now prs are a fantastic way to organize your code into distinct change sets to document the changes and to facilitate code review. All the code your company writes should be looked at at

to document the changes and to facilitate code review. All the code your company writes should be looked at at least twice before going live. And when I talk about it, I call this four i's meaning either two people paraprogramming or one person coding and the other person reviewing. But pull requests don't just facilitate other people reviewing code. They also facilitate you reading your own code again

people reviewing code. They also facilitate you reading your own code again before you actually commit it. So good PR is gonna describe what the code is and what it does often with graphical elements or animations, but it also gives your team and yourself space to review implementation before they go live. Similar to the article I referenced before, there's a really great post titled Building a Pull

Similar to the article I referenced before, there's a really great post titled Building a Pull Request this time on the Tighten blog. And I definitely recommend you check it out for some of the things I think are vital for understanding how to build a good good pull request. But essentially with the pull request, we're introducing a set of changes that can be merged without breaking the application. And like I said before, not every commit can necessarily be

that can be merged without breaking the application. And like I said before, not every commit can necessarily be merged without breaking some things, although that's ideal. But every pull request should be a distinct piece of work that can be described, that can be evaluated and that can be applied without your app breaking. And with most GI branching standards, a pull request also signals the end of a short-lived feature branch, which helps us avoid the painful situation

of a short-lived feature branch, which helps us avoid the painful situation of long lived feature branches that slowly diverge from develop, making the eventual merge more and more painful by the day. So my kind of general rule for pull requests is that you want them to stay open for days, not weeks, and contain dozens or less commits not hundreds and, and those are kind of arbitrary rules that's not always possible.

and those are kind of arbitrary rules that's not always possible. But the bigger and the longer running that pull request is, the harder it's gonna be to get it merged and that is not a good state to be in because it's gonna get harder and harder and less and less likely. And these just things just kind of build on top of each other until you're an absolutely mess and you can't deploy anything.

of each other until you're an absolutely mess and you can't deploy anything. We will talk in a minute about how to set up the deploy tooling you can use to deploy your site once your PRS are merged. But before we do so several pieces of that tooling rely on us choosing your development and engineering standards ahead of time. You're definitely going to want to establish some kind of a coding standard and as many engineering standards

You're definitely going to want to establish some kind of a coding standard and as many engineering standards as you can right off from the bat. So you can avoid a concept called bike shedding, which is wasting time going back and forth about where the braces go or tabs versus spaces or styles of architecture or preferred package for this rather than actually building useful code for actual users.

for this rather than actually building useful code for actual users. At minimum, every dev team should have a defined set of core coding standards for their backend language, their framework, and their core JavaScript framework. If they're using one for Laravel teams, you can stick with Pint Outta the Box. Or at Tighten we actually have a tool called Duster that includes pint and a few other tools and configures them all to work together to form a sort

that includes pint and a few other tools and configures them all to work together to form a sort of kind of mega linter outta the box. It's using titan's coating standards that we have defined over years, but you can also create a duster config file to have your own linting, whether for your team or for your specific repo. Once you've chosen a standard, whether you're using our tooling

Once you've chosen a standard, whether you're using our tooling or not, you're gonna expect your devs to learn that standard. They're gonna use it and they're gonna build it into their both local and remote tool stack. So you shouldn't see your senior developers wasting time linting code and pull requests 'cause the coding standards will all already have been defined and they'll, they'll show what

'cause the coding standards will all already have been defined and they'll, they'll show what that code should look like from a minor perspective, right? It's not gonna be the full implementation details, but it's gonna be at least you know where the braces go and all those things. And your developers should understand it and write it. Their local setups should ensure that it gets written that way. And then your CICD will also catch anything that slips

ensure that it gets written that way. And then your CICD will also catch anything that slips by the devs long before it actually gets to individuals doing code review. And finally, this brings us to the shared third party SaaS services you should set up on every project. So first we wanna make it easy as possible to push to staging and to prod both of those should happen preferably just by a commit

to staging and to prod both of those should happen preferably just by a commit to a specific branch. So we're gonna need to set up a staging server that is close as possible to the prod server and then automate deploys preferably to both based on commits to their respective branches. Remember I said that I think that Maine should pair together with prod, develop, should pair together with staging. So at Tighten we use Laravel tools, forge

with prod, develop, should pair together with staging. So at Tighten we use Laravel tools, forge and Envoy, and now cloud for this. But you can use whatever you like as long as it does not require a manual push to deploy. You wanna avoid that as much as possible. You're probably aware of this concept, it's often called CICD and that is continuous integration. And continuous deploy CI means that certain functions that are not deploy related are run when you push code,

And continuous deploy CI means that certain functions that are not deploy related are run when you push code, usually running your tests, linting your code, maybe building something, and then CD moon means that your code is deployed when pushed to a certain branch or when a certain trigger is run. And both of those automate core DevOps tasks and significantly diminish the cost of the steps between writing code and it going live on the internet.

and significantly diminish the cost of the steps between writing code and it going live on the internet. And you should be doing that as often as possible. Your production site should, if at all possible aim to deploy once a week at minimum. The longer you go between deploys, the bigger the cost and then the bigger the risk is every single time you deploy. There's two other third party services I want you to consider that would really beneficial

There's two other third party services I want you to consider that would really beneficial to have preferably on any staging and production sites. First, you wanna sign up for an exception tracking service and pipe its notifications into a shared channel in a tool like Slack. Make sure everybody sees those issues and it happens on all of your servers. Install this on staging and prod. And second, I would recommend considering a centralized

Install this on staging and prod. And second, I would recommend considering a centralized mailbox mail's one of the hardest things to test on staging. And there's tools like Mail Trap that make it easier for you to preview staging emails in a real looking mail client. You can also then make those emails accessible to non-technical team members and to your clients alliance. There's just one last thing I wanna share about how to help you build productive coding processes and that's the concept of paper cuts.

to help you build productive coding processes and that's the concept of paper cuts. So paper cuts are any minor annoyances that on their own aren't that bad, but when you look at the sum of their accumulated impact over time end up actually having a very large impact on your development and your developer's happiness. So the first paper cut that I see very commonly is slow tests.

So the first paper cut that I see very commonly is slow tests. If your local test suite takes more than a minute to run on someone's local machine, it's just not gonna get run. Ideally, your team can be running their tests after every significant change they make, but even if they have to get stuck running only a smaller subset of their tests on a regular basis, they'll still have to run

to get stuck running only a smaller subset of their tests on a regular basis, they'll still have to run that full suite every time they push code. And if it takes eight minutes, you know you're not just losing eight minutes, you're actually losing 15 or 20 minutes before they get back on the workflow every single time they run their tests, which means they're either going to be extremely distracted or they're not gonna run the tests very often.

to be extremely distracted or they're not gonna run the tests very often. And both of those are big problems. And this is a paper cut not just for local development, but for CICD as well. You do have more time there because usually when somebody's pushing code, they don't have to just sit there in front of the CI waiting for it to pass, but that's not always true. Sometimes you need CI to clear

for it to pass, but that's not always true. Sometimes you need CI to clear before you can make sure a PR is ready or you need CD to finish so you can get that urgent bug that you just fixed actually live. You don't wanna wait an hour in either of those scenarios. Another paper cut is long running pull requests, and we already covered why it's valuable to merge PRS quickly, but I just wanna throw in here that long lived PRS and long running branches are two huge

to merge PRS quickly, but I just wanna throw in here that long lived PRS and long running branches are two huge and extremely common paper cuts that you should save your team from because they're wasting hours cumulatively even over the span of weeks if you have those things running longer than they need to. And finally, out of date dependencies, we'll talk more later about how important it's to prioritize addressing technical debt

we'll talk more later about how important it's to prioritize addressing technical debt and what it looks like to kind of vie for that in your organization. But I just wanna mention here that out of dependencies are a huge paper cut, not just because you have security concerns that come from it, but also you can't use the latest features. You always have to be figuring out which version the docs you're in.

You always have to be figuring out which version the docs you're in. You often have to do extra coding work to bridge between the version you have and what is necessary to work with some other system. And often if you do want a particular thing that's not there, you know it exists, you know it's coming. And so now you have to build these short-lived systems that do the work now, which cost, and then also remember to remove them later, which costs.

that do the work now, which cost, and then also remember to remove them later, which costs. You might be wondering how we've gotten to the end of this video, and I haven't talked about AI at all, but I'm just gonna say it's not worth recording a long section here about AI because by the time this video's released, it'll all be different. AI is great for road work, it's great for junior developer stuff.

AI is great for road work, it's great for junior developer stuff. If you're happy to sit down and give something explicit directions and then review its work, it's a great tool. Just like a junior developer can be a useful thing. So I actually like using AI for building templates and doing other stuff where I know exactly how to do it. I just don't feel like typing right. Sometimes it can just save me a little bit of time

I just don't feel like typing right. Sometimes it can just save me a little bit of time and doing rote work and that's fine. But AI is no replacement for real creative development thought. And it's really important for me to say that especially to you as folks who are talking about leading development teams. You can't replace a developer with ai now you may be able to get the benefit a junior developer would've added.

You can't replace a developer with ai now you may be able to get the benefit a junior developer would've added. You might be able to speed up other developers by wasting less of their time using ai, but it does not replace the need for an actual development developer in the first place. And I just wanna note AI brings with it a real concern for the environment that we as an industry have just kind of casually shrugged off and we're not gonna be able to do that forever.

of casually shrugged off and we're not gonna be able to do that forever. So like every tool, it can be useful, but it brings with it costs both to our development workflow and in this case to our world, and we just have to figure out when is the right time to use it or not. Obviously, there are concerns that we may not have talked about that are specific to your tech stack, to your team's abilities,

that we may not have talked about that are specific to your tech stack, to your team's abilities, to the specifics of your niche of the industry. But hopefully this gets you some baseline standards for how to get your coders ready to write great code.