In my previous post, I reviewed feature flagging and using Tailwind CSS. In this post, I continue my review of engineering management.

Measuring Cycle Time

Cycle time starts from the engineers move a ticket from To-Do to In Progress, and it ends at Done.

I review the average ticket cycle time every two weeks with my team. Jira Control Chart comes as a handy tool to measure cycle time.

When the average cycle time increases, it indicates our delivery speed slows down. The factors could be scope creep, too many WIP, big PR, etc.

When the average cycle time decreases, it indicates that we are doing well. We need to maintain the same practices.

We identify a couple of ways to shorten the cycle time and they make engineers’ life easier.

Reduce PR size. We observed our code review pattern. Team members tend to choose to review a smaller PR over a bigger one. If the PR is huge, the reviewers prefer to block off an hour or two from their calendar to perform the review. This delays the time to review. To deal with this, we split the feature into many smaller chunks to make the review process easier.

Pair code review. Sometimes, we discover new information during development and we change the implementation. In this case, the review is difficult. If this happens, the code author will set up a meeting with reviewers to walk through the code together. Reviewers will ask questions and the code author answers on the spot. This minimizes the back-and-forth conversations to clear things up.

Deploy more. Before, we performed deployment only if there was a hot-fix or urgent feature. If nothing urgent, the merged code will stale for a while before going into production. Now, we deploy every day. We intend to get the task out of our heads and focus on the next feature.

Regular 1-on-1

“I work with my direct report every day. We don’t need any 1-on-1 session.”

I have a misconception in 1-on-1 before. Now, regular 1-on-1 with direct reports is mandatory to me as a manager.

I run two types of 1-on-1 with my reports, monthly regular 1-on-1, and weekly engineering 1-on-1.

Monthly Regular 1-on-1. In this session, I concern about their personal and career growths. Instead of acting as a superior, I position myself as a career mentor. I often give advice based on their growth in general, not limited only to the current company.

Speaking to team members and motivating them as a recommendation from a friend, more so than an order from superior. I personally enjoy the refreshing discussions we have.

This is the feedback I received from my report. I am happy our 1-on-1s bringing value to her.

Weekly Engineering 1-on-1. I started this session as an experiment with one member. In this session, we exchange our thoughts in writing code and making technical decisions. As a result, we kick-started a side project to build a design system.

Writing RFCs

RFCs stands for Request For Comments.

For better or worse, Requests for Comments (RFCs) are how we specify many protocols on the Internet. — https://www.ietf.org/blog/how-read-rfc/

IETF (Internet Engineering Task Force) adopts some of the proposals published as RFCs as Internet Standards.

The OAuth 2.0 Standard is the creation of the process of RFCs.

Some large companies, such as Uber, use the RFC process to maintain their open source projects, BaseUI. You can read how it helps Uber to scale its engineering teams from Gergely Orosz’s post.

Our teams adopted this process based on similar reasons, such as information silos and too many meetings. Although, we don’t have a standard process and a task force to guardrail this process yet. But, I definitely feel that this is a necessary process for growing teams.

I’ve written a few RFCs. I started to write one when:

1. a change is affecting many systems
2. I have more than one approaches to solve the problem

Encourage collaboration between teams. When a change is affecting many systems, we write RFC and ask for feedbacks from affected teams.

Crowdsource solution. In the RFC review meetings, we accept the new ideas and improve the solutions.

Documented solution. Although I don’t write code often nowadays, from all the RFCs I’ve written, my team executed them well. I also indirectly influence the code.

Thank you for reading.

2020 Year In Review: Part 2 was originally published in Mindvalley Technology on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a Tech Lead in Mindvalley, I had an inspiring and productive year.

2020 allowed me to add several best 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

“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 had to double-check with other teams before deploying. We did this to prevent deploying any unstable functionalities. 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.

Personalized 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 significant impact feature, such as the feature that impacts the revenue.
• Have a fixed release date; you can make dark launch the feature ahead of 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
• During 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

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 regular CSS and Tailwind CSS. Using Tailwind CSS, the style is more comfortable to learn from the template file. Using it also reduces the engineer’s cognitive load, maintains 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 Continued

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

2020 Year In Review: Part 1 was originally published in Mindvalley Technology on Medium, where people are continuing the conversation by highlighting and responding to this story.

At the year 2018, I’d become a VP of Engineering in a small startup from a software engineer.

I’m writing this article to you who just started to lead an engineering team and you have no clue what to do and where to start. At the same time, I’m writing to myself.

As I was managing a 12-person engineering team, the advice in this article might not apply to the bigger team.

Clear communication

First and foremost, you are working with people, communication plays the most essential part.

To form a clear communication channel, you shall start documenting the conversation. When I say about documentation, it’s not recording every single word, instead, capturing the important information and actionable items.

At this stage, don’t worry about the format. Keep all the documents in one place and keep them updated. You’ll figure out the format in the future.

These are two good documents for a starter, product requirements document and meeting note.

Although it requires some portion of your time to write the document but the time you’ve spent is worthy.

Why product requirements document?

When the requirements are written down, it sets a clear expectation between stakeholders and engineers. It saves a ton of meeting to clarify the expected outcome.

Additionally, you can invite other teams or departments to contribute to the document. In this way, everyone will be on the same page.

Why meeting note?

The main purpose is reviewing the decisions that have been made and what has been done. Without it, you might let a certain amount of great ideas go into lost memory.

Effective and efficient workflow

Second, establish an effective and efficient workflow. Why bother mentioning effective and efficient here? I want to highlight that effective means it makes sense to the business or user and efficient means you can do it as least effort as possible.

Hereby, I recommend Gitflow which gives you a sense of the stage of the development and the control of the releases. Only the tested and verified pull requests will merge to the master branch and deploy it to the production.

Then, set up on-call rotation or dedicated role to provide technical support to the operation if necessary.

Mission statement

Third, mission statement. In the early stage, this is good to have. What’s the mission statement and why? The mission statement is one or two sentences summarise your team’s purposes and values.

Why this team exists? What does this team want to achieve? What values does this team hold?

Alright, why do you need this? A clear and strong mission statement gives your team a sense of belonging and responsibility. It tells everyone in the team how you treat each other, how you react to the problems and how you make decisions.

Fail fast. Fail again. Fail better.

Last, keep this in mind.

Try again. Fail again. Fail better. – Samuel Beckett

You won’t get everything right immediately. Keep improving. Furthermore, nowadays most of the information is right on your palm. Everything is happening lightning fast. “Try again” is not enough.

Fail fast. Fail again. Fail better. – Sky Chin

Whether you are running scrum or free flow with your team, I strongly suggest having a retrospective meeting. In this meeting, the simplest format is asking these few questions.

• What was going well last sprint/week?
• What was going wrong during the last sprint/weeks?
• What can be improved next sprint/week?

The retrospective meeting allows you and your team to allocate time to reflect on what’s working and what’s not. Continuous improvement is the air for growth.

Thank you for reading

If something works for you and your team but not appear in this article, please share it to me in the comment section below. I’m happy to learn from you.

Flutter is so easy to learn.

Flutter is the new mobile UI framework by Google for creating high-quality native experiences on iOS and Android. Yes, it’s cross-platform.

You can learn more about Flutter from here.

There is a significant difference between Flutter and React Native, which is you are writing UI code in an object-oriented way. IMO, Flutter is easy for native mobile developer or Backend developer. React Native is easy for a Frontend developer.

Writing a Hello World app is as simple as writing a Class.

class MyApp extends StatelessWidget {
    @override
    Widget build(BuildContext context) {
        return MaterialApp(
            title: 'Welcome to Flutter',
            theme: ThemeData(
                primaryColor: Colors.white,
                ),
            home: Scaffold(
                appBar: AppBar(
                    title: Text('Hello World App'),
                    ),
                body: HelloWorld()
                )
            );
    }
}

class HelloWorld extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Center(
      child: Text('Hello World')
    );
  }
}

In Flutter, everything is a widget, which is similar to the component in React Native.

HelloWorld class is a `StatelessWidget` that builds a `Text` widget on the centre of the screen.

MyApp class renders HelloWorld widget on the body with Material theme.

How about making a ListView?

class HelloWorldList extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return ListView.builder(
      itemBuilder: (BuildContext _context, int i) {
        return ListTile(
          title: Text('Hello World ' + i.toString()),
          trailing: Icon(Icons.android),
        );
      }
    );
  }
}

Simple, huh?

Flutter saves you tons of time from figuring out the right padding size and making sure the android icon sticks on the right of the list item.

So, Flutter is the best? It’s too soon to say that.

I spent 6 hours making a simple countdown app that can speak. Among the 6 hours, I spent 2 on learning the Flutter and writing the code. The other 4 were spending on updating XCode and solving the plugin compatibility issue.

First of all, I don’t think updating Xcode is a major issue. Unless you are the person like me who seldom write an iOS app and have a MacBook with 128GB HDD only (always running out of space).

The second problem is the plugin compatibility. I was installing this plugin, flutter_tts to implement the text to speech feature. I faced an error during the installation.

Unable to determine Swift version for the following pods

I’m not alone having the same problem.

The problem is solved by adding a few lines in the Podfile. I hope this solution helps you too.

target 'Runner' do
  use_frameworks! # <--- add this
  system('rm -rf .symlinks')
  system('mkdir -p .symlinks/plugins')

  ...
end

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['ENABLE_BITCODE'] = 'NO'
      config.build_settings['SWIFT_VERSION'] = '5.0' # <--- specify SWIFT_VERSION
      if target.name == 'flutter_tts' # <--- specify SWIFT_VERSION for plugin
        config.build_settings['SWIFT_VERSION'] = '4.0'
      end
    end
  end
end

If you are a plugin user, choosing and managing plugin is hard, especially when you are excited to upgrade your app to the newest version of Swift or Android.

If you are a plugin developer, maintaining plugin compatibility is hard, especially it is supporting Android and Swift at the same time, the effort is double. Sincerely appreciate for the plugin developers who diligently producing updates.

But, that shouldn’t stop us from creating great things. Let’s create a great ecosystem around Flutter.

This post is originally posted at my blog, www.skychin.me. Check it out here.

Back to development.

Lately, I was busy with management tasks. This week, I have the chance to contribute to our latest API project.

This is a very productive week. I managed to setup monorepo, practised TDD by writing unit testing and end-to-end testing, and learned to use mocking strategy in the testing.

Monorepo and Manyrepos are a very interesting topic. I figured them out while diving deep into how Taylor Otwell structured the Laravel’s code.

I’m writing about it, but I need some time because it is a big topic. Source code repository strategy is a very important decision to an engineering team. I’ll spend some time to explain it better.

Therefore, I want to share with you another thing I’ve learned in this week. Mocking in the unit test is a very useful strategy.

Mocking

Mocking is simulating the behaviour of a class or an object. You can define the expected value from a class.

If you have a Post model, which has a getContent method that returns the post content. The post content is a string containing HTML script like <p>, <div>, etc.

In the unit testing, you can mock a Post model and returns different post content to simulate different use cases. For example, you can mock the model to returns malicious script from getContent method and see how it breaks the application.

Simple example

$mock = \Mockery::mock(Post::class);

$mock->shouldReceive('getContent')->andReturn('<img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>');

$mock->getContent();
// returns '<img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>'

I know this can be done by inserting a row in the database.

Remember these two points.

• First, unit testings should be isolated and not involving the database. If you want to test with the database, you can write integration testing.
• Second, for a complex case like a series of actions/operations are needed to reproduce the steps, you can mock the object to behave as expected without going through all the steps.

In my case, I was creating a new API endpoint for Subscription services. This endpoint is returning a list of available subscription plans for a shop.

To list down the available subscription plans, there were few considerations.

1. Is the current shop has an active subscription?
2. Is the current shop eligible for upgrading to higher value plans?
3. Is the current shop eligible to extend the subscribed plan?

To test all the above, I need multiple shops with different subscription plans.

Let’s say I have three types of subscription plan, they are Trial, Limited, and Beginner.

Installation

The mock library I am using is Mockery.

composer require mockery/mockery --dev

Mock a class or object

In this example, I mock a Shop model and getActivePlans method is defined to return an empty Collection.

// This method mocks a Shop model which can be reused to simulate
// different subscriptions.
private function mockShop()
{
    $mock = \Mockery::mock(Shop::class);
    return $mock;
}

// This method mocks a Shop that subscribed to Limited plan. 
// No active plan means it is Limited.
private function mockShopWithLimitedPlan($countryCode = 'MY')
{
    $shop = $this->mockShop();
    $shop->shouldReceive('getActivePlans')
        ->andReturn(collect([]));
    return $shop;
}

Mock a collection

In this example, I mock a Shop model and getActivePlans method is defined to return a Collection that contains an active SubscriptionPlan.

// This method mocks a Shop that subscribed to Beginner plan
private function mockShopWithBeginnerPlan($countryCode = 'MY')
{
    $shop = $this->mockShop();

    // Mock a SubscriptionPlan which has a property named plan_code
    $beginnerPlan = \Mockery::mock(SubscriptionPlan::class);
    $beginnerPlan->shouldReceive('getAttribute')
        ->with('plan_code')
        ->andReturn('beginner_plan');

    // Create a collection
    $collection = new Collection();
    $collection->push($beginnerPlan);

    $shop->shouldReceive('getActivePlans')
        ->andReturn($collection);

    return $shop;
}

Otherwise, you can use the shorthand.

$shop->shouldReceive('getActivePlans')
        ->andReturn(collect([$beginnerPlan]));

Have fun mocking!

This post is also posted on my blog. You can read it at http://www.skychin.me/posts/2019-03-05/mocking-is-not-making-fun-of-the-class-or-object/.

In a few years back, your parents want you to find a full-time position in a good company, your friends tell you freelancing can receive a good pay.

People talk about full-time position gives you job security, freelancing gives you freedom.

In my opinion, they both have their own challenges and downsides. No clear winner.

In the recent years, remote position is growing rapidly and becoming trendy. Working remotely gives you the job security and the freedom at the same time.

Well, I know this statistics is dull and boring.

However, I find it interesting when I realise that choosing between full-time, freelance, and remote positions are like choosing job classes in the RPG game.

Do you play RPG game, don’t you?

Job classes in real life vs job classes in RPG game

The full-time developer is a crusader.

Crusaders are the protectors of the kingdom. Their missions are to protect the king (CEO or boss), the kingdom (company), and the people (customers) from the threat.

The freelance developer is a bounty hunter.

Bounty hunters are the survivors. Their missions are to survive as long as they can (more projects) and collect as much reward as possible (higher pays) by themselves.

The remote developer is a wizard.

Wizards are the adventurers. They share the same missions as crusaders, the only difference is they do it without being seen.

The decision making

In a different job class, the decision making is different.

Let’s say they have a mission which writing a new feature.

Crusaders and wizards will focus on the long run. They don’t protect the kingdom for one or two months only.

Full time and remote developers will consider:

• How can I make this feature scalable, so that we can add new capabilities easily next time?
• How can I make this code more readable, so that other team members can understand?

Bounty hunters will focus on the speed and the accuracy.

Freelance developers will consider:

• How can I complete the project on time or earlier?
• How can I fulfil the requirements?

The growth

When you become a full-time (crusader) developer, you can grow into a very skilful and collaborative developer.

You have the opportunity to learn from your peers or seniors and your career path is clear. In this position, your growth is easier and quicker than the freelancer.

When you become a freelance (bounty hunter) developer, you can grow into a very independent and well-rounded developer.

You have the advantage to learn from pitching a project, negotiating the deal, to delivering the project.

IMHO, you are more competent in this position comparing to full-timer. The reason is most of the full-timers are too dependent on the guidance from the peers. You need to learn to solve the problem on your own.

When you become a remote developer (wizard), you can be more independent (as a freelance developer), and more collaborative (you have a team), and your career path is clearer.

The tradeoff is you are far away from your peers. The communication is the greatest challenge.

Who are you?

Are you a crusader, bounty hunter, or wizard? Perhaps, you are a crusader at daytime and a bounty hunter at night?

This article is originally posted at TribeHired. If looking for a freelance job in Malaysia - visit tribehired.com

Laravel’s Collection has many powerful methods that can help you to do the complex tasks.

Map method applies a callback function to each of the items in the collection. In the callback function, you can modify the item before returning it.

Here are three simple ways you can use the map method.

Given you have a collection of fruits.

$fruits = collect(['apple', 'orange', 'watermelon']);

You can transform the value in the collection.

You turn the fruits into big size.

$bigFruits = $fruits->map(function($fruit) {
    return strtoupper($fruit);
});

// ['APPLE', 'ORANGE', 'WATERMELON']

Besides, you can perform checking in the callback function.

You don’t like to eat the orange, so you replace it with the grape.

$noOrange = $bigFruits->map(function($fruit) {
    if ($fruit === 'ORANGE') {
        return 'GRAPE';
    }

    return $fruit;
});

// ['APPLE', 'GRAPE', 'WATERMELON']

Otherwise, you can modify the item. For example, modify the string collection into associative array collection.

You put the fruits into the basket in order.

$fruitBasket = $noOrange->map(function($fruit, $index) {
    return [
        'name' => $fruit,
        'seq' => $index + 1
    ];
});

// [['name': 'APPLE', 'seq' => 1], ['name': 'GRAPE', 'seq' => 2], ['name': 'WATERMELON', 'seq' => 3]]

This article was originally posted at TribeHired.