{"id":44,"date":"2022-11-09T08:34:20","date_gmt":"2022-11-09T08:34:20","guid":{"rendered":"https:\/\/productive.io\/engineering\/blog\/"},"modified":"2023-03-07T22:31:21","modified_gmt":"2023-03-07T22:31:21","slug":"pull-requests-the-good-the-bad-and-really-not-that-ugly","status":"publish","type":"post","link":"https:\/\/productive.io\/engineering\/pull-requests-the-good-the-bad-and-really-not-that-ugly\/","title":{"rendered":"Pull Requests\u2014The Good, the Bad and Really, Not That Ugly"},"content":{"rendered":"\n\n\t\t\n\t\t\t
\n\t\t\t\n\t
\n\t\t\n\n\n\t\t\n\t\t\t
\n\t\t\t
\n\t\n\n
\n\t\n\n\n\t\t\n\t\t\t
\n\t\t\t\n
\n\t\n\tEngineering<\/a><\/p>\n\t\t\t – <\/span>\n\t\t\n\t{{minutes}} min read<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
\n\t\t\t\n
\n\t\n\tPull Requests\u2014The Good, the Bad and Really, Not That Ugly<\/h1><\/div>\n\t\t<\/div>\n\t<\/div>\n\n<\/div>\n\n<\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
\n\t\t\t
\n\t\n\n
\n\t\n\n\n\t\t\n\t\t\t
\n\t\t\t\n
\n\t\n\t\t
\n\t\t\t\t\t<\/div>\n\t<\/a>\n\n\t
\n\t\t\n\t\t\n\tIvan Lu\u010din<\/p><\/a> \n\tVP of Engineering @ Productive. Frontend engineer under the hood. Outside of working hours\u2014a happy husband, dad of two girls and a wannabe musician.<\/div>\n\tNovember 9, 2022<\/p>\t<\/div>\n<\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
\n\t\t\t\n
\n\t\n\t\t\t
\n\t\t\t\n\t\t\t<\/svg>\t\t<\/i>\n\t\t\t<\/div>\n\t<\/a>\n\t\t\t
\n\t\t\t\n\t\t\t<\/svg>\t\t<\/i>\n\t\t\t<\/div>\n\t<\/a>\n\t\t\t
\n\t\t\t\n\t\t\t<\/svg>\t\t<\/i>\n\t\t\t<\/div>\n\t<\/a><\/div>\n\t\t<\/div>\n\t<\/div>\n\n<\/div>\n\n\n\n
\n\t\n\n\n\t\t\n\t\t\t
\n\t\t\t\n\n\t\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\n\t\t\n\t<\/picture>\n\t<\/div>\t\t<\/div>\n\t<\/div>\n\n<\/div>\n\n<\/div>\n\t\t<\/div>\n\t<\/div>\n\n\t<\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
\n\t\t\t
\n\t\n\n
\n\t<\/div>\n\n\n\n
\n\t<\/div>\n\n<\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
\n\t\t\t
\n\t\n\n
\n\t<\/div>\n\n\n\n
\n\t\n\n\n\t\t\n\t\t\t
\n\t\t\t\n\n\t\n\tRecently, I stumbled upon an article on\u00a0arkency<\/a>\u2014Disadvantages of pull requests<\/a>.<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
\n\t\t\t\n\n\t\n\tI soon realized this was interesting stuff, worth sharing with my colleagues. Immediately I started writing a follow-up article, debating every claim made in the text.

We practice PR review workflow in\u00a0Productive’s<\/a>\u00a0engineering team daily. This workflow helps us with:<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
\n\t\t\t
\n\t\n\t
  • Ensuring code quality and stability<\/li>
  • Domain knowledge sharing in the team<\/li>
  • Organized mentoring activities<\/li><\/ul><\/div>\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tProductive’s Engineering team builds one SaaS product and works on two\u00a0massive codebases<\/strong>\u2014the backend (API) and the frontend (web app).<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\n\t\t\n\t<\/picture>\n\t<\/div>\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tEvery process comes with overhead, and so does this one, but I\u2019ll argue it\u2019s worth it.

    In this blog post, I\u2019ll quote key points from the mentioned article and give my thoughts on the matter.

    Now, let\u2019s discuss the disadvantages of pull requests! <\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n
    \n\t\n\t1. More Long-Living Branches, More Merge Conflicts<\/strong><\/h2><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tPRs promote developing code in branches, which increases the time and the amount of code staying in a divergent state, which increases chances of merge conflicts. And merge conflicts can be terrible, especially if the branch waited for a long time.<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tYes, this is true. But it shouldn\u2019t be that big of an issue if you practice a good distribution of work in your team.

    Most products consist of many modules which are usually different screens or sections in the app. You should always divide work across those modules, in a way that one PR doesn\u2019t interact with the other.

    If your codebase is not that modularized, you can ensure a few good practices to avoid this issue:<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t
    \n\t\n\t
  • Always split a big chunk of work into smaller, but functional PRs.<\/li>
  • Rebase the branch daily and update it with new changes from the master\/develop (I usually do this before every code review).<\/li>
  • Always separate preparatory refactorings and merge them before implementing the actual feature changes. This is great advice given in the original article!<\/li><\/ul><\/div>\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tThe most common mistake developers do is putting too much work into one PR, making both the review and merge process harder than it should be.<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n
    \n\t\n\t2. The Reviewability of a Change Decreases With Size<\/strong><\/h2><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tPRs tend to promote reviewing bigger chunks of code.<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tMore often than not, developers fall into this trap. They think something like \u201cI\u2019ll just refactor this while I\u2019m already here\u201d or \u201cI need to complete the whole thing before sending it for review\u201d. This leads to oversized PRs and a slow development process.

    3 PRs with 100 lines are reviewed and merged faster than 1 PR of 300 lines.<\/strong>

    Of course, not all changes are the same. If we have 100 lines of boilerplate code, which is usually framework scaffolding, there\u2019s no complexity there. Tests take a lot of lines but should be easy to read. Code with fewer dependencies will always be easier to grasp too.

    Basically, the more a developer is experienced and familiar with the codebase, the more lines he\/she is allowed to put in one PR. Less experienced developers on the project should strive to make their PRs as thin as possible.<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n
    \n\t\n\t3. Short Feedback Loop Makes Programming Fun<\/strong><\/h2><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tYou code something up but it\u2019s nowhere close to being integrated and working. You now have to wait for the reviewer, go through his remarks, discuss them, change the code\u2026<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tI couldn\u2019t agree more. There\u2019s nothing more exciting in programming than getting a great idea, implementing it fast, and testing it out instantly.

    The original author\u2019s claim is that PR reviews kill that short feedback loop which makes programming less fun. But if that\u2019s true, then it also means that:<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t
    \n\t\n\t
  • Your team is producing large and overcomplicated pull requests.<\/li>
  • You don\u2019t have a good deployment and review environment setup.<\/li>
  • You\u2019re not coding features in safe-enough isolation.<\/li><\/ul><\/div>\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tAgain, it all revolves around making small and easily reviewable PRs, but we\u2019ve already acknowledged that, so let\u2019s move on.

    If you do have a large PR waiting review, that doesn\u2019t mean you can\u2019t try it out in the wild. You could easily deploy the code to a staging environment, or even production, but on a separate domain so only you and your team can try out the new changes.

    At Productive, for our main frontend app, we have an automated PR deployment setup. When you create a new PR on Github or push commits to an existing PR, a Github action is triggered that deploys the code to the \u201creview\u201d environment.

    It takes the name of the git branch and deploys the frontend app to the subdomain with the same name. For example\u00a0    https:\/\/cool-new-stuff.review.productive.io<\/a>.

    Voil\u00e0, now you can try your PR changes in the live environment two minutes after you\u2019ve created the PR.

    Plus, there\u2019s another Github action that posts a comment with a test link, so you don\u2019t need to type it into the browser\u2019s URL bar manually:<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\n\t\t\n\t<\/picture>\n\t<\/div>\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tThis is a frontend app example hosted as a static asset on a CDN, but you could do it similarly with backend apps.

    There\u2019s another mechanism for achieving a short feedback loop which is safe if done properly. With\u00a0    feature flags<\/a>, you can ensure that your PR is not introducing any breaking changes and that new code is implemented in isolation from existing features.

    Feature flags allow you to try the new changes in an isolated scope, without changing anything in the rest of the system. The scope can be either one user, one account, or just one API request. It\u2019s a powerful mechanism that our team uses on a daily basis. It allows us to push new changes to the live environment rapidly, without worrying about breaking things.<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n
    \n\t\n\t4. Reviews Tend To Be Superficial<\/strong>
    <\/h2><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tProper review takes the same amount of focus as actual coding. Why not pair-program instead?<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tI agree that PR reviews tend to be superficial, especially when there\u2019s too much to review. That only means that the reviewer is doing their job poorly. You can recognize this situation when you see a complex PR that only has code-style comments like \u201cFix naming\u201d or \u201cWrong indentation\u201d, etc.

    If the PR seems like it\u2019s too complicated\u2014why not pair-review instead?<\/strong>

    Pair programming (not to be confused with pair-reviewing) is useful for mentoring junior developers, but it\u2019s a waste of time in a lot of other cases. That\u2019s because you\u2019re not solving complex problems all the time.

    A better way to do it is to pair-review the PR with the author after most of the boilerplate is done and proper research has been made. Then you only talk about the complex stuff and you can leave the author of the PR to explain their thought process in detail.

    There\u2019s one more thing here… Programmers usually get this “feeling” when something stinks about their solution. They should be honest and leave comments in the PR, in every place where they feel they could be doing something wrong. That greatly increases the reviewability of the PR.<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n
    \n\t\n\t5. Merging Is Blocked by Remarks That Shouldn\u2019t Be Blocking<\/strong><\/h2><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tRemarks made by the reviewer can fall anywhere on the spectrum of whether they should block merging or not: from a mistake that\u2019ll bring production down to cosmetic suggestions or opinions.<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tThese situations happen quite often with inexperienced reviewers. When commenting on the PR, you should tell the author if the comment is a merge-blocker or not, and never insist on details too much.

    When I\u2019m working with inexperienced developers, I\u2019ll usually tell them exactly how to fix something, with an explanation. For non-blocking mistakes, I\u2019ll just comment to watch out for that in the next PR. Usually, I\u2019m the one to merge the PR, so they don\u2019t have to wonder whether the PR is finished or not.

    When reviewing experienced dev\u2019s PR, I\u2019ll tell them what I think about the problematic places in the code, but I\u2019ll mostly approve the changes and leave them to the author to do the fixes the way they want to.

    Not everything the reviewer says is always correct or the right thing to do. The author should be the one to decide on the comments\u2014because it\u2019s their work.<\/strong><\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n
    \n\t\n\t6. It\u2019s Easier To Fix Than To Explain the Fix<\/h2><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tThe original author has to understand it first, agree with it, and then is expected to implement it. Often it\u2019s better to let the original author merge his thing, and let the reviewer implement his remark post-factum?<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tA lot of times it\u2019s hard to explain the fix to the author and it would be more\u00a0efficient\u00a0just to implement the fix yourself. But merging the unfinished PR could be dangerous, so I\u2019d never suggest that. You\u2019d also be missing the opportunity to educate the original author about the problem.

    Pull requests don\u2019t have to be done by only one person. Why wouldn\u2019t you, the reviewer, just pull the branch, implement, and push the fixes back upstream? That way the author gets notified about what you did and you both have an opportunity to discuss the issue.

    That\u2019s also an effective thing to do when there are a few simple fixes required on the PR. Let\u2019s say you notice a typo somewhere in the PR. It\u2019s much faster to fix it yourself than to leave a comment and wait for the author to do the fix. You could do that directly in Github and it would take like 30 seconds.<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n
    \n\t\n\t7. Developers Are Slower To Adapt the Responsibility Mindset<\/strong><\/h2><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tThe second one knows that every line they write can screw up things for other developers or even bring production down. They watch their step, they know they are the only one responsible for this change. It shortens the delay between making a mistake and seeing the effect of it.<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tThis is an interesting and important claim. Can your business afford to tear the live server down just to teach the developers some responsibility? Sometimes it\u2019s worth it, but in most cases, you wouldn\u2019t want to do that.

    Code stability is not the only reason why we should be reviewing our PRs. There are also benefits of mentoring, knowledge sharing, better release organization, feature completeness, structured discussion around a diff, etc.

    At Productive, we encourage people to self-merge PRs without a review when they\u2019re confident that the changes are fine. The developer should have the freedom to do that in the part of the codebase where they have more ownership. I believe this is how the responsibility mindset can be trained. When people build something from the ground up, they will feel the responsibility to keep everything in great shape.<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n
    \n\t\n\t8. PRs Discourage Continuous Refactoring<\/strong><\/h2><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tIt\u2019s good to follow boy scouts\u2019 rule: always leave the place better than it was before. With PRs, though, this rule is harder to apply.<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tPRs will slow you down on refactoring. When you realize that some refactoring is needed, you need to switch to another branch to implement the refactoring separately, submit the PR to review, wait for the approval and merge the changes back into the original branch.

    But it\u2019s still better to do it that way, in my opinion. Refactoring PRs shouldn\u2019t be complicated to review since there shouldn\u2019t be any changes in the logic, only the code structure. That\u2019s especially true if you have good test coverage. If you don\u2019t, then maybe you should write the tests first?

    Maybe the refactoring PR doesn\u2019t need to go through the review process if everything is trivial. If it does, then mention to the reviewer that this is a refactoring-only PR that’s blocking feature development and the reviewer should prioritize the approval.

    Having good team communication around PRs will minimize most of the downsides of the PR review process.<\/strong><\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n
    \n\t\n\t9. Negative Emotions<\/strong><\/strong><\/h2><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tMandatory PR reviews can induce way more negative emotions than needed. We all have limited emotional budgets \u2014 it\u2019s better not to waste it on avoidable stuff.<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tWhen it comes to pull request reviewing, the responsibility is both the author’s and reviewer’s. There\u2019s one simple rule to follow:

    Don\u2019t be a prick when reviewing or authoring the PR.<\/strong>

    The original article is basically saying that we should let developers do what they want because they might get offended by the review comments.

    Obviously, that’s ridiculous. This doesn\u2019t have anything to do with PR reviewing itself\u2014it\u2019s a communication problem. If your engineering team doesn\u2019t know how to communicate, then you\u2019ll have bigger issues than developers offended by a PR review.<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n
    \n\t\n\t10. How Do You Switch to Branches With Migrations<\/strong><\/strong><\/h2><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tYou obviously sometimes need migrations while working on a branch. What do you do if you then have to switch back to another branch locally? Cumbersome.<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tWell, just do the migration separately on the main branch, before implementing the remaining logic in the PR. The world won\u2019t collapse if you don\u2019t always work on branches with PR reviews. You can always omit the process if you have a good reason for it.<\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n
    \n\t\n\tConclusion<\/strong><\/h2><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\n\t\n\tThe original article contains a\u00a0list of suggestions<\/a>\u00a0on how to improve your team\u2019s PR workflow. Those are all great ideas, which I encourage you to try. Thanks to\u00a0arkency<\/a>\u00a0for writing a great and educational article! We\u2019ve also published a copy of this article on Medium.

    As with other organizational processes, we shouldn\u2019t take them too seriously because they tend to generate overhead and slow work down. We should be pragmatic about PR reviews and when we notice they’re becoming a burden\u2014we can skip them sometimes.

    Don\u2019t follow the rules blindly, try thinking with your head and do the right thing depending on the situation you\u2019re in.

    And a little remark for the end\u2014let\u2019s all be humble and respectful towards each other while reviewing each other’s code!<\/strong>
    <\/p><\/div>\n\t\t<\/div>\n\t<\/div>\n\n<\/div>\n\n<\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n
    \n\t
    \n\t\t
    \n\t\t\t\t\t<\/div>\n\n\t\t
    \n\t\t\t\n\tIvan Lu\u010din<\/p>\n\tVP of Engineering @ Productive. Frontend engineer under the hood. Outside of working hours\u2014a happy husband, dad of two girls and a wannabe musician.<\/div>\n\t\tMore From This Author
    \n\t\t\t\n\t\t\t<\/svg>\t\t<\/i>\n\t<\/div>\t\t\t<\/a>\t\t<\/div>\n\t<\/div>\n<\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n
    \n\t\n\tRelated articles<\/h2><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n\t\n\t
    \n\t\n\n\n\t\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\n\t\t\n\t<\/picture>\n\tEngineering<\/p>\n\tIntegrations Series: Authentication And Connection<\/h2>\n<\/a>\n\n\n\t\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\n\t\t\n\t<\/picture>\n\tWorkflow<\/p>\n\tHow to Keep Your Project From Stagnating<\/h2>\n<\/a>\t<\/div>\n\n\t
    \n\t\t
    \n\t<\/circle><\/circle><\/g><\/svg><\/div>\t<\/div>\n\n\t<\/div>\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t\n
    \n\t\n\tRelated jobs<\/h2><\/div>\n\t\t<\/div>\n\t<\/div>\n\n\n\n\n\t\t\n\t\t\t
    \n\t\t\t
    \n\t\t\t
    \n\t\t\t\n\t
    \n\t\t

    \n\tOpen Job Application<\/p>

    \n\t<\/p>\t<\/div>\n\n\t

    \n\t\t