When I was 15 or so, my high school sent us all on one of those character-building outdoor holidays. We hiked, camped and abseiled in the Welsh sunshine with a vague goal of us returning home as changed people.

Stock image may not be wholly representative of aforementioned school trip in late 90's North Wales

Only, that’s precisely what happened. With our fears exposed and our strengths celebrated, students that had never gotten along found a new respect for their classmates. Long-held grudges were forgotten as midnight snacks were exchanged and twigs detangled from one anothers’ hair. The trip wasn’t really about sport — it was about challenging ourselves and learning to respect and support one another.

It’s a core feature of almost every coding bootcamp — the final project phase. A group will design and build a full stack application in around two weeks; they’ll choose the technologies and frameworks, design the database from scratch then top it off with a technical presentation. And just as the school trip wasn’t solely about our ability to pitch a tent, project phase isn’t just about the code. Learning to work as a team is a crucial part of software development and something employers will be keen to see evidence of.

For me, it was a sprint like no other — the most intense, challenging and exciting part of the course. With the benefit of hindsight, these are just five things I gained a new appreciation for and that you may want to keep in mind as your own project approaches.

1. The Importance of a Clear, Core Idea

You’ve sat down, shared your thoughts and decided on the application you want to make. Or have you? In the flurry of ideas and suggestions, one of you is planning an app to find missing pets, two are designing the database for an animal shelter and the fourth is keen to spike e-commerce strategies for selling pet food. By the implementation stage, you all have very different ideas of what to prioritise, how to design the database relationships and what the front-end design needs.

With a strong plan and a clear goal, what can possibly go wrong?

Solidify clearly exactly what your app is and what it does. Which features will be at its core and which are optional extras? It may seem like overkill, but it can save headaches later down the line when you realise you’ve spent a day or two collaborating on four slightly different pet-related apps.

2. Project Management

With multiple programmers working towards a single goal, it’s important to plan how tasks are to be divided up. A popular idea is a Kanban board, where tasks can be pinned and prioritised for any member of the team to take on and deal with.

Kanban: the other use for post-its.

A number of software development methodologies exist and employers will want to hear how your implementation helped the project flow. An Agile methodology allows for a team to adapt to problems or new requirements, especially if each member is familiar enough with the tasks in progress that they can step in.

We attempted to follow an Agile methodology, but significant database issues kept the team divided into front and back-end pairs for a few days. Although we communicated what we needed from one another, gradually our respective code bases became larger and, as we grew more comfortable and familiar with ‘our’ code in which we’d thoroughly immersed ourselves for a week, it became harder to swap to ‘their’ code which we had lost touch with on a detailed level.

Ensure your code can be understood by others and not just yourself

To stay Agile, consider mixing the pairs at times so each can have a hand in the construction of other components, ensuring everyone is familiar with all of the code and the design decisions made. It also means that if problems arise, someone in the group should be able to jump in and help without feeling as if they’re seeing the code for the first time.

3. Libraries

Initially I wanted to avoid using libraries I didn’t yet understand. I felt more comfortable, as a newcomer, simply writing my own code and knowing exactly what was going on, rather than relying on a large chunk of someone else’s code for core functionality.

By the end of the project I’d come to appreciate some of the issues that libraries solve. Integrating GoogleMaps, which relies on manipulating the DOM, into React, which is valued because it doesn’t, is possible but can be inefficient, bypassing a number of React’s benefits.

“when in doubt, go to the library.”

Tools have been created to streamline this integration, but to a newcomer none of those benefits were immediately apparent. However, after 9 days elbow-deep in lifecycle management, props delegation and event callbacks, the documentation began to make sense. Perhaps you need to experience the problem first-hand before the solution seems like a good use of time.

4. Async

Few things consolidate async theory like project phase. Remember that first day of callbacks, where you scratched your head over a single API call?

Now you have an app taking shape. You have multiple Promise chains to resolve, delivering reams of data from an increasingly bad-tempered database. You’re sending a portion of that data to a Google map that never really wanted to be a React component in the first place, then dividing the rest between mathematical formulae, the values you want held in state and front-page rendering.

It sounds intense but, having designed and built this, you and your group know your way around it better than anyone. You know where you want to access your objects and arrays and which component needs what and when. The app becomes your baby, a little Frankenstein’s monster, and you can intuit where the data needs to flow because you created it that way.

Yes, like a mind palace

At the end of the phase, when the dust has settled, you will now be able to identify where that data flow could have been improved, highlighting important aspects of software design that may have been difficult to learn without first-hand experience.

5. You’ll be amazed at what you can achieve.

It’s two days to the deadline. Your bugs are spawning bugs, you’ve had to drop a feature and reluctantly hard-code another. Maybe you feel disappointed at the things you didn’t have time to add and the tasks that went undone.

On the final day, take a step back. It’s time to present and showcase the things that did go well. Though you might not see it if you dwell on those last few disappointments, you’ve achieved an admirable amount in just a few days, considering how much, or how little, Javascript you knew just 12 weeks ago. Focus on what the app does well, how you brought it together and how effectively you adapted when things didn’t go to plan. You’ve a lot to be proud of, so smile, rehearse your lines and show it off at its best.

#highfive