Pull Requests are those things that people who write code (developers) use to move their code around. That's pretty much it in a nutshell.
We have a more detailed overview of PRs in our Ultimate Guide to Pull Requests - so head on over if you don't quite know what a Pull Request is yet. In this post, we'll dive into the "why" type questions - like... why you should even care about PRs in the first place!
Back to Profit Engineering! What's the point of PRs today? Getting code into production as fast and as safely as possible.
This will be the main way individual developers and engineering teams deliver product to customers, day in and day out. Each feature is built in a separate code branch and gets merged in through a PR to the main branch, triggering a deployment.
We'll cover workflows and CI/CD pipelines in a different article but the expectation here is that code changes to the main branch automatically cause a production deployment. If not... we'll get there.
That doesn't necessarily mean a production "release" either (end users seeing the changes). For that we'll cover feature flags... in another separate article.
There's a chance as a solo developer working on something in isolation that PRs can be skipped - but even then there's benefits to still utilizing them that we'll cover below.
Most of the time writing code happens in a team. Gone are the days of upload files & hoping not to overwrite the work of others - that wasn't cool, FTP.
Since we all pretty much use git (or some variation of it like SVN) Pull Requests are the go-to method of merging work together. Sure we could email patches and other wonky things - but we're in this to make our businesses profit - not re-inventing working models.
If you're a junior developer then you'll have learned plenty from Googling solutions and watching tutorials - but there is so, so much more to learn hands on.
PRs are the perfect opportunity to learn from more senior folks who've seen all the ways "not" to do something that you haven't gotten to yet. You won't be making your company very profitable by repeating the same mistakes every other junior dev has made over the years - but you can by learning from others and applying their wisdom.
Without PRs you'd have to screenshot code, slack your questions, and hope for the best. If someone else has the same questions or needs to know the context, you'll end up repeating yourself or making 1-time group chats wasting everyone's time.
Instead, PRs allow for an async "when they get to it" type of learning model where comments & suggestions (and sometimes instructions) can be in-lined and viewable as an educational archivable resource for the betterment of every other dev on the team.
Even when closed PRs serve as an excellent source of contextual learning to understand why a suggestion was made or how a piece of code was written, in a way that respects the time and focus of your peers.
This might be the single biggest reason modern Pull Requests can make companies profitable - the robots.
These come in many flavors, but the most common are called "checks" - little conditions that your code changes must pass to allow the code to merge.
Checks can range from spelling checkers, linting tools for style, unit/e2e tests for functionality, actual checklist confirmation in PR descriptions, and so much more. This is where the real power comes from that'll give you a leg up from being a "normal" developer.
By intelligently using automation to do the grunt work of ensuring the code in your Pull Requests do what it's supposed to do, you're freeing up human time to move on to the next code to write. This will have an exponential effect on productivity and how much stuff you can churn out day after day.
We'll cover more details about checks, which to use, how to use them, etc. further below.
Pull Requests make great conduits for deploying code to places - namely production (where your users see the code changes).
PR checks passingOnce your "checks" pass (noted above) and a human approves the PR (more on that below), closing the PR by merging in your changes can trigger deployments to put the updated code into the right places. Common scenarios are Vercel / Netlify ephemeral environment builds, production updates, Docker image deployments, etc.
Deployments should still happen when code in a branch changes, but PRs are an excellent way to control, coordinate, and validate getting code "into" a branch (like main) to trigger those deployments instead of blindly trusting them. I'll cover this in the separate "workflows" article.
Be that as it may, there are still some scenarios here PRs can be skipped which we'll get to next.
In case it wasn't clear by now pull requests are for getting code changes from one branch into another. That means PRs are mostly for software projects, websites, apps, systems, and other things that rely on code to operate.
If you don't write code or work with people who do... I'm not sure why you're ready this?
It'll be difficult to justify skipping PRs on any team with more than one person authoring software changes.
The inefficiency of coordinating code between any two people let alone a dozen is enormous without PRs, thus difficult to make sense of. Maximizing profit by ensuring our time spent yields valuable money-exchangeable end user solutions means we need to get our features implemented ASAP.
If you're the only one working in a particular git repository, then it "might" be justifiable to push changes directly to production without going through a Pull Request... but that's a pretty rare case.
The safety & security of automation & checks tends to reduce a large amount of risk, which usually negates any speed boost gained by skipping them.
Even if the code you're writing isn't done - file a Pull Request.
Pretty much every branch you make, file a PR right at the beginning to serve as a "checklist" and bookmark for other's to see your progress, and to have automation start checking & crunching away at your contributions.
Depending on what tooling you're using to keep an eye on changes to the code in your PRs (like What the Portal) you'll start to notice check failures & automation anomalies even while you're still building the feature.
Stay fast and reactive to what the robots are saying about your code while you're still in the middle of writing it. I assure you this yields maximum efficiency in time (aka money) as an engineer - and genuinely makes you stand out compared to folks who sit around idle waiting at the end to see what went wrong with their stuff.
Get the automated feedback and fast and as frequently as possible; keep writing code and keep an eye on things, so you can apply the tweaks & fixes as they come in.
That feedback loop of humans writing code -> robots checking it is what makes Pull Requests useful even for solo developers; without 'em you're flying blind.
Now on to making them!
