Last year, I added a few good practices and skills into my engineering and management toolbox. In this post, I review them and hope this post inspires you.

I break them down into three categories:

Engineering practices - practices we use to develop software
Engineering management - manage team and communication
Product management - manage communication and expectation

Short Introduction About Me

I joined the Mindvalley Tech team in October 2020. In the Tech team, we have four web teams, two mobile teams, and one data team. There is a total of 60 engineers and designers.

I lead a team of six full-stack engineers, a designer, and a product manager. My team handles the customer-facing web application and supports mobile applications with API.

Let's start with engineering practices.

Engineering Practices

In the year 2020, my team starts to feature flagging and using Tailwind CSS.

Feature Flagging

Photo by Gabriel on Unsplash

"Feature Toggling" is a set of patterns which can help a team to deliver new functionality to users rapidly but safely. — source

Feature Flagging (also known as Feature Toggling) is a powerful technique. Generally, you wrap a feature under a feature flag and turn it on to expose it to the users.

if flag_is_on do
    feature()
end

Feature flagging allows you to change the application's behavior in production without deployment. This practice isn't a silver bullet. It increases complexity but improves safety and productivity.

Complexity. Feature flagging increases code complexity. At one time, we have many versions of the UI living in the production code. To manage this complexity, we review the flags and clean up the codebase.

Safety. Deploy on Friday worries engineers because things usually break in the weekend. Feature flagging improves deployment safety. We are confident that Friday's deployment has a minimal impact on the application. We can choose to keep the flag off or on. We can turn it off if something breaks.

Productivity. When we are fearless, we move faster. Before feature flagging, we always have to double-check with other teams before deploying. This is to prevent deploying any unstable feature. But now, we deploy every day without breaking the application.

Besides safe deployment, feature flagging opens up a lot of new possibilities.

New Possibilities

Canary Launches. You can introduce a new feature to the users gradually.

A/B testing. Running experiments with the target user group. You can keep two different versions of a feature to see which version performs better.

Personalised features. We can assign users a role or level. The feature enables or disables based on role or level.

When to use it?

Building a major impact feature, such as the feature that impacts the revenue.
Have a fixed release date, you can dark launch the feature ahead of the schedule.
Turn things off as a kill switch. Lately, we migrated major systems to new cloud infrastructure. During the migration, we turn off the flag to stop communicating to the migrating system.

When not to use it?

Fixing a bug
Refactoring, unless refactoring for performance.
Working on a minor impact feature. You don't want to manage too many flags and reduce the works to deprecate the flags later.

Using Tailwind CSS

Photo by Paul Felberbauer on Unsplash

Using Tailwind CSS to style application UI offers more than technical benefits.

<!-- 
Normal CSS 
-->
<div class="events-page">
  <div class="limited-width-content">
    <div class="header">
      <h3 class="font-bold title">
        Events
      </h3>
    </div>

    <!-- Content -->
  </div>
</div>

<!-- 
Tailwind CSS
-->
<div class="container mx-auto">
  <div class="mt-6 text-warm-gray-600 xs_mt-9 md_mt-12">
    <h3 class="font-bold leading-10 text-warm-gray-650 text-3xl-1 xs_text-4xl-2 xs_tracking-normal md_text-5xl-2 md_tracking-tight">
      Events
    </h3>
  </div>

  <!-- Content -->
</div>

From the code snippet above, you can see the difference between normal CSS and Tailwind CSS. Using Tailwind CSS, the style is easier to learn from the template file. Using it also reduces the engineer's cognitive load, maintain consistency, and works well with the feature flag.

Reduces cognitive load. You don't need to remember the properties of custom CSS classes. By looking at the template file, you know the implemented styles.

Maintains consistency. Sometimes you have the same element style using across pages. You can avoid duplicating class names in many places.

Works well with the feature flag. Let's say you update the UI of the Events page. You add some top margin and set the background color to light gray and a feature flag guards the changes. You can see the different implementations below.

<!-- 
Normal CSS 
-->
<!-- if flag is on -->
<div class="events-page-v2"></div>
<!-- if flag is off -->
<div class="events-page"></div>

<!-- 
Tailwind CSS
-->
<!-- if flag is on -->
<div class="container mx-auto mt-6 bg-gray-50"></div>
<!-- if flag is off -->
<div class="container mx-auto"></div>

You can avoid creating more redundant CSS codes and it makes the maintenance easier.

To be continue

I'll review engineering management practices in the next post.

Sky Chin