Today, I asked my colleague Aashiq, “when was the last time you wrote CSS?”

Aashiq: “hmmm… its been a long while, I didn’t have to write; our visual components solved most of the problems!”

We have been building a framework to help our engineers deliver features faster without affecting the quality of the interface, we called it visual components. Visual components are simple React components which define color and structure of the app. Some people call it design systems or as ‘UI framework’, like Twitter Bootstrap. You may wonder why build a new framework when there are many popular frameworks available? When the product evolves, it creates patterns and behavior which developers have to replicate in every feature. This is grunt work and slows down development. Also, when the behaviors change, it becomes harder to update in multiple places across the app.

What are Design systems?

Design systems are like UI frameworks on steroids. Design system removes the cognitive load on the engineers to decide which class/style to use, it defines the building blocks of the application. It will ensure engineers don’t have to write styles while developing features.

A simple example would be, typography. There are multiple ways of styling a simple text with millions of color and size. Its impossible to make it consistent without a design system. Text component is one of the basic components of design system, with basic properties like size, color, and font weight.

Building a reusable visual component

Let’s look at a simple example of a title.

We can convert this to a reusable component.

This reusable component will provide flexibility to change the behavior of a component easily and also makes it easy for developers to use it. Whenever a new requirement comes with a new style for the title, all we have to do is to modify the corresponding component to achieve the behavior!

This Title component now takes a style as prop. The style prop adds a new class my-heading-style--primary, which you can use to style the component.

It’s important to not use props value which define the visual styles like blue, red, as these styles may change later. Instead, if you define the values as primary, secondary and where to use these components, we will be able to scale the use of the component. This also helps in self-documentation and it makes the engineer’s life easy!

Basic components of design systems are

• Text
  Handle all the typography and should be using it across the app.
• Space
  Handle spaces between the elements, vertical, horizontal or around.
• Color
  Handle color to text, icon, etc
• Button
• Form
• Grid

Check out a simple login page build using visual components https://codesandbox.io/s/zl18zy21kl

Things to keep in mind

• Design system is a collaboration between the designer and the developer. Issues will arise, when designers are not involved in the process of building design systems, right from the start. It’s important that designers and developers have a common understanding of components and props. The designer should be able to say “Use the Title with secondary style.”
• When developing a component you need to make sure you are not adding too many properties, adding too many properties will confuse the developers.
  Example, let’s say there is a Button with normal-casing, now there is one scenario where the Button should have upper-casing! Instead of creating a new prop called upperCase it should be treated as a new style, say style=primary-alt
• Design system should evolve over a period of time, it’s not something you build once and it works forever. It will evolve depending on technology, patterns, behavior, and use-cases of the product.
• Components should not have any business names. When a component is built with a business name, it becomes non-reusable.

Design systems fail when there are too many choices when developing a feature

I have created a boilerplate code with react, redux and design system, Hope it will be helpful

https://github.com/Anenth/react-redux-design-system-boilerplate

Building a UI framework with React! aka Design system was originally published in inside-recruiterbox on Medium, where people are continuing the conversation by highlighting and responding to this story.

React 16 upgrade overview:

• 46 Pull-request
• 450 commits
• 36000 line changes
• ~2 months(with feature development in parallel)

How we did it

1. Upgrade to v15.6.0 (we were using v15.4.0)
2. Remove usage of React.createClass
   We used the codemod to update all our files. The major friction here was the eslint issues on the our old files.
   Codemod https://github.com/reactjs/react-codemod#explanation-of-the-new-es2015-class-transform-with-property-initializers
3. Remove usage of React.PropTypes
   Codemod https://github.com/reactjs/react-codemod#react-proptypes-to-prop-types
4. Remove usage of react-addons-css-transition-group
   Due to discontinuing support for React Addons, we had to replace the usage with react-transition-group.
   https://reactjs.org/blog/2017/04/07/react-v15.5.0.html#discontinuing-support-for-react-addons
5. Remove usage of react-addons-test-utils
   We have ~2000 tests for our react code base.
   1) Replace import TestUtils from ‘react-addons-test-utils’; to import TestUtils from ‘react-dom/test-utils’;
   2) Replace import { createRenderer } from ‘react-addons-test-utils’; to import { createRenderer } from ‘react-test-renderer/shallow’;
   3) If you are using skin-deep or other libs using react-addons-test-utils, you need to ignore it by adding the webpack.IgnorePlugin(/ReactContext|react-addons-test-utils/)
   https://reactjs.org/blog/2017/04/07/react-v15.5.0.html#react-test-utils
6. Portal
   ReactDOM.unstable_renderSubtreeIntoContainer to ReactDOM.createPortal
7. Major Eslint error we had to fix.
   Ref string deprecations, replace all the ref string to functional refs
8. Upgrade supporting libraries
   a) skin-deep
   b) react-bootstrap
   c) react-bootstrap-table
   d) react-router 4 from beta

Issues we faced:

1. Portal

Events now bubble up to the parent component

Even though a portal can be anywhere in the DOM tree, it behaves like a normal React child in every other way. Features like context work exactly the same regardless of whether the child is a portal, as the portal still exists in the React tree regardless of position in the DOM tree. https://github.com/facebook/react/issues/11387

2. Change in behaviour of componentWillUnmount lifecycle method

When replacing <A /> with <B />, B.componentWillMount now always happens before A.componentWillUnmount. Previously, A.componentWillUnmount could have fired first in some cases.
https://reactjs.org/blog/2017/09/26/react-v16.0.html

What we love:

componentDidCatch: We love this api! When working with rich UI, interaction this api helps us to contain the error. https://reactjs.org/blog/2017/07/26/error-handling-in-react-16.html

What we learnt:

• Update the libraries to the latest version as soon as possible.
• Create a wrapper component for all the third-party libraries so that we can easily make modification at one place.

Challenges with React 16 upgrades was originally published in inside-recruiterbox on Medium, where people are continuing the conversation by highlighting and responding to this story.

In any case, as we added more and more features to the product, the total time to run our test suite kept growing. About 2 years ago, it became too difficult to run all tests in local. At the time, we setup a Jenkins based system with 4 slaves to parallelise tests across these machines. With time, we increased the number of slaves to about 10 and kept the time to run tests to ~20 minutes. We also upgraded this setup to have 2 parallel pipelines of 10 machines each to accommodate increasing number of developers and more code being developed. If more than 2 developers pushed their code at the same time, they would have to wait their turn to run their tests.

However, this setup was very wasteful because the load on the slaves was very spiky at specific times of the day. It was difficult to predict patterns in this and setting up auto-scaling required too much work. Since there were only 2 parallel pipelines to run our test suite, during peak loads, the queue to run tests was also becoming too big. Sometimes developers had to wait 4 hours to run their tests. This was unacceptable waste of developer time.

We came across CodeBuild when we were just considering moving to EC2 Container Service with auto scaling turned on. As you can imagine CodeBuild felt like a life saver. We can get almost infinite parallelisation (upto a safety limit we can choose). As more and more tests are added, we can increase the number of containers to keep the time to run tests constant and it can keep scaling to as many parallel pipelines as we want based on spiky loads or as we add more team members.

In summary, kudos to the AWS team for building an awesome service like CodeBuild.

Constant time CI with CodeBuild was originally published in inside-recruiterbox on Medium, where people are continuing the conversation by highlighting and responding to this story.

Empathy — the ability to understand and share the feelings of another.

We talk about empathy for colleagues. We talk about empathy for customers.

But empathy is hard.

Sometime we just forget.

I find it useful to use the following simple rules when I work and commit a work.

1. Understand how your work affects others directly.
2. Understand how your work affects others indirectly.

E.g.

You are not prepared with a pipeline of work for the engineers — Rahul has to cancel his vacation that he had planned 6 months back to ensure that the feature ships on time. Seth has to be ok with a suboptimal interaction for the user because there is less time to enhance the design.

You write buggy code — Smith in ops will be woken up with alarms. He has a 5 year old who wakes up at slight noise and take 3 hours to go back to sleep. Cathy will not be able to create the report that she has to submit to her director. She will have to skip her son’s game so that she can prepare it manually.

Just remember Rahul/Seth/Smith/Cathy when you work.

Empathy is f***ing hard was originally published in inside-recruiterbox on Medium, where people are continuing the conversation by highlighting and responding to this story.

When I started writing source code a few years back I had only one focus, get the shit done. After working on building multiple products and features, I realized there is more than getting it just to work and it’s more about how long it stays i.e maintainability. Being a front-end engineer, I have a great taste for user experience and I care a lot about the developer’s experience reading the source code I write, they should be able to understand code easily and should be able to add more functionality without my help.

Code is read more than it is written

There are 2 main things to take care while writing code.

• Source code should be like a story, anyone who reads it should understand how it flows.
• And well it should work.

Here are some of my tips for making source code live longer.

1. Small is the answer! Try to make all the logic into smaller logics. Small function means easier to understand and easier to write tests.
2. Follow Single responsibility principle, each function should handle only one task.
3. Source code should be a self-documented. When you write a complex piece of code, you might feels great but you are not really doing a great job, it will make the developers scared to touch this piece of code because they don’t understand what is going on inside and makes it difficult to maintain, so If the code explains itself then it will live longer.
4. Name your functions and variables well. Don’t worry about how long they are, it only improves the code readability and it shouldn’t affect performance because production javascript codes are usually minified.
5. Smaller commits with a good message will make sure why a particular functionality was done.

There is nothing as complex logic, It’s all about how you look at it.

Make source code live longer was originally published in inside-recruiterbox on Medium, where people are continuing the conversation by highlighting and responding to this story.

It isn’t Always Pretty.

It was a Friday morning, around 745am Eastern time. Fridays typically being our slower days, I had settled in with my breakfast and a glass of tea as I updated a few help articles. I began clicking through the system taking screenshots when I received a server error.

Around here we’re lucky — our team runs a tight ship, and things very rarely go down. I quickly alerted the technical team on our chat program, Slack (most of whom were home, as it was Friday night in India), and they jumped on the problem.

The thing is, this time it wasn’t a quick fix. It took them about 3.5 hours to find the problem, push a fix, and deploy it. In my tenure at Recruiterbox, this was the longest downtime we have had.

Obviously this post isn’t about the downtime directly, it’s about how we handled it on Support.

A 3.5 hour downtime beginning at 745am Eastern managed to span the beginning of the work day for all of our continental US customers. Each time a new timezone came on board, we received another wave of messages. Having a set of messages to send at certain times helped us quickly get back to the customers. Below are the steps we took and the lessons we learned.

Step 1 — Update your status page

Our first step in a known downtime is to update our status page. This allows us to alert customers of the downtime. We also added it to the banner of the top of the site. For this downtime accessing the system was hit or miss — depending on which server you pinged. Because of this, the status message helped for some but not for others.

Step 2 — Prepare for the wave of messages

The next thing we did was log off of live chat. This was a spur of the moment decision, but we didn’t want to loose customers on live chat in mid conversation if they hit the down server. We also were receiving a large volume of emails — and wanted to reply to them quickly. Concentrating on just emails allowed us to hit the largest range of users at once.

Once the downtime was identified — we created a standard message to allow us to write back to customers who noted the outage quickly. Fast replies is something our team is known for already — but we felt during this time, the assurance that our team was looking at the issue was critical.

Thank you for reaching out to us — our apologies for the roadblock in your hiring workflow this morning!

Our team is aware of this issue, and are working on it as we speak.

We’ll be back in touch as soon as we know more! Appreciate your patience!

In our ticketing system (Frehsdesk) we also created a new status tag for these tickets, to make it easy to find them for follow up. I also created a note on my computer, to keep each ticket URL to double check that we got back to the customers.

Step 3 — If it has been more than 45 minutes, follow up again, and again, and again, until it’s over

Once the downtime had passed the 45 minute mark, we started writing again to those people who had been waiting more than 45 minutes. We wanted them to know we hadn’t forgotten about them and that we were still working on everything. We continued this (with variations to the message) until we were back up.

We wanted to give you a quick update -

Our team is still investigating the cause of the current application slowness and error messages. We are working hard to resolved this issue.

Our apologies for the continued delay in your workflow! We will be in touch as soon as we know more!

Step 4 — Follow up (again) once it is over (but not too eagerly)

Once the downtime was over, we made sure to tell everyone. I checked the list of tagged tickets, and my list I’d been keeping in my notes, multiple times to make sure every customer had been written back to.

We also included an apology for the delay to their workflow, and a thank you — for their patience during the event.

Especially with a downtime this long, it becomes easy to get super excited to give the all clear. Doing so falsely is even worse than waiting a bit longer. Make sure you’re 100% sure you’re back up before you send the all clear message.

Also be sure to return to your status page, and update it.

Thank you for your super awesome patience as we worked through a few different server issues this morning!

We apologize for any delay this caused to your Friday!

The system is back up and running! Our team will continue to monitor for any issues over the next few hours.

We hope you are headed towards a lovely weekend! Please reach out right away if you have any questions!

We also tagged these tickets for follow up the next day as well.

Step 5 — Follow up again the next day

Most of the customers who we wrote to with the “all clear” wrote back fairly quickly confirming everything was up and running. Any one we hadn’t heard from by the next day we wrote to again, just confirming all was okay. This may seem like an extra step, but we did find a few lingering bugs with this second follow up — things which we had assumed were related to the downtime, but were actually a different problem altogether.

I wanted to drop you a friendly followup — is everything running smoothly for you now?

Please feel free to reach out to us at any time!

Step 6 — Complete your Retrospective

After any type of an event a retrospective should be completed by all of those who were involved. This is used to explore the root cause of the issue, as well as how it can be handled better in the future. You should do this as soon as possible after the event, while it is fresh on everyone’s mind. Share the notes with everyone — even if they weren’t involved in the event.

Additional Thoughts and Lessons learned:

By the end of this downtime, we’d had almost 50 customers reach out, to which we sent a minimum of 3 messages (acknowledging the event, a(t least one) 45 minute follow up and an all clear (and potentially a next day follow up). Some customers also wrote back asking questions, which we did our best to answer — without making any promises.

We found the pace to be difficult but manageable with two of us answering the emails, tagging the tickets, and monitoring updates from the technical team.

At about 45 minutes after each hour the tickets would begin to slow — but they would quickly pick up again as another US timezone joined the mix. Once we anticipated this, the last two time zones were much easier.

Sure, it would have been simple to slap up an automated reply on the support email address (shudder) and call it a day, but not all of the messages we were getting were related to the downtime.

A few users could still access the system, and they had general, unrelated questions. We made sure to read messages carefully, and notice these — to avoid sending them the standard downtime message.

We also receive a number of emails every day that are not related to the use of the system, such as potential new clients. We made sure to not send them a downtime notice as well, of course.

Focus. Stop doing everything else.

With only two of us, the only way to manage the pace was by making emailed tickets our only activity. Everything else was stopped. I even told a teammate who started chatting us up about weekend plans to stop. We had one goal — get back to our customers with reassurance as quickly as possible.

We have a variety of ways to access client information, and we were using all of them during this downtime. It’s amazing how blind you suddenly feel when you can’t access the tools you use every single day. Make sure you have redundancies in place for accessing vital data points, and that you’re up to date on how to use them.

Lastly, take a deep breath, and don’t take it personally

When things don’t work, people are upset. This is a general understanding when working support — but especially so when when things go wrong. Sometimes people simply need a person to vent to — and — at this moment — you are this person. Take a deep breath. Put on your cheesiest smile, and be ready for a cold beer that night :)

How does your team handle downtimes?

I’d love to learn more from you!

Originally published at inside.recruiterbox.com on April 5, 2016.

Giving High Quality Support When Things Go Wrong. was originally published in inside-recruiterbox on Medium, where people are continuing the conversation by highlighting and responding to this story.

But really. We did. And I survived. Below are the thoughts that were running through my head on the flight home last April.

I am currently on the last leg of a 33 hour travel travel day, heading in the direction of home. 21 days ago I flew 8,797 miles to meet my India-based team members.

While there was a lot to learn going from small-town-USA (population 20 thousand) to Bangalore, India (population 4.3 million), once I got over the 100 degree heat and learned how to bob and weave while crossing the street, it was on to meet the India team.

Prior to this trip, I had never (in person) met another member of the Recruiterbox Team. Every second was exhilarating, awesome, exhausting, exciting and overwhelming — all rolled in to one.

Here are some of the top thoughts that stand out:

We’re all fighting the same fight.

Customer Happiness at Recruiterbox is just that — happiness. We get the amazing opportunity to make our customers happy — every single day. We also receive a unique look at our customer’s needs — we’re on the front lines fighting for what they need and want to make their hiring easier.

Unlike a lot of Customer Happiness roles, I always knew the other teams had our backs. Over the past few months we’ve tightened our connections with our Blackops team (which squashes bugs) and developed our Customer Delight team (their sole responsibility is to deliver small enhancements to delight our customers).

Even with these tight team connections, during my first week in office I found myself fascinated as I listened to conversations. Every conversation happening was about the exact things our customers are asking for, needing, or wanting.

I also had many long conversations with numerous teammates. We talked about why we joined, what we love about our jobs, and how excited we are for the future. Working for a company and with co-workers that are this aligned and this sure of its vision is incredibly exhilarating.

Seeing behind the curtain was exciting. If not a bit terrifying.

Working in a timezone opposite of our technical team, and remotely, most of the time system enhancements and fixes almost seem like magic. We report a request or a bug, and when we wake up the next morning — the fix is in place. Magic.

The first time something needed fixing while I was in office I was fascinated to watch the process of identification, debugging and fix-pushing in real time. For about the first 5 minutes. After that I decided I was perhaps more content just knowing in the end that all was okay, without seeing everything else in between.

There is some magic that’s better left unseen.

Spending some time in the office actually mattered

There were certainly moments before I left the comfort of my introverted work-from-home daily routine that I questioned why it was a good idea fly almost 9,000 miles to sit somewhere else and work for 3 weeks.

While I am the biggest remote work fan in the world, nothing can replace the deletion of timezones, being there to hear every day sidebar conversations, and forming the friendships that are created while sitting side by side one another.

In addition to crossing off a long to-do list that I’d accumulated over the months leading up to the trip, being in the office for the first time allowed me to observe and absorb the thought processes of different teams as they were happening — instead of simply digesting the end result of the conversations when a decision or change was deployed. Having this insight of how the teams work helps shape my interactions with them moving forward, even after I’m back home.

So, was it worth it?

One-Thousand percent. And that’s not just the jet-lag talking.

Being on site for a short stint helped me grow as a contributor to my team, and to my company. I formed relationships with my teammates, and ironed out processes to help us run more efficiently in the future. Totally worth it.

With that said, my sights are currently set on home, my familiar remote working routine, and daily temperatures hovering around 60 degrees F.

~ Chelsea — Recruiterbox Customer Happiness

P.S. Huge kudos to my US team members who held down the fort while I ventured away, and to the India team — for adopting me as one of their own during my stay!

Originally published at inside.recruiterbox.com on May 4, 2016.

An Introvert Experiment: What I learned when I met (some of) my team was originally published in inside-recruiterbox on Medium, where people are continuing the conversation by highlighting and responding to this story.

“But why? They are good. Try with Sambar. They will taste good” — Rajesh

“No. It is yuckyy.” — Titli

“Why?” — Rajesh

There are narratives in our head.

Idli is good. It is healthy. It is easy to make.

There are narratives in their head.

Idli is yuck.

​

There are more narratives in our head.

This place is awesome to work.

The product is useful.

Writing code in a certain way is important.

— — — — — — — — — — — -

It does not matter what our narrative is.

You cannot alter the other’s narrative by asking

“Why?” “What?”

The decisions of

Where to work?

What product to buy?

How to write code?

are based on their narratives.

They are as valid as yours.

Make your narrative strong.

So strong that they feel that it is their narrative.

Originally published at dino.xyz/Recruiterbox

Narratives are different — But was originally published in inside-recruiterbox on Medium, where people are continuing the conversation by highlighting and responding to this story.

“No” — Renuka

It is easy to explain away the deviation from the principles during difficult circumstances.

“I will skip the code review this time because …”

“I will respond to customer late because …”

“I will push my agenda this time because …”

“I will pay bribe to get this done this time because …”

“I will test this later at this time because …”

The “cause” may be genuine.

The deviation may be warranted.

​

But

Either you stand for a principle or you do not.

There is no “but this time”.

​

It is OK to decide that you do not agree or stand for a principle.

It is NOT ok to have deviations once you decide to stand for it.

That leads to

• Inconsistency
• Illusion
• Lie

above all — “Broken trust”

​

​

Originally published at dino.xyz/Recruiterbox

“But this time” — Is a dangerous spiral was originally published in inside-recruiterbox on Medium, where people are continuing the conversation by highlighting and responding to this story.

We typically present a list.

I am working on

1. Painting the car
2. Organizing the dashboard
3. Cleaning the boot
4. Changing the oil.

​

We do this is many places.

When asked — Why is your product better? — Out comes, a feature list.

When asked — What is the benefit of a process? — Out comes, a list of benefits.

When asked — How are you solving a problem? — Out comes, a list of items.

When asked — What does your NGO do? — Out comes, a list of activities.

​

The problem with lists are -

* They are hard to remember

* They are unexciting

* Hard to build on

* Very boring

​

It does not help that “To do” apps focus on lists.

It does not help that finally we have a bunch of activities to do.

​

Instead try to build and tell a story.

Stories excite everyone.

Stories are easy to present.

Stories are easy to remember.

​

“I will be driving to go on a cool trip — Visit places mentioned mentioned in this historical novel. So getting my car ready for it.”

​

We have been tuned (evolution) to relate to stories.

Remember

“My very educated mother just served us nine pizzas” (or some variation if it).

​

So when someone asks

“What do ..”?

​

Try starting with

“Once upon a time ..”

PS :

1. “Made to Stick” is a wonderful book that talks about messages that stick. Stories are a repeated them that come in that.
2. “Start with why” is another book that talks about conveying “Why?” being the core. “What?” and “How?” follow them.

Originally published at dino.xyz/Recruiterbox

Once upon a time … was originally published in inside-recruiterbox on Medium, where people are continuing the conversation by highlighting and responding to this story.