Hello everyone. So I’m Henry Lie from Indonesia, specifically Surabaya city. Fun facts? Well, I love spicy food, mechanical keyboards and living in Japan!

This is something I struggle with when my mom asks me what I do at work. If I just say “front-end engineer” she has no idea what that means. Basically, I’m working on the public-facing part of a website or web app. For example, every post you make on a site like Facebook or Twitter (X) is stored on a server. But as a front-end engineer I don’t work with the server. I’m focused on how that post is sent to your browser and presented to you as the user.

Right, it’s an important distinction. At HENNGE we’re selling a B2B product so it’s immediately a different demographic. A lot of front-end engineers will start out on B2C projects for things that need to be easily searchable by Google, but we’re working on products within HENNGE for customers who are already familiar with our product and have a contract to use our services. In practical terms, this means we’re paying closer attention to things like stability to ensure that those already relying on our services can continue to work seamlessly.

It typically starts with a daily stand-up meeting to catch up with team members on what we’re working on and raise any issues. We have scheduled meetings with the design and product marketing management teams to discuss longer-term goals, and then get together when it’s helpful to dive into a specific new feature.

For my software development tasks, these usually cover new feature development, updates to existing features, bugfixes, reviewing others’ code, and making weekly releases. But, by design, this varies for each team at HENNGE.

Yes. It’s about having the freedom to choose the right tools and approach that work best for each team and individual. As front-end engineers, we are not constricted to one framework. We might use Vue or React to deliver tasks like building new features or fixing bugs. The cool thing is that knowledge sharing is actively encouraged. For example, we hold monthly open discussion meetups where front-end engineers can share case studies of what has worked well in an informal way that still ensures we’re always learning, evolving, and improving. There is also another session for general knowledge sharing about technology that is open to everyone in the company, but it doesn’t have to be about work-related technology. I mentioned that I like mechanical keyboards, right? Well, I’ve also given talks about that, which often lead to some fun discussions with other mechanical keyboard users.

It’s a natural process. For example, maybe we’ve gotten used to doing something a certain way but a team member thinks there may be a better approach. They can pitch their idea to the whole team and if the majority agree it can be put into effect there and then. Rather than go through a lengthy approval process, we can just try it out first. If it works, we keep it. If it doesn’t, we review and adjust.

Absolutely. In fact, it’s most common when new team members join. They might have a totally different experience from their previous job, or if they are a new-grad they may bring a fresh perspective that we haven’t considered before. Everyone’s input has equal value from the get-go.

Exactly. Another example that makes HENNGE different is that we also do peer reviews of each other’s code. It’s a good way to not only ensure that everything is up to standard, but also a chance to discuss openly if we have different opinions on how something can be done. This peer review works both ways. Not only will a team leader review newcomers’ code, new members also get to review the team leader’s code, so it’s definitely a flatter structure, which I feel empowers every team member to shine.

HENNGE has a lot of key products already serving many customers, so of course, we have to be careful before jumping into a new technology. However, the same approach applies. We will openly review the pros and cons. For example, if the team agrees to adopting a new technology but thinks that it will take too much time to finish, we try to break it up into smaller bite-size tasks. That way we can still make incremental shifts that integrate new technologies while minimizing the risk of any unforeseen errors or incompatibilities affecting he existing product. So far this has been working really well for us.

Yes! Actually, I have a story about that. We’ve always been using Vue and React, and I was asked to help bootstrap a new front-end project. I’ve been learning a lot myself about a new framework called Svelte that looked interesting. Starting a new project seemed like a good chance to try it out so I consulted with the team. After sharing why I thought it would be a good fit for the project, everyone agreed and we’re now using it successfully in this new project.

It depends on the individual but as a company there are systems in place like the Talent Mapping survey, which includes questions to help match your skills and interests with the best team. I know a back-end engineer who wanted to try a new opportunity and was able to move to a front-end team. If there are clear benefits for both the old and new team then it can be done.

I would have to say either spring or fall. The city becomes extra beautiful at those times with sakura cherry blossom and red leaves, and that’s when it’s not too hot and not too cold.

Well sometimes the menu says it’s spicy when it really isn’t so you have to know where to go. I guess readers will have to join, and then I’ll share the secrets!