Forem: Victor Cordova

Learn your codebase and be 10x more effective

Victor Cordova — Wed, 24 Jul 2024 10:04:46 +0000

As a software engineer, being an expert on your team's/company's codebase is amongst the most important skills you can have. Here's why:

Knowing your codebase lets you understand the costs and risks associated with any proposed changes. This means you can make more accurate estimates and prevent bugs. Also, you can help identify when's the right time to tackle some tech debt.

Becoming familiar with a codebase takes time, but here are some methods I've used to make this process much faster:

Keep a personal log: of important files, coding patterns, and gotchas. Build it as you learn more.
Speak to experts: First, conduct a preliminary review of the code to identify patterns and questions. Then book a few short calls with experts in your company. If you don't know who they are, ask your manager. Make sure to ask them to point out any important documentation related to the code
Use git smartly: Read through past pull requests and see what files needed to be changed together. Use git blame to see who wrote a particular line of code and reach out for additional context if possible. Use the git pickaxe to find when a particular line was added or removed.
Contribute to documentation: If you find something that you deem important, discuss it with your team. Consider adding code comments explaining the reason for some technical decisions or using a wiki to document these decisions.
Identify and read past RFCs, design docs and ADRs: Do this to understand why some decisions were made and what alternatives were considered.

Repeat as needed when you find a new part of the code you aren't familiar with.

Thank you for reading! ⭐

Also available on my personal blog https://www.victorandcode.com/learn-your-codebase-and-be-10-x-more-effective

12 Effective Writing Tips for Software Engineers

Victor Cordova — Wed, 25 Jan 2023 12:30:00 +0000

Originally posted in my personal blog

Excellent written communication skills are key to your software engineering career growth. It can help you deliver projects more successfully, create better relationships at work, grow faster as an engineer, and much more. The more senior the role, the more you're expected to communicate with other humans. This article summarizes some lessons I've learned about communicating more efficiently in the context of software development.

Scope 📒

This article is mostly about written communication for software engineers but it'll probably also be helpful for other roles working in the software development lifecycle.

What is effective communication 🤷

First, let's define what I call "ineffective communication." It's an exchange of messages which has one or many of these characteristics:

Slow
Frustrating
Causes misunderstandings
Consecutively makes people lose time and money

By contrast, for the purpose of this article, effective communication leads to fast and empathetic resolution of problems and the exchange of ideas with a minimum number of misunderstandings.

List of communication tips ✍️

Know your audience: Before you send any message, ask the following. What's their role? What knowledge do they have in the topic you're about to discuss? What timezone are they in? All of this will help guide how technical your vocabulary will be. It's very different to say, "Our server's overloaded with requests, and we're working to fix the load balancer," than saying, "We're having some issues with our servers but are working on it."

Have the key decision-makers in the conversation: If you don't, you might not receive essential feedback or need to backtrack on the decision afterward. Make sure to involve the right people but not anyone else.

Be action-oriented, and propose solutions: Avoid conversations of the type: - Hey everyone, did you see we have this problem - Yup, we have a problem - The end

Think about what follow-up questions the other person will ask: Try to answer them in advance, so the number of messages in the exchange is minimized.

Use as few words as possible: If your message is short, more people will read it, it'll avoid confusion and it'll take less time to make a decision. So, before sending your message, review it. Delete as many words as you can to keep the core message and avoid any fluf

Clearly state urgency and next steps: Say, if your question is urgent, what's the impact? Is it blocking anyone?

Enumerate questions : For multiple questions, it's easier to enumerate them so you can refer back to them and allow the other person to answer one by one.

If there's room for interpretation clarify! : Believe it or not, a lot of times, small assumptions or misunderstandings will be highly costly. If there's something with some room for interpretation or too vague, get to the details. The simplest way of doing this is to ask, "So when you say [insert original part of their message], you mean [shorter paraphrased version]?"

Know when to change to videocall (or IRL conversation) : Remember, written communication has limits. If the conversation is taking too long or you need to discuss live changes, you might be better off having a call

Think of solutions: Lead the conversation by saying "We have this problem, and I've thought about some implications, so I think we have these options enumerate options. What do you think?". Sooner or later, you'll be the person to whom people come for answers.

Be kind : You're (probably) talking to a person. Don't demand things; ask nicely. Say hi, and present yourself if you're talking to someone for the first time; you don't have to send your whole life's story, just a simple "Hey name, I'm an engineer at team investigating an issue related to invoicing, I could really use your help with the following...".

Respect people's attention: Messaging apps are built to distract people, so be mindful and don't @ everyone, don't @ after working hours.

Closing thoughts

Thanks for reading this far. I hope one or many of these tips are as helpful to you as they have been to me.
Again, communication is complex, but being a bit more thoughtful about what we write can go a long way.

Understanding software estimates and how to get better at making them

Victor Cordova — Sat, 19 Sep 2020 12:52:41 +0000

The first time you finish a piece of software you've estimated, you discover a harsh reality ... software estimates are hard. Unexpected edge-cases, dependencies, meetings, and a thousand other things. This law summarizes it perfectly:

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

My objective with this post is to provide you with a framework to help you understand and create better software estimates, which will allow you to reduce risk in your projects and align expectations with other stakeholders.

What is a software estimate 🤷

A software estimate predicts how much effort is necessary to create, modify, or maintain software. You give estimates in some unit, which in my experience is usually man-hours and story points.

An estimate does NOT imply a commitment. It represents the most well-informed guess you can make with the given restrictions of time and knowledge. This difference is often overlooked and can be the source of conflict and frustration. This doesn't mean you should not commit; it means you should treat estimation and commitment separately. As a professional, you should make a commitment when needed after carefully evaluating the situation, and preparing an estimate. But, you should also say NO when pressured to commit to work that isn't adequately estimated.

Who needs estimates and why 📅

It is crucial to understand how estimates fit into the bigger picture of your organization 💸. Estimates represent cost, which helps inform different stakeholders' decisions. Here are some common scenarios:

Calculate the price of a project: Consultancy firms and freelancers use estimates to calculate how much they charge clients. For this reason, it is of critical importance that estimates are accurate.
Defining product roadmaps: Product teams need to know how long a piece of software will take to shape their plans and help coordination.
Sprint capacity planning: For teams working in sprints, estimates help scope a sprint and reach a sensible commitment.

What makes estimating so hard 😟

There are many reasons why doing estimates is so hard. This list presents what I believe are some of the most important ones you should take into account.

Communication is hard

To develop software, you need to have conversations between people who are analyzing the problem and people who will design and create the software. During these conversations, information can be wrong, misunderstandings can happen, or data might lack documentation.
It can take one big misunderstanding for an estimate to be dozens or hundreds of hours wrong.

Every software is different

It's almost impossible for a software that is more than a couple of code lines to be completely the same. They might be solving very similar needs (e.g., shopping cart), but they have been created by different people who chose other technologies at a different point in time, for a given market, with specific time constraints. All these decisions can drastically alter how much effort is needed.

Scope creep

Scope creep refers to unexpected changes that increase the scope initially planned for the project. It is natural that in a software project, you stumble upon an unexpected. Expect some changes to be asked, but mind that small things can pile up, so make sure that these changes are: discussed, negotiated, documented, and postponed (if possible).

Variations in experience and availability from the development team

Some team members might lack experience with the technologies used in the project; this is not rare considering how technology advances. It's also possible that you don't know all these technologies in advance, which implies some learning time and occasional head bumps.

The team's availability might also be unknown in advance. It would be best if you planned for holidays in advance to adjust the estimates. Unfortunately, things like resignations, lay-offs, and personal problems can happen without any warning.

The team's experience

The team's experience can make all the difference between a good and a wrong estimate.

Technical expertise: An expert is more likely to know the patterns that will help implement the solution faster and will also be able to identify the risks more easily.
Experience working together: People that have experience working together develop habits and processes that make them more productive.

Who should do the estimate

Ideally, the people doing the work should be doing the estimation. After all, they are the experts. If this is not possible, try to find someone with experience in similar projects and ask how much it took for them and what problems they found along the way.

Tools and tips to improve your estimates 🧭

These recommendations aren't set in stone, so I encourage you to adapt them to your team.

Have the right mindset

Acknowledge that software estimates are HARD (ask any software engineer ever). Even with all the information in the world, you are very likely to be wrong. However, also keep in mind that estimations do get better with experience. As an engineer, help other stakeholders understand this.

Clarify if you are doing a high-level estimate or a low-level one

Knowing if you're doing a high-level or a low-level estimate will help select an estimation unit and guide how much time you spend going into details.

Split the work

Split it into smaller parts, especially when estimating big loads of work. This separation can be epics, features, screens, use-cases, user stories, or whatever you find comfortable. Even when estimating at a user-story level, you might later find that one of them is too big, so you can just split it.

Choose the right unit of estimation and make sure everyone understands it

I like Uncle Bob's advice around how estimates should never be a date but rather a date range. The cool thing is that you don't have to be working with dates to follow this advice. Whatever type of estimation you are doing, it's more accurate to give a range with the following values: best case scenario, some drawbacks (but nothing major), and worst-case.

Also, all people involved in the estimate should understand the unit of effort you'll be using. For example, if you're using story points, have an example of what a 1 or 3 points feature looks like. If you're using time, explain if you expect this to be "work-hours" or "productive non-interrupted hours."

For high-level estimates, I've found T-Shirt size estimation the easiest to use. You can also estimate in weeks or months.

For low-level estimates, story points are a very wide-spread unit to use because they already take into account uncertainty and risk. You can also use man-hours but be explicit about how you will handle uncertainty and risk; you can add a percentage or a formula based on your past results and other variables. When estimating significant efforts, increase the amount of risk since things like integration, communication, and dependency issues are more likely to happen.

Gather all possible information

This step varies from high-level to low-level estimates. With high-level estimates, you probably won't go much into detail and identify the main components/tasks of the project. For low-level estimates, you'll want to understand things like assumptions, inputs, outputs, UI design, non-functional requirements, dependencies, happy-paths, and edge-cases. Having your own definition of ready is useful here.

Make sure you ask questions and clarify when needed.

I can't stress this enough don't rush it. Software estimation is an essential step in the software development life cycle, and it has a massive impact on stakeholders' expectations. On the other hand, don't take forever, the lower level you go into an estimate, the higher the cost.

Defer estimation if more information is needed

If you have a big unknown and need to do a bit of research, do it before providing an estimate. If you definitely can't wait, give the estimate but underline that you have some assumptions about that estimate.

Give your estimate

Now that you have selected a unit of effort, you have split your workload, and you have researched the necessary information; you only need to start assigning numbers. I have found better results using a consensus-based technique like planning poker rather than having a single person like a tech lead estimate on its own. The former allows more people to identify edge-cases, bring their experience, and have more ownership of the final number.

What to do if you know you are going to miss an estimate 😤

After what I've presented here, it's clear that estimates often fail. So we should be prepared for such cases. First and foremost, if you know your estimate will be missed, have a precise analysis of how behind-schedule you are, the reasons for the delay, accompanied by a proposal of how it can be amended or at least minimized.

Then, proceed to deliver the bad news so you can adjust your plans and ask for help. Be clear explaining the reasons and avoid compromising the software's quality since that will be more costly in the long-run.

Finally, do not fall prey to the man-month myth where you think people and effort are interchangeable. Adding new people to a delayed project almost always causes it to slow even further because of communication and training.

Final thoughts

Thank you for reading this far. I hope this article has provided you with useful information to improve your estimates and reach your organization's or personal goals. Don't forget to share the article with your team! 🗣️

9 concepts you should know from functional programming

Victor Cordova — Mon, 06 Jul 2020 18:16:11 +0000

Originally posted in my personal blog

Let's begin by defining what functional programming is (FP from now on). FP is a programming paradigm where software is written by applying and composing functions. A paradigm is a "Philosophical or theoretical framework of any kind." In other words, FP is a way for us to think of problems as a matter of interconnecting functions.

This article aims to give a basic understanding of fundamental concepts in FP and some of the problems it helps solve.

Note: For practicality, I'll omit specific mathematical properties that define these concepts. This is not necessary for you to use these concepts and apply them in your programs.

Immutability

A mutation is a modification of the value or structure of an object. Immutability means that something cannot be modified. Consider the following example:

const cartProducts = [
  {
    "name": "Nintendo Switch",
    "price": 320.0,
    "currency": "EUR"
  },
  {
    "name": "Play station 4",
    "price": 350.0,
    "currency": "USD"
  }
]

// Let's format the price field so it includes the currency e.g. 320 €
cartProducts.forEach((product) => {
  const currencySign = product.currency === 'EUR' ? '€' : '$'
  // Alert! We're mutating the original object
  product.price = `${product.price} ${currencyName}`
})

// Calculate total
let total = 0
cartProducts.forEach((product) => {
  total += product.price
})

// Now let's print the total
console.log(total) // Prints '0320 €350 $' 😟

What happened? Since we're mutating the cartProducts object, we lose the original value of price.

Mutation can be problematic because it makes tracing the state changes in our application hard or even impossible. You don't want to call a function in a third party library and not know if it will modify the object you're passing.

Let's look at a better option:

const cartProducts = [...]

const productsWithCurrencySign = cartProducts.map((product) => {
  const currencyName = product.currency === 'EUR' ? 'euros' : 'dollars'
  // Copy the original data and then add priceWithCurrency
  return {
    ...product,
    priceWithCurrency: `${product.price} ${currencyName}`
  }
})

let total = 0
cartProducts.forEach((product) => {
  total += product.price
})

console.log(total) // Prints 670 as expected 😎

Now, instead of modifying the original object, we clone the data in the original cartProducts by using the spread operator

return {
  ...product,
  priceWithCurrency: `${product.price} ${currencyName}`
}

With this second option, we avoid mutating the original object by creating a new one that has the priceWithCurrency property.

Immutability can actually be mandated by the language. JavaScript has the Object.freeze utility, but there are also mature libraries such as Immutable.js you can use instead. Nevertheless, before enforcing immutability everywhere, evaluate the tradeoff of adding a new library + the extra syntax; maybe you'd be better off creating an agreement in your team not to mutate objects if possible.

Function composition

It's the application of a function to the output of another function. Here's a small example:


const deductTaxes = (grossSalary) => grossSalary * 0.8
const addBonus = (grossSalary) => grossSalary + 500

const netSalary = addBonus(deductTaxes(2000))

In practice, this means we can split out algorithms into smaller pieces, reuse them throughout our application, and test each part separately.

Deterministic functions

A function is deterministic if, given the same input, it returns the same output. For example:

const joinWithComma = (names) => names.join(', ')

console.log(joinWithComma(["Shrek", "Donkey"])) // Prints Shrek, Donkey
console.log(joinWithComma(["Shrek", "Donkey"])) // Prints Shrek, Donkey again!

A common non-deterministic function is Math.random:

console.log(Math.random()) // Maybe we get 0.6924493472043922
console.log(Math.random()) // Maybe we get 0.4146573369082662

Deterministic functions help your software's behavior be more predictable and make the chance of bugs lower.

It's worth noting that we don't always want deterministic functions. For example, when we want to generate a new ID for a database row or get the current date in milliseconds, we need a new value to be returned on every call.

Pure functions

A pure function is a function that is deterministic and has no side-effects. We already saw what deterministic means. A side-effect is a modification of state outside the local environment of a function.

Let's look at a function with a nasty side-effect:


let sessionState = 'ACTIVE'

const sessionIsActive = (lastLogin, expirationDate) => {
  if (lastLogin > expirationDate) {
    // Modify state outside of this function 😟
    sessionState = 'EXPIRED'
    return false
  }
  return true
}

const expirationDate = new Date(2020, 10, 01)
const currentDate = new Date()
const isActive = sessionIsActive(currentDate, expirationDate)

// This condition will always evaluate to false 🐛
if (!isActive && sessionState === 'ACTIVE') {
  logout()
}

As you can see, sessionIsActive modifies a variable outside its scope, which causes problems for the function caller.

Now here's an alternative without side-effects:

let sessionState = 'ACTIVE'

function sessionIsActive(lastLogin, expirationDate) {
  if (lastLogin > expirationDate) {
    return false
  }
  return true
}

function getSessionState(currentState, isActive) {
  if (currentState === 'ACTIVE' && !isActive) {
    return 'EXPIRED'
  }
  return currentState
}

const expirationDate = new Date(2020, 10, 01)
const currentDate = new Date()
const isActive = sessionIsActive(currentDate, expirationDate)
const newState = getSessionState(sessionState, isActive)

// Now, this function will only logout when necessary 😎
if (!isActive && sessionState === 'ACTIVE') {
  logout()
}

It's important to understand we don't want to eliminate all side-effects since all programs need to do some sort of side-effect such as calling APIs or printing to some stdout. What we want is to minimize side-effects, so our program's behavior is easier to predict and test.

High-order functions

Despite the intimidating name, high-order functions are just functions that either: take one or more functions as arguments, or returns a function as its output.

Here's an example that takes a function as a parameter and also returns a function:


const simpleProfile = (longRunningTask) => {
  return () => {
    console.log(`Started running at: ${new Date().getTime()}`)
    longRunningTask()
    console.log(`Finished running at: ${new Date().getTime()}`)
  }
}

const calculateBigSum = () => {
  let total = 0
  for (let counter = 0; counter < 100000000; counter += 1) {
    total += counter
  }
  return total
}


const runCalculationWithProfile = simpleProfile(calculateBigSum)

runCalculationWithProfile()

As you can see, we can do cool stuff, such as adding functionality around the execution of the original function. We'll see other uses of higher-order in curried functions.

Arity

Arity is the number of arguments that a function takes.


// This function has an arity of 1. Also called unary
const stringify = x => `Current number is ${x}`

// This function has an arity of 2. Also called binary
const sum => (x, y) => x + y

That's why in programming, you sometimes hear unary operators such as ++ or !

Curried functions

Curried functions are functions that take multiple parameters, only that one at a time (have an arity of one). They can be created in JavaScript via high-order functions.

Here's a curried function with the ES6 arrow function syntax:

const generateGreeting = (ocassion) => (relationship) => (name) => {
  console.log(`My dear ${relationship} ${name}. Hope you have a great ${ocassion}`)
}

const greeter = generateGreeting('birthday')

// Specialized greeter for cousin birthday
const greeterCousin = greeter('cousin')
const cousins = ['Jamie', 'Tyrion', 'Cersei']

cousins.forEach((cousin) => {
  greeterCousin(cousin)
})
/* Prints:
  My dear cousin Jamie. Hope you have a great birthday
  My dear cousin Tyrion. Hope you have a great birthday
  My dear cousin Cersei. Hope you have a great birthday
*/

// Specialized greeter for friends birthday
const greeterFriend = greeter('friend')
const friends = ['Ned', 'John', 'Rob']
friends.forEach((friend) => {
  greeterFriend(friend)
})
/* Prints:
  My dear friend Ned. Hope you have a great birthday
  My dear friend John. Hope you have a great birthday
  My dear friend Rob. Hope you have a great birthday
*/

Great right? We were able to customize the functionality of our function by passing one argument at a time.

More generally, curried functions are great for giving functions polymorphic behavior and to simplify their composition.

Functors

Don't get intimidated by the name. Functors are just an abstractions that wraps a value into a context and allows mapping over this value. Mapping means applying a function to a value to get another value. Here's how a very simple Functor looks like:

const Identity = value => ({
  map: fn => Identity(fn(value)),
  valueOf: () => value
})

Why would you go over the trouble of creating a Functor instead of just applying a function? To facilitate function composition. Functors are agnostic of the type inside of them so you can apply transformation functions sequentially. Let's see an example:


const double = (x) => {
  return x * 2
}

const plusTen = (x) => {
  return x + 10
}

const num = 10
const doubledPlus10 = Identity(num)
  .map(double)
  .map(plusTen)

console.log(doubledPlus10.valueOf()) // Prints 30

This technique is very powerful because you can decompose your programs into smaller reusable pieces and test each one separately without a problem. In case you were wondering, JavaScript's Array object is also a Functor.

Monads

A Monad is a Functor that also provides a flatMap operation. This structure helps to compose type lifting functions. We'll now explain each part of this definition step by step and why we might want to use it.

What are type lifting functions?

Type lifting functions are functions that wrap a value inside some context. Let's look at some examples:


// Here we lift x into an Array data structure and also repeat the value twice.
const repeatTwice = x => [x, x]

// Here we lift x into a Set data structure and also square it.
const setWithSquared = x => new Set(x ** 2)

Type lifting functions can be quite common, so it makes sense we would want to compose them.

What is a flat function

The flat function (also called join) is a function that extracts the value from some context. You can easily understand this operation with the help of JavaScript's Array.prototype.flat function.

// Notice the [2, 3] inside the following array. 2 and 3 are inside the context of an Array
const favouriteNumbers = [1, [2, 3], 4]

// JavaScript's Array.prototype.flat method will go over each of its element, and if the value is itself an array, its values will be extracted and concatenated with the outermost array.
console.log(favouriteNumbers.flat()) // Will print [1, 2, 3, 4]

What is a flatMap function

It's a function that first applies a mapping function (map), then removes the context around it (flat). Yeah... I know it's confusing that the operations are not applied in the same order as the method name implies.

How are monads useful

Imagine we want to compose two type lifting functions that square and divide by two inside a context. Let's first try to use map and a very simple functor called Identity.

const Identity = value => ({
  // flatMap: f => f(value),
  map: f => Identity.of(f(value)),
  valueOf: () => value
})

// The `of` method is a common type lifting functions to create a Monad object.
Identity.of = value => Identity(value)

const squareIdentity = x => Identity.of(x ** 2)
const divideByTwoIdentity = x => Identity.of(x / 2)

const result = Identity(3)
  .map(squareIdentity)
  .map(divideByTwoIdentity) // 💣 This will fail because will receive an Identity.of(9) which cannot be divided by 2
  .valueOf()

We cannot just use the map function and need to first extract the values inside of the Identity. Here's where the flatMap function comes into place.

const Identity = value => ({
  flatMap: f => f(value),
  valueOf: () => value
})

...

const result = Identity(3)
  .flatMap(squareIdentity)
  .flatMap(divideByTwoIdentity)
  .valueOf()

console.log(result); // Logs out 4.5

We are finally able to compose type lifting functions, thanks to monads.

Conclusion

I hope this article gives you a basic understanding of some fundamental concepts in functional programming and encourages you to dig deeper into this paradigm so you can write more reusable, maintainable, and easy-to-test software.

Should you be using Deno instead of Node.js?

Victor Cordova — Sun, 24 May 2020 19:27:23 +0000

Originally posted in my personal blog

A new contender is threatening Node.js monopoly as a JavaScript runtime, and its name is (drumrolls) Deno.

This article will give you a basic understanding of what Deno is, the value this technology adds, and where it lacks at the moment. Also, I'll share some thoughts about adopting it.

In a nutshell, what is Deno?

Deno is a new (version 1.0 just came out) JavaScript runtime, created by the Node.js creator and designed to overcome several design flaws from Node.js and add improvements on top of that. A runtime is a "box" where code can run, and it's a vital part of a system because it imposes certain restrictions around applications built inside of it and dictates a tremendous amount of the development experience and tradeoffs involved in creating the system.

Before checking Deno's benefits, we need to understand which problems it aims to address.

Problems with Node.js

On this great talk, Ryan Dahl, the creator of Node.js, talks about some of the regrets in the development of Node.js

Amongst them, I'd like to highlight the following:

Security: There was a missed opportunity while designing Node to add certain guarantees around security. For example, your linter should not get access to your network or entire file system.
Making npm the defacto standard: This creates a centralized and privately controlled entity that has great power over the whole ecosystem and things like this happen.
node_modules: You know the meme, nothing is deeper than the node modules folder. It complicates the module resolution algorithm and is very inconsistent with how browsers work.

After reading this, you might be wondering: "Why not just fix these issues in Node?". Deno's blog answers this question: "Due to the large number of users that Node has, it is difficult and slow to evolve the system."

Another great benefit of using Deno is the complexity around developing JavaScript applications with Node. There is just massive tooling involved, which creates confusion amongst new developers and headaches to more experienced ones for having to keep up with new versions of each package.

Benefits of using Deno

Some of Deno's most important benefits compared to Node are:

Secure by default: Just like mobile applications, you need to grant explicit permission to access file, network, or environment. Because of this, you don't have to be scared anymore about one corrupted package stealing your personal information.
Simplicity: Deno ships as a single executable, which provides everything you need to develop your application. No need for a package.json file or setting up external config files.
Support for TypeScript out of the box: Given Typescript popularity and adoption, this can significantly improve the developer experience and help developers catch bugs early.
Built-in utilities such as a bundler and code formatter: In other words, there is no need for external dependencies such as Prettier or Webpack for common tasks.
Standard library: This has been a long-requested feature for JavaScript, and Deno offers one. It provides utilities for testing, date-formatting, and more.
Browser compatible API: Global variables and events such as fetch, load, unload, and window are available in Deno just like you would expect in a browser, thus reducing the friction of moving from one platform to another.

All these benefits translate to mainly two things. First, you significantly improve developer experience, thus leading to potentially shorter development cycles, and second, you reduce the risk of downtime and data loss due to vulnerabilities from unsecured scripts.

How does a script built for Deno look like

To exemplify Deno's benefits, here's a sample index.ts file that you can run out of the box with Deno.

// Importing a dependency directly from a URL 🤯
import { parseDateTime } from "https://deno.land/std/datetime/mod.ts"

// Using browser compatible apis such as fetch
const res = await fetch('https://icanhazdadjoke.com', {
    headers: { 'Accept': 'application/json' }
})
const data = await res.json()

const enc = new TextEncoder();
// Using the Deno global namespace for os utilities
await Deno.writeFile("joke-of-the-day.txt", enc.encode(data.joke))

console.log("We're done here 🦕")

How to run the script

deno run --allow-read --allow-write index.ts

Deno's limitations

Despite all the significant merits, Deno has some shortcomings that prevent it from being on the same level as Node today. Here they are:

Migration cost: Most organizations using Node, are tightly coupled to npm's ecosystem. For example, teams have thousands of tests written with Jest, their configuration for prettier, their custom Webpack config, Node global variables, and much more. Adopting Deno for these types of applications would probably be more costly than to keep using Node and npm. Also, if you use Deno for new projects, there would be extra effort maintaining utilities that work for this runtime and a lot of effort would be wasted
Incompatibility with some NPM packages: One study referenced in this talk from 2019 suggests that the reason JavaScript is the most popular language today is because of the large number of packages available in the npm registry. Unfortunately, some very popular Node packages are not compatible with Deno.
The standard module is not stable: According to the docs, "Deno's standard modules (https://deno.land/std/) are not yet stable": This means that you could end up finding some unexpected behavior with one of your use cases or even bugs.
Lack of experienced developers using it: This means that even if companies decide to use Deno, finding experts would be challenging.

Conclusion, should you adopt it now?

In my opinion, if you're talking about using Deno for production apps, then you should NOT (for now). The technology is still in its early stages, which means the ecosystem isn't mature enough to support the thousands of use cases companies have for Node and also the common problems that will arise with Deno that don't have an answer in the JavaScript community. Finally, working with unstable APIs is a dangerous game. You can end up needing to create a pull request to Deno itself to support a critical application.

On the other hand, if you're talking about side projects, then definitely give it a go. The technology does provide great benefits as it is and should allow you to bootstrap a new project in no time. Also, the community is thriving, so the more you use it, the more you can contribute to its growth.

Just take in mind all the limitations I mentioned and enjoy building JavaScript apps with no node_modules folder. 🎉

Lessons from migrating a web application to a design system

Victor Cordova — Sat, 02 May 2020 00:00:00 +0000

Also available in my personal blog

What is a design system

In the world of frontend development, a design system is a set of common guidelines, UI components, and reusable utilities that allow for the rapid creation of applications.

Some notable examples are: Github's Primer or Mozilla's Photon

They provide the following benefits (amongst others):

Faster time to market
Consistency between products
Less code to maintain
Robustness

The story of this initiative

I recently had the opportunity to champion an initiative to migrate an application of ~15k lines of code, and approximately 239 React components. This meant being responsible for splitting the effort to implement the initiative, provide appropriate details and context to the rest of the team, lead refinement sessions around these tasks, and following up their progress.

The objective of this initiative was to replace existing React components written in pure React and styled-components with the design system's alternative for these components. This also included migrating utilities for responsive design, spacing, and font. Finally, files that were no longer needed would be removed from the original codebase.

Next, I'll describe how the effort was planned and executed, as well as share some lessons learned along the way.

The goals

There were three goals that we wanted to achieve by implementing this initiative:

Reduce codebase while keeping functionality: Generally speaking, if you have less code in your application, it's easier to maintain and it's less prone to error.
Reduce development time for new frontend tasks: After the migration, we'd be dealing mostly with the components from the design system which means it would be easier to change their behavior through one of the configuration properties it provides.
Reduce wasted effort for future initiatives: Given that we would delete custom components, utilities, test files, and assets, all of these files wouldn't add effort to future technical debt initiatives.

State of the website previous to migration

Metric	Value
Test coverage	87.09% statements, 79.65% functions, 87.64% lines
JavaScript files	441
Lines of code without blank lines and comments	14908
UI components these are the ones we'd be replacing	215
Container components (components with complex logic in them)	24

The high test coverage gave us confidence that we could do this migration without having to worry to much about breaking stuff. Of course, each developer still did testing around each task.

The plan

During kickoff, the following plan was shared with the frontend team to address the migration:

Split workload amongst 16 tasks of similar-effort
Timespan: 3.5 sprints (the initiative was developed alongside regular sprint objectives)
Implement between 3 to 5 tasks per sprint
Bi-weekly refinements to scope the tasks

The results

In this section, I'll give some comments analyzing the impact that this initiative had on the project. First, the numbers:

Metric	Value
Components that were deleted	35.81%
Other files deleted (% of overall codebase files)	6.8%
Net number of lines deleted	12.36%

Components that were deleted

Of the 215 UI components, 77 were deleted which accounts for a 35.81% reduction. This accomplishes objectives 1 and 3 of the initiative given that there is a significant proportion of UI components that don't need to be maintained anymore. You might wonder why there is still 64% of UI components remaining in the application. The answer is mostly application-specific components. This might also indicate that some reusable components should be included in a future version of our design library.

Other files deleted

As expected, some utility files were deleted, albeit not a huge amount. Still, given that we don't have these in the code anymore, a new developer will not get confused and use them by accident.

Net number of lines deleted

The impact in the overall size of the project is smaller (12.36%) than the impact of % of components deleted. Nevertheless, this shoudn't be discouraging because after the migration the UI has the added robustness from the design system which also makes it less prone to error.

We should also remember that, even though the UI components are a critical part of a frontend application, there are several other concerns such as:

Container components
Test files
State Management
Custom hooks
Authorization
Constants
API calls
Configuration
3rd party wrappers (i18n, date formatting, tracking)

Lessons learned

These are some other lessons I gathered from the whole process of implementing this initiative that made it possible for it to be completed on time:

Due to the fact that we used react-testing-library and followed its guiding principles, we weren't concerned with breaking our tests because the underlying implementation changed. This made the transition much smoother.
Keep reusable code for the end of the migration, so that individual packages can get migrated without being blocked.
When migrating to a new component library, make sure to validate with designers to make sure expectations of UI are met.
Communicate with your product owner so they are aware of the changes being made from the UI perspective.
Communicate continuously with teams before a sprint start so technical tickets can be assigned according to capacity and adjustments to the plan can be made.

Conclusion

If you have a mature enough design system, the impact of adopting it in a web application can be hugely positive for reducing the amount of code in your UI layer. It can also help detect gaps in the design system's functionality that can later help to improve it.

Credit

The migration was possible thanks to my amazing colleagues at the @FREENOW frontend chapter in the Barcelona Tech hub and the design system team.

What to do when you're stuck with a problem 🤷

Victor Cordova — Sat, 21 Mar 2020 13:19:13 +0000

What I mean by "stuck"

Here's how I frame this kind of situation. Being stuck means that you're not able to finish or make progress in a task with your current knowledge, mental state or physical state. It happens every once in a while and requires special consideration to tackle it effectively. Some examples are: not being able to solve a bug or not being able to find a good design that satisfies all the constraints of a given problem.

How to tell that you're stuck

The first step towards getting unstuck is to recognize you're stuck. Here are some ways to determine this:

When you're not making any progress for a little while. For me, this usually means half an hour to an hour
When you're feeling deeply frustrated with a problem
When you're unable to understand the problem and its factors. For example, when you need to implement a feature in a platform or with a library you're not familiar with

What to do when you're stuck

The mindset

Usually, we grow the most when we're faced with challenges, so every time you get stuck, recognize that you found an opportunity to grow. It might be hard to get through it but it will be rewarding.

The physical aspect of it

Our minds need to be in a good physical state to solve problems. Some of the things that can make put it in a bad state are stress, lack of sleep or an unhealthy diet. It's critical for you to get into a positive mental state. Here are some techniques you can use to achieve that:

Get away from the computer (if your problem presents there). This will help your mind rest from being exposed to the problem and achieve some relaxation, as well as allowing you to think of the big picture of where this problem fits. Even better, take a walk if you can.
Breathe mindfully
Eat the right type of food
Try to get the right amount of sleep

If you want to go deeper into this topic, I really recommend watching this

Do your homework

Always do some research on the problem. Try to identify what are its key elements: a specific layer of your application, given technology, a specific set of conditions or constraints. Then, google it. It's very likely someone already solved that problem (or a very similar one).

If you have just a thin idea of where a possible solution might be, spend some time learning everything you can around the related technologies/topics. Search for articles, documentation on the API/technology, common patterns, etc. In case you're wondering, yes, learning is part of your job.

Ask for help

If you're unable to find a solution on your own or need to solve the problem very urgently. You can ask somebody who is familiar with the problem such as a friend or colleague. Also, you can go into an online community such as StackOverflow and ask there for help.

If everything else fails

Apply the diffuse mode. This is an underused way of using your brain to solve problems in the background. Learn about it here

A note for people starting out in the world of programming

It's normal that at the start of your career you find these kinds of situations more often. It's normal. Even if you're very experienced, you'll still find these situations but you'll have better tools to tackle them faster and efficiently.

Feel free to share your experiences of getting stuck and how you overcame it.

👨‍💻📚 65 practical lessons from "The Pragmatic Programmer: From Journeyman to Master"

Victor Cordova — Wed, 12 Feb 2020 21:29:03 +0000

"The Pragmatic Programmer: From Journeyman to Master" is a book that has had a profound impact on my career as a developer. I've found myself often coming back to it to check my notes and highlights, so to make this more practical, I created this compilation. Please take this article as a teaser for the entire book. I highly encourage you to read it yourself.

Disclaimer: These bullet points are me paraphrasing sentences from the book, others are direct quotes (these are between double-quotes). Also, these notes are for the first edition of the book, I haven't yet checked out the second edition but from the table of contents, it seems like the authors added more stuff into it rather than removing from it.

List of lessons

To be a pragmatic programmer, be: "Early adopter/fast adapter", "Inquisitive", "Critical thinker", "Realistic", "Jack of all trades". In short "Care about your craft". Page xviii
What distinguishes a pragmatic programmer? The attitude to thinking beyond the immediate problem and take the context into account. Also, they are accountable for everything they do. Page 1
How does a pragmatic programmer take responsibility? Providing options and not making excuses. Page 3
Software can rot, the most important factor that affects this is the people's psychology around a project. Page 4
Don't leave tech debt unfixed. Fix stuff as soon as they pop-up or at least plan to address it later. Page 5
To make positive change, be proactive so you become a Catalyst for Change. Page 8
"Constantly review what's happening around you, not just what you are doing". Page 9
Make sure you involve users in the trade-offs to identify the real constraints of the project and prioritize accordingly. Page 10
Code can never be perfect. "Great software today is often preferable to perfect software tomorrow". Page 11
"Knowledge and expertise are your most important professional assets". "Unfortunately, they're expiring assets". Page 12
"Think critically about what you read and hear. You need to ensure that the knowledge in your portfolio is accurate". Page 16
Be an effective communicator and think about your audience before delivering the message and be timely when delivering the message. Page 19
Avoid duplication by having a clear design in mind when tackling a problem. Also, constantly communicate with your peers is key. Page 32
When evaluating using third party libraries, evaluate if they impose any unwanted restrictions on you. Page 39
If you want to cheaply evaluate a risky decision, prototypes are a great tool. Page 53
Prototypes aren't only to explore features, they can serve to explore architectures, third-party components or UI changes. Page 54
Get familiar with the domain language and use it in your programs. Page 58
When doing estimations, ask yourself about the context in which this estimate will be used. Do you need a high-level estimate for roadmap planning? Do you need a more precise number for your current sprint?. Page 64
A good way to estimate something is to ask someone who has done it before. Page 65
Often the only way to truly determine the timetable for a project is by gaining experience on that project. Page 68
When asked for an estimate, answering "I'll get back to you" will help you slow down the process, apply several decomposition techniques (more detail in the book) and provide a better answer. Page 69
Consider using plain text as a format to represent knowledge given its simplicity, longevity, and ease of use. Page 74
When debugging, get into the right mindset first. Turn off your ego, any pressure you have from the project you're currently working on and get comfortable. Also, don't panic. Try to discover the root cause instead of just fixing the symptoms. Page 91
While eliminating possible causes of a bug, recognize that if you change something and the system stopped working, that something is probably the reason why. Page 96
Don't assume some function is not related to a bug, prove it, run it with the data that's causing the problem. Page 97
If the bug took a long time to fix, ask yourself what you can do to fix it next time easier. Page 98
"You can't write perfect software". Page 107
When your program detects that it entered a state that shouldn't have happened, crash. It's much better to crash than continue running with a corrupted state. Page 121
"Exceptions should rarely be part of a program's normal flow; they should be reserved for unexpected events". Page 126
A routine that allocates resources should ideally also free them. Page 131
When asking an object for a particular service, we'd like the service to be performed on our behalf. Do not rely on third-party objects to be returned. Otherwise, you're increasing the coupling of your code to another module. Page 139
Given the frequency at which business needs can change, it's best to add support for dynamic behavior through configuration at runtime. Page 144
Coding isn't mechanical, there are decisions made every minute. Page 171
Don't rely on your programs working by coincidence, be aware of what you're doing and do your coding with a plan in mind. Page 175
"Don't let existing code dictate future code". Page 176
Be pragmatic when choosing your algorithm. The fastest one isn't always the best one. Page 182
Code needs to evolve. Software is more like gardening than to construction. Page 184
Refactor early and refactor often. Also, keep track of the things that need to be refactored. Page 186
"Don't try to refactor and add functionality at the same time". Page 186
Before refactoring, make sure you have good tests. Also, do your refactoring in short small steps. Page 186
Built testability into your software from the beginning and test each piece thoroughly before integrating them. Page 189
If you use a tool to generate code for you, understand everything it produces so you can control your application. Page 199
Software requirements are generally hard to identify. They're usually buried beneath layers of assumptions, misconceptions, and politics. Page 202
"It's important to discover the underlying reason why users do a particular thing, rather than just the way they currently do it". Page 203
A simple technique for getting inside your user's requirements is to become a user. Spend some time with them in their actual working environment. Page 203
"Requirements are not architecture, they are not design or user interface. They are needs.". Page 208
To ensure consistent communication with other stakeholders, maintain a project glossary. Page 210
When solving though problems, first identify the constraints placed on you and the degree of freedom you have. Challenge any preconceived notions and evaluate whether or not they are hard/absolute constraints or just preconceived notions. Page 213
When faced with a tough problem, enumerate all the possible solutions you can think of. If you want to dismiss an option, think clearly about the reasons why. Page 213
When faced with a problem that seems harder than it should be, ask yourself these questions: "Is there an easier way?", "Are you trying to solve the right problem, or have you been distracted by a peripheral technicality?", "Why is this thing a problem?", "What is it that's making it so hard to solve?", "Does it have to be done this way?", "Does it have to be done at all?" Page 214
Don't obsess over creating software specifications. Often, it's only during coding that certain options become apparent. Page 218
"As soon as you have more than one person working on a project, you need to establish some rules and delegate parts of the project accordingly." Page 223
Quality is a team effort, not a single developer effort. Page 224
Your team is a single entity that needs to communicate clearly with the rest of the world. Create a personality for it and generate a positive reputation. Page 225
Organize your team around functionality, not job function. Page 227
Automate every task everything you can, avoid manual procedures at all cost. Page 231
Pragmatic programmers test their code early, often and automatically. Page 237
Failing to meet usability criteria is just as a bug as dividing by zero. Page 241
The data you use for testing has a huge impact on giving you confidence. Don't blindly trust code coverage. Page 245
If a bug slips through the net of existing tests, you need to add a new test to trap it next time. Page 246
"In general, comments should discuss why something is done, its purpose and goal". Also, it's a good way to document why decisions were made and what other alternatives were discarded. Page 249
"The success of a project is measured by how well it meets the expectations of your users.". Page 255
"Work with your users so that their understanding of what you'll be delivering is accurate.". Page 256
Go the extra mile to surprise your users, try to delight them. Page 256

Thanks for reading this far 🙏

5 invaluable learning methods for programmers 👩‍💻

Victor Cordova — Sun, 29 Dec 2019 18:23:51 +0000

Learning feels sometimes like putting together pieces of a puzzle. Photo by Hans-Peter Gauster on Unsplash

As developers, learning is an everyday thing. However, there are so many ways to learn that it can easily feel overwhelming. It's helpful to keep in mind that each method has its pros and cons so you can have more effective learning sessions.

Here are the main methods I use for learning. For each one, I'll answer the following questions:

What value does it give?
When to use it?
What limitations does it have?

Disclaimer: This is by no means an extensive list of all methods available, but these are the main ones I personally use. Feel free to reach out to me with others I'm missing :)

Short online courses (e.g. pluralsight, egghead)

Photo by Thomas William on Unsplash

What value does it give?

Easy to consume: people can follow along when you show them running code instead of just pasting chunks of code
Fast to consume: when videos are short and centered on a specific sub-topic, you can just watch it and get an idea of the concept it explains

When to use it?

First contact with new technology: You can watch a video almost effortlessly and get a sense of what a technology does
Deepen knowledge in a specific technology: You can find videos from very high-level engineers or even the creators of a technology
Get common best practices: Common patterns tend to be spread really quickly so someone will usually make a course on it

What problems does it have?

Subscriptions can get pricey: Good material costs money. It can be a very good investment though
The theoretical base is many times weak: Since the videos usually focus on practical applications of the technology. The whys behind the design of the example project or the technologies are left as an afterthought
Examples are sometimes basic: Since time is limited, usually courses take a contrived example and don't give you a broad perspective on a real-world application

Personal projects

Photo by Raul Varzar on Unsplash

I'm talking about projects you do in your spare time to solve your problems with programming.

What value does it give?

Gives you experience making technical decisions: when you solve actual problems instead of hello-worlds, you need to make technical trade-offs, evaluate new technologies and many other real-life decisions. This is a very important muscle to exercise
Gives you experience with the many aspects of releasing a software project: from frontend to CI to deployment, each one has its intricacies
Longer lasting learning: we learn better from our mistakes, nothing like a 2-hour configuration bug to make you remember to read the docs ;)
Provide a playground to try new ideas or technologies: by trying out new approaches you can expand your repertoire and try out new cool tech

When to use it?

When you have a problem you can solve with technology: you have the skillset, why not use it? Maybe other people have the same problem
Experimenting with new ideas or technologies
All the time: there is so much new stuff to try out and updates to existing stuff that it helps to have a working product that needs to be maintained
When you want to get familiar with a family of technologies: maybe you want to see how it feels to use react with GraphQL? Or how using redux and its many middlewares make you structure your app?
Profit: hey you never know if you have the next dropbox
When you want to develop your portfolio

What problems does it have?

Takes long time and motivation: you have to be disciplined to finish a complete project, even a small one
Needs clear objective: Either solve a problem or learn. If it doesn't, it can fade into the realm of unfinished ideas

Open source contributions

Photo by Ursula Spaulding on Unsplash

What value does it give?

Learn to navigate other people's source code: this is a fundamental skill as a software developer. We spend a large chunk of our time reading other people's code. Big open-source projects will challenge you in that they can be humongous in terms of size. You will need to ask for questions and process other people's way of solving problems
Discuss technical decisions with very smart people: open source projects need to make sure their decisions don't impact negatively their existing users so prepare to be challenged on a solution you are proposing and defend your arguments
Learn current best practices and tools: maintained open-source projects need to keep up to date. This means they usually use state-of-the-art technologies to solve their problems
Learn more about a technology you are using: if you get familiar with how a library you are using works on the inside, it will give you more insight on how to use it better and maybe propose a feature or fix a bug

When to use it?

As much as you have time to (at least once every 1-2 months): it will help you challenge yourself with problems you are not familiar with and collaborate with other very smart engineers
When you want to learn how some technology works on the inside
Getting up to date on current technologies
Developing your portfolio of contributions: it is very valued in the industry

What problems does it have?

Solving the actual ticket can take a long time depending on its complexity and the back and forths with the maintainers
You have to dig into the issue list to find a worthwhile issue to solve

Technical Books (technology agnostic and technology-specific)

Photo by Alfons Morales on Unsplash

What value does it give?

Quality content: if chosen correctly (by editorial, author or otherwise), you make sure the quality of the book is top-notch
Deep understanding of specific topics: broadening your toolset with a specific technology will help you choose a more fitting solution
Convenience for consumption: if physical, you can read them anywhere you like

When to use it?

All the time: be always reading a technical book, there is so much to learn and it can help you get off the screen for a little while
Wanting to deepen knowledge into a specific technology
Wanting to improve your overall thinking process with better mental models and techniques

What problems does it have?

Long-time to consume: in my experience, to really grasp new ideas from a technical book, you need to re-read and think about the content for a while
Expensive: technical books are very expensive compared to other non-fiction books
If technology-specific will probably get out of date quickly
Need to balance your reading time between technology-agnostic vs technology-specific books, both are important

Blog posts

Photo by Samuel Zeller on Unsplash

What value does it give?

Solutions to specific problems
Short learning sessions
Learn about other people's mistake
Hands-on solutions

When to use it?

All the time, maybe every day depending on your learning schedule
Solving very specific problems
Getting started with technology
Wanting to get deeper into technology or concept

What problems does it have?

There is an avalanche of articles every week: hackernews, medium, subscriptions, dev.to, it goes on and on. You need to prioritize which ones to read and keep looking for new sources.
A lot of noise is generated from duplicated articles: some examples, "Getting started with react.js" or "How to become a programmer".

Communities (e.g. spectrum, slack channels, gitter)

Photo by Héctor J. Rivas on Unsplash

What value does it give?

Evaluate your ideas
Learn about other people's thinking process

When to participate in one?

All the time
Solving a specific problem
Networking
Finding a job
See what's coming in the future
While developing a personal project

What problems does it have?

Needs constant engagement
You need to dig to find a conversation you are interested in

How do you learn and keep improving your technical skills?

Even Swaps, a rational way to choose a library

Victor Cordova — Tue, 10 Dec 2019 20:30:06 +0000

As developers, we are fortunate enough to have at our disposal a never-ending selection of high-quality libraries to choose from when we want to solve our problems. This creates a new challenge: which one to use and why?

The main question this article helps answer is how to methodically choose a library that will best fit your needs and will save you time on unwanted refactorings. This method is most useful when a clear alternative is not clear, and there are several options to choose from

Who are our users? 👨‍💻🙋‍♀️

There are two users we should keep in mind when choosing a library. Each one has his own needs and expectations.

The first type of user is, of course, the final user of our application. This person expects an easy to use, performant, and beautiful product. She doesn't want to spend time learning how to use your UI or have to read somewhere else what are the steps they need to do their job or solve their problem.

The second type of user is the developer, who will be using the library. This person expects an easy to use API, plenty of customization available, smart defaults, proper documentation for the library, and that the project is still maintained.

What are the exact needs your product has?

This is the first question you should be asking. What features are they expecting your library to have? What are the use cases for it? How does the design look like?

Do you need a library? 🤔

After understanding the need, you should ask if you need to use an existing library. If the use case is very simple, you might be better off just creating the code yourself or making use of a feature from JavaScript (don't forget to check things in stage 3 of the standard). Just keep in mind the pros and cons of using a library:

Pros:

Battle-tested
It's usually highly customizable
Best practices baked-in

Cons:

Has a learning curve
Might require making decisions you might not like (depend on another external library like moment.js, using CSS classes instead of styled-components)
You'll have to keep it up to date for security reasons
Adds to your bundle size

The method to choose a library (Even Swaps)🔄

Alright, let's say you have decided that you are going to need a library, now it's time to apply the method for evaluating the best choice. This is based on a Harvard Business Review publication called "Even Swaps" from authors John S. Hammond, Ralph L. Keeney, and Howard Raiffa published in 1998.
For this example, let's say you have decided you need to choose a datepicker library that will be used in several screens of your app. We'll be creating a matrix of library vs. dimension to evaluate our decision.

Part 1: Choosing dimensions

Here's where knowing your two types of user counts, what does each one need? First, let's see what a final user would expect from such a library. We'll assign numbers to qualitative dimensions:

Good UX (easy to use) (1-5, 5 is best)
Mobile friendly *
Supports localization *

How about the developers? Here are a couple of ideas:

Proper documentation (1-5, 5 is best)
Bundle size (smaller is better)
Dependencies (no dependencies is ideal)
Easy to style (1-5, 5 is best)

If any of the other dimensions is a must, then you can mark it with a * for part 4 of this method. For this particular case, I've marked mobile friendly and localization as musts.

Part 2: Finding relevant options

List out all the options you find after a quick google search. Make sure you also search for alternatives to the first result. You can do this by typing "FIRST ALTERNATIVE vs." and google will autocomplete other options. Finally, you can also tweet or post questions in communities such as Reddit or Spectrum.

Part 3: Creating a consequence table

For this part, you'll have to read the docs and preferably play around with the library.

Afterward, you can create a table with the libraries in one axis and the dimensions from step 1 in another axis. This is called a consequence table in the original method. For measuring bundle size, I recommend using bundlephobia.com

Library	UX	Mobile Friendly *	Supports localization *	Good documentation	Bundle size	Dependencies	Easy to style
react-dates	5	Yes	Yes (using moment.js)	5	231kB	moment.js	5
react-datepicker	3	Yes	Yes (internally uses date-fns)	3	63.5kB	None	3
~~react-day-picker~~	4	No	~~Yes (either manual or moment.js))~~	4	~~3.7kB~~	~~None~~	4

As you can see, react-date-picker has been discarded because it's not mobile-friendly, which was one of our must dimensions.

Part 4: Doing even swaps

This is the core of the method. It will allow us to narrow down our options to a single one. I'll let the original authors explain it much better than I can:

What do we mean by even swaps? To explain the concept, we need to state an obvious but fundamental principle of decision-making: If every alternative for a given objective is rated equally—for example, if they all cost the same—you can ignore that objective in making your decision. If all airlines charge the same fare for the New York to San Francisco flight, then cost doesn’t matter. Your choice will hinge on only the remaining objectives.

In short, we want to make two options have the same values for all their dimensions except one; then, we'll use that last dimension to pick the dominating option and discard the other one, as simple as that.

How do we do this 🤷? We must determine what it would take to make two options have the same value in one dimension. For example, let's say we want to ignore the UX dimension; this would mean we want two options to have the same values. We then ask, how many additional kB of bundle size would I add to give an option two extra points of UX? Let's say it's 150 kB. Let's add 2 UX points to react-datepicker and increase its bundle size by 150 kB.

Library	UX	Mobile Friendly *	Supports localization *	Good documentation	Bundle size	Dependencies	Easy to style
react-dates	5	Yes	Yes (using moment.js)	5	231kB	moment.js	5
react-datepicker	5	Yes	Yes (internally uses date-fns)	3	213.5kB	None	3
~~react-day-picker~~	4	No	~~Yes (either manual or moment.js))~~	4	~~3.7kB~~	~~None~~	4

Now, the first and second option are almost the same. Let's ask, for two additional points of documentation, how many kB would we add? Let's say it's 80 kB

Library	UX	Mobile Friendly *	Supports localization *	Good documentation	Bundle size	Dependencies	Easy to style
react-dates	5	Yes	Yes (using moment.js)	5	231kB	moment.js	5
react-datepicker	5	Yes	Yes (internally uses date-fns)	5	293.5kB	None	3
~~react-day-picker~~	4	No	~~Yes (either manual or moment.js))~~	4	~~3.7kB~~	~~None~~	4

The remaining options are almost the same. Finally, we can choose how many points in easy to style we would take if we were to remove moment.js. Let's say it's 2. This will allow us to select the final winner 🎉

Library	UX	Mobile Friendly *	Supports localization *	Good documentation	Bundle size	Dependencies	Easy to style
react-dates	5	Yes	Yes (using moment.js)	5	231kB	None	3
~~react-datepicker~~	5	~~Yes~~	~~Yes (internally uses date-fns)~~	5	~~293.5kB~~	~~None~~	5
~~react-day-picker~~	4	No	~~Yes (either manual or moment.js))~~	4	~~3.7kB~~	~~None~~	4

As you can see, doing swaps correctly requires experience and criteria, the more you use it, the better you'll get at it.

Part 5: Documenting your decision 📖

Once you are left with only one option. I'd recommend you add the information about why you chose this library for your teammates to understand why they are using this library. A good option is creating a markdown file where you document the consequence table and method you used.

Reference

Even Swaps: A Rational Method for Making Trade-offs