Working for Jkopay

Introduction

Last week, a LinkedIn notification suddenly popped up saying "OOO, liked your work anniversary". Reflecting on it, from starting to write my first piece of code to my one-year anniversary as an engineer, this journey has been filled with luck and maybe worth documenting.

If you haven't read my first post, you can check out My path to software engineering.

What I Learned This Year

As someone who only had experience with Toy Side Projects and had no clue about real software engineering and collaboration processes, I vividly remember my clueless self when I first joined the company. Although it seems I still am (?), the reality in a startup is that there isn't much time to nurture newbies. So, not long after joining, I began handling my first-ever project, which contributed significantly to my growth. I am thankful for this environment and the opportunity my manager gave me. Over the year, I handled four projects. Although they weren't large in scale, completing them within tight deadlines meant crazy overtime for someone as green as me, barely stopping short of sleeping in the office.

Here are some of the insights I've gained:

Technical Skills

UI Engineering

UI engineering was a major adaptation challenge for me when I first joined the company. Before then, I had no concept of component reuse or CSS-in-JS, nor was I aware of helpful tools like Storybook. I even panicked when I saw backend API return variable names different from what I expected in the component parameters, not knowing what to do. When I worked on Side Projects, it was all about coding and integrating by myself. I had no idea why I was there XD.

A year later, I participated in building a UI Library, growing it from about four or five common components to now over twenty. I learned that a useful component requires continuous communication with designers and is developed after getting the final design, made reusable and flexible, and then adjusted based on practical applications. When a page has similar UI components, we can simply import them from the UI Library, avoiding repetition and focusing more on code readability, maintainability, and performance.

React & Redux

Our projects primarily use React + Redux. Initially, I had no idea that multiple React.useEffect could be placed under the same component, nor did I understand what Custom Hooks were. I recall the development of my first project, where, clueless, I crammed everything into one file, ballooning it to over a thousand lines of UI and logic. This code was incinerated during a code review XD. I was asked to rewrite it all, dragging my manager into weekend overtime with me Q_Q.

A year later, I've gradually mastered various React APIs and started to consider optimization during development, pondering whether a piece of code is precious enough to wrap in React.useMemo or React.useCallback. I also learned how to handle complex and multi-page forms and form validation with React + Redux + Formik + Yup. My current refactoring project has taught me about the abstraction required in platform establishment.

Code Quality

In the past, as long as my code worked, it was good enough. I had no concept of Clean Code, making it painful to look back at my old code. It was full of side effects, naming, readability, and extensibility issues.

Now, I strive to write functions that are clear within 10 seconds during a code review. I apply Functional Programming concepts to reduce side effects and train my abstraction skills for better code reuse and extension.

I also introduced testing in some projects, practicing TDD and BDD. The benefits are thinking through product requirements and user flow before development and avoiding elementary bugs, thus bringing more confidence to the testing phase.

Product Development Process

For front-end development, any blocking from any team can delay the schedule. What to do when the development document is ready, but the design is not finalized, and the backend API is not yet available? The front end can't just wait for their completion; that would certainly cause delays.

For not yet finalized designs, we can start by creating all the page files and User Flow, quickly verifying with the PM and making rapid adjustments if necessary. If we have BDD tests, we can review the features with the PM and roughly implement the page layouts.

When the backend API isn't ready, we can discuss getting API documentation from the backend engineers first. Then, we can use Mock Service Worker (MSW) for API mocking, at least achieving CRUD mock, refining server responses, and simulating various error scenarios.

Usually, by the time these tasks are completed, the backend mock API and designs are almost ready for the front end, allowing us to quickly complete previously unforeseen functions and requirements and swiftly move to testing.

Communication Skills

Effective communication can reduce the gap between expectations among different teams. For example,

• How to negotiate sufficient development time with the PM and ensure the features
• Discussing the feasibility of a component design with designers and whether it achieves their envisioned look.
• Communicating API or Webview function integration with the backend or Mobile Team.
• Clearly reporting to the manager the progress of the projects I'm handling, solutions to issues, or decisions made after discussions.

Continuous communication and negotiation are necessary to achieve satisfying results for all parties. I'm still learning and hope to handle these issues effortlessly one day.

Conclusion

When I first joined the company, the Web Team was still in its infancy, just my manager and me. The development culture within the team was yet to be formed. Everything from project development to Nginx setup and project deployment was learned through hands-on experience. This process involved countless pitfalls and mistakes. Although the initial pressure was somewhat high, and there were hardly any days off, solving problems with my own hands brought an indescribable sense of achievement. I'm also grateful to my manager and colleagues from various teams, always willing to answer my basic and ignorant questions. Now, the Web Team has five members, each a master in their field!