I’m happy to be able to contribute to other blogs and publications, and this article on Simple Programmer was no exception. In many cases, we come in to work with existing development teams or coach other developers on navigating this process. Looking for some help augmenting your dev team? Don’t hesitate to reach out. Now, let’s get to the post:
At some point as a freelance developer, you will likely be asked to apply your expertise to a team comprised of full-time employees.
Joining a team like this as a contractor or freelancer can be a great opportunity. You can find new peers in your industry and get a chance to apply your knowledge to a new and challenging problem. If you are a senior developer, this can be a great chance to mentor a junior team.
However it can also be frustrating. You might struggle to fit in if everyone on the team already knows each other; not truly being a part of the company can create some tension. Navigating these technical and interpersonal minefields successfully can turn a potential disaster into a very rewarding experience.
Take note that any experience you earn will largely depend on why your client decided to hire you in the first place. It’s important to know why you were brought on and how you fit into the project.
Why Do Companies with Full-Time Employees Bring on Freelancers?
There are a few reasons companies with an existing full-time staff hire freelancers. They essentially boil down to their current staffing arrangement not being a perfect fit for their existing needs.
Need Experience in a New Stack
For example, if the full-time staff has years of experience in Java, but a new project at the company is being built in PHP, companies will often hire an experienced PHP developer to help the staff get familiar with the new stack.
A freelancer can be a good intermediate step in this process, helping to get the existing team up to speed on the new technology more quickly. With a knowledgeable freelancer at their back, the company won’t be forced to hire all new developers or even commit to hiring any full-time employees until it’s decided that PHP will be a firm direction going forward.
A Project Is Behind
If a project is behind deadline or moving in that direction, companies will sometimes hire freelancers to augment the existing team, thinking that having more developers on the project will make the end result ship faster.
As detailed in The Mythical Man-Month, this scenario rarely works out that simply; nonetheless, you may be in a position where time is the most important requirement. If the project is already behind when you join the team, that’s a very important fact to know when you begin since it can affect some of the engineering decisions you make and even some of the office political pressure you’ll be under.
Trying to Expand the Existing Team
Hiring is hard. Especially with the explosion of people learning to be developers, it can be difficult to distinguish superior developers from mediocre ones.
One of the ways companies deal with this problem is to hire freelancers on a “contract-to-hire” basis. Contract-to-hire arrangements define a period of time where a contractor (or freelancer) will work for a company. When that period ends, the employer can decide if they want to hire the contractor on as a full-time employee.
With a contract in place, the employer’s risk is reduced because, by the time they decide to hire the contractor full-time or not, they already know how well they work. Many freelancers prefer this as well since they don’t have to decide to take a job not knowing whether they’ll fit in at the company’s environment or not.
Whatever you decide to do as a freelancer, make sure you know what you’re getting into. When you start as a temp or a contract-to-hire, being aware of your situation and the employer’s needs can be an important step in making the project run smoothly. Each of these arrangements implies a different political landscape for you to navigate as a freelancer.
Dealing With Politics
Many freelancers strike out on their own to avoid the corporate politics that plague many full-time employees. Choosing to work for a company as someone who isn’t as tightly integrated into the team as the full-time members means that it can be difficult to get your ideas accepted or your contributions welcomed if the team feels threatened by your presence.
In addition, it can be difficult to find out where you fit into the team if you were hired by someone higher up in the company. Depending on the team’s size, you may get passed around between different projects with no real direction unless there is someone you can specifically report to.
In any environment—but especially as a freelancer who’s new to the team—soft skills are critical. Things like figuring out how you can best help the direction of the team, who you ask for help, and how you fit into the overall team structure are crucial to ensuring a successful project. Working as part of an existing team means determining your role among them and how you can best help move the project forward.
Are You “The Expert”?
Thinking back to our scenarios above, have you been brought in to lead a team of developers transitioning to a new technology, or are you joining a team where you’re more of a hired gun?
As developers, we all have opinions about how architectural decisions should be made or how projects should be run. If you’re leading the team, you probably have more ability to voice those opinions and have the project move in that direction. However, if you’re just working as another set of hands on an existing team with leadership in place, you might find your suggestions don’t carry much weight, especially when you’re first joining the project.
Either way, it’s important to not make snap judgements about the state of the project that you’ve been brought into. If you’ve been writing code for any stretch of time, you know that real-world constraints often force developers to write code they’re less than proud of.
Jumping into a project and immediately criticizing all the work that’s been done is a surefire way to instantly become the least popular member of the team, and you’ll have a hard time changing that negative first impression.
Who Can You Go to for Help?
As you get introduced to all the new pieces of this project (workflow, code, people, and schedule), it’s important to have someone on the team that you feel comfortable going to for help or to ask any questions about your new working environment. Sometimes, this is the person you directly report to, but often a peer or someone else more familiar with the project can be a better resource.
Whoever this person is, it’s important to either find them yourself or ask the person who hired you to identify the best resource for you. Struggling with getting added to a project and wasting time when someone already familiar with the project could have answered your question isn’t a good way to start off your contract.
Day One on Your New Team
As with starting any new job, there will be plenty of housekeeping tasks to keep you busy on your first day.
Paperwork is a certainty, but you’ll also deal with getting your computer set up with their version control system, VPN, ticketing system, and build tools; you may even get a company email address! This all happens before you write a single line of code.
It can be overwhelming, but hopefully the company will have documentation in place to help you get acquainted with their existing procedures. If now, find a point of contact on the team who can help you with any concerns you have while getting set up.
Once you’re up and running on all the company’s systems, it can be helpful to start looking through the ticketing system. By looking at which types of tickets are coming in more frequently, you can get a sense of the current priorities of the project.
Perhaps more notably, tickets that have been sitting in the queue for a long time—especially ones with lots of back-and-forth discussion—may be areas of the project that are complex or particularly contentious.
Once you’ve surveyed the project and all the open tickets, you might find there’s a ticket with a limited scope that you can use to experiment with the codebase.
Working on a simple ticket and actually digging into the code will give you a sense for how the project is structured and any local tooling that you forgot to set up. In addition, the questions that this initial investigation creates will help you get up to speed quicker on the codebase and workflow in general.
If you manage to solve an existing small ticket, that’s great! Check with any documentation you received at the beginning of the project to make sure you’ve followed all requisite development practices. Try to bring in someone else on the team and make sure there aren’t any code standards or anything else that you should have been following for this first contribution. If there is a formal code review process, your code is probably ready for that at this point.
Going through this process may take you longer than just your first day, but once you’ve gotten even a simple contribution all the way through the process, you’re well on your way to getting familiar with the codebase and the project as a whole.
Getting up to Speed on the Codebase
If you’ve looked through the ticketing system and even made a contribution, you should have a clearer idea as to how at least part of the codebase is structured. Now is the time when you should start figuring out how to make larger contributions. One of the best ways to do this is to work with your new teammates.
Asking questions like “What is the most important thing being worked on right now?” or “Where is a lot of effort being spent without much result?” can give you areas to investigate. These questions are also important to ask your direct supervisor if it’s appropriate. If you’re reporting to a project manager or tech lead, they might have visibility into other areas of the project that your peers don’t.
In addition to asking these questions, pair-programming with a teammate as they work through one of their existing tickets can be a good way to find things to watch out for in the current codebase. This can also illuminate workarounds that existing team members have developed to help them work faster.
If you’re not in a position to eliminate these workarounds with more proper solutions (see “Are You ‘The Expert’?” above), you can at least use them for now to make yourself more efficient until the root cause can be addressed. As you’re pairing, ask them to take you through the entire process of how the application is loaded, including pulling in dependencies and anything else required to render the application, if you have time.
Asking intelligent questions and getting thorough answers is one of the quickest ways to get immersed in the codebase and start making a meaningful impact. Be sure to have a point of contact who is familiar with the code and the workflow who can help you.
Moving Forward
Working as a freelancer with an in-house development team isn’t always easy, but it can be rewarding. Many freelancers turn these projects into full-time jobs, and even if it doesn’t end up that way, you can take pride in helping a team ship a product with the flexibility of still being open to other opportunities.
However, operating as an outsider alongside a larger team is not without its challenges. If you can bring the soft skills of getting involved with the team and helping them accelerate the project as well as the technical skills to get immersed in the codebase quickly, you can have a large impact on the team as a whole. This means a successful project for you, the company that hired you, and your newfound peers.
It can be a challenge, but getting exposed to a different way of working can make you a better developer and a more well-rounded contributor in the future. Make sure to stay in touch with your former client in case you can help out in the future, and you can turn this win into an even bigger one down the road!
This post originally appeared on SimpleProgrammer.com and all images are courtesy of SimpleProgrammer.com