---
title: Management is a skill, not a career
description:
published: 2025-01-12
tags: management, software leadership
image: capybara-darkmode.png
incomplete: true
---

Jogging down some thoughts on being a teamlead

## My teamlead experience: the glorified facilitator

- identified major timeing issues the moment I became the teamlead and communicated to the company
- Highly autonomous team, no need for micro management
- Mainly learn about the past present and future to help facilitate progress

## Being a teamlead is not about just saying "no"

- noticed a full team sitting in a corner of the office and looking all solemn
- found out they have to manually update some values which would take them a full afternoon to complete
- offer to help and delivered. delivered my own hack project as well
- saved CS and dev time of internal team, and user have a good experiences of viewing the map

## Being the beacon of light

- Things will feel dark and purposeless. Good teamlead can bring light to the direction where we should be going.
- align team member personal interest with the business

## Dream a little

- being teamlead is not just about delivering features

## Talk to people

- talk to customer
- talk to CS, marketing
- talk to internal teams

## References

### Mentors

- [Jere Suikkila](https://www.linkedin.com/in/jeresuikkila?miniProfileUrn=urn%3Ali%3Afs_miniProfile%3AACoAAAVvL10BbWWCx9r_qyHXs_wZ96nTw31vCiM&lipi=urn%3Ali%3Apage%3Ad_flagship3_search_srp_all%3BAQyYndjXQACdOEE6QqYqCQ%3D%3D)
- [Alan Rocha](https://www.linkedin.com/in/rochaallan?miniProfileUrn=urn%3Ali%3Afs_miniProfile%3AACoAAAQkKjIBeBP0s9-ovqBEn-188R1ljg2v17s&lipi=urn%3Ali%3Apage%3Ad_flagship3_search_srp_all%3BwYU8hy%2FgSRyXNRjRhUD13g%3D%3D)
- [Teddy Seyed](https://www.linkedin.com/in/teddyseyed?miniProfileUrn=urn%3Ali%3Afs_miniProfile%3AACoAAAtV_qcBLo_tDHnqhdUU3rmTTiREW_WLYfg&lipi=urn%3Ali%3Apage%3Ad_flagship3_search_srp_all%3BjYi39Am1TgCPsTwztkYtlw%3D%3D)


Management is a skill, not a career

---
title: Thoughts After Reading "Product-Minded Engineer"
description: Random thoughts after reading the book <Product-Minded Engineer>
published: 2024-08-23
tags: Product design, Engineering
---

## Thoughts on the Article

Not all engineers care about products, but I believe we should. Good engineers focus on:

- Designing the right thing.
- Being efficient.
- Building something people love.

The reason we're so concerned with performance and other technical details is because we want to create something great. However, the definition of "great" often differs between developers and product teams, and aligning these perspectives is crucial for building successful products.

So, why don't more developers lean into the product side? The disconnect often stems from:

- **Lack of Training:** Many developers simply don't know that understanding the product is an important part of their role. They're more exposed to code structure and optimization, which is why they have stronger opinions in those areas.
- **Difficulty Accessing Product Info:** It can be tedious or challenging to get the information needed to understand the product deeply.
- **Politics:** Leading a product direction can be complicated, especially if the company isn't set up to support it. In a well-run company, this is significantly easier, but in others, you'll feel the strain of trying to make a product-level impact while being judged primarily on code output.
- **Performance Metrics Not Tied to Product Impact:** If your environment values daily code output or bug fixes over product impact, it can be tough to lead in this area. You might have to work hard to educate others on the importance of a product-minded approach.
- **Team Culture & Peer Pressure:** Team culture is vital. If you're in a culture where the focus is on getting work done without considering the product, it can be frustrating to push for product-minded changes.

## Self Reflection

I'm proud that I've pushed for some features that resulted in a better, smoother user experience. My background in Human-Computer Interaction (HCI) has given me a strong appreciation for designing the "right" thing, even though I'm not a designer by trade. The effort is rewarding, even if the recognition is minimal.

I enjoy this aspect of my work, though it pushes me out of my comfort zone. Learning about the product has made me realize how much I still have to learn, even after being with the company for over six months. It also requires engaging with people I’m not familiar with, such as attending company events and joining discussions outside my immediate circle.

## What I Can Do More in My Career

Moving forward, I plan to allocate more time to understanding product direction and less to the technical nitty-gritty, as our development environment is now in a "good" place. Over the years, I've defaulted to:

- Improve job workspace overall
  - Performance improvements.
  - Developer experience (DX) improvements.
  - Refactoring
- "Shapen my 🪓"
  - Tinkering with my development setup during "free" time.
  - Learn more about the foundational technologies we use.
  - Learn more about new tools and technologies

Now, I want to focus more on:

- Learning about our products and contributing to their design.
- Joining more customer calls.
- Collaborating more with various teams to understand different perspectives.
- Learning how to use analytics data to inform product decisions.
- Picking up some design skills to better understand customer needs.

By shifting my focus, I hope to have a more significant impact on the products we build and ensure that they truly meet the needs of our users.

### Foreseeable Challenges

- **Time:** Finding the right balance between:

  - Completing challenging programming tasks.
  - Keeping up to date with the team in terms of software design and building rapport.
  - Managing board tickets and staying on track with due dates.

- **Remote Work:**
  - Mappedin is a remote-first company, but we have a few offices in Ontario where most people connect.
  - Not being in the office in person could significantly impact feeling like part of the team and being involved in product decisions or processes.

### How to Deal with These Challenges

- **Prioritize:** Focus on communication and delivery over developer experience (DX) improvements if the current setup is good enough.
- **Remote Work Issue:**
  - Make an extra effort to meet people in person when possible.
  - Be thorough with suggestions by backing them with data and prototypes—show, don’t just tell.


Random thoughts after reading the book <Product-Minded Engineer>

Thoughts After Reading "Product-Minded Engineer"

---
title: Building performant web visualization
description:
published: 2023-08-31
tags: performance, visualization, web development
---

Throughout my career, I've had the pleasure to be intimately involved in several web visualization projects. In the first couple years, I was directly using _canvas api_ to render 2D graphics based on realtime sensor data collected from devices such as MS kinect, Google Tango, and Wearable devices. After that, I was heavily involved in a 3D data visualization project using _Three.js_. where the data is already available. The trick is to figure out how to render out the large amount of geological/medical data in a way that makes sense to human. During the time, I was also involved in other couple 2D map visualization project with _d3.js_.

There are some tricks or principles I had picked up along the way, I thought worth mentioning for future reference.

## Start from understanding the users

## Thinking in frames

## Every pixel matters

The pixels that doesn't matter should not be in the rendering buffer.

## Call stack needs to be clean


Building performant web visualization

---
title: Process Driven vs Result Driven
description: Personal experience shifting between process driven and result driven programming mindset. How I approach finding the happy medium.
tags: Software Development, Programming mindset
published: 2023-08-30
image: capybara-digging.png
---

{% callout title="Takeaway" %}
Being fixated on results can lead to repetitive issue-solving, while an obsession with process can result in fear of missing out (FOMO) and detachment from the product. Achieving balance often entails making informed trade-offs based on experience.
{% /callout %}

## Being Result Driven

I pride myself being the person for building things quickly and efficiently. I was heavily `result driven`. Most of the projects assigned to me were either completely greenfield or brand-new initiatives. I thrived in this fast-paced environment, even working extra hours to maintain speed and efficiency. While this approach served me well initially, things changed when I transitioned to an existing project with an established architecture.

Eager and excited, I quickly learned the ropes, mastering the system and team dynamics. Before long, I became a productive member of the team. However, one day, I found myself fixing the same bug for the tenth time. Though I was fast, I realized that my speed was channeled into resolving the same issues repeatedly. It prompted me to question the effectiveness of my result-driven approach. "There has to be a better way to do this," I told myself.

{% callout title="Learnings" %}
Being focused on speedy and effective results is commendable but unsustainable if the architecture itself is flawed and requires improvement.
{% /callout %}

## Process Driven

That was the day I realized that being result-driven wasn't the end-all. Building quality software efficiently required more than just coding skills—it needed a well-thought-out process. I began seeking guidance from established architectures, design patterns, and successful case studies. My exploration led me to React & Redux and their underlying principles. I documented my learnings [here](/posts/redux)

The transition to a new architectural paradigm wasn't all sunshine and rainbows; it was both exhilarating and daunting. Nonetheless, the investment paid off. However, once the architecture was revamped, I found myself becoming too absorbed in the process. My focus shifted to constantly seeking improvements—better testing frameworks, more effective side-effect handling, superior build tools, and so on. In hindsight, I was somewhat distracted, perhaps due to a fear of missing out on some groundbreaking solution to problems we might encounter.

{% callout title="Learnings" %}
Continuous improvement is essential, but not every problem necessitates an architectural overhaul.
{% /callout %}

## The Balance

As I gained more experience and understood various frameworks and libraries, my approach evolved. For example, I realized that [React & Redux is not the solution for every frontend architectural problem](/post/eject_from_redux#general-issues-with-redux-library-and-react). My strategies for tackling intricate, high-performance applications became increasingly lightweight and custom. My guiding principles for finding the right balance include:

- **Apply the right tool for the right job.** Don't be afraid to experiment. You will make mistakes. Be brave to admit them, be ready to rectify them and move on.
- **Start small and add things if necessary.** There are less necessary tools than you might think.
- **Take control over the runtime.** Whether it's frontend or backend, it's crucial to understand every call stack. Be picky about what goes into it.
- **Learn the Basics, Dig Deeper.** A solid understanding of the underlying technology will empower you to make more informed decisions. Don't hesitate to dig a couple of layers deeper into the tech stack.
- **Prototype Real-World Scenarios** Build prototypes and analyze results carefully and safely.
- **Be prepared to discard inadequate solutions.** Some tools or methods may seem attractive due to flashy features or promises, but it's essential to consider their actual utility and effectiveness.
- **Document the journey and findings** Keep a record of what you’ve learned, what worked, and what didn’t. Documentation is a treasure trove for future problem-solving.
- **Influence the Team with Your Principles** Share these principles with your team to cultivate a collective approach to balancing speed and quality.
- **Talk Over Noodles 🍜** Sometimes, the best conversations and revelations happen informally. Treat your teammates to some pho or ramen as you discuss your findings and insights.

In summary, striking a balance between being result-driven and process-driven requires an adaptable mindset, bolstered by experience and ongoing learning.


Personal experience shifting between process driven and result driven programming mindset. How I approach finding the happy medium.

Process Driven vs Result Driven

---
title: Web app problem solving - darkmode
description: Adding darkmode to this website. Documenting the issues I tackled.
published: 2023-07-06
tags: darkmode, nextjs, tailwindcss
image: capybara-darkmode.png
---

{% callout type="caution" title="Note" %}
This post is curently published as _dev notes_ format. Will turn it into a proper blog post at somepoint. 🤞
{% /callout %}

It's good solve problems by understanding the nature of the problem before dive into the solutions. I've aware there are adequate darkmode solutions out there. However, it always helps to tackle the problem first. Let's start with requirement gathering.

## Requirements

- Functional requirements
  - darkmode decides whether the application renders the light or dark theme
  - allows configuration, preference should be stored and persisted
- UX & Technical requirements
  - Darkmode should behave expectedly as how OS handles darkmode
  - renders system preference by default

## Importance

Understanding the how important the problem is to solve helps laying down the scope and expectation of the result. The expectation consists of the following:

- Solving darkmode well lays ground work for future user preference handling
- Make the loading experience seamless. First 3 seconds is important.
- Learning how to handle darkmode helps with future development.

## Process

Adding darkmode is a fairly straightforward process, it can be summerized as:

- Enable user to set theme preference with `<ThemePrefToggleBtn />`
- Store theme preferencee with `useLocalStorage`
- Render out darkmode based on user preference

Let's have a look at how to add the toggle button.

### A darkmode toggle button

{% image
  src="/static/img/posts/darkmode-toggle.png"
  height=500
  /%}

The current iteration of the darkmode button was inspired by tailwind documentation. It's a single action button to toggle theme from `dark => light` and from `light => dark`.

The drawback of this design is it only supports toggling from between "always dark" and "always light". Once the toggle is clicked, there's no way to go back to "using system preference" option. A better approach would be having a dropdown where user can select all three options. This is documented at [future plans](/post/darkmode#future-plan)

### Storing theme preference

I ended up choosing `localStorage` to store the user preference theme state due to:

- theme data being small
- easy to build
- browser environment dependent: the look of the browser can affect user preference

Came across `useLocalStorage` hook to easily abstract storing and syncing logic. Checkout the hook [here](https://github.com/Yxwww/yuxi-site/blob/main/utils/hooks/useLocalStorage.ts)

To use it:

```typescript
export type ThemePreference = 'light' | 'dark' | 'none';
const [theme, setTheme] = useLocalStorage<ThemePreference>('theme', 'none');
```

## Fixing issues

Although, adding darkmode button is faily staright forward. Devil's always in the detail. There are two technical challanges stood out to me when adding darkmode:

- Hydration issue: server side rendering does not have access to local storage causes hydration mismatch
- Theme preference render happens later than expected which causes an uncomfortable flash.

### The hydration issue

The problem: hydration content mismatch due to state difference

Very standard hydration issue when the source of state is not stored on server. This happens to the theme button due to the icon rendering state is dependent on the theme state:

- theme state is stored on the client `localStorage`
- server doesn't have access to the theme state
- renders the content that does not match with client leads to hydration error

{% callout type="check" title="Solution" %}
`useMounted` solves "all" hydration issue.
{% /callout %}

Checkout `useMounted` [here](https://github.com/Yxwww/yuxi-site/blob/main/utils/hooks/useMounted.ts). This simple hook utilized the nature of useEffect. useEffect with empty `[]` dependencies only gets called by the client when the component gets mounted.

To use useMounted hook:

```typescript
function Component() {
  const mounted = useMounted();
  return mounted ? <>Only rendered by client.</> : null;
}
```

Using useMounted hook makes the <ThemeToggleButton /> only rendered by client. This avoids hydration issue all together. Now, let's have a looking at how to fix the flash issue.

### The flash issue

While addressing the requirements, I've noticed an issue when the page renders the theme preference stored in `localStorage` later than expected causes the app to render "incorrect" theme first before rendering the prefered theme.

Assessing the current design:

- webpage flashes the light theme before render the darktheme after page gets loaded
- source of truth of theme state is stored in `localStorage`
- theme toggle effect is handled by <ThemePrefToggleBtn /> component

{% callout type="note" title="Hypothesis" %}
.theme class gets rendered by <ThemePrevToggle /> too late
{% /callout %}

- Observation
  - throttle CPU speed to 4X in chrome performance tab
  - notice the flash comes from the light theme gets rendered first
  - `theme` css class gets rendered too late
  - assumption: the theme button gets rendered too late due to theme toggle button is too nested in the render tree
- Approach
  - lift up the theme state so the theme state gets resolved at the root
  - <ThemePrefToggleBtn /> only handles toggling

Prototype: lifting theme state into app root see if flash persists:

![Images](/static/img/posts/lift-theme-effect-up.png)

Result in flash disappear sooner! Yet, it is still obvious. Rerender is the issue, can we handle darkmode even earlier?

{% callout type="note" title="Hypothesis" %}
lift darkmode logic all the way to the top of render tree makes rerender not observable
{% /callout %}

![Images](/static/img/posts/tailwind-darkmode-logic.png)

- Observation:
  - tailwind has inline script tag handles darkmode
  - lifing darkmode all the way into script tag will do the trick
- Consideration
  - flash can still happen depends on how fast rerender can happen
- Approach:
  - use `_document` for prerendered darkmode script
  - tryout tailwind darkmode script
  - `useDarkMode` recommendation script see: [docs page](https://github.com/donavon/use-dark-mode#that-flash)

Result, flash is gone! It looks like the script gets executed synchronously which immediately adds `.dark` class into document. The document renders theme right after. This is good enough for now.

{% callout type="note" title="Hypothesis" %}
render darkmode on the server solves rerender issue completely
{% /callout %}

![Images](/static/img/posts/prerenders_dark_mode.png)

- Observation:
  - Looks like tailwind dark mode came with the http request
  - What's an effecient way to render darkmode in SSR/SSG?
- Consideration:
  - Landing page should be static instead of server rendered
  - Could fix hydration issue if done correctly

## Future plan

- use a dropdown <select /> component to support user to select "system preference state", "always light", and "always dark".
  - sync "prefer system theme" state with toggle UI
- if user select system preferences, app should detect theme change when system theme is changed
  - long polling, check system theme pref every 5 mins
  - check system pref on window focused
- checkout the last hypothesis: rendering darkmode on server approach
  - is there a request header you can specify user theme preference?
- checkout [shadcn](https://ui.shadcn.com/docs/dark-mode/next)

## Resources:

- [Github thread](https://github.com/vercel/next.js/discussions/21982)
- [tailwindcsss](https://tailwindcss.com)
- [useDarkMode hook doc](https://github.com/donavon/use-dark-mode#that-flash)


Adding darkmode to this website. Documenting the issues I tackled.

Web app problem solving - darkmode

---
title: Fast by Default ⚡️
description: Explore ways to develop frontend fast by default.
published: 2023-07-04
tags: Performance, Web Development, JavaScript
incomplete: true
image: capybara-jetpack.png
---

The goal is to reduce:

- unnecessary calls
- memory leak
- long running main thread procedures
- long GC calls

## Performance Foundamentals

Before we dive into various ways to improve the performance of the application, we should first establish some foundamental knowledge of the existing stack. Often times, we look elsewhere to find a solution we can add to our application and hope for a optimistic result. In reality, I've found most of the biggest performance gain is fixing or replacing something we've alreadiy have. The answer usually lies right in front of us.

{% callout %}
Take full control over the event loop.
{% /callout %}

- Minimize third party dependencies
- Understand exactly what's happening in CPU and memory at any given time and procedure
- Understand how event loop works such as microtask/macrotasks, frame, and timeout,
- Understand how to use browser dev tools. Such as CPU monitoring, memory monitoring, frame inspection

## Performance Improvement

Now, we've established a good understanding of what's happening at runtime. We can look for ways to improve our application foundamentally. Here's some simple ways to speed up our application or at least make it feels like the application is faster. Introducing `imaginaryUtilities`:

### Chunking down heavy work

Powerful utils enables processing large data by chunks asynchronously. Such as extends Array methods to process certain amount of array items per frame, so it doesn't introduce jank.

```javascript
const { filter } = imaginaryUtilities;

const filteredArr = filter(arr, (v) => v + 1, { chunkSize: 1000 });
```

### Parallel by default

Any non main-thread dependent operation should be delegated to web workers. For example:

```javascript
const { createWorkerUtil } = imaginaryUtilities;
const { filter } = createWorkerUtil();

const filteredArr = await filter(arr, (v) => v + 1); // not sure how to make this happen with worker ? Maybe some kind of eval ?
```

### All operations must be cancellable

Once the heavy work is chunked, the thread has room to breath in between heavy works. We can introduce mechanism such as cancellation.

- Any loops are built with a kill switch
- Extend Array methods to accept cancellation mechanism
- Any fetch (promise based async) procedures are design with `AbortSignal` handling

```javascript
const { createWorkerUtil } = imaginaryUtilities;
const { filter } = createWorkerUtil();

const controller = new AbortController();
const abortSignal = controller.signal;

const filteredArr = await filter(arr, (v) => v + 1, {
  abortSignal,
});

// anytime later
controller.abort();
```

### All creations must be destroyed

Any entity generated by the application, whether it's an element, event handler, state, or loaded data, must be properly disposed of when no longer needed.

- Release resource that's held by an entity (app, closure, promise).
- Release the reference to the entities themselves.
- Monitor memory see if it gets cleaned up.

```javascript
function createController(id, initialState) {
  const cachedListeners = [];
  return {
    getState,
    dispose() {
      cachedListeners.forEach((e) => {
        el.removeEventListener('click', e);
      });
      cachedListeners.length = 0;
    },
  };
}

let entity = createController();

// onDestroy
entity.dipose();
entity = null;
```


Explore ways to develop frontend fast by default.

Fast by Default ⚡️

---
title: Eject From React Redux with Grace
description: After using React and Redux for years, I want to take some time to reimagine web app developement with the learnings.
tags: Redux, React, Web Developemenmt
published: 2023-07-03
image: capybara-watch.png
incomplete: true
---

Although no tool is perfect, Redux [changed how I approach software development](/post/redux). Redux is designed with React ecosystem as its primary consumer. The three principles and concepts are powerful, and there are many ways to implement them? The way Redux approaches it is specifically tailored toward React. If you need to use Redux outside of React, you will need some kind of caching-capable adapter. Otherwise, there will be too much performance overhead.

{% callout %}
Though tools may adapt to circumstance, the essence of their purpose remains unaltered.
{% /callout %}

Instead of trying to make Redux work for various environments, we can adapt Redux principles and concepts to the new environment. But why do we want to bring Redux to a different environemnt in the first place ? Couldn't we just use React & Redux to build every single web app there is ? My answer to that is:

1. not all apps are built using React & Redux stack so learning how to adapt is important
2. React & Redux is not the best option for every application

Here are some issues I came across working with the stack:

## General issues with Redux library and React

Most complains I read about Redux is related to how much boilerplate code there is when programming Redux. I personally don't find that's an issue. Regardless if we are writing reducers, actions, or selectors, we are simply writing pure functions that can be easily composed. In fact, there are projects such as [redux toolkit](https://redux-toolkit.js.org/) aims to improve the quality of life when using Redux.

My concern with React Redux is:

{% callout type="warning" %}
React Redux ecosystem is not designed to allow maximum runtime performance.
{% /callout %}

Both technologies focus on building things `correctly`, but not building things run `fast`. While there can be an argument made that "if it's easier to built things right, then it's easier to make them fast". I agree with this notion. Being able to build things right is the must have. Although, depends on the type of application that's being developed, being able to build things that runs fast becomes a must have requirement as well. Many web apps now adays handles large amount of data while process many events and I/O at the same time. In my experience, if an architecture enables programming style to be slower here and there, then it will always add up which reduce the user experience and costs business unnecessary resources.

React developers come up with ways to make things `NOT slower than it should` using technology like memoization, [reselect](https://www.npmjs.com/package/reselect), and [virtual dom](https://www.npmjs.com/package/React-dom). Here are some pitfalls I've experienced while applying Redux concepts in a real world application:

### Issue with "single source of truth"

[Single source of truth with unidirectional data flow](</post/redux#single-source-of-truth-with-unidirectional-data-flow-(udf)>) is powerful for reasoning about state update; however, it leads to any state update will have to go through the entire store each time it updates.

- State update reaches every single reducer inorder to produce a new state
- Memoization to prevent the app from rerendering (selectors, v-dom, hooks)
- Unrelated functions gets called (including function components)
  - Developers hope they cache or memoize state object correctly to avoid a rerender.
  - Dealing with apps with large data, caching data alone can easily lead to memory overflow which easily blown up the browser tab

### Issue with "pure functions"

[Pure functions](/post/redux#pure-functions-with-kickass-compositions) does not make it easy to make the app performant.

- Mutation will always be faster than creating new data
- In-place operations is always more memory effecient; however, it goes against the whole point of writing pure functions.
- Fixated about writing pure functions may lead to heavy garbage collection (GC) work.
  - When the GC happens on the main thread, it will be very noticeable.

### Issue with "immutable data"

[Immutable data](/post/redux#readonly-state-with-immutable-data) is just a nightmare concept working with large data.

- Due to lack of native immutable data structure support in JS, we are using third party solutions
- Treating something immutable is way more effecient than actually making it immutable.
  - Even shallow clone can still be expensive depends on the data type
- Developer needs to know how to set purity boundary when working with large data set

If you've spent time working with React long enough, you will hear a lot about how to `prevent rerender`. The way to achieve it is not obvious. Working with React in combination with Redux does not make things easier either. To demonstrate this, please see the following example where I breakdown the architecture about what happens if there's state change:

### Example 1 - an architecture overview

Let's say we are building a color changer. There's a colorpicker that will update a square div `background-color`. You can play with the demo [here](/playground/colorchanger). The app looks like this:

{% image
  src="/static/img/posts/colorchanger-demo.png"
  height=500 /%}

Here is what happens (roughly) during runtime if the app is built using React Redux:

![Images](/static/img/posts/react-redux-dataflow.png)

As you can see, there's a lot going on to simply change a color of a box. In traditional programming, it should be simply handled in couple lines of code. Here is another example where React over renders.

### Example 2: everything gets rendered all the time

In react, any parents component rerenders, the child gets rerendered as well. Here is another example where we are building a simple form component:

```jsx
/**
 * When input changes list items rerenders
 */
function Form() {
  const [name, setName] = useState('');
  return (
    <form>
      <input
        value={name}
        onChange={(e) => {
          setName(e.target.value);
        }}
      />
      <UserName name={name} />
      <ListComponent list={someLargeArray} />
    </form>
  );
}

function UserName({ name }) {
  return <span>@{name}</span>;
}

function ListComponent({ list }) {
  return <table>{list.map(renderListItem)}</table>;
}
```

Can you believe that that `<ListComponent />` render function will always gets called on `<input />` change while having no direct connection between them. Even though virtual dom will eventually block rerendering to the dom nodes, we are still paying the CPU and memory costs for these unnecessary rerendering calls. What if the component render functions has expensive procedures. Memoize the heavy compute logic is required so that the application is not slowing down too much. The point is: any parent component causes all child component rerender by default is a design flaw. We have to worry about any component rerendering is cost on the developer and any machine the React engine runs on.

### Play the Cache game

The two example apps above demonstrate what I mean by React Redux stack is not designed for writing performant web apps. It's very easy to write correctly behaving yet "slow" applications. _Slow_ as in slower than it should be.

> Okay, this looks ridiculous. React Redux stack is overkill for such a simple application. But there is a reason it was designed this way so it can scale, I'm sure any modification of the current system is going to make it more difficult to scale right?

It's not necessary if we change how we apply Redux principle would make it way worse to maintain. I personally prefer to tackle a problem head on by exposing the problem and solve it from there. For example, if a codebase having problem with rendering performance, I'd wish I can directly look into the code where rendering happens and find out why instead of "playing a cache game". You see, one of the key knowledge to React performance is "managing when referencial equality check should pass". It's a bit overly counter intuitive imo. When we build applications, we just want to focus on building the app logic. Let's say, we are implementing the behavior where one element triggers the update of another. Instead of directly programming that procedure using handler and call an update function, we are playing this game around referencial equality to make sure the app is not too eager to rerender.

Then the question becomes: how can we design the app to be fast while adheres to React & Redux principles so that it can scale. It looks like it's time for us to do some soul searching. Let's unlearn what we have leanred.

## Unlearn what we have learned

[Redux principles and concepts transcends the library](</post/redux#single-source-of-truth-with-unidirectional-data-flow-(udf)>). I've had great success applying unidirectional data flow concept long before I started using Redux. This convinced me, we can apply the rest of the Redux concept to make our application more robust, easy to work with, and performant.

In that spirit, let's take an another look at [example 2 - the form element](/post/eject_from_redux#example-2:-everything-gets-rendered-all-the-time). Instead of wondering how to build a performant form in react, I'd sit back and ask: what's the most effecient way to build this regardless if you are using react? What do we know in terms of the underlying interactions:

- input changed
- `<UserName />` updates based on the name change

In plain HTML, this looks like:

```html
<script>
  function onInputChange(newName) {
    document.querySelector('#UserName')?.setText(newName);
  }
</script>

<form>
  <input on-change="onInputChange" />
  <span id="UserName"></span>
  <ul id="ListComponent">
    ...
  </ul>
</form>
```

Here you go, that's it. That's all there is. No rerendering from the `<ul>` component, we don't have to memoize anything. Something changed directly update the things needs to be updated. How come this is not the norm??

You might think it's unfair to use such a simple example. Which is kind of my point because it is supposed to be simple. However, to make React & Redux work exactly how the rawjs example works at run time, we are looking at:

- memoize the ListComponent, which memoizes the `list` prop
- shallow copy the `list` prop everytime we update even just one item from that array
- if the `list` prop is a large array, we can have two array exists at the same time in memory for referential equality

Even we do all that, virtual dom still needs resource for handling array rendering. In this experimentation, we ejected from the react ecosystem, we moved from using a `Framework` to directly dealing with `RawJS`. We are dealing with the lower level abstraction of the web app development:

{% image
  src="/static/img/posts/webapp-abstraction.png"
  height=300 /%}

A problem of this approach is of course it doesn't scale very well. We aren't thinking in components lifecycle, side effects management, or state management. Instead, we are thinking in managing and updating the dom nodes directly. We need to build some abstraction to allow us think app level instead of dom manipulation level. Before we move on I want to make the app more complete:

Now, let's add some more functions for a more feature complete demo

- input appends item to the list
- delete button for each list item

```html
<script>
  // handles when document ready
  const userNameInputEl = document.querySelector('#UserName');
  const listEl = document.querySelector('#ListComponent');

  userNameInputEl.addEventListener('keyboard', (e) => {
    if (isEnter(e)) {
      const newLi = document.createElement('li');
      newLi.innerText = e.target.value;
      listEl.appendChild(newLi);
    }
  });

  function onInputChange(newName) {
    userNameInputEl.setText(newName);
  }

  function onDeleteClicked(e) {
    e.target.remove();
  }
</script>

<form>
  <input on-change="onInputChange" />
  <span id="UserName"></span>
  <ul id="ListComponent">
    <li on-click="onDeleteClicked">...</li>
    
  </ul>
</form>
```

Now, the app is complete, we can do some refactoring to raise the abstraction level back to the application level.

{% callout type="check" title="Keep in mind!" %}
Any modification from this point forward can potentially slow down the app and not make the app better for the user.
{% /callout %}

## [Insert updated example followed with Redux principle]

### TO BE CONTINUED...

After using React and Redux for years, I want to take some time to reimagine web app developement with the learnings.

Eject From React Redux with Grace

---
title: My Programming Compendium ∞
description: Personal Collection of Programming Content such as books, videos, or podcasts.
published: 2023-06-06
tags: Programming, Talks, Presentations
image: compendium-pixel.png
---

## The Past Present & Future of JavaScript - Brendan Eich 2016

Podcast video: [https://www.youtube.com/watch?v=fg4e-2lBw5E](https://www.youtube.com/watch?v=fg4e-2lBw5E)

It was back in 2016, JavaScript air was the first podcast I ever listened to. At the time, full long Web application development was taking off. React wasn't everywhere yet. Most of the webapps are written in their own proprietary architecture powered by JQuery.
During that time, I was an aspiring web developer looking for some guidance in the web ecosystem.

## Embracing Algorithms (WWDC) - Dave Abrahams 2018

Talk video: [https://www.youtube.com/watch?v=ZSRHeXYDLko](https://www.youtube.com/watch?v=ZSRHeXYDLko)

## Preventing the Collapse of Civilization - Jonathan Blow 2019

Talk video: [https://www.youtube.com/watch?v=ZSRHeXYDLko](https://www.youtube.com/watch?v=ZSRHeXYDLko)

## Mostly Adequate Guide to Functional Programming -

You can read it for free: [Professor Frisby's Mostly Adequate Guide to Functional Programming](https://mostly-adequate.gitbook.io/mostly-adequate-guide/)

`To be continued ...`


Personal Collection of Programming Content such as books, videos, or podcasts.

My Programming Compendium ∞

---
title: What I Learned From Using Redux
description: Redux transformed the way I build applications. Here is what I learned after using it for several years.
tags: JavaScript, Redux, Learning
published: 2023-06-06
updated: 2023-07-09
image: capybara_wood_working.png
---

Alongside the Functional Programming (FP) Paradigm, Redux has significantly impacted my journey in programming. Around the year 2016, I was searching for an architecture to build web applications. React wasn't widely adopted at the time and its main focus was on building components and rendering. I was seeking an architecture that could effectively manage the state of an application.

The primary challenge I faced was scaling a startup's frontend stack. I had issues maintaining and reasoning about the data flow and the state of the existing stack. After reviewing a bunch of Object-Oriented design patterns, none of the design patterns resonated with me as they all felt anecdotal. That's when I discovered Redux.

The last time I delved into anything closely resembling FP was during a university course on Programming Paradigms, where I learned and came to appreciate Haskell. It felt mathematical and unfamiliar compared to Java or Python. Having only written Java, Haskell was not the most intuitive language to grasp, but you can't argue with the results it produces. The learning curve is steep when getting started; however, the difficulty of maintenance scales better.

The FP flavor in Redux reminded me of Haskell. I was eager to put Redux to the test. Using an FP approach in solving a real-world problem was exciting. Going from prototype to production, following Redux principles and concepts has led us to great successes:

- Reduced the amount of time spent on maintaining code and building new features
- The state of the application is much easier to reason about directly led to deterministic application behavior
- Established architecture standard. Having a structure is always better than not having one.

## The principles, the challenges, and how to get there

The best thing about learning Redux is grasping its principles and concepts that come with it. I've applied Redux concepts to solve various programming problems in different environments. Like any other technologies, knowing how to apply the concepts into an application stack effectively remains challenging.

### Single source of truth with unidirectional data flow (UDF)

You know that joy of revelation when something has been working for you, though you haven't fully acknowledged its existence. Then, someone else names it, and you're like "AHA! That's what it is!!". Throughout my career, I've maintained several complex systems. I found success in unknowingly applying the UDF concept to solve problems after many failed attempts.

![realtime application data flow](/static/img/posts/realtime-application-data-flow.png)

Challenges to consider:

- It's easy to lose track of what the source of truth is.
- Effectively and properly synchronizing state.
- Communicating the state of the application to the user.

How to migrate to using pure functions:

...

### Pure functions with kickass compositions

Functions are like vessels and organs carries and process "blood" in your system - Event data, state data or network data. Foundational functions such as `pipe`/`compose` and `curry`/`partial` opens up foundamental ways to compose functions, much like body's circulatory system.
Once accustomed to using pure functions, it opens up many possibilities such as memoization, easier to test, easier to share the logic even between threads, and easier to compose. You can harness the power of [ramdajs](https://ramdajs.com/). This library brings in rich suite of capabilities to your programming toolbox.

Challenges to consider:

- Most of the business logic can be implemented as pure functions.
- Use FP techniques for composition.
- Handle side effects at the edge.

How to migrate to using pure functions:

- seperate the state update computation from the side effects
- parameterize any data that's not created by the function
- try out utility funcitons like `curry` `compose` ;P

Once you dicipline yourself to write pure functions, the functions become idempotent:

```javascript
var a = subtract(2, 1);
// is the same as
var a = 2 - 1;
// is the same as
var a = 1;
```

It makes your functions more trustworthy. You can trust that under any circumstances, your code will always produce the same output given the same input. There's no hidden state.

### Readonly state with immutable data

Dealing with immutable data is not the most intuitive in JS due to there's no built in immutable data types. There are various solutions to enable developers to work with actual immutable data structures in JS; however, the cost of doing so is expensive and unnecessary. We can be trained and diciplined knowing when to meddle with the data structures.

Challenges to consider:

- Treating data as if it's immutable versus actually making it
- Mutate for performance if needed but maintain the immutability at the correct boundaries.
- Understand the performance trade-off and how to minimize its impact.

How to migrate to using immutable data:

- do not mutate any array or object data
- create new array when any update is needed
- cache against the referencial equality to check whether the array value is updated

## Conclusion

Redux has helped me immensely to develop reliable software. It makes the application much easier to reason about and easy to maintain. However, while beneficial, it's not without its limitations. No tool is perfect. While redux is powerful, I've documented my observations on its drawbacks on another blog [You may not need Redux](/post/you_may_not_need_redux), and discussed ways to leverage its power without having to pay the Redux tax.

{% callout %}
Checkout [this other blog](/post/eject_from_redux) where I discuss the issues using React Redux and eject from the ecosystem.
{% /callout %}


Redux transformed the way I build applications. Here is what I learned after using it for several years.

What I Learned From Using Redux

---
title: My Approach to the DRY Principle
description: Document my thougths on DRY principle and how I incorporate it
tags: DRY Principle, Abstraction, Product Driven Design
image: dry.png
published: 2023-05-25
updated: 2023-07-24
---

## Introduction

> Every piece of knowledge must have a single, unambiguous, authoritative representation within a system

This is the Don't Repeat Yourself (DRY) Principle highlighted in the book _The Pragmatic Programmer_. During development, the DRY principle is implemented through `abstraction`, in forms such as components, functions, or scripts. However, the process requires understanding of its nuances. Otherwise, you might run into the term I use to describe `Premature Abstraction`. Premature abstraction occurs when you abstract at the wrong place and the wrong time. To get it right, my strategy involves a blend of PDAD (Product Driven Architecture Design) principle, a term I use so 🐻 with me, and the WET(Write Everything Twice) principle.

The process includes:

1. Collaborating with product, UX and CS teams to devise sophisticated solutions to user problems.
2. Designing the tech architecture based on principles such as DRY, and appropriate design patterns, along with product requirements
3. Apply WET principle during development. Abstract when you are confident the abstraction will be reused.
4. Test solution and iterate with product, UX, and CS teams

## The challenge

Abstraction, while beneficial, often prompts discussion on its application scope. Developers frequently debate not just how to abstract, but what to abstract and when. From my experience, moving from eager abstraction to judicious use of the WET principle made me realize the cost of abstraction.

Good abstraction can be refreshing and efficient, but it carries costs: it can separate logically connected parts of the program, demands careful design, and requires naming and placement, increasing the cost.

It's essential to avoid pitfalls such as immediate abstraction at the sight of repetition, abstracting without considering the product roadmap, or abstracting merely for the sake of it.

## What worked for me 🔧

{% callout %}
Let's make it work, then we make it better!
{% /callout %}

My advice is to make it work first, then make it better! This approach depends on understanding the product's future, not afraid to write things more than once, and learning from battle-tested solutions. The optimal approach is different for different development purpose such as developing products vs developing tools

### Developing products - fluidity

When developing a product, generally we want to make things flexible. When we discover a user problem, we aim to solve that problem and provide value to our user. The process looks like:

`Ideation => User Study => Product Requirements => Architecture Design => Implementation => Test and Iteration`.

During the ideation and user study process, it's crucial to be involved to understand the problem that's being solved. Keep in mind, it's the problem we are focusing on, not the solution. Solutions can change and adapt, but the problem remains as long as it's relevant. Once I began collaborating, I quickly learned that a solution is very temporary. This mindset frees me from committing to a certain code structure. An nimble and scalable architecture is more desirable than a rigid structure promising infinite scalability. While abstraction makes code more defined and structured, over-abstraction makes it hard to change and adapt, which goes against the idea of exploration.

In addition, collaborating with various teams brings fresh perspectives to the problems we're trying to solve. Simply having a more comprehensive context enhances our understanding of the problem, allowing us to focus on the solution rather than getting lost in the fog of uncertainty.

With that being said, it's important to follow software design patterns and principles. Such as [Redux principles](/post/redux#the-principles,-the-challenges,-and-how-to-get-there), [React best practices](https://react.dev/learn/thinking-in-react), to build correctly behaving applications and go from there.

### Developing tools - less is more

When developing a library, we want to have full control of every single line of code. Tools such as libraries or frameworks is meant to be simple and reliable. You shouldn't do more or less than what its intended. In order to achieve that, we can limit third party dependencies and practice SOLID principle. SOLID principle is a principle, it can be used under any context regardless if you are using object-oriented programming flavour or functional programming flavour.

### Reusability & Readability

When following DRY principle, we abstract for reusability. Sometimes, we abstract for readability to make our code easier to read. Some of my preference:

- Minimize the nested scope. This includes callbacks, for loops, nested component.
- Use battle tested abstractions. see: JS standard methods, lodash, [talk: no raw loops](https://www.youtube.com/watch?v=W2tWOdzgXHA)
- Be mindful when physically splitting code such as seperate code into different files. Avoid splitting files unless it actually makes sense.

### WET programming - seperation of concern

Let's take a look at the following types:

```ts
interface PostContext {
  title: string;
  description: string;
  image: string;
  tags?: string[];
}
interface PageContext {
  title: string;
  description: string;
  image: string;
  tags?: string[];
}
```

Both `PostContext` and `PageContext` describes the same kind of metadata for a post or a page. If I was younger, I would've advocated for applying DRY principle to consolidate these two types into one since the the two types are structurally identical. Howeer, I have decided to let these two coexist for the time being. The reason is: firstly, it makes sense for the application to have both types, and each type has its own identity and meaning. PostContext is parsed from the post data of each blog. PageContext, however, is the metadata rendered out on the web page. Secondly:

{% callout %}
Duplication promotes seperation of concern.
{% /callout %}

When something is duplicated, we don't have to worry about whether modifications to one would impact the other. The mere fact that these two types appear identical does not mean they are the same. Utilizing duplication to ensure separation of concerns is a common approach. Here are a few examples:

- Webworker [clone](https://developer.mozilla.org/en-US/docs/Web/API/structuredClone) data when passing value to different threads for memory safety
- Redux uses [immutable data](/post/redux#readonly-state-with-immutable-data) to ensure each state update is pure "enough". To garantee each render is behaving correctly.

Back to our example, the more sophisticated refactor is:

```TS
interface Frontmatter {
  title: string;
  description: string;
  image: string;
  tags?: string[];
}

interface PostContext extends Frontmatter {}
interface PageContext extends Frontmatter {}
```

This approach keeps Page and Post contexts seperated while removes the duplication. It also enables the reuse of the Frontmatter.

## Conclusion

This is my approach to implement DRY principle during software architecture design. It involves collaborating with various stakeholders to understand the problem correctly. Contributing to the conversation to explore various ways to solve the problem. Applying various principles and tools to design the software architecture, then testing and iterating on the solution.

## Glossaries

- `CS`: customer success
- `UX`: user experience


Document my thougths on DRY principle and how I incorporate it

Blogs