Underpromise 🤝🏻, Branded types 🏷️, Negotiations 💵, CommonJS vs ES Modules

Techletter #70 | April 27, 2024

Underpromise and over-deliver

Let me express my thoughts on this. The problem with over-promising and under-delivering is in the end the person expecting the work to be done will be not satisfied by your work. He/She may be your client or customer. This is a bad impression to have.

Let’s think it the other way, what if you underpromise and overdeliver? Your client/customer will be more happy that you delivered with more concern on the craft, and they will definitely appreciate your work.

Typescript branded types

Branding also known as the opaque types enables the differentiation of types in TypeScript which otherwise would be classified as the same type.

Let’s understand this with an example

type A = {
    x: number,
    y: boolean,
    z: string,
}

type B = {
    x: number,
    y: boolean,
    z: string,
}

const fn = (a: A) => {
    console.log('do something with A')
}

const obj: B = {
    x: 1,
    y: true,
    z: 'hello'
}

fn(obj) // This can create confusion. Because, you are passing object with type B, but the function is accepting the object with type A.

So, how can you use branded type for differentiation?

const brand = Symbol('brand') // keep this private!!

type A = {
    x: number,
    y: boolean,
    z: string,
} & {
    [brand]: 'A'
}

type B = {
    x: number,
    y: boolean,
    z: string,
} & {
    [brand]: 'B'
}

const fn = (a: A) => {
    console.log('do something with A')
}

const obj: B = {
    x: 1,
    y: true,
    z: 'hello'
}

fn(obj) // Error!

Original Link

Mistakes with salary negotiations

Never share your expected salary with HR. Believe me, HRs are smarter than you in terms of salary negotiation.

The only thing we can do is prepare. I have made this mistake. I have realized it.

Don’t be dissatisfied if you have made such a mistake. I believe it’s okay if you’re learning new things in the new company. If there is no learning, you need to level up.

You can always expect what you want if you under promise and over deliver.

CommonJS vs ES modules

I love commonJS while building a server-side application. Unfortunately, there is a divide in the JavaScript ecosystem which is a long ongoing debate.

The issue with ‘require’ is that it is synchronous and works seamlessly assuming all files are readily available. But, within a browser context, where you might need to wait for external resources, the synchronous nature of require collapses the system.

When publishing a package, this compatibility problem — also known as the dual package hazard — makes it incredibly difficult because you must cater to both ES Modules and CommonJS users. If you only ship ES Modules, CommonJS users are left out, and vice versa.

Original Link