Business schools often proclaim fostering teamwork by assigning tons of group projects. Yet, it’s at General Assembly – the three-month programming bootcamp I’m currently enrolled in – where I’ve been immersed in the most intense team environment of my career. Without a doubt, the depth of collaboration has been the biggest surprise of my summer in software development.

General Assembly boasts three immersive tracks: user experience (UX) design, product management, and web development (the one I’m taking). These tracks reflect three of the main functions inside of many early-stage Internet firms today. The role of the developer is pretty obvious: to build a product using code. UX designers, on the other hand, focus on shaping the experience of a user when interacting with the product. As our lives become cluttered with applications, excellent design is quickly becoming paramount to capture and retain our limited attention. Finally, product managers liaise between UX designers and developers, and validate customers desires for a specific product. I think of product managers as “mini-CEOs” of a product.

The climax of General Assembly is a “cross-immersive” project during weeks 9 and 10 where 2-3 programming students are paired up with a product management student and a UX design student. I was a bit apprehensive at first because I had no idea what kind of project our product manager would assign us to, but I was pleasantly surprised that instead of diving into a predetermined idea we had a day-long brainstorming session to figure out what we should build. To me, the key criteria to decide on a project centered on 1) finding a reasonably cool idea and 2) making sure that the project was within scope (in terms of time and ability to execute given our rather limited skill-set). We decided on a web app to create and join pick-up soccer games in and around New York City.

As a business school student, I found it both refreshing and challenging to collaborate with a product manager. It was refreshing because we could finally talk about “customer validation” or “monetization strategies” which are part of my daily b-school vocabulary. At the same time, I constantly had to stop myself in team discussions regarding the direction we should take because as a junior programmer my role in the team is completely different. Instead of focusing on the merits of the idea and how we should proceed, I homed in on understanding the requirements, features, and time horizon of the project. Hard as it may be, I think learning to follow is a crucial leadership ability that more business students need to practice.

On the first few days, I also found myself pushing back – more than my programmer teammates – on many of the features thrown at us by the designer and the product manager because I could foresee that they would take way more time than originally estimated. This reinforced my notion that serious product managers should take the time to learn how to code – at least enough to understand the time, effort, and pain it can take to create something as simple as, say, a login page.

This cross-immersive project was also the first time my fellow coders and I really used Git and Github. It’s taken me a few months to really understand how these two tools really work together, so explaining it fully requires a standalone blogpost. But at the most basic level, Git and Github allow for “version control” of the code in a big project. In production settings, programmers will work on a “clone” of the master codebase, making changes to the code on their own computers. If the workflow is coordinated well, then no two programmers should be working on the same files. Parallel workflow would then allow each programmer to essentially save their work and “push” it into the cloud (Github) without producing a problem. At this point, all the files that have been changed are merged back into the master codebase and process then repeats itself.

At first, the process of pulling, saving, pushing, and merging felt arduous and we maybe completed a cycle per day. This, however, proved to be a huge mistake because there were just too many changes to keep track of and each person’s work spilled into the files of another teammate, creating merge conflicts at the end of the day. By day three, we were communicating much more explicitly – telling each other exactly what were going to work on – and after 30 minutes or so, we’d all stop and integrate our files on Github.

Building software requires teams to be truly synced up, both on a developer-to-non-developer level as well as on a developer-to-developer level. Failing to do so only leads to deployment delays, conflicting code, and an overall crappy product at the end of the day.