Joining an engineering team

It’s 8:47pm and you still haven’t been outside today. Your last meal, which you ate at your desk, was toast… with an egg. You haven’t had a chance to go grocery shopping in a couple of days. You’ll have that time once you finally get this piece of code to connect to the “API” (which strangely enough, involves FTPing an SVG file) consistently. At this precise moment though, you receive an email:

We just got word there are some changes to the SVG file, will send you another email in a few minutes. Hope this doesn't push out the estimate too much. Thanks in advance!

If this sounds like your current job, you’re probably a freelancer and it’s definitely time to join an engineering team.

Joining an engineering team frees you from constantly hustling for projects. You stop playing bill collector and worrying about where your next paycheck is coming from. Best of all: you’re finally surrounded by people who care about writing good code.

Despite the relief of finally getting away from freelance work, joining a team can be a bit of a culture shock. You’re adjusting from being the sole expert to being surrounded by peers. Which brings us to the first of several challenges…

Your technology choices are peer reviewed.

Your days of bower install latest-hotness-you-saw-on-twitter-dot-js --save && git commit -am yolo && git push origin master are over. You may be used to having clients defer to your judgment: after all, you’re a professional. Now that you’re on a team, both your code and your third-party library choices will be reviewed.

Be prepared to defend what you commit. Your peers have a vested interest in understanding the code making it into the repository. You will not always necessarily be around to help out when your code needs to be maintained (e.g., when you go on vacation). And of course, the libraries you choose have to solve the problem, scale, and not break the rest of the system.

On the other hand, your team is constantly adding new features. Plenty of opportunities arise for using new libraries and tools, many of which wouldn’t make sense to use in a freelance environment. You’ll still have the opportunity to incorporate new things; you’ll just have to justify adding them.

The feedback loop changes.

One of my freelance clients needed a multi-step, conditionally advancing form with validations on every input. I took the opportunity to learn and apply some advanced JavaScript techniques. When I presented the finished product, they were thrilled! As a bonus, my design handled inevitable last-minute changes with ease. (+1 to learning from prior experience!) Now, if my team were given a similar project and I submitted the same solution, I imagine I’d get feedback like this:

• Have you considered how you will make this ready for internationalization?
• We need unit tests around these validation functions.
• Consider writing this markup in one of our standard templating systems.
• Is there a way we can capture onclick events so we can report back to our analytics systems?
• Please use snake_case for this variable name instead of CamelCase.

And then to top it all off:

• We’re going to have to hold off on merging until the above issues are addressed.

Ouch. One-off approaches that would delight freelance clients will not always be sufficient in the context of an ongoing software project. Adjust your expectations of how quickly your code will get merged and deployed. Your teammates are seeing the code from different perspectives and applying lessons they’ve learned from when things went wrong.

Be patient, address the issues, and submit your code for review again. Once you go through the process regularly for a few months, you’ll gain a better understanding of the needs of the system you’re working on.

You have to let go of knowing the whole system.

When you do a freelance project, you typically pull up your framework of choice, write the code, deliver it to the client, and you’re done: you’ve authored all of the code specific to that project and you know it it all. If something breaks or your client wants to do a follow up project, you can dive right back in.

It’s just not possible to know it all on a project with an engineering team. Even if you do master one part of the system, it’s likely you’ll come back later only to find someone else heavily refactored it and you have to learn the new way it works.

So don’t. Instead of treating the project like a classic novel set in time, treat it more like Wikipedia where anyone can (and will) edit and reorganize. Don’t approach the project as something you will read from top to bottom, understand completely, and then adjust as necessary. Instead, strive to understand the problem the project solves. Understand the major components of the system and how they interact with other systems. Then you can dive more deeply into specific portions as you work on various features.

Credit where credit is due: you’re now sharing it.

When you complete a freelance project for a client (and it went well), you are right there at the moment when they say “Fantastic, looks great! Thank you so much!” This moment is unique: you and your client have successfully bridged the gap between their needs and your talents. Ideally, you’ve learned a bit about a cause, a product, or a place and have created a piece of software meeting that world on its own terms. Your client is now confident with the solution you’ve provided and now your software is in the wild where people can use it!

If you’re used to getting direct praise for your work, receiving indirect recognition can take some getting used to. Your efforts are now a much smaller portion of what’s being delivered. Aside from all of the other engineers making their contributions to the project, there are entire departments dedicated to tasks like management, sales, and support.

Take a moment to step back and realize the product you’re helping create is much larger than any freelance project you could possibly take on by yourself. And more often than not, you’re delivering reusable software clients wouldn’t otherwise be able to afford as a one-off system.

Your secret talent: context switching.

Despite the challenges of joining an engineering team, there’s one talent you may not already realize you have: context switching. When you’re freelancing, you’re not only an engineer: you’re project management, sales, IT support, quality assurance, and many other roles all at the same time. Being a freelancer exercises those muscles, making it easier for you to see the bigger picture.

It’s also easier for you to pick up new tools: you’re often called on to write “glue code” holding several systems together. You also have a good idea for what can go wrong and how you can go about fixing it. Once you leave the freelance world, you still have those skills, but you can focus more of your energy on discussing problems with your peers rather than chasing down clients with invoices.

Relax, you now hold one job, not six.

It’s now 2:07pm. Lunch with the engineering team was delicious and my grocery shopping is already done. (Thanks, Instacart!) This morning, I merged in a pull request, fixed up another one, and reviewed two more. Just before lunch, I had time to do a deep dive on a bug report to make sure we’re not overlooking some edge cases. While it is quick, the development process isn’t rushed and we’re not making careless mistakes. When I get stuck, I know my teammates are only a Slack message away.

I do miss freelancing, but only nostalgically. While freelancing gave me a great start, being a part of an engineering team is making me into a better programmer. I’m no longer distracted by the duties of running my own shop and I now have peers who hold me accountable to the technology choices I make. Better still: I’m able to contribute to something I wouldn’t have been able to have done on my own.

Are you currently freelancing? Are you wanting to make a “context switch” in your career? Join us! We have engineering openings in San Francisco, Austin, and Sydney.