DEV Community: Sam Sedighian

How and why we Bug Bash at LinkedIn and why you should too

Sam Sedighian — Wed, 26 May 2021 22:08:47 +0000

If you have been doing any kind of software development you are familiar with the bug bash concept in one way or another, even though you may call it something else. I want to share with you what I have learned doing bug bashes at LinkedIn for the past 2+ years and how it gives us confidence for releasing code at the scale of, well, the planet.

The what

Bug Bash is a cross-functional event for stress testing every bit of a new feature planned for external release. The format of this event is highly collaborative and async and with today's circumstances, fully virtual, however, it has always had an optional virtual attendance under regular business situations as well. Bug Bashes usually range somewhere between 1 to 2 hours in time and includes members from Marketing, Business Development, accessibility (a11y) as well as the usual suspects of Design, Product and, Engineering (perhaps also QA for some companies. At LinkedIn we do not have a dedicated team for QA as we all wear that hat).

The How

Preparation

Preparation is arguably the most important part of the bug bash. This is usually done by one person (or one per platform). A well-prepared bug bash is destined for success while a not-prepared bug bash is a recipe for wasting your colleague's time and a post launch failure.

The good thing is that preparation is not complicated and can even be done by the team intern. For the rest of this section let's say we came up with a new Navigation bar for LinkedIn. Make sure to send out the prep doc along with the event invite and for those taking part in the bug bash in an async manner a note on the deadline to file the bugs.

A Good bug bash doc should include the following:

POCs
Set up instructions
Test cases and Categories to cover
Bug reporting instructions
Resources - specs and anything else that may be required

Below is an example of such bug bash doc:

Sample Bug Bash document for the Navbar feature. https://docs.google.com/document/d/1ZT_W5wzdyP8xF16jMQL5FL1vuV85M6yeNbVOXmFqLPo/edit?usp=sharing

Bug Bash event

Make sure to send out the prepared doc for the bug bash at least 24 hours ahead of time, giving everyone ample time to set up and address any issue before the event so that you are not wasting time trying to debug individual issues.

At LinkedIn we like to start meeting with a success statement, so for example: "This meeting/bug-bash will be a success if we will be able to cover all test cases & categories mentioned in the preparation doc for all platforms"

[For Engineers] If possible avoid bug bashing your code as you might be so close to it that miss issues. Instead, focus your time bug bashing other's code or be the resource for others for the session.

Remember 1–2 hours is not enough time so you may need to divide and conquer. As long as you cover all categories and come up with solid documentation of the issues it is a success. Based on the scope of the bug bash and the number of issues found, you may have to set up another bug bash for a future time. There is no shame in multiple bug bashes, if anything it tells you that the bug bash was a success.

Post Bug bash

Remember the bug bash is async so they might be some more bugs trickling in after the event. With that said this is the time where the team huddles and assesses if they are aligned on the mission and vision and if so, given the level of feedback from the bug bash are they on track for the previously communicated release deadline and if need be, make appropriate adjustments and communications. This is the time to triage the tickets and start working on addressing all issues.

Finally, and perhaps optionally (depending on the scale of the feature) you may send out a follow-up communication on the bug bash event and the next steps to the stakeholders. As a bonus, this is the step that makes the difference between a good POC and a great one so don't skip this if you want to excel at your position. Do not forget to thank and give credit to all involved. Teamwork makes the dream work!

Feature Release

Bug Bash is not the ultimate bug-finding solution so as always ensure you are ramping the feature incrementally and measure and solicit feedback at every ramp stage.

What it means for Bug Bash to be async

Don't let someone's inability to attend the bug bash meeting be a deterrence of them being another set of eyes on the deliverable. If you have put the effort into the preparation step it should not cost you any additional effort to have the bug bash set up as an async event.

But what does it mean for the bug bash to be async? Async here means that those colleagues can contribute at their own pace or time given the same set of instructions and set up that was provided as part of the preparation. Just make sure to communicate a clear deadline on when to complete the bug bash by.

A11y

I am going to highlight this one piece just because it has traditionally been an afterthought when developing software. A11y for so many reasons that I will spare you why is not optional nor even a fast follow-up for any release. So please use bug bash as an opportunity to hash out any shortcomings with a11y and better yet next time if you have not done so in this cycle make sure to include a section in both Product and Design specs for a11y.

The Why

If you are reading this you are most likely familiar with the why so let me tell you why we at LinkedIn put a big emphasis on this. LinkedIn is a big company with very complex and interconnected pieces serving an even more diverse audience, it is practically impossible for any group of engineers (regardless of size) to be able to think of every use case and scenario not to mention the crazy big landscape of devices and operating systems and platforms. When we bug bash we have the opportunity to get fresh sets of eyes on our deliverable that were not there in the development process or perhaps not for the same platform (iOS vs. Android vs. web). Finally, my favorite is having those colleagues that just have different usability habits or requirements such as keyboard-only or screenreader requirements (or any assistive technology for that matter).

What bug bash is not…

For all its usefulness bug bash is not the right venue for a few things. For example, bug bash is not the place to question the overall objective of the feature or the product. It is completely valid to ask the question of whether or not the deliverable is aligned with the vision of the product and the mission of the company but it is not the right venue to question the vision and the mission. Also, a bug bash is not the right venue to exert your personal preferences, ideally and hopefully at a time much before the bug bash those feedbacks are solicited and taken into account, however, and regardless, at this point, the idea is to release to a wider audience of internal or external users for implicit and explicit feedback. Finally and perhaps most importantly, bug bash is not the venue to point fingers at any one person or group for a mistake or to try and figure out the how and who for addressing the issues that surfaced.

I want to end this post with my gratitude to you for taking the time to read my thoughts. I also want to express my desire that we in the software development community have an opportunity and responsibility to make the web a more inclusive, safe, and accessible place for all.

Keep on coding!! ❤️ 💻

Opinions are my own and not the views of LinkedIn. Examples in this blog post are just that, examples, and are not based on any actual works at LinkedIn or by any of its employees (including yours truly)

Everything you need to know about NaN in JavaScript

Sam Sedighian — Fri, 28 Feb 2020 16:31:54 +0000

NaN is a global property that represents the value of Not-A-Number, hence the name. It is possible to get the value NaN returned when doing an arithmetic operation or coercing some value to a number. Here are some operations that result in NaN

0 / 0; // NaN
Infinity / Infinity; // NaN
1 / undefined; // NaN
undefined / 1; // NaN

// [almost] all arithmetic operation involving NaN

NaN + 1; // NaN
NaN - 1; // NaN
NaN * 1; // NaN
NaN / 1; // NaN
NaN ** 1; // NaN
NaN % 1; // NaN
// with the exception of
NaN ** 0; // 1

// Finally, coercing any value that does not have a numeric value

parseInt('hi', 10); // NaN
parseFloat(undefined); // NaN
+"hi"; // NaN
Number({}); // NaN
"hi" - 1; // NaN
"hi" * 1; // NaN
"hi" / 1; // NaN
"hi" % 1; // NaN
"hi" ** 1; // NaN

it is worth mentioning that most of the confusion about NaN comes from the behavior of coercing a non-numeric-value to a numeric-value which results in NaN. For this reason, I recommend getting yourself familiarized with the last few examples from the code above and better yet why some values such as booleans, [1] and '' do not result in NaN

Interesting facts about `NaN`

NaN has a bad reputation for being tricky, however, if you familiarize yourself with the following few facts you will be able to work with NaN with no issue.

NaN unlike it's name is actually from the type Number

typeof NaN; // 'number'

NaN Has a falsy value

Boolean(NaN); // false

NaN is the only value in JavaScript that does not equal itself. Hint: this will become useful later on.

NaN === NaN; // false
NaN == NaN; // false
NaN !== NaN; // true

// No, it is not pointing to a differnt NaN object (no such thing)
const iAmNaN = NaN;
iAmNaN == iAmNaN; //false

You can access NaN in four different ways.

NaN;
this.NaN;
globalThis.NaN;
Number.NaN

Avoid comparisons with NaN

NaN > 0; // false
NaN >= 0; // false
NaN < 0; // false

Let's look at an example

Let's say we have a function that takes one argument and increments it by 10 . We want to accept both numbers and strings representing a number so we will use parseFloat

const incrementByTen = function(val) {
  const n = parseFloat(val, 10);
  return n + 10;
};

incrementByTen(0); // 10 ✅
incrementByTen('2.3'); // 12.3 ✅

/*
  result of parseFloat will be NaN in examples below
  hence the addition operations will also return NaN
*/
incrementByTen(NaN); // NaN ❌
incrementByTen(false); // NaN ❌
incrementByTen({}); // NaN ❌
incrementByTen([]); // NaN ❌
incrementByTen('a'); // NaN ❌
incrementByTen(true); // NaN ❌
incrementByTen(['a', 1]); // NaN ❌

We just learned there are plenty of arguments which would result in NaN. Perhaps a better way to handle this is to throw an error for those cases. However, as we learned earlier the usual comparisons will not work for NaN as we can see below. For this reason, we will use the global function isNaN.

typeof NaN === NaN; // false
NaN === NaN; // false

what is `isNaN` and how it works?

isNaN is a global function, takes a single argument and returns a boolean indicating whether or not the argument passed is NaN. MDN explains isNaN as such:

The function [ isNaN ] should be interpreted as answering the question, "is this value, when coerced to a numeric value, an IEEE-754 'Not A Number' value?"

We now write our function with isNaN to throw an error when the result of the parseFloat is NaN.

const incrementByTen = function(val) {
  const n = parseFloat(val, 10);
  if (isNaN(n)) {
    throw new Error('Resulted in NaN!');
  }
  return n + 10;
};

incrementByTen(0); // 10 ✅
incrementByTen('2.3'); // 12.3 ✅
incrementByTen(NaN); // Error: Resulted in NaN! ✅
incrementByTen(false); // Error: Resulted in NaN! ✅
incrementByTen({}); // Error: Resulted in NaN! ✅
incrementByTen([]); // Error: Resulted in NaN! ✅
incrementByTen('a'); // Error: Resulted in NaN! ✅
incrementByTen(true); // Error: Resulted in NaN! ✅
incrementByTen(['a', 1]); // Error: Resulted in NaN! ✅

Great, our function works as expected. Now let's learn a bit more about isNaN. Best way to understand how isNaN works is to create our own [basic version] polyfill for it. Polyfill is not required to use isNaN, It is super old...IE 3 old! 👴🏽

const isNaN = function(value) {
  // coercing it into a numeric value. BEWARE OF THIS LINE
  const n = Number(value);
  // now checking to see if it does not equal itself
  // only NaN does not equal itself 🤯
  return n !== n;
};

When working with isNaN you need to beware of the coercion of the value to a numeric-value. Remember some values cannot be coerced to a numeric-value and will result in NaN so even though your argument to isNaN might not have been NaN it could become one.

Here are a few examples where this happens and isNaN does not work as we perhaps expect it to:

isNaN(NaN); // true ✅

isNaN(undefined); // true ❌
isNaN('a'); // true ❌
isNaN({}); // true ❌
isNaN(['a']); // true ❌
isNaN(10n); // TypeError: Cannot convert a BigInt value to a number ❌
isNaN(Symbol()); // Uncaught TypeError: Cannot convert a Symbol value to a number ❌

`Number.isNaN` to the rescue 🦸🏻‍♀️

For the reasons that should be clear from above using isNaN is not ideal. This is why Number.isNaN has been added to JavaScript starting from ES6. The main difference between the two functions is that Number.isNaN does not convert its argument to a numeric-value before determining whether it is NaN.

Number.isNaN(NaN); // true ✅

Number.isNaN(undefined); // false ✅
Number.isNaN('a'); // false ✅
Number.isNaN({}); // false ✅
Number.isNaN(['a']); // false ✅
Number.isNaN(10n); // false ✅
Number.isNaN(Symbol()); // false ✅

Great, it is working as expected. I recommend to always use Number.isNaN. Even if you want to coerce the value to a numeric-value do it yourself and then use Number.isNaN that way you are clearly expressing your intentions.

// Bad
isNaN(someValue);

// Good
Number.isNaN(someValue)

// And if we do need someValue to be coerced to a numeric-value
const numericalValue = +someValue; // or Number(someValue)
Number.isNaN(numericalValue);

Alternatives to native `isNaN` and `Number.isNaN`

As you can imagine before Number.isNaN was introduced there were some workarounds for us to handle this which perhaps are no longer needed but worth noting.

Write your own

If you are not going to use Number.isNaN, this is perhaps the quickest and fastest way to get going. The key to understanding this function is that isNaN is the only value that does not equal itself.

const _isNaN = function(value) {
  return value !== value;
}

Lodash and Underscore

Both of these popular utility libraries have their own version of the functionality which works similar to Number.isNaN

import lodash from 'lodash';
import underscore from 'underscore';

lodash.isNaN();
underscore.isNaN();

Resources and citations

NaN
- MDN https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN
- ECMAScript Spec https://tc39.es/ecma262/#sec-value-properties-of-the-global-object-nan
isNaN
- MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/isNaN
- ECMAScript Spec https://tc39.es/ecma262/#sec-isnan-number
- Lodash https://lodash.com/docs/4.17.15#isNaN
- Underscore https://underscorejs.org/#isNaN
Number.isNaN
- MDN https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/isNaN
- ECMAScript Spec https://tc39.es/ecma262/#sec-number.isnan
Related topics
- freeCodeCamp: JavaScript type coercion explained https://www.freecodecamp.org/news/js-type-coercion-explained-27ba3d9a2839/
- SitePoint ES6 New Number Methods https://www.sitepoint.com/es6-number-methods/

Optional Chaining, Null Coalescing and how they will change the way you write code

Sam Sedighian — Wed, 15 Jan 2020 05:36:39 +0000

If you have been following the TypeScript releases recently you already know that in TypeScript 3.7 Optional Chaining and Nullish Coalescing were introduced. They are both part upcoming features of the JavaScript and as of the time of publishing this article, they are in stage 4 and stage 3 respectively.

UPDATED: As of Babel 7.8.0 These features are also included by default.

Optional Chaining

Quite often we find ourselves working deep into an object to get the value of a property and if you have written more than 100 lines of code in JavaScript you know that this is the root of a well common error Uncaught TypeError when not done right

We are going to use this mock response for the rest of the examples:

In order to avoid the common Uncaught TypeError and get the value of id from the response above, we need to do some dance in JavaScript. The way we approach this today is by checking the truthiness of the object at each depth as we work our way to id. This pattern looks more like a conditional statement that should result in a boolean rather than being a property accessor statement but it is, the cleanest and safest native way we have today.

Or if you prefer object destructuring:

Basically what is happening here is the code block on the left side of the && Logical and operator is being evaluated similar to Boolean(data) and if the value is true it moves to evaluate the right side.

There are more ergonomic ways of doing this if you use Lodash or Ember

So how do we do the same thing using the new Optional Chaining?

Null Coalescing

It is common practice to have a default value when the value of the property we access is null or undefined. Currently the common way to accomplish this is by using the || Logical or operator

If we are looking to get the Github username which is the login property and set a default to the current user's username, sedighian in this case, we will do so as below:

the second and third examples look very similar so why is Null Coalescing useful? Simply put Null Coalescing evaluates the right side of the ?? operator only if the result of the left side is undefined or null and this gives us some protection against unintended results when dealing with valid but falsy values in our data.

For example, in many cases, we wish to an empty string '' , false and 0 to the value returned rather than resulting in a falsy value and hence moving to evaluate the right side of the || Logical-or-operator. Now, we can use the Null Coalescing and we will not have these issues any longer as seen in the examples below:

For coming up with fallback/default values when accessing an object there are alternative ways in the form of third party libraries and in Ember's case a built-in utility.

Do not forget that Null Coalescing is for more than coming up with a default value to assign to a variable, it is a new alternative way to execute a code block given a null or undefined value. For example:

What to watch out for...

Order matters when using ? in Optional Chaining

Optional Chaining does not protect you against incorrectly invoking a non-function

Null Coalescing is not an apple to apple to lodash.get or EmberObject.getWithDefault. The main difference is in how Null Coalescing treats null vs. these two utilities.

Resources

TypeScript 3.7 release notes
Babel 7.8.0 Release notes
Optional Chaining for JavaScript Proposal
Nullish Coalescing for JavaScript Proposal
lodash.get
EmberObject.get
EmberObject.getWithDefault