by peterWeinberg

The freeCodeCamp Alumni Network: A homegrown mentorship network for FCC alumni

My “public” profile page — visible only to other FCCAN members

For the last year, I’ve been spending nearly all my free time learning to code. I’ve been a regular freeCodeCamp contributor, working on various projects such as the new React and Beta curriculums, the Testable Projects, a CDN-loaded front end test suite.

But about 3 months ago, I set out to level-up my coding skills in a big way. I only had one criteria: I wanted to take on my biggest coding challenge yet.

The final result is the culmination of 2 Campers’ efforts, 60 days of development, and hundreds of hours of work. And, of course, a project that I’m incredibly excited to introduce: the freeCodeCamp Alumni Network (FCCAN)!

FCCAN is an extension of the freeCodeCamp community, where holders of at least one freeCodeCamp certificate can come to connect.

In short, our goal is to promote meaningful relationships among experienced campers. Especially those who are looking to level-up their skills and/or share their expertise with other Campers. Here’s a few features that we know you’ll love:

  • Seamless user authentication. Sign in using your GitHub account and verify with your freeCodeCamp credentials.
  • Mentorship opportunities. An optional mentorship program for prospective mentors and mentees.
  • Personal profile. Identify coding skills and interests, personal stats, mentorship status, and more.
  • Member search. A search engine to help you find other members (and potential mentors) based on skills, interests, location, and more.
  • Collaboration. Looking for help with your new app? Share your open source projects with other Campers here.
  • Keep in touch. Identified a potential mentor? Reach out through FCCAN private chat, or visit the public room to talk all things code.

FCCAN is a platform to help you take your relationships with your fellow Campers to the next level.

But to fully realize this vision, we need you, the Campers, to come along for the ride with us. We invite you to visit the application and check out our about page. If you’re intrigued, sign up and see what it’s all about!

Our new home is

There’s always room for improvement, but we’re pretty happy with the MVP that we have, and we hope that you will be too.

In the spirit of freeCodeCamp and Open Source Software, this project is 100% open source. We encourage you to check out the repo and explore the codebase.

Active development will continue on this project, so if you find a bug or have a suggestion for a feature, feel free to open an issue. If you’re interested in contributing, we’ve already collected a few suggestions from our team and beta testers that we would love some help with! Please check out our contribution guidelines if you’d like to learn more.

Now that you’ve seen the project (and set up a totally rad profile!), I hope you’ll stick around to hear our story.

Three months ago, I thought coding something on this level was something I’d never be able to do. A feeling that I know that many Campers can relate to.

So if you’re intrigued, read on to learn more about the freeCodeCamp Alumni Network and how two freeCodeCampers developed a complex full-stack web application in just two months.

I started coding just over a year ago, and my journey has been one of completely self-guided learning. Throughout this short history, I’ve relied almost entirely on freeCodeCamp to sharpen my skills.

During this time, I picked up some basic skills in JavaScript, React, HTML5, CSS3, and Sass. You might recognize these as some of the core skills evangelized in freeCodeCamp’s current curriculum.

And although I had accomplished a lot, I found that I had gotten to a sort of plateau. What felt like rapid progress to my totally un-tech-oriented brain, actually just barely positioned me as a beginner-level programmer.

I knew I needed a much stronger arsenal of skills. But, transitioning from basic front end projects, to developing production-level full stack applications from scratch, felt like a gap that I was never going to be able to bridge. But, I knew I needed to somehow, so I began to explore some new avenues.

One thing I discovered, was that I learned much more and much faster when I was working with other programmers. So I reached out to Chance McAlister (aka Chance Taken), the father and organizer of the Chingu Cohorts. Chance regularly champions group projects within the Cohorts, and he set me up with a team who had recently finished up a project of their own.

The project was Campfire Stories (a freeCodeCamp-centric app that recounts campers’ stories), and they needed a bit of help maintaining and improving their legacy codebase. So I had a call with one of the creators to bring me up to speed. And wow… the complexity and architecture of the application was just way too much for me to follow.

Even though I was mostly familiar with their technology, the structure and coding paradigms seemed totally foreign to me. I was further behind than I had realized, and I walked away from that call feeling a tad disheartened. All the confidence I had gained over the last few months had all but vanished.

How was I ever going to learn this stuff? The back end was completely intimidating, I barely understood state management, and complex views were more than I could handle.

It took me a couple of days, but I eventually overcame my defeatism. As confounded as I was by the complexity of the Campfire Stories codebase, I emerged feeling more motivated than ever to get the job done. It was just my approach that was wrong.

The recipe for my success, I realized, was to build and define the architecture from scratch. That way I could follow the process from zero to complex every step of the way.


So, after this first failed attempt, I decided the timing was ripe to give an idea of my own a try.

Inspired by Campfire Stories, I also wanted to build a freeCodeCamp-related app. One of my favorite things about freeCodeCamp is the success stories I often hear, about people “graduating” from freeCodeCamp, and getting coding jobs in the real world.

These stories are an important part of other campers’ success. Knowing there’s a pot of gold at the end of the rainbow is a huge motivator!

With this in mind, I envisioned a place where campers could come to connect and track one another’s accomplishments. The idea would change a bit over time, but this was enough to get the ball rolling. I pitched it to Chance, who helped me to develop the idea a bit further, and soon after, we had formed a team.

I was pretty pumped, this was exactly the kind of project I needed to take on to get my skills to where I wanted them to be! Once we had defined what our minimum viable product (MVP) would look like, it was clear that this project was going to be rather ambitious for a few beginner-level programmers. We would need:

  • Working user registration/authentication
  • A database to store user data
  • An interface for users to input, edit, and maintain personal data
  • A way for users to communicate with one another within the application
  • A search feature for users to find one another
  • Effective routing from one view to the next
  • State management to manage complex application state

And this was just to get us off the ground! My wish was coming true — this was shaping up to be the most complex and challenging project I had ever taken on.

We defined our technology stack and got to work. We opted for classic freeCodeCamp, and chose ReactJS as a JavaScript framework, and in fully embracing that choice, Redux, and React-Redux were natural additions to the mix for state management. A MongoDB database, and an Express/NodeJS back end rounded out the core of our application. We bootstrapped our project with Create-React-App, made some tweaks for Sass support, installed an army of NPM packages, and were on our way.

Now up until this point, I had done enough research to know what each of these technologies were. But aside from React and Sass, I had never touched a single one. Needless to say, this was going to be a challenge for me.

Yet through some pair programming, and by working very closely with my teammate, Sean Smith, I was able to overcome every technological hurdle I encountered.

After configuring Create-React-App to work with a proxy server, our first step was to implement user authentication and registration. This was quite the challenge — we wanted to decouple registration from the app itself (less sensitive data for us to manage, fewer usernames and passwords for you). So enabling GitHub-based login via PassportJS seemed like the way to go.

However, we also needed to implement some sort of user verification process since we wanted to enforce that members actually be freeCodeCamp alumni (that is, campers who’ve earned at least one certificate). After devising an end-point redirect counting technique for verifying user certs using Axios, we were finally on our way!

This was my first ever introduction to back end programming, and a major milestone for the app. Now that we could login and logout successfully, the real work could begin.

Our earliest iteration of successful user login and registration (shout out to the Chingu Penguins Cohort!).
We’ve come a long way: A look at our current user authentication process.

Next up was tackling state management. For example, to create the user profile page, the core of the FCCAN user experience, we needed to implement CRUD functionality, or Create, Read, Update, and Delete.

The preferences page is highly editable — over a dozen fields makes for some complicated state, too complex for React to manage alone. This was a job for Redux. This meant we were managing state on 3 separate levels spanning both ends of the stack: with React, on the Component level, with Redux on the Store level, and with MongoDB on the database level.

Figuring out how to efficiently manipulate and manage a complex state object proved a formidable challenge. Yet once we had it down, we were able to reuse this same paradigm over and over again throughout the application.

Here is another great example, which unlike our CRUD example, uses only React and Redux (see gif below):


Notice that even though I’ve navigated away from the search page, when I return, the state exists exactly as it was when I left.

State managed locally by React clears as soon as a component unmounts, but passing this state to Redux allows us to preserve that state beyond the lifecycle of a React component, and passing it to the database as needed allows us to preserve that state beyond the lifecycle of a Redux store, which exists inherently only as long as a user’s session is persisted.

The single most complex implementation of CRUD functionality in the FCCAN application is our chat feature. While this may not seem like a typical CRUD implementation, the core principles are exactly the same.

Basically, the database is our single source of truth. For any CRUD action, we POST to a route which handles that action. If, and only if, we get a successful response from the server (indicating the database is up to date with that action), we then broadcast a real-time update via Socket.IO. Simultaneously, we dispatch an action which performs an update to the UI through Redux, where the chat data is persisted using ImmutableJS data structures.

In this way, we only show an update to a user if we have actually updated the data in the database first. Using this pattern, we were able to implement some core chat functionality including likes, editing and deleting messages, and just for fun, some pretty cool emojis!

While continuing to check off the boxes on our MVP feature checklist, we had to consider design every step of the way. From this perspective, our early decision to adapt Semantic-UI as a CSS library proved to be a sound one. We used it heavily and were very happy with its sleek and easy to work with styling and layout options, its Semantic-UI-React integration, and its well-thought-out responsive design capabilities. When it came to the latter, we sometimes supplemented Semantic with React-Screen-Size, when the default breaks and media queries were not enough.

For more granular control over styling, we complimented Semantic with some custom Sass stylesheets and Styled-Components. Styled-Components is a newer CSS/JavaScript package for React that allows for more intuitive and conditionally rendered CSS, written directly into your component files. I highly recommend that you check it out.

Once we had our core functionality down, we were ready for our next big step: deployment.

I had never deployed an application before, and quickly found that this brought with it a whole new set of challenges.

We configured Heroku, subscribed to cloud hosted instances of MongoDB and Redis, and after hours of troubleshooting and 19 commits later, we had reached another major landmark. A beta version of FCCAN was finally live!

Deployment looks like fun? It wasn’t.

Though this was not as glorious as I had hoped it would be. Once the app was live, some new concerns were immediately brought to light. For one thing, we needed a much stronger mobile UI (which we had been unable to reliably test up until this point). And, of course, cross-device compatibility was a major problem.

But, we were in the home stretch. Nearly there, we were both extremely motivated to see this project through to completion.

Celebrating our 100th PR!

Over the next few weeks, we were busy at work putting some finishing touches on our application. Not to mention working out a few major bugs. For example, it was a shock to discover that if someone got distracted during login and never attempted to “verify” their account, the entire app would crash!

As a final touch, we decided to move away from the default Semantic-UI theme, which didn’t feel quite sleek enough. Plus, we wanted Campers to feel right at home, even on their very first visit. We thought the best way to achieve this would be to recreate the freeCodeCamp theme as closely as we could, while not having to backtrack and compromise the stylistic choices we had already made.

So instead of pulling in Semantic via CDN, we use their Gulp build tools and custom theming capabilities and built the package directly into our project. The results were fantastic. The site went from a tacky and unprofessional-feeling teal, to a sharp and distinguished freeCodeCamp green.

Before custom theming (above), and after (below). What a difference!

After 60 days of development and about 20–30 hours per week, we had just about wrapped things up. We conducted a short round of beta testing with live users, and now, as I write this article, we are finally ready for our official launch!

This had turned out to be the quintessential experience that I was looking for. Throughout this process, as things got incrementally more complex, the architecture and inner workings of a modern single-page web app became clear to me. As the codebase grew, I was there for it every step of the way, either contributing code, or reviewing and understanding the code that I didn’t.

Now that we’re done, I can’t reiterate enough times how enriching this experience has been for me. The key takeaway is this: sometimes taking baby steps just doesn’t cut it anymore. If you ever feel frustrated about the rate of your progress, or if you feel like you’ve plateaued, don’t give up.

Instead, go out and find something that’s twice or three times as hard than anything you’ve ever done before.

It will be difficult, any might feel impossible at times. But the reward of finally completing the challenge, and the value of the knowledge you’ll gain along the way is immeasurable!

Whether 1 or 100 people join the freeCodeCamp Alumni Network, this will all have been worth it. If you can relate to the mindset I had before I started the development of this project, I would encourage you to think about what represents your next biggest challenge, attack it, and own it! I hope you will have as much fun with it as I did.