Workplace reviews and discussion: 東森購物_電視購物_東森得易購股份有限公司

The following are my subjective impressions after one year here as a junior frontend engineer.

1. The e-commerce system is stable. The B2C frontend website is developed with React, and there are also internal projects using Vue. People familiar with both frontend technologies can be found within the company for discussion.

2. The members and managers of both the frontend and backend teams are nice. Colleagues also look after one another. When encountering problems or uncertainties during development, we can discuss them with each other. It is not a situation where everyone works independently without communicating. If you are willing to ask, you can receive plenty of feedback.

3. There is a weekly frontend meeting, and employees are also encouraged to give presentations and share knowledge.

4. If there is something you want to learn or optimize, it can be included as one of your quarterly individual RD goals and counted in your performance score. Even for passive employees, managers will push them to set goals, at least ensuring that team members continue to grow gradually. Note that you need to make use of the limited free time available to research improvements or prepare presentations.

5. Online revenue is growing.

6. The PO (PM) is friendly, and communication and discussion are possible. Everyone focuses on solving problems and sticks to the issues at hand.

7. Managers periodically meet with RD members in small meeting rooms to discuss and check on work conditions. Problems, suggestions, or other situations can be raised at an appropriate time.

8. The computers at the R&D center are ThinkPads. Their carbon-fiber bodies are lighter than Macs, and they are quite usable. The R&D center is currently split between two offices. RD members in the new office have height-adjustable desks, and the old office is also scheduled to move there in the second half of the year.

9. After all, this is a large company, so there are occasional departmental activities. You can also apply for company funding to purchase tickets for large conferences.

10. There are many opportunities for cross-departmental communication, and you can collaborate with different teams.

1. The schedule is tight, and development also involves refactoring old things. There is quite a bit of frontend legacy code, so it is easy to run into strange and difficult-to-modify code.

2. The company needs people who can contribute immediately, but certain tasks are overly focused on simply tightening screws. They are the kind that can make you ponder the meaning of life while doing them. I deeply felt that I was a small cog and code farmer in a large company. This team needs people who can immediately modify code and inventory the codebase, so if you encounter a genuinely new development requirement, make sure to seize the opportunity.

3. Following from the previous point, based on observing my colleagues' situation over the past year, basically taking on a new large-scale requirements project means working overtime. Handling projects from the parent group or other companies in the same group is reasonably part of the job, but new project assignments do not seem to offer any substantial incentives—apart from learning new technologies—to increase colleagues' willingness to step forward and take them on.

4. The previous agile implementation failed, leaving behind only some terminology (for example, PO here actually means PM). The current development model is Waterfall, so nearly all the various shortcomings encountered in the process are the shortcomings of the Waterfall model.

5. Even though the PO helps filter requests and directly face the requesting departments (other departments within the group), you know how large-company politics work. Although the PO assists with communication between departments, when there is an urgent request that really needs to be modified, RD and the PO still have to swallow their frustration and take on the sudden meteor. Most requirement changes are made simply because someone says to change them; only those that are not so urgent are merged into the requirements for the next release.

6. UI/web design does not belong to the R&D center, and even the office floor is different. Although communication software is available, this still creates significant communication costs. In theory, frontend engineers should interact closely with designers, so it is quite unfortunate that this situation exists.

7. Due to the characteristics of certain tasks, you may obediently complete and test them according to the requirements, only to discover after launch that specific situations produce different results. You only learn these hidden pieces of know-how and subtle details after encountering a pitfall and issuing a hotfix. Although it is true that problems should be solved when they arise, hotfixes compress the development time for that release cycle.

8. Browser support levels and features can be discussed with the PO, but the main workflow still has to support ... IE9 as much as possible.

Other:

All current frontend staff joined in 2018, making this a relatively new team. In the 2019 IT邦幫忙 Ironman competition, four of the seven frontend members participated, and everyone encouraged and challenged one another. However, there are many fragmented frontend tasks, with very different characteristics. Some tasks are interesting, and you can build requirements that are quite fun to work on :); other tasks are dull—so boring and mechanical that they wear down your enthusiasm :(

The pros and cons here are all within an acceptable range. Ultimately, I chose to resign simply to pursue better pay and a new environment and experience.

The company as a whole is not that bad. It is much better than some inexplicable outsourcing or gambling companies, and the Eslite Group's business and traffic have indeed grown over the past year.