Hahow for Business
Hahow is a well-known e-learning platform for individuals seeking to learn various subjects. (I’ve personally purchased courses on Yoga, writing, investing, and web animation)
Fun Fact: “Hahow” has the same pronunciation as “school” (“學校”) in Taiwanese.
Besides Hahow, H4B targets corporations, offering external education courses and internal training services. It includes diverse learning materials like video lessons, articles, quizzes, PDF readers, notes, and discussion forums. We also provide comprehensive admin services for HR professionals focused on L&D, with data visualization dashboards, customized training courses, and event management.
And the best part? I get to use the code I’ve written, which is a huge achievement for me!
I’m always thrilled to see my work in action on the platform!
Development Life as a Front-End Engineer
Introduction
Our team follow the Scrum methodology. I believe each development team is different with no one-size-fits-all Scrum solution. I’ll skip the details of Scrum, focus on how we implement Scrum in our team.
Scrum Overview
- Sprint: 15-day cycles with 7 days for development and 8 days for QA testing
- Stand-up Meeting: Daily 15-minute meetings to keep everyone aligned
- Refinement Meeting: PM summarizes milestones before sprints to align vision
- Planning Meeting: Developers break down milestones into story points
- Story Point Estimation: We use XS, S, M, L categories, avoiding over M size by splitting again. (we believe larger points are harder to track.)
- Retro Meeting: End-of-sprint reviews focusing on: Keep, Start, Stop, Thanks
Product Workflow
Quarterly goals comes after company decisions. PM and Designers create wireframe and mockups for developer feasible review. Then front-end and back-end teams develop technical documentation.
For front-end technical documentation, we focus on component planning, logic structuring, and story-point breakdown.After reviewing back-end API documentation, we align both documents and estimate story points.
The development workflow remains flexible and open to discussion. I especially value our retro meetings, fostering an open-minded and psychologically safe communication culture.
Example: Our stand-up meetings initially exceeded 30 minutes due to detailed progress reports. After a retro meeting, someone noted this caused “fade out” as focus waned. We switched to written reporting with only critical matters discussed during stand-ups, reducing meetings to under 15 minutes.
This was eye-opening for me. I never imagined admitting “fade out” could be constructive—it wasn’t about blame but collective problem-solving.
Code Reviews
At Hahow, code quality is a priority. I’m fortunate to work with a team that considers code reviews essential, not optional (and factors them into story-point estimations).
Colleague’s Quote: “Nice-to-have equals never-to-have.”
The benefits of code reviews are numerous. Align coding styles, catch edge cases, and identify reusable components during development—helping us maintain the product and scale efficiently.
Moreover, we maintain wiki guidelines covering topics like avoiding “ninja code” and magic numbers, making reasonable commits, and following naming conventions. These practices not only make code easier for reviewers to read but also ensure consistent coding style.
As a junior developer, I benefit from others’ suggestions, but reviewing others’ code provides even greater value. It trains me to understand different logical workflows and builds my research and feedback skills.
Communication
I used to believe that software engineers just spent 8 hours coding with their hoodies on. But in reality, being part of a team means that collaboration and communication are crucial.
Communication isn’t just about time-consuming meetings—it’s about sharing information during development.
Example: While I joined, the front-end team expanded from 2 to 4 people. This made alignment harder, causing inconsistent coding styles, multiple PR reviews, redundant component work, different naming conventions, and task division challenges. After several retro meetings, we integrated technical documentation into Planning Meetings, allowing earlier task division and pseudo-code standardization. This added planning time but eliminated ping-pong communication and repetitive work.
The way of communcation
As we work in a hybrid team, we mainly use two forms of communication(like JavaScript):
- Synchronous: In-person or online (Google Meet, Slack huddle) for complex discussions or urgent matters, typically after stand-ups
- Asynchronous: For technical documentation, reviews, and guidelines that require research and thoughtful responses
These communications typically conclude with a call to action(CTA) for clear next steps.
Conclusion
This one-year journey may not be very long, but it’s been filled with countless meaningful and memorable moments. I’m fortunate to work with supportive colleagues and an open-minded manager in an encouraging culture. Tech sharing sessions, front-end circles, and UX book clubs have provided valuable growth opportunities.
