DEV Community: Robin Pokorny

Supermarket Meeting: The Secret to Cutting Down Useless Meetings

Robin Pokorny — Thu, 12 Sep 2024 10:17:13 +0000

Meetings. Whoever you are, I’m sure this word brings an emotional response.

Maybe you see them as a way to reach agreement, maybe you hate them with a passion, maybe you view them as a necessary evil. Maybe you even see them as a welcome break in your workday, maybe you think your reports see them like a welcome break.

Over the years, I’ve experienced meetings across the entire spectrum of quality, usefulness, and engagement. Some of my career bests have happened in meetings, and so have some of my worst moments.

The main rule I’ve developed for meetings is simple: When you’re there, be present.

That means no browsing, no Slack, no coding while the meeting lasts. If the meeting is bad, you have three options: actively make it better, call it out, or just leave. But when I’m there, I want to use the time as effectively as possible.

The Supermarket Over the Specialized Shop

When I plan my week or day, I want meetings to use the time they’re scheduled for—not more, not less. I dislike going overtime just as much as I dislike when the host suddenly ‘gives me 20 minutes back.’ On the same note, it’s annoying to receive a cancellation email for lack of topics just an hour before the start of a weekly meeting.

So when someone suggested a new meeting for a quite specific topic, I shared my concerns. Maybe it would work for the first two three sessions, but eventually, the topics would dry up, and the meeting would die out. Keeping a recurring meeting alive and interesting requires—surprisingly—a lot of work.

Then I realized we already have some recurring meetings that sometimes end sooner and sometimes get cancelled. It would be much better to expand their purpose to allow related topics. This way, we ensure that the allocated time gets fully used before starting anything new. By making meetings more saturated with diverse topics, we maximize their value.

A Supermarket Meeting is a consolidated approach to recurring meetings, where diverse topics are discussed in one weekly session, similar to how you’d buy various items in one trip to the supermarket. Instead of creating multiple specialized meetings for different subjects, a supermarket meeting gathers all related discussions into a single, regular time slot. This maximizes productivity, ensures efficient use of time, and keeps meetings engaging and relevant.

It’s like a supermarket visit where you buy all your groceries at once, instead of going to specialized shops—baker’s on Mondays, butcher’s on Tuesdays, and a wine shop on Fridays. One meeting, every week, same time, diverse topics.

A New Approach to Meetings

From now on, I plan to use a single weekly meeting as a "supermarket" for discussing anything relevant to Tech. A GraphQL schema question? Bring it on! Kafka learnings from your previous job? Sure! DataDog feeding itself quirk? Our inner geeks love that!

Then, if (or should I write iff?) we often find we don’t have enough time to cover everything, or that some areas would benefit from their own meeting, we’ll create a new slot.

I’m sure this approach will lead to more engaging meetings while adding some predictability to our schedules. Win, win.

Why Developers Should Stop Using ISO 8601 for Date-Time

Robin Pokorny — Mon, 07 Aug 2023 15:07:42 +0000

When documenting APIs, developers often link to ISO 8601 as the standard for computer-readable date and date-time format.

Dates and times (and time zones!) are complicated. There are so many edge cases and pitfalls. I’m sure every developer has a battle story about them. It’s good to delegate that hard work to somebody else. So when an international body that everybody knows and trusts publishes such a standard, it’s no surprise all the API designers start referring to it.

This is what an ISO 8601 date and date-times look like:

2023‐08‐07
2023‐08‐07T13:25:38Z

This is what we want to receive.

The ISO allows too much variability and it’s paid to read

Do you know what is also a valid ISO 8601 date-time?

2023-W32-1T15:38+02:00 (= Monday of the 32nd week in my local time zone)

How sure are you that your API will accept such a string? For example, JavaScript’s Date.parse will fail. There are many more allowed formats in the standard. And support for these is not guaranteed at all.

If you are thinking about creating a library that will understand all of them, I have bad news for you. There are four versions of the standard, released in the years 1988, 2000, 2004, and 2019, and they are not fully compatible with each other! Plus, you need to pay (about $190) to receive a copy of the standard.

Fortunately, there is a better way:

There are two better-suited (and free) standards

In your documentation, refer to either of these two standards:

RFC 3339
HTML (who would’ve guessed?)

Each of those allows just a small variation of that date-time we want: allowing space instead of T or not providing some parts. To my knowledge, all of those variations are generally supported. Moreover, the standards are precise and free to read for anybody.

If you want to be truly strict, I’d also include the format like so:

RFC3339 date-time in %Y-%M-%DT%h:%m:%sZ format

This is a very clear way to document your API.

Next time, just write RFC 3339 instead

When you find yourself typing ISO 8601 in your code or documentation, just replace it with RFC 3339 and continue knowing you made dates a tiny bit easier for you and your API users.

Replace null with ES6 Symbols

Robin Pokorny — Sat, 24 Jul 2021 12:31:59 +0000

When I was working on my small side-project library, I needed to represent a missing value. In the past, I'd used the nullable approach in simple settings and Option (aka Maybe) when I wanted more control.

In this case, neither felt correct so I came up with a different approach I'd like to present.

Why Nullable was not enough

Nullable means that when there is a value it is a string, a number, or an object. When there is no value, we use either null or undefined.

Tip: if you work with nullable types in TypeScript, make sure you turn on the strictNullChecks

This is often fine.

There are, in general, two cases when it's not:

The value can be null or undefined. In the end, these are both valid JavaScript primitives and people can use them in many ways.
You want to add some advanced logic. Writing x == null everywhere gets cumbersome.

In my case I was handling an output of a Promise, that can return
anything. And I could foresee that both of the ‘missing’ will be eventually returned.

In general, the problem 1 and 2 have the same solution: use a library that implements the Option type.

Why Option was too much

Option (sometimes called Maybe) type has two possibilities: either there is no value (None on Nothing) or there is a value (Some or Just).

In JavaScript/TypeScript this means introducing a new structure that wraps the value. Most commonly an object with a property tag that defines what possibility it is.

This is how you could quickly implement Option in TypeScript:

type Option<T> = { tag: 'none' } | { tag: 'some', value: T }

Usually, you would use a library that defines the type and a bunch of useful utils alongside. Here is an intro to Option in my favourite fp-ts library.

The library I was building was small, had zero dependencies, and there was no need for using any Option utility. Therefore, bringing in an Option library would be overkill.

robinpokorny / promise-throttle-all

🤏 Promise.all with limited concurrency

For a while I was thinking about inlining the Option, that is coding it from scratch. For my use case that would be just a few lines. It would complicate the logic of the library a bit, though.

Then, I had a better idea!

Symbol as the new null

Coming back to Nullable, the unsolvable problem is that null (or undefined) is global. It is one value equal to itself. It is the same for everybody.

If you return null and I return null, later, it is not possible to find out where the null comes from.

In other words, there is ever only one instance. To solve it, we need to have a new instance of null.

Sure, we could use an empty object. In JavaScript each object is a new instance that is not equal to any other object.

But hey, in ES6 we got a new primitive that does exactly that: Symbol. (Read some introduction to Symbols)

What I did was a new constant that represented a missing value, which was a symbol:

const None = Symbol(`None`)

Let's look at the benefits:

It is a simple value, no wrapper needed
Anything else is treated as data
It's a private None, the symbol cannot be recreated elsewhere
It has no meaning outside our code
The label makes debugging easier

That is great! Especially the first point allows using None as null. See some example use:

const isNone = (value: unknown) => x === None

const hasNone = (arr: Array<unknown>) =>
  arr.some((x) => x === None)

const map = <T, S>(
  fn: (x: T) => S,
  value: T | typeof None
) => {
  if (value === None) {
    return None
  } else {
    return fn(value)
  }
}

Symbols are almost nulls

There are some disadvantages, too.

First, which is IMO rare, is that the environment has to support ES6 Symbols. That means Node.js >=0.12 (not to be confused with v12).

Second, there are problems with (de)serialisation. Funnily, Symbols behave exactly like undefined.

JSON.stringify({ x: Symbol(), y: undefined })
// -> "{}"

JSON.stringify([Symbol(), undefined])
// -> "[null,null]"

So, the information about the instance is, of course, lost. Yet, since it then behaves like undefined—the native ‘missing value’)—makes it well suited for representing a custom ‘missing value’.

In contrast, Option is based on structure not instances. Any object with a property tag set to none is considered None. This allows for easier serialisation and deserialisation.

Summary

I'm rather happy with this pattern. It seems it's a safer alternative to null in places where no advanced operations on the property are needed.

Maybe, I'd avoid it if this custom symbol should leak outside of a module or a library.

I especially like that with the variable name and the symbol label, I can communicate the domain meaning of the missing value. In my small library it represents that the promise is not settled:

const notSettled = Symbol(`not-settled`)

Potentially, there could be multiple missing values for different domain meanings.

Let me know what you think of this use? Is it a good replacement for null? Should everybody always use an Option?

Note: Symbols are not always easy to use, watch my talk Symbols complicated it all.

Dictator paradox: Why micromanagement is so tempting

Robin Pokorny — Tue, 25 May 2021 21:34:13 +0000

I firmly believe all creative people hate when others tell them what to do. When instead of problems to solve, they are handled solutions to implement or, even worse, isolated tasks to just complete.

Yet, the world is full of micromanagers.

Over my career, I’ve heard countless complaints about how managers do not give their reports enough context, enough trust, enough freedom. That they decide all on their own.

Why is that?

Because micromanagement gets the thing done faster.

Well, kind of. Let me explain.

Dictators and complex systems

Originally a dictator (a micromanager is a local dictator) was a role in Ancient Rome, giving almost unlimited power to a selected individual during wartime. The appointment was for emergencies only and it was time-limited.

The idea was that one person would hold all the important information in their head and, because of that, they will make educated decisions fast. And during the war, a good decision today trumps a better decision tomorrow.

Having a dictator was actually very smart.

At wartime.

You see, a war (or a company, or a software system) is an example of a complex system. One crucial property of a complex system is that nobody can have a mental model of it that is complete.

That is, there were things (probably loads of things) that the Roman dictator did not count with and which harmed the people later. But, again, during the war, all is sacrificed towards winning it. Obviously, losing the war would harm all the citizens much more.

In other words, a dictator is a reasonable solution if fixing a single problem is all that matters. A dictator heavily favors a short-term solution over a long-term solution.

That is never the case in the real world of software engineering. While there are strict deadlines, meeting them with an exhausted team that is unable to continue is not acceptable. Neither is sacrificing the quality and maintainability of the architecture.

The project you are working on, however important it seems, cannot jeopardize the ability of the team to continue tackling the next projects. This includes piling the technical debt.

Why is that a paradox?

What I write might seem clear and obvious (I hope it is!). So, where is the paradox?

I define the Dictator paradox as the following:

Given a set of projects, every single project alone will be finished faster with a dictator. However, to finish all of the projects, decentralization and coöperation will beat any dictator.

This is the reason why people talk about self-organized teams, incremental delivery, and emergent design.

This is why the industry has replaced Waterfall with Agile development.

This is also why when the pressure makes a manager forget the context and perspective, they will start to micromanage.

After all: A dictator is a reasonable solution if fixing a single problem is all that matters.

TypeScript Enums I Want to Actually Use

Robin Pokorny — Sun, 18 Apr 2021 20:16:28 +0000

Since the very first moment I learned about TypeScript, I knew there's gonna be this one thing I'll always hate: Enums. So un-elegant, so old-school, and so why-do-you-pollute-my-runtime.

Well, I was wrong. I use Enums now. At least some of them.

Let me show you.

What is an Enum in TypeScript

First, let's quickly talk about what are Enumerators, or Enums for short.

An Enum in TypeScript is a well-defined collection of a limited number of cases. That is, we write down all possibilities and do not allow anything else.

The meaning of enumerations is that in the code you deal with only these few cases and you can be sure to deal with all of them. The compiler will warn if you forget to handle one or more.

Here are some common enumeration examples to give you a bette idea:

Directions: North, South, East, West
CardRanks: Ace, King, Queen, Jack, 10, 9, 8, 7, 6, 5, 4, 3, 2
DateFormats: Unix, ISO, Email

In this article, I'll be using countries my app supports as an example. This is how you write enums in TypeScript:

enum Country {
  Germany,
  Sweden,
  USA,
}

It is almost like a simple object. Notice that there is no equal sign, this is not an assignment. The definition looks similar to the definition of an interface.

There is one interesting property of an Enum: it defines both types and values. See some use here:

enum Country {
  Germany,
  Sweden,
  USA,
}

const setActiveCountry = (country: Country) => {
  //                               ^^^ this is a type

  // do something
}

setActiveCountry(Country.Sweden)
//               ^^^ this is a value

// @ts-expect-error
setActiveCountry('SE')

Playground Link

Note: I use @ts-expect-error in the code examples to mark there is a TypeScript error on the next line. This also suppresses the error, so you will not see it in the playground. Remove the line to see the error reported.

What's wrong with Enums

Right, that sounds kind of nice, what is the problem?

There are three main points, I've held against Enums since day one.

1. Enums introduce (ugly) runtime code

If you want to have a value available, it means that the value has to be there during runtime. That means Enums are one of the very few (and probably the only regularly used) TypeScript constructs that generate some code in the resulting JavaScript.

Usually, when the target is the current ECMAScript, all type definitions and annotations are just removed. That is because all other constructs like object literals, functions, or classes are the same in JavaScript as in TypeScript.

Look at how the Country Enum, defined above, ends up as:

var Country;
(function (Country) {
    Country[Country["Germany"] = 0] = "Germany";
    Country[Country["Sweden"] = 1] = "Sweden";
    Country[Country["USA"] = 2] = "USA";
})(Country || (Country = {}));

2. Enums are number-based by default

Do you see that code? Do you see those numbers 0, 1, and 2?

That is the actual value assigned to the country. So while you work with nice names, they are translated to numbers.

The generated code is practically equal to the following dictionary object.

const Country = {
  Germany: 0,
  Sweden: 1,
  USA: 2,
};

So when you want to debug your code and you log the country your function received, you get a cryptic number. Then you need to go and see the relevant version of the source code in TypeScript, count that number from the top, and then you have the name you actually wanted in the first place. Ugh, that is bad.

Another problem is that you can pass a number where Country type is expected. A maintenance headache about to happen on its own. But, you can actually pass any number, irrespective if it is defined in the Enum or not. Both of these calls will pass the type check:

setActiveCountry(1)   // 1 for Sweden
setActiveCountry(100) // 100 for ???

Sure, an Enum should be just a unique value. And the developer should not care about the runtime value and treat the Enum as opaque. However, the whole translation to numbers feels very old-school, a reminder of times where memory was expensive and numbers were used as a means of saving it.

I know there is a solution with string Enums (we will talk about them in a bit). Yet, I do not understand why the values could not be equal to the labels which are unique already. Or, when the target is ES2015+, the values could be Symbols – using them at a place they were created for.

3. Enums are not needed in TypeScript

Do you have to use Enums in TypeScript?

No, there are other ways to type a limited number of cases.

I see people avoiding Enums in many ways. Either on purpose or out of habit. And, of course, you do not need them to write good code.

Before I show you how I'm using Enums now so that I'm comfortable with them, let's explore these common alternatives and discuss their pros and cons.

Alternatives to Enums

Disjoint union of literal types

A rather straightforward option is to define a type that consists of all the actual strings (or other values) that are permitted. This is called disjoint or discriminated union; see Discriminated Unions in TypeScript docs.

type Country = 'DE' | 'SE' | 'US'

const setActiveCountry = (country: Country) => {
  // do something
}

setActiveCountry('SE')

// @ts-expect-error
setActiveCountry('CZ')

Playground Link

As you can see this approach correctly types the function. The problem is that there are ‘magic’ strings all over the place. Sure, for my example the strings are actually somewhat self-explanatory. But let's imagine that instead of ISO 3166-1 two-letter country codes we would be using ISO 3166-1 numeric country codes:

type Country = '276' | '752' | '840'

const setActiveCountry = (country: Country) => {
  // do something
}

setActiveCountry('752')

// @ts-expect-error
setActiveCountry('203')

Playground Link

While technically equivalent to the previous, this is now utterly unreadable and error-prone.

Disjoint union of iteral types with constants

What can we do to remove those ‘magic’ strings? Let's save the values to constants:

const GERMANY = '276'
const SWEDEN = '752'
const USA = '840'
const CZECHIA = '203'

type Country = '276' | '752' | '840'

const setActiveCountry = (country: Country) => {
  // do something
}

setActiveCountry(SWEDEN)

// @ts-expect-error
setActiveCountry(CZECHIA)

Playground Link

Now, that sure is better. The constant's name tells the developer what they work with.

This is, in fact, a way that is popular in the Redux community for Redux actions (Or, should I say was popular?).

Still, we can identify problems. First, nothing forces you to use these constants. So if it slips the usually meticulous reviewer's eye, you can end up with a mixed approach: constants and magic strings. Second, the code is not very elegant, we either have to repeat the value in the type definition or use a strange-looking typeof operators. In either way, adding or removing means a change in two places.

Constant dictionary

Hmm, maybe there is a way to combine them all in one. When we look at the code generated for an Enum, we might think: can we just use that dictionary in the first place?

This works. And it is really close to Enum:

const Country = {
  Germany: 'DE',
  Sweden: 'SE',
  USA: 'US',
} as const

type Country = typeof Country[keyof typeof Country];

const setActiveCountry = (country: Country) => {
  // do something
}

setActiveCountry(Country.Sweden)

// @ts-expect-error
setActiveCountry('CZ')

Playground Link

Weel, it's not terrible. But it's not great either.

Let me go through some points to keep in mind.

The dictionary has to be declared as const. This prevents the type engine to infer the type as general dictionary Record<string, string>. This is OK.
The Country dictionary is a value and not a type. We need to define the type separately. It's a cryptic command, one I always have to google – not so OK. Fortunately, the type can be named the same as the dictionary, so from now on it's the same as Enum, right? Well, no.
As in the previous case, nothing truly ties the dictionary to the function arguments. Calling setActiveCountry('SE') raises no error. The Country type is, in the end, just another disjoint union of iteral types again. The benefit is that changes are made only in one place. This is Boo (or at least Meh).

Enums the right way my way

For years, I'd been using the previous techniques to avoid Enums.

And then one day on one PR someone asked: ‘Why?’.

I was in the middle of my reply when I decided to fact-check some points and, …, and I discovered how wrong I'd been. There were two important properties of Enums that made them superior to anything else. Even for people that worry about moving back to vanilla JavaScript one day.

String Enums

Instead of depending on the source code order to define the value of an option in an Enum, you can define it yourself.

The following code is so close to the dictionary example above, just much cleaner.

enum Country {
  Germany = 'DE',
  Sweden = 'SE',
  USA = 'US',
}

const setActiveCountry = (country: Country) => {
  // do something
}

setActiveCountry(Country.Sweden)

// @ts-expect-error
setActiveCountry('CZ')

// @ts-expect-error
setActiveCountry('SE')

Playground Link

Again, let's discuss some more or less obvious observations:

It uses equal sigs, not colons. Do not ask me why. Still, it's very close to object literal.
The values must be all strings. Other values are not supported. (Technically, numbers can be used, but they bring no advantage. Stick to strings.)
You have to use the Enum values anywhere (for example Country.Sweden) where an Enum value is expected. Passing the same string doesn't work (for example 'SE'). This makes refactoring a headache-free process. And your codebase stays consistent.
However, it's not all unicorns and rainbow. The generated code is a) still there and b) still (kind of) ugly.

‘How on earth you want to improve that, Robin?’ you might ask

You're in for a treat.

Constant, string Enums

The second improvement that helped me cross the Enum Rubicon (‘The type is cast!’, sorry, sorry, I had to) is constant Enum or const Enum for short.

How does it look like?

const enum Country {
  Germany = 'DE',
  Sweden = 'SE',
  USA = 'US',
}

const setActiveCountry = (country: Country) => {
  // do something
}

setActiveCountry(Country.Sweden)

// @ts-expect-error
setActiveCountry('CZ')

// @ts-expect-error
setActiveCountry('SE')

Playground Link

Wait, wait, I'm not pulling your leg.

It is a letter-to-letter, carbon copy of the previous code, except for the addition of the const in front of the enum.

The functionality is exactly the same, too. Looking at the list items above: 1. is the same, 2. is the same, 3. is the same, 4. is… NOT the same!

There is no code generated for the const Enum. This is what the output of the previous code look like:

const setActiveCountry = (country) => {
    // do something
}

setActiveCountry('SE' /* Sweden */)

Yes, all the values are now inlined in the place of use. There is no clue that there ever was an Enum. Except, maybe, for the helpful comment.

In the end, the result is the same as in the very first alternative we talked about: the disjoint union of literal types. Yet, it is so much easier to use and safer in all regards.

To summarize, with constant, string Enums you get all the benefits of string Enums (type checking, debuggable, not replaceable by string) and of writing it directly (no extra code).

Constant Enums are a one-way street

Before we go next, I need to warn you about const Enums. They are not a drop-in replacement every time.

What's the issue? There is no way to get a label for a value. You see, there is no dictionary, there is no code generated at all. So if you have value, say 'SE', and you want its label for logging, Sweden in this case, you will not be able to.

That is a small inconvenience, you should keep in mind.

Also, if you need to access the labels for something else than logging, it might mean that Enum is not for you. Enum labels should have a meaning only for the developer.

Constant Enums can be huge

One great use case I found of constant Enums, is that you do not care about the number of items in an Enum. There could be a const string Enum of all the countries in the world and if you only use there, just these three will make it to the production code. The rest would just disappear. And code autocomplete still works with no issue.

In our service code, we now have a share const string Enum with all existing HTTP response codes (excerpt):

export const enum Success {
  OK = '200',
  Created = '201',
  // …
}

export const enum ClientError {
  BadRequest = '400',
  Unauthorized = '401',
  PaymentRequired = '402',
  Forbidden = '403',
  NotFound = '404',
  // …
}

// …

export type HttpStatusCode =
  | InformationalResponse
  | Success
  | Redirection
  | ClientError
  | ServerError

What makes a great Enum

Const string Enums.

That's it.

That is what I now use everywhere.

Before commit, I make sure each Enum fulfills the following two conditions:

All Enum options have a defined custom string value.
The Enum is declared as const.

I think this combines the benefits of TypeScript with the eloquence of pure JavaScript. A superb developer experience with close to zero impact on the result.

Do you use Enums in your code? Do you avoid language features that are not considered for ECMAScript? Tweet a reply

Engineering Managers Should Not Have the Best Tech Skills in Team

Robin Pokorny — Fri, 19 Mar 2021 21:57:41 +0000

Recently I was re-reading one of my favorite engineering articles The Trident Model of Career Development by Patrick Kua. The sentence that caught my eye this time was a note about the role of a Tech Lead:

They should have good but not necessarily the best [tech] skills in the team they are leading.

‘How does this apply to an Engineering Manager?’ came to my mind instantly. And my initial response was that it's the same. Yet, after some more thought and thinking about the Engineering Managers I've met, I was not sure. Then I made my mind: no, it's not the same. Now, I think that it is actually dangerous when an Engineering Manager has the best tech skills in the team.

Let me show you why.

1. They cannot utilize it

Becoming a manager is a big lateral step for an engineer. While they can draw from their tech experience, being a manager requires a very different set of skills, and–what makes it even more challenging–many of these will be completely new for them. There are so many activities that are not coding, reviewing, or architecting. The new manager simply doesn't have the time to use their tech skills as they did before. That means that the team and the company now lost a significant portion of tech contributions.

The team is not the only one who is unhappy about it; in fact, and I'll bet on this, the manager is even more unhappy about it themself. In my previous experience, I saw many brilliant senior engineers who wanted to grow and become an Engineering Manager seemed so natural. Often they were told that the new responsibility will only mandate 10 or 20 % of their time. What a lie that was, as they soon found out.

There were three outcomes I've witnessed: not many of the managers accommodated and let the tech go (at least partially); some felt guilty and coded in overtime; and quite a few decided that management was not for them and went back to senior engineers. (A side note for the last case: since becoming an Engineering Manager is often seen as a promotion, most of them rather left the company and applied to a senior engineering position elsewhere.)

2. They will be a bottleneck

Connected closely to the previous point, the team might be waiting for code contributions, PR reviews, or comments on RFCs longer.

The number one comment I hear from new managers is about the number of meetings they are expected to attend. This not only deducts from their hours in a day directly but because of the workday fragmentation and constant context switching it is more difficult to find a longer time for uninterrupted work in between the meetings.

This will become a big issue when the task is extremely time-sensitive, like when there is an incident and the best person available should lead the detailed debugging. While avoiding huge losses for the company, the manager will build up a personal debt of materials they need to read, meeting recordings they need to watch, and postponed decisions they need to make.

3. They will cause sub-optimal decisions

Speaking of decisions, there is a significant risk that the team will make some bad tech decisions. Or at least not as good decisions.

Why? In simple words, it's difficult to disagree with the person who evaluates your performance and decides on your salary, bonuses, and promotions. This whole desire to please one's superior might very well be subconscious. Yet, it creates a disbalance that might result in worse tech decisions made.

There are some great stories about preconceptions the managers had to fight in Kim Scott's Radical Candor.

I'm not saying that it is not possible to avoid it, but it requires that the manager is aware and puts some compensation processes in place. They also have to work on increasing the level of psychological safety among the team members.

What should I do when this is my case?

Are you a manager that has the best tech skills in the team? Do you wonder what to do next?

First, this is a fairly common scenario and I know many teams like that that work just fine. The key is to acknowledge that there are some potential risks and be vigilant about their signs.

The best, however, is to stop being the tech go-to expert in the team. Of course, that doesn't mean you should become worse or leave your manager post. It means actively working on growing your report's skills. It means extensive knowledge sharing. It means grooming your successor (or successors).

Lastly, you should become comfortable in your position. Accepting and embracing that there will be people better than you in technology, in skills you've been so proud to possess. Knowing that the value you bring has shifted from individual strengths to multiplying strengths of others.

Are you an engineering manager that balances tech and people skills? Who do you think should be best at tech in a team? Tweet a reply

People, Product, and Technology: A Beginner’s Guide to Engineering Management at Toptal blog
The Trident Model of Career Development by Patrick Kua
5 Engineering Manager Archetypes by Patrick Kua

Are open-source databases dead? [Quora answer]

Robin Pokorny — Fri, 05 Mar 2021 19:36:47 +0000

This is an answer to a Quora question: Are open-source databases dead?.

Yes, they are dying (this is no joke answer).

Sure, many open-source databases are being used and maintained every day. And, of course, any open-source software will exist and can be forked by anybody. So on the technical level, they cannot die.

However, we have seen several big open-source databases die in the past years. MongoDB, Redis, CockroachDB, TimescaleDB, and–most recently–Elasticsearch. All of those databases ceased to be open-source.

Let me show it on the example of MongoDB and Elasticsearch. Both of the companies behind the databases decided to switch to Server Side Public License (SSPL) which is not considered to be an open-source license. Since this license allows free (as in beer) use for some use cases we will likely be seeing them for quite some time. It’s nevertheless a death of an open-source project.

The reason cited by both projects is… Amazon. More specifically AWS. You see, Mongo and ES were developed by companies and these companies not only lead the project development, but they also hold the trademarks etc. They both also make money on providing some services for their DB, be it consulting, paid extensions, or DBaaS (database-as-a-service) hosting. Historically, publishing open-source software and making money on the services worked great and for many companies, it was a viable business strategy (yes, open source is a business strategy).

In the world of AWS (and other cloud providers) it creates an asymmetrical relationship: AWS can provide and charge for their DBaaS based on an open-source database while paying nothing back to Mongo or Elastic (Amazon has the manpower to support it themselves even on large scale). Which is completely OK under the open-source licenses.

Both of those companies realised that their business strategy was wrong and open-sourcing their DB was a mistake (from the business point of view). So they changed the license to a non-free (as in speech) and non-open one. This created some controversy as relicensing open-source is generally not possible, they took advantage of a clause in CLA that every contributor had to sign.

(Side note, this lowered already low trust in CLAs. A problem for some mostly big companies, that feel they need some extra intellectual property protection and still want to have an open-source program.)

If I were starting a business in providing a database engine now, I’d really think about open-sourcing it based on the experience of Mongo and Elastic. And we see exactly that already, with DBs like Fauna or Firebase not being open-sourced at all.

So I think that open-source databases are dying because we might see less and less of them published in the future.

And just like that, Amazon Web Services forked Elasticsearch, Kibana. Was that part of the plan, Elastic? on The Register
Elasticsearch does not belong to Elastic on Drew DeVault's blog
Doubling down on open, Part II on Elastic blog
Why We're Relicensing CockroachDB on Cockroachlabs blog
How we are building a self-sustaining open-source business in the cloud era (version 2) on Timescale blog

Index as a key is an anti-pattern

Robin Pokorny — Fri, 22 May 2020 12:03:16 +0000

This article was cross-posted from Medium, please use also the discussion there.

Index as a key is an anti-pattern (React) | by Robin Pokorny | Medium

Robin Pokorny ・ Aug 4, 2022 ・
Medium

So many times I have seen developers use the index of an item as its key when they render a list.

{
  todos.map((todo, index) => <Todo {...todo} key={index} />);
}

It looks elegant and it does get rid of the warning (which was the ‘real’ issue, right?). What is the danger here?

It may break your application and display wrong data!

Let me explain, a key is the only thing React uses to identify DOM elements. What happens if you push an item to the list or remove something in the middle? If the key is same as before React assumes that the DOM element represents the same component as before. But that is no longer true.

Stephen describes the problem he run into on egghead.io

To demonstrate the potential danger I created a simple example (with source).

Screenshot of the example showing the danger of using the index as key.

It turns out, when nothing is passed React uses the index as key because it is the best guess at the moment. Moreover, it will warn you that it is suboptimal (it says that in a bit confusing words, yes). If you provide it by yourself React just thinks that you know what you are doing which — remember the example — can lead to unpredictable results.

Better

Each such item should have a permanent and unique property. Ideally, it should be assigned when the item is created. Of course, I am speaking about an id. Then we can use it the following way:

{
  todos.map((todo) => <Todo {...todo} key={todo.id} />);
}

Note: First look at the existing properties of the items. It is possible they already have something that can be used as an id.

One way to do so it to just move the numbering one step up in the abstraction. Using a global index makes sure any two items would have different *id*s.

todoCounter = 1;

function createNewTodo(text) {
  return {
    completed: false,
    id: todoCounter++,
    text,
  };
}

Much better

A production solution should use a more robust approach that would handle distributed creation of items. For such, I recommend shortid. It quickly generates ‘short non-sequential url-friendly unique’ ids. The code could look like the following:

var shortid = require("shortid");

function createNewTodo(text) {
  return {
    completed: false,
    id: shortid.generate(),
    text,
  };
}

TL;DR: Generate a unique id for every item and use it as key when rendering the list.

Update: Exception from the rule

Many people asked if they always, always have to generate ids. Others have suggested use cases when using the index as a key seems justifiable.

It is true that sometimes generating new ids is redundant and may be avoided. For example translation of license terms or list of contributors.

To help you decide, I put together three conditions which these examples have in common:

the list and items are static–they are not computed and do not change;
the items in the list have no ids;
the list is never reordered or filtered.

When all of them are met, you may safely use the index as a key.

Update 2: React, Preact, and *react

Although in this article I write about React, the problem is not exclusive to it. In similar libraries, like Preact, the danger is present, too. However, the effects can be different.

See the following StackOverflow question, where the last element disappears. Also please note the explanation in the answers provided by the creator of Preact, Jason Miller: Wrong components rendered by Preact.

References and related articles

Dynamic Children and Keyed Fragments in React Docs
Explanation from Paul O’Shannessy
The importance of component keys in React.js
React.js and Dynamic Children — Why the Keys are Important
React animations for a single component, section The key is using key
Why you need keys for collections in React by Paul Gray

DEV Community: Robin Pokorny

Supermarket Meeting: The Secret to Cutting Down Useless Meetings

The Supermarket Over the Specialized Shop

A New Approach to Meetings

Why Developers Should Stop Using ISO 8601 for Date-Time

The ISO allows too much variability and it’s paid to read

There are two better-suited (and free) standards

Next time, just write RFC 3339 instead

Replace null with ES6 Symbols

Why Nullable was not enough

Why Option was too much

robinpokorny / promise-throttle-all

🤏 Promise.all with limited concurrency

Symbol as the new null

Symbols are almost nulls

Summary

Dictator paradox: Why micromanagement is so tempting

Dictators and complex systems

Why is that a paradox?

TypeScript Enums I Want to Actually Use

What is an Enum in TypeScript

What's wrong with Enums

1. Enums introduce (ugly) runtime code

2. Enums are number-based by default

3. Enums are not needed in TypeScript

Alternatives to Enums

Disjoint union of literal types

Disjoint union of iteral types with constants

Constant dictionary

Enums the right way my way

String Enums

Constant, string Enums

Constant Enums are a one-way street

Constant Enums can be huge

What makes a great Enum

Engineering Managers Should Not Have the Best Tech Skills in Team

1. They cannot utilize it

2. They will be a bottleneck

3. They will cause sub-optimal decisions

What should I do when this is my case?

Related articles

Are open-source databases dead? [Quora answer]

Related articles

Index as a key is an anti-pattern

Index as a key is an anti-pattern (React) | by Robin Pokorny | Medium

Robin Pokorny ・ Aug 4, 2022 ・ Medium

It may break your application and display wrong data!

Better

Much better

TL;DR: Generate a unique id for every item and use it as key when rendering the list.

Update: Exception from the rule

Update 2: React, Preact, and *react

References and related articles

Robin Pokorny ・ Aug 4, 2022 ・
Medium