I'm currently a student in a full-stack web development boot camp. We are just about to turn in our first group project and I learned a lot during this process. I learned some handy tricks in JavaScript and CSS, but more importantly, the lessons learned from this assignment were lessons about working with people in a creative and collaborative environment. I'm making a career pivot after almost 20 years in sales and collaborating is rarely an option in that field. Even when you're part of a team, there's an underlying layer of competition involved.
Spoiler alert: I thoroughly enjoyed the group dynamic and felt lucky to have landed with the team I did. We learned about each other's skillsets and strengths and weaknesses as well as our own. Here are some of the highlights:
Decisiveness
I have to be honest, our first night felt a little messy. We spent the majority of our 3 hour session trying to get a consensus on a project. Not because there were passionate disagreements but because it felt difficult choosing something that was important, but also within reach of our current skillsets. We still hadn't learned anything about server-side programming or any sort of third party storage. That ultimately became the deciding factor in making our choice between our two top candidates.
I felt a little conflicted here. I was fully on board with our ultimate choice in project. It was partly my idea. But I also felt a responsibility to really give it 100% effort so that the decision to commit to that idea really resulted in exceeding the potential of our backup idea. That sounds a little strange to say even as I type it, but essentially I wanted to feel confident that the route we were taking was going to truly produce a better application and wasn't just a matter of taking the easy route.
At the end of that first night we all agreed readily on one major philosophy for the project; once we made that choice, we weren't looking back. It was full steam ahead with our decision. Two weeks sounded like an eternity at the beginning of the project. But currently with only one class left before our presentation, we wish we had another week. I was glad we decided to commit to an idea in those early hours and move forward to delivering our minimum viable product.
Project management
Collaboration is hard. It's a completely separate layer of skill. Through the first couple months of work prior to our group assignment, I had developed a pretty fluid workflow and pace to my development work. Having to learn to operate in concert with several teammembers taught me the value of focus.
Perhaps in the real world I will occasionally not be bound by constraints on time and other resources. My guess is that, more often than not, the opposite will be true. With a due date looming and several other moving pieces revolving around my efforts I learned quickly that I need to focus on a task, knock it out, test it and push my commits to version control. There were several times when someone was waiting on me to complete a task or vice versa. In my previous method of "solo" development, I frequently would get inspired and leave a function unfinished to pursue the shiny object. Now, I've learned to drop a comment where that new feature should go and make an issue to revisit it when the workflow allows.
Delegation
4 years of my aforementioned 2 decades of sales experience was spent managing people in a large sales organization. That was a roller-coaster of an experience but it taught me some valuable inter-personal skills.
As a natural introvert, it took a lot of practice to learn to take charge of a situation. I was always afraid of stepping on toes or insulting someone. What I realized over time was that there is a big difference between holding someone accountable to their responsibilities and being an over-bearing jerk.
That is not to say we experienced any inter-personal drama. But we were in need of someone to organize our collective thoughts and democratically map out the chart of progress. I volunteered for that role and dove into the projects and issues tools on GitHub.
It's difficult to manage my own scattered brain, but having to juggle my own thought process while being aware of what was happening in the several other branches of our repo made the value of those tracking tools apparent. In future projects, I would want to increase my granularity with those tools. I typically found myself spending 15 minutes before class started cleaning up issues that had been solved in the past two days. It still provided a record and a roadmap of our progess.
Version control
This is a dangerous topic. In the first few days of our collaboration, I completely scrambled our codebase multiple times due to mishandling of pull requests and a failure to better plan out protocols for our version control. Yet, by the end of week 1, we were merging the majority of our pull requests without any conflicts and the application was progressing nicely.
Since the early days of this boot camp I have committed and pushed early and often. It's been a life-preserver one more than one occasion. I was intimidated by having to process gobs of pull requests if everyone took the same approach. Surprisingly, it was less of a time investment to process large quantities of pull requests which could auto-merge than it was to have to resolve conflicts throughout 100 lines of new code.
Hurdle-jumping
One of the most surprising and beneficial lessons was learning to pass the football. The biggest pain points in this boot camp have always revolved around roadblocks I'd encounter tackling a homework assignment on my own. Fortunately, we had developed a tight-knit study group consisting of most of the cohort and help was always a Discord or Slack ping away. But you still felt like you were on an island of sorts.
With this team, communication was frequent and constant. The hours between class sessions were almost all dotted with short collaborative conversations in our Slack message group. Most of the real progress made on the codebase was written in those gaps.
The all-hands on deck approach of our team allowed us to hand off an issue and quickly get a second or third set of eyes on the code to help troubleshoot. This rapid response was really what saved the project and made it possible to produce an application we were proud of. It gave us sufficient time to spend on deciphering endless console errors and returned data format trifles in our chosen API calls.
Trusting your teammate to innovate and create
My current career is in real estate. As a Realtor, I do not work on a team. I do work for a supportive broker and have access to an array of talent via the experience of my office-mates. Ultimately, though, I am self-employed and it's easy to develop a control complex in that environment.
I really had to fight the urge to try and override someone else's decision throughout this project. I had my own vision for how the project would look and in my current position I would have no one presenting alternative options. I knew going into this boot camp that this was a weakness in my professional life that I needed to work on.
While I am not surprised, I am relieved to confirm that every time I had a difference of opinion about a certain feature and deferred to someone else's judgment the finished product was that much better for it. The lesson for myself here is that if I am passionate about a certain feature, then I need to make sure I've considered all the pros and cons before going to the mat for it. I believe that if an idea is truly the best way to go then its best shot at adoption is to develop the idea to a point where it can convince everyone else of its own merits.
This is almost certainly an optimistic way to think about every decision and situation. There will be times where I feel I support a superior option and another option wins out. I hope in those moments I am able to remember that the winning idea has someone behind it who is just as passionate about it as I am about my own. In that case, it deserves an honest effort and will potentially benefit from complimentary ideas from my own option.
The importance of comments
Comments had long been a mystery to me. I was of the mind that my code should be so clean, well thought out, and organized that it would speak for itself. That's a tall order in a time crunch with three other coders all bouncing ideas off each other. Also, there were times I ran across something someone had added and asked myself, "What the heck is this?". Turns out there's a saying about people who live in glass houses.
I soon realized how beneficial it was to have a brief summary of a function commented out right above that function's code block. A little date stamp with some initials would save a lot of alt-tabbing between my IDE and my GitHub repo while researching commit history. I even discovered how valuable comments can be as storage containers. It was very helpful to provide a link to an API's documentation right above an ajax call for easy reference.
In Summary
And so here we are. 90% of the way to our minimum viable product. And with time left to be able to put some vanity touches on our app with CSS, add in last minute functionality that enhances the experience, or even dry out that script.js file that was always on the brink of becoming unwieldy.
I've learned a lot about coding and about myself. Not least of all, I've learned a lot about the people I worked with and for that I am grateful.
Thanks for taking the time to read. I would love to hear what you think and how your early group-efforts went. Comment below or find my contact info on my profile page.
-Jon Deavers
https://lucsedirae.github.io/
Top comments (0)