Collaboration is paramount to our industry. A key to being able to collaborate well is the ability to have dissenting opinions. Sometimes, your idea will be the best; sometimes it won’t. If you always have to be right, nobody will want to collaborate with you, and your work will suffer. For the sake of a project’s success, creativity, and problem solving, it’s best to abandon your ego. There are many ways to collaborate on a project. There are more traditional pairings and more creative ones. I wanted to share a few that I have experienced that have helped me become a better developer and have more empathy for the people I work with.
How We Collaborate and the Many Ways
At Sparkbox, we generally work in small project teams, and while we don’t Extreme Program, we very often pair up to solve tough problems or gather additional input. Sometimes, the act of verbalizing your code, project challenge, or ideas leads to great clarity and problem solving. Anybody who has worked with me knows that I often come up with solutions just by explaining my problem aloud. So maybe the term collaborative programming fits better than pair programming. We all bring different skillsets and experiences to our work. Our team is made up of more than just developers. We have project managers, designers, UX and content strategists, sales, an accountant, and many others that make up Sparkbox. While your first thought of someone to help with an issue may be one of the developers around you, I have found over the past few years that sometimes, that is not necessarily the case. While traditional pairing does have its merits, more unique collaborative pairings shouldn’t be overlooked.
Our projects are constantly becoming more and more complex. With single-page apps pulling data from online databases and services from all over the Internet, the lines between frontend and backend feel blurrier than ever. This can lead to people who are usually designing and writing frontend code needing to set up DBs and servers. Having access to those who have years of experience with these things can turn a frustrating afternoon of fighting with MySQL into a moment of triumph. Recently one of our Frontend Designers needed to do just this. Fighting with Homebrew and MySQL versions is no fun for anyone, but when it’s totally out of your wheelhouse, it’s nice to be able to call in someone who has years of experience fixing these problems.
This is one of my favorite pairings. Often, I find that our project managers and developers have different perspectives on what needs to be done for a project. This can lead to interesting conversations and dialogue around how we should solve a challenging issue. Over the years, our project managers have made an effort to better understand the development side of things, and they are often great people to rubber duck with, especially in situations where requirements might be changing. I find that project managers often have just the right perspective. They have a very good understanding of the project as a whole and often have insight into parts of the project that I may not. They can draw from past experiences of similar projects and bring up questions and propositions that can often lead to new ways of thinking and solutions that may not have occurred to a developer.
This may be one of the most unique pairings I’ve seen but it happens. Recently, we had a problem that involved figuring out ratios of different font sizes based on screen sizes. The math was a bit tricky, so we called in our accountant and spreadsheet wizard Josiah to help us work through the equations and understand some odd ratios.
Take a Look Around
Traditional and unique pairings have their time and place, but collaboration is always the answer. It results in finding creative solutions, building empathy, and simply being a better developer. It’s also just fun to work with various people in the office that aren’t always involved in the dev process. So next time you need another brain to look at a problem, take a look around the office and see who’s there that you do—or don’t—usually work with who might be able to help.