HexSchool Node.js Enterprise Course
Some rough thoughts and reflections after completing the HexSchool Node.js Enterprise Course.
Why did I take this course? What problem was I trying to solve?
This is an expensive course. Given HexSchool's nature (they can't turn away paying students for business reasons), the course content has to be designed on the easier side.
With those conditions, signing up might seem like a bad deal. But in practice, there are a few angles worth considering:
Teamwork
The course requires group collaboration from the start. Since most participants come from frontend backgrounds and have little to no backend experience, it's a chance to practice communication and coordination in backend development.
From another angle, the people you collaborate with can become future connections who help each other out -- it's a way to build your professional network.
Sunk Cost
As I mentioned, this is a pricey course. Even if you're as lazy as I am, if you don't want that money to go to waste, you'll have to put in effort after work to keep up with the project and hit the deadline. In a way, it forces you to be disciplined.
New Perspectives
The entire project goes from design ideation to development, end to end. Objectively, the content is fairly surface-level, but it still lets every member walk through the PM, UI/UX, frontend, and backend workflow at least once. That gives you some new perspectives for future work.
Course Content
Beyond the basics of MongoDB commands and Node.js API implementation, the most valuable part, in my opinion, was the integration with third-party services -- things like third-party login and payment processing. These are tedious by nature and require time spent digging through the provider's documentation, so having structured teaching saves you that effort.
Also, some parts of the course still use MVC as the example architecture, so the team had to figure out frontend-backend separation on their own during the project. That's another area that takes time and thought.
Some sessions were essentially outsourced to guest instructors for live teaching, which can create gaps. For example, the unit testing session provided examples for frontend only, so if you wanted to practice backend unit testing, you were on your own.
Project Work (Very Subjective Take)
The project work is what I consider the most valuable part of this course, and the key to it is the team's internal collaboration and planning.
Be honest before forming teams
Before teams are formed, there's a self-assessment of your abilities. If you're unfamiliar with a domain, be honest about it. If the skill gap within a team is too large, it easily leads to serious disagreements, and the project falls apart.
Build in buffer time for development
Since most people are frontend developers stepping into backend work, there are many gotchas that slow things down -- things frontend devs never had to worry about before. For example, after integrating payment processing, you inevitably have to handle orders, and orders involve transaction timestamps and other complexities.
For frontend devs, these issues were never on the radar before. It was always just calling APIs and rendering lists. But on the backend side, these are things you absolutely have to think about.
Aim for a shipped project
Please seriously consider these points:
- Team members all have day jobs and can only invest limited time (you can't predict if someone will have urgent work demands or overtime)
- The deadline is very tight, with limited actual development time
- Most members won't have backend experience, so there will inevitably be time spent hitting walls
So the first-phase goal should be building something that works, not something perfect. Don't overthink architecture, optimization, or testing at this stage -- those come later.
If you chase perfection, you'll not only get stuck on development time, but worse, you might cause the team to fracture (hidden conflicts everywhere, especially when you can't tell if teammates are dealing with work pressure during the day). Once a team fractures, the project is 94.87% dead. Shipping an ugly but functional feature goes a long way in boosting everyone's confidence.
In particular, avoid endlessly expanding the team's tech stack. On the frontend side, you should never end up using both React and Vue at the same time. Even if someone on the team is great with one framework, that doesn't mean others can pick it up quickly enough to contribute.
Expansion and Optimization
After the project completes its first role-based feature, you can consider the first phase done. Besides taking a breather, you can start thinking about additional features, including things you want to try technically or UX improvements.
For our project, we gradually added websocket messaging, PWA support, animations, a check-in system, and more, enriching the overall site.
Final Words
Here are the deployed URLs and repos for our project. Feel free to check them out.
Client
Admin
<!-- test account & password -->
account : admin
password : 12345678