Are you still waiting for a Jira ticket to be prioritized and taken into a sprint? How about you git gud and open a pull request yourself? It will be a bumpy road, but it’ll be worth it in the end.  

The Status Quo 

How do we approach inter-team projects today? At Infobip, teams own their services. They implement tasks, sure, but they also deploy the code, debug it, upgrade dependencies, etc. On the other hand, there are stakeholders opening Jira tickets. And then there are product owners in between, prioritizing those tasks. This is, for better or for worse, not a story about POs.  

This is about you, a fellow developer with a particular need. Anyway, you are a developer and need a certain feature implemented in another team’s service. You explain your need, maybe even propose a solution. And then you wait.  

The waiting game is a long one, indeed. You may need to talk to PO (look at them popping up again) and advocate for the importance of your feature. They are likely to school you for proposing a technical solution in your Jira ticket. Less likely is that they will turn the backlog upside down to prioritize your ticket.   

That’s the core of the conflict: though the proposed feature is a top priority for you, it is not for the product in general. With the Jira ticket approach, the product team must put in the work to implement the feature.  

Considering all that, your feature is more likely to land in production if you open a pull request. Bite the bullet, and do the work. Don’t wait for the team to abandon their priorities in favor of your own.  

You take a leap… You hit a wall. 

OK, so you decide to go for it. You open a PR. It might be a small one at first. You resolved some compatibility that was interfering with your own work. You fixed a bug forcing you to do some error-handling gymnastics on your side of an interface. This feels good! You may mention it on your next daily standup, and your team cheers you on (true story).  

Encouraged by this newfound power to scratch your own itch, you go further: you open bigger PRs, and you contribute to more services. When breaking down your own tasks, you think about where the implementation fits best, not constrained to your own services.  

This is also where you hit a couple of walls. You encounter projects with no tests or coded in unfamiliar languages. You waste time trying to build projects and hunting for versions of build tools deprecated half a decade ago. You fall into unfathomable depths of eldritch horror that some, apparently, accept as production-worthy code.  

One day, after pouring all that time (sweat and tears) into a pull request, it gets rejected. And you lose it, flip the table, and all that. Who in their right mind would reject all this free work you are offering them? Why doesn’t the team appreciate that you spent time implementing a feature on their service, so they don’t have to?  

The many hurdles to jump 

Take a breath. It’s fine. Yes, this approach has its drawbacks. Let’s see if we can make it easier. The first thing you need to realize is that your pull request is not “free” for the product team.  

The reviewer needs to put in the effort to review the PR. Reviewing a PR from someone unfamiliar with the team’s coding standards and practices will take more time. This is one thing we can all improve on: Teams can document and codify their standards. Amend the README with their working agreement, codify stuff like linting and automate it with githooks.   

On the other hand, as a contributor, it’s up to you to conform to the project you are contributing to. Refrain from barging in with your favorite code formatting. Try to blend your code in instead.  

OK, so you accept the awful line breaks and adopt tabs instead of spaces. Can your PR be merged now? Well, no. There’s the bigger picture, the project’s architecture, to consider. You aren’t as familiar with the codebase as its owners. They may want this feature implemented in another place. Or they may prefer you to use a different approach. And this, too, can be preempted. The team could have an ARCHITECTURE file with their project detailing this in advance. And you could have checked it going in.  

Keep in mind: It’s not free work 

So you conform to the project architecture. Can you merge the PR now? Perhaps. Because you see, PR is not, in fact, “free work,” even if you adhere to all the standards.

What happens with the code after it’s merged? Think back to modus operandi; it’s the team who owns the service. They maintain it: they need to ensure that all dependencies are up to date. That includes the cutting-edge library you just added. They troubleshoot and debug it: they get called in the middle of the night if something breaks.

That includes that hard-to-read but super-fast code you came up with. And they will now start receiving future Jira tickets for expanding this feature you just implemented. Doesn’t sound like such a good deal anymore, right?  

In the end, it comes down to the transfer of ownership. A pull request is the point at which you, as the author of the code, need to convince the team that they indeed want your new feature so badly they are willing to wake up in the middle of the night and fix issues with it. And that’s why you need to be prepared to take no as an answer.  

Hidden benefits  

At this point, you may be getting a bit disenchanted with this whole idea. You take a break and go back to your own code base. The one you own, maintain, and troubleshoot. Written in a familiar language, with the tooling you have set up just the way you like it. Same old tasks, same old language, same old frameworks. And you start to miss the excitement of working on new projects.  

You did get to work with different languages. And you did learn new frameworks (like that bean mapping lib you brought back to your own project.) There were some good PRs too. There were ones where the team was enthusiastic about the proposed changes, sure. But also the ones where the reviewer approached the code critically, and you engaged in a dialog over comments on the PR only to discover new solutions to familiar problems.  

There’s also pride in your work. It’s OK to admit it: you do good work. Your PRs increased overall test coverage, and you simplified a few build processes along the way. You improved the overall health of the codebase in addition to just cramming in new features. And you shared your knowledge with teams working on those products.  

Something to it after all  

So it’s not all cream and peaches when it comes to opening PRs instead of Jira tickets. There are clear benefits and some more subtle ones. There are also roadblocks.  

You’ll probably go back to opening PRs, but perhaps be more self-conscious this time. Have more sensibility for the team taking over ownership of your code. Have more respect for the standards and practices observed on the projects you’re contributing to. And in the end, more success in tour cross-team pull requests.  

And you’ll encourage other teams to prepare for and open PRs to others. To document their own practices and share them with other teams. The Jira waiting game might be what got you to submit the PR in the first place, but it’s a mix of learning and teaching that keeps you getting back to it.