Coding Crossroads

main image

The School of Code Way

Hi everyone, Michał here! As you know, I recently graduated from the School of Code boot camp. Today, I'm super excited to share some of my journey with you.
But I've got to say, there's so much about the School of Code that I can't cover it all in one blog post. So, think of this as the first part of a series where I'll dive into different parts of my experience. In this post, I'm going to write about what makes the School of Code special. It's not your average coding course - there's something unique about how they do things here, and I've loved every bit of it. I'll also give you a sneak peek into the story behind their way of working on projects and collaborating in teams – it's pretty cool stuff!

So, grab a cup of tea, get comfy, and join me as I start to unfold this chapter of my coding adventure!

Over the years, the term 'Bootcamp' has kind of lost its wow factor. It used to be that when you heard someone graduated from a bootcamp, you'd think, "Wow, they must be ready to jump into coding and get going fast!" Back then, bootcamp grads were rare gems in the tech world. But times have changed. Nowadays, bootcamps are everywhere. You've even got online pre-recorded courses calling themselves bootcamps. With so many out there, it's hard to know what's what. That's why I want to tell you about the School of Code. It's not just any bootcamp. It's a life-changer, and I want to share how it's made an impact on me.

In this post, I'm not going to talk much about coding. Don't get me wrong, coding is key when you're starting as a developer. But I believe what really makes a junior software engineer stand out are the soft skills: team collaboration, attitude, growth mindset, willingness to learn, understanding of agile methodologies, and the entire project lifecycle. Sure, your coding skills will get sharper every day, especially once you're in the thick of it, working on real projects. But with strong soft skills in your toolkit, you'll grow faster and become a valuable team member in no time.

In the School of Code, it was all about teamwork. For the entire 16 weeks of the bootcamp, I was never coding alone. Our teams changed every week, sometimes just two of us, sometimes as many as six. We followed the driver-navigator style, which meant we were always collaborating closely. Regularly committing, branching, and merging code was a part of our daily routine. At first, being thrown into a new team every week, with people I’d never met, was quite uncomfortable. But that’s the thing about the School of Code - they believe in stepping out of your comfort zone and enjoying this process. And let me tell you - it works. By the third week, the anxiety turned into excitement. I even found myself starting conversations with strangers outside in parks or shops!

But it wasn't always easy. In such a dynamic environment, while learning entirely new things, there were moments I felt like I was lagging. That's when the School of Code's mindset sessions came into play. We had weekly sessions on teamwork, problem-solving, and psychology. These weren't just about coding, they were life lessons. They taught us to be open about our struggles, to ask questions without fear, to fight our imposter syndrome, to release our inner winner and to appreciate our support systems. This not only helped me in my professional life but also in my personal life.

Let me tell you how our project collaboration looked. I'll base this on our 'Build' project, where I worked in a team of six developers for four weeks. I'll also include pictures of our Figma jam and Trello board, where all the magic happened.
My key takeaway from the bootcamp is that complete software isn't just a working application. It's the essence of agile methodology and planning. Before we even started planning, the very first thing our team did was create our own agile manifesto. This manifesto was a set of principles and values that guided our approach to the project. It helped us align our goals, work ethics, and team dynamics, ensuring that everyone was on the same page from the start.

With our agile manifesto in place, we focused on the groundwork. Without a well-prepared problem statement, user research, and user personas, we couldn't identify the core problem we wanted to solve. Our pre-coding phase involved conducting competitor research, creating diagrams for the process, establishing database structures, defining user flow on our application, and designing a component tree. Then, we moved on to create low-fidelity frames, insert content, and create high-fidelity frames on Figma. This process was crucial as it was essential to continuously receive and incorporate feedback. We made changes to our plan, refactored, and improved it based on this feedback. Presenting our work-in-progress to our project stakeholders was a vital part of development, often revealing potential bugs and improvements that needed to be addressed.

Believe it or not, in our four-week project, the first week didn't involve opening VS Code or writing a single line of text. Trust me, this approach pays off in the development phase. Our typical week included all five Scrum ceremonies:

Sprint Planning: Initially, we spent a considerable amount of time planning our sprint. Given the limited time for our project, our sprints were four days long. We defined objectives and tasks for the upcoming weeks, which was crucial for setting a clear direction. The first sprint planning session was the most challenging as we were starting from scratch, but subsequent planning sessions went smoothly.

Daily stand-ups and retro at the end of the day: Every day started with a chat to update each other on our progress, discuss challenges, and realign our efforts. At the end of the day, we talked about our achievements. These daily check-ins kept us connected and on track.

Sprint Review: At each sprint's end, we reviewed our work. This wasn't just about our achievements but also involved gathering feedback, which was invaluable for refining our project.

Sprint Retrospective: These sessions were for reflection, discussing what went well and what could be improved. It was a learning experience that helped us enhance our collaboration and work processes.

Backlog Refinement: Regularly revisiting our backlog ensured that our task list was up-to-date and prioritized, preparing us for the next sprint.
The end of each sprint was Demo day, where we met with our stakeholders. We created a PowerPoint presentation, with each team member discussing a section of the project. Based on stakeholder feedback, we adjusted our plan for the upcoming sprint.

Our deep planning made the creation of our application much simpler and a more rewarding experience. Thanks to our thorough groundwork, we weren't overwhelmed by the limited time to deliver a complex application. We even managed to record and edit a demo of our application to share with friends and School of Code partners.

At the end, we presented our application on demo day, showcasing it to various School of Code partners. The feedback we received was nothing but positive. I find myself missing those days a lot now. Working in close collaboration for the last 16 weeks was brilliant, and continuing this journey on my own makes me feel a bit lonely. However, I'm hopeful that this feeling will change soon as I venture into new opportunities and collaborations. The School of Code was more than just a bootcamp. It was a transformative experience that has prepared me not just as a developer, but as a team player ready for the challenges ahead.

Until next time, keep coding and collaborating. The journey is just as important as the destination!

blog post
blog post
blog post
blog post
blog post
blog post
blog post
blog post
blog post
blog post
blog post
blog post

Comments

Don't forget to share this post!

Add comment