## The problem with waterfall

![Interaction design (ID), visual design (VD) and front-end development (FED) working with a waterfall approach](/img/articles/design-front-end-development-waterfall.png)*Interaction design (ID), visual design (VD) and front-end development (FED) working with a waterfall approach*

A traditional way of collaboration between visual design, interaction design and front-end development is the waterfall technique with a review moment. Visual and interaction designers work together to produce a static design. Front-end developers translate this design into interactive components. At the end of this process, there's a moment to review the implementation by all parties.

The problem with this approach is that design and front-end development produce output for vastly different mediums. Often, designs are made in tools like Sketch, Figma or the Adobe suite. The tool outputs static images. For front-end development, the output is for a virtually unlimited variation in mediums. There are functionalities in these design tools to create interactive designs, but they don't offer the vast range of devices, browsers, screen sizes and other factors.

> In front-end development there is no one-size-fits-all

This causes issues when a design is made for a limited number of these variations (usually being a mobile, tablet and desktop viewport). Design issues or potential opportunities arise late in the production cycle. I often see that the time and capabilities to resolve these are limited at this stage. Most of these issues can be prevented by not just leveraging design handoff in the browser, but changing the approach to how design and front-end development work together.
## Several stages of design and development collaboration

![Interaction design (ID), visual design (VD) and front-end development (FED) working together in different stages of producing components](/img/articles/design-front-end-development-fluid.png)*Interaction design (ID), visual design (VD) and front-end development (FED) working together in different stages of producing components*

Front-end development at my company Mirabeau, a Cognizant Digital Business, is in the same unit as visual design and interaction design. This structure has been set up for tight collaboration between these disciplines. In projects as a front-end developer, I've identified six major stages where design and front-end development can take advantage of each other's view, experience and skillset.

### 1. Concepting
During the concepting phase, design often works with stakeholders and users to identify what the problem is and how they can solve it. Even though there isn't a line of code being written yet, this is where front-end development can help in identifying issues early on and, perhaps even more important, suggesting potential opportunities. For example, there is an ask for an incredibly important alert component. Did you know that on some mobile browsers you can use the phone's vibration to give haptic feedback? By involving front-end development in the concepting phase, these kinds of opportunities can contribute to a better solution for the user.

### 2. Design production
After this front-end development can assist design during the actual production phase. A tight collaboration in this phase adds a lot of value by having a back-and-forth between disciplines. Design can actively seek input from front-end development when taking the solution from concept to an actual design that will be implemented. Due to diversity in view, experience and skillset, both design and front-end development push each other to see problems through different eyes. This always leads to a better thought-out and considered result.
### 3. Design review

Once the design production is done, there is a moment for front-end development to do a final review. Design and front-end development go over the proposed solution, see if everything is clear and whether there are still improvements to be made. For example, front-end builds in reusable components and sizings. Does the proposed design suddenly use vastly different sizings? Is there really the need for a new kind of dropdown component? These questions can be asked to ensure consistency, preventing reinventing the wheel and more.

### 4. Browser handoff
Next, front-end development builds the design. This is where the most vital part of the approach lies. There is no way you can predict and prevent all potential issues you will encounter. With real content or data, the fluidity of the web and different context in which design is used you're bound to find problems. For example, a narrow component with a welcome message does not fit on an in-between screen size due to a longer name. During the design phase, two things weren't accounted for. First, a design was made for mobile and tablet. What about right in between? Second, during the design phase, the default persona was used with a name eight characters long. With production users, there can be a wide range of lengths of users' names.

Luckily, design and front-end development have been working tightly together online or in person. They work together in the browser to identify the specifics of the issue, brainstorm options and build the solution in the browser together. The disciplines come up with the solution together when there is an unusually long name. There is no need to update all the actual designs. In the end, we all work together to build for the web. Our single source of truth lives there and this is where we collaboratively craft our final version.
### 5. Development review
After front-end completes their work, there is a final session between design and front-end development to dot the i's and cross the t's. I've noticed a lot of designers I worked with who are really appreciative of this moment. Together design and front-end development go over the final implementation. Are there some things that front-end development missed? Are there some things the design would like to alter based on the actual interactive product?

> Here's where we perfect our creation together

I've asked my colleague and interaction designer Virginia Rispoli what she thinks about browser handoff and the development review. Virginia loves that you can finally see the interactions and designs in action. This usually allows both design and front-end development to look at the ideas, features and components a bit more critically. To her, this is the moment where the superpowers and skills of design and front-end development come together. If both are open enough to discuss and rethink their ideas, the result is always better than the initial idea.

These points are further solidified by my colleague and visual designer Alexander Munz. He states that the advantages of design handoff in the browser are diverse. It’s a great opportunity to collaborate between development and design; seeing, feeling and anticipating behaviours on an iteration of the end-product offers the opportunity to discover, change and adapt quickly. Design handoff in the browser and collaboration offers the opportunity to learn from each other, create better solutions and do this a lot quicker then re-designing a static screen in your design tool of choice. The team saves time, which gives the client more value for their money and they can even be part of the fun if they choose to be.
### 6. Documentation
Lastly, we document our single source of truth. There's already a static design, so what's the point of documenting the component again? Besides developer-documentation on how to work with the component, we want to document the interactive component in a way where you can view it in all the contexts you'd like.

![Storybook showcasing a badge component](/img/articles/storybook.jpg)*Storybook showcasing a badge component*

A good solution for this is an interactive component showcase library, the best-known among them being [Storybook](https://storybook.js.org/). Storybook offers a flexible UI for both design and front-end development to not just view and interact with the components, but alter them as well. With the wide range of features and plugins you can dynamically change the content (e.g. change the name in a component to more characters), test different screen sizes and more. This fluid version of showcasing the design implemented in interactive components is most flexible.

Finally, documenting all existing interactive components and variations gives the team a place to reference. For example, design might check whether there's already a dropdown component, developers look up what variants they can use and copywriters can see what happens when they change certain labels.
## Get started in your team
Excited to try a similar approach? There are a few people you might want to open the discussion up to. First, open up the discussion with your design and front-end development team. Try to see if you ever ran into some of the issues I mentioned above. In my experience, design is often very open to more moments of working together with front-end development.

Second, you might work in a scrum team. Propose this new way of working together as design and front-end development to your project manager and scrum master. It might be a bit too much to completely overhaul the current workflow you have. Start with one new component. If it works, try it again and again.

Finally, you might have to persuade certain stakeholders. This will be on a case-by-case basis. Time, costs and resources however are an often-heared concern. You are asking for more time together to craft the best work possible. An immense benefit of this new approach is that you actually resolve many of these concerns. You tackle (potential) issues early on. This costs time at the start of the trajectory, but you earn this back by mitigating the surfacing of these issues at the end or even in production. You could use the components you build while trying out this workflow as examples to get them on board.

Try to see if this way of working works well for your team. This doesn't work for you? That's fine as well. The goal is to further improve cross-discipline collaboration and ensure you build your best work together!

Design handoff in the browser

## Why did I need this?
I'm a fairly social (read easily distracted) guy. In an office setting, this causes some self-inflicted issues for me. On the one hand, it's great to interact with all my colleagues, on the other hand, I lack the prolonged focus to be productive. It's easy to blame others for this, but why does it get even worse while working at home?

What I noticed is that verbal communication shifted to digital. Having a digital wall between you and the person trying to reach you is a big culprit in the daily interruptions in your work. In an office, people can see you working focussed with your fancy noise-cancelling headphones on and determine whether they should bother you with what they're about to say or ask. With everybody working at home this short moment of hesitation is gone.

The basic advice people give is to turn off notifications and batch reply to all of your messages. For me, this is easier said than done. Let's say I respond and start a task, I usually get a message back after a few minutes. There is this urge for me to respond as quickly as the person I'm talking to. Should I now keep chatting with everybody for a while or interrupt my flow continuously? It all feels very unstructured.

I researched some ways to keep focussed while still be able to alternate between different task like coding, communicating and coffees. You know, the big three C's! In my search, I stumbled upon the well known Pomodoro technique for time-management developed in the late 1980s by university student Francesco Cirillo. I've heard about it before but never really tried it out as I often feel fatigued by all these techniques everybody swears by until it's time to make the next blog or video.

The Pomodoro technique helped me with improving my productivity without turning it into a large task itself. It felt very natural to work with and I will continue working this way in the future.
## How does it help?
Great, so how does it help and work? In short, you divide your day into 25-minute sessions to work on smaller tasks. You set a Pomodoro (named after the tomato-shaped timer) for 25 minutes. You don't stop working on your task while that timer is running for anything. Well, if your house is on fire you might want to break the rules a bit. After the timer runs out you have a short break of five minutes. During this break, you might stretch your legs, make a coffee or stare out the window contemplating life. The important point here is that you detach from your working state. After the five-minute break timer runs out, you start another Pomodoro for 25 minutes. After four 25-minute Pomodoro's you take a longer break of 15 minutes. You repeat this pattern for your entire day using these fixed sections to focus on a single task.

There are numerous benefits by doing this as described [here](https://todoist.com/productivity-methods/pomodoro-technique). What worked well in particular for me is having fixed time slots without putting them on a calendar. I've tried planning my calendar by the minute for an entire day before. This gave me a state of anxiety of having this calendar standing over my shoulder and continuously feeling like a was "catching up". With the Pomodoro technique, I have the structure of time slots without worrying if I'm a few minutes behind on some things.

Next, it helped me to break down seemingly gigantic tasks into smaller chunks of work. This doesn't just give me more structure but comes with a second benefit. I'm more easily able to mix these tasks throughout my day. I can focus on singular tasks while still work on different larger tasks during the workday at the same time. This, to me, is the most vital improvement to my productivity and state of mind.
## What did I make?
Luckily, to use this technique all you need is the timer on your phone or computer. But where's the fun in that? I'm a front-end developer. I can make something cool! As part of my learning goals this year I want to build a few small projects with the focus on design. I often get caught up in the engineering side of front-end development and want to work on some more creative projects as well. For this, I picked a few front-end challenges from [frontendmentor.io](http://frontendmentor.io/challenges). One of the challenges happens to be a Pomodoro timer. That sounds like a perfect match!

The logic for a timer is fairly straight-forward. You either set an interval or recursive function that calls itself after a timeout. The timer then makes a short alarm sound. The reason I picked the challenge of the Pomodoro timer is the neumorphic design. If you're not familiar with the term, it's a design style successor to skeuomorphic design. The goal of skeumorphism is an affordance for the user by using known real-life things. A folder on your computer looks and is named like that as it directly reflects a real-life folder used by people. Therefore, people know what it is and what it does before needing to learn about it.

Neumorphism is not as focused on affordance as it is to give depth to interfaces. After the flat-design hype that you've seen in nearly every digital interface the past few years, this design style seems to focus more making it clear to users where elements are to each other on a "stack level". I'm not sure about the affordance benefits, but I do think it looks refreshing and very cool!
### Design
![Pomodoro](/img/articles/pomodoro-hero.jpg)*Neumorphic Pomodoro*
As you can see, the tabs at the tab are flat-design. The timer itself however seems to protrude from the background. It's clear that this is the most important element on the screen and I can interact with it. The way this effect is done is through shadows on the screen the contrast between dark and light shadows make it look like the timer itself is "higher" of the background. I used neumorphism to create the base effect in box shadows for CSS. I then tweaked the size and colour values to the point I was happy with the result. A fairly simple, but refreshing design to see on the web which at this point is flatter than the Netherlands.
### Interactivity
![Pomodoro settings](/img/articles/pomodoro-settings.jpg)*Settings*
The second part of the challenge is to let the user set different values for the timers, choose a font and set a different primary colour. Through this modal, the user can tweak how the website works and looks. For the font and primary colour, I used CSS-variables. Whenever the user makes a change, I update the corresponding variable and the browser updates the screen accordingly.
### Progressive Web App?
![Pomodoro Progressive Web App on MacOS](/img/articles/pomodoro-pwa.jpg)*Pomodoro Progressive Web App on MacOS*
My Pomodoro app just needs some static files to work. I added a service worker to cache all the static files and serve them if my server is down or internet connectivity is lost. This ensures that the app will always work. Next to that, I added a manifest with some more information about the app. This turned my app into a Progressive Web App (PWA). Besides the before-mentioned offline capabilities, the app can now be installed on desktop, tablet and mobile devices as well. This makes it easier to quickly open the Pomodoro from the device you're working on.
### Demo
If you made it this far, you probably want to try it out. You can do so by visiting [pomodoro.davebitter.com](https://pomodoro.davebitter.com/). You can view the individual components through Storybook at [pomodoro.davebitter.com/components](https://pomodoro.davebitter.com/components). Finally, developers can head over to [github.com/DaveBitter/pomodoro](https://github.com/DaveBitter/pomodoro) to look at the source code.
## Wrapping up
This technique, or rather part of this technique, works for me. It might not for you and that's fine. I suggest to try it out for a day and see what you think. I noticed a welcome change in how I structure my days and do my work. As always, thanks for reading and I see you in the next one!

I build a neumorphic Pomodoro to stay sane

## Ultra quick setup
Many of the people I speak to regarding [React.js](https://reactjs.org/) use [Create React App](https://github.com/facebook/create-react-app) (CRA) to quickly bootstrap applications. It would be great if [Next.js](https://nextjs.org/) had something similar. Let's call it Create Next App (CNA). Well, it exists! [Vercel](https://vercel.com/), the company behind Next.js has created [CNA](https://nextjs.org/docs/api-reference/create-next-app). Let's have a look.

![yarn create next-app](/img/articles/create-next-app-command.png)

You will be guided to an interactive setup that will just ask you for a project name. After that, all the required node modules will be installed and a very basic Next.js app will be bootstrapped. You could opt-in for a TypeScript variant as well. The output should look something like this:

![Outputted Create Next App folders](/img/articles/create-next-app-folders.jpg)*Outputted Create Next App folders*

Note: you can ignore the `pages/api` folder for now. If you are interested in the feature you can have a read at my article ["Next.js API routes"](https://www.davebitter.com/articles/next-js-api-routes).

For those who are familiar with CRA, this will look very familiar. Besides all the build tools, CNA outputs a simple home page with an image and some styling. As you can see, by default CSS modules are used. If you want to add something like SCSS you can easily do so by installing SCSS. Next.js will just work. Next to all of this, CNA comes with the development tools that you'd expect it to like, for instance, hot-module reloading. In my experience, the way you alter your CRA project for things like linting and rules is very similar in CNA. Please refer to the documentation if you want more details. That's it, you are now ready to start developing!

![yarn dev](/img/articles/create-next-app-dev.png)

![Create Next App default page](/img/articles/create-next-app-boilerplate-page.jpg)*Create Next App default page*

## Building your first page
Naturally, Next.js documented all you need to know very well. Let's have a quick look however how we can build our first page.
### Standard route
The `pages` folder is a special folder by Next.js. Basically, every file in this folder translates to a route. For example, by default, you see an `index.js` file. This gets build into `/index.html`.  So what if we want to create an about page. Well, we make a file called `about.js` and return a React.js component. In this case a functional component:

![Created "about" page](/img/articles/create-next-app-about-page.png)*Created "about" page*

If you go to `/about` in your browser you will see that you now have an about page. This is all you need to do to create pages. Creating folders works as you expect it to. `pages/contact/socials.js` will translate to `/contact/socials.html`.

From here on out you can write all the same React.js code you are familiar with for every page. As you might have guessed, you can use [Next links](https://nextjs.org/docs/api-reference/next/link) to take care of your client-side routing.
### Dynamic routes
So what if we need to use dynamic routes. In the case of my blog, I have various articles under `/articles/... .html`. It wouldn't make sense to create a separate file for each new article. This is where dynamic routes come in. You can use the special bracket notation to indicate to Next.js that a part of the route is dynamic. In the case of the example of the articles, we can create a file under `pages/articles/[slug].js`. Whatever you put as a slug now in the URL will be mapped to this file. There is one small addition you need to make that we'll cover in the next chapter.
### Special page files
As you may have noticed, there is a file called `pages/_app.js`. Next.js has a couple of special files which are prefixed with a `_`. This specific file is exactly the same as the file you might have worked with in a CRA React.js app. It is a sort of "wrapper component" around your page. Here, you could for instance load a header, navigation and footer component that will be loaded for each page. Next to this file, there are a few more. `pages/_error.js` is a page that will be loaded if there is a critical error. You can create a bit of a nicer page than the default one if you want. Finally, there is a `pages/_document.js` page which is a "wrapper-page" around the `pages/_app.js` where you can load for instance some external scripts or set meta-information in the `head`. Please refer to the documentation for these pages to learn more.
## You can stop here
Great, that's the basics. We now have React.js pages build with Next.js that will be rendered server-side. Next.js takes care of the development environment and build process with things like automatic code-splitting, minifying and post-processing. You can stop here for now or take it up one notch and really get the benefits of Next.js.
## A short introduction to server-side functions
By far, having server-side functions is one of Next.js's biggest features. It may sound a bit daunting at first, but let's look at some practical examples of how to use it.
In essence, these functions run on the server, or during build time, before the page gets loaded in the client. These functions can, for instance, fetch some needed data on the server, return the data as a React.js prop to the page and be rendered on the server based on the value.
### getInitialProps
Let's keep using the blog as an example. When the user navigates to `/articles/the-meaning-of-life` we want to fetch the articles from a CMS and return it as a React.js prop to the page. This is done through by exporting a special Next.js function. This could look something like this:

![Code example getInitialProps](/img/articles/create-next-app-get-initial-props.png)*Code example getInitialProps*

As you can see, we retrieve the dynamic slug from the request object, fetch the article and return the article. We now receive it as a React.js prop for the page itself. You can now use the data to render the page (server-side).

There is however a small addition to this. Next.js needs to know what all the possible slugs are in order to build a page for every article. We can do this by exporting another special Next.js function like this:

![Code example getStaticPaths](/img/articles/create-next-app-get-static-paths.png)*Code example getStaticPaths*

Based on this array of slugs, Next.js will now build pages during the build process.
### getInitialProps
The previous example is used when you want to fetch some data on the serving during build time, but what if you want to fetch during run time? You can export an other special Next.js function like this:

![Code example getInitialPaths](/img/articles/create-next-app-get-initial-paths.png)*Code example getInitialPaths*

The vital difference in this function, compared to the previous one, is that this will only run on run time. This page will therefore no longer be statically generated but requires either a Node.js server or serverless function. The question is how you want to host your site. A statically generated site is easier to deploy as it is just some static files, a Node.js server or serverless environment will allow you to retrieve data on demand. The cool thing about Next.js is that you can use both these techniques on different pages. If you want to dive a bit more into this part of Next.js I suggest you to read my article ["Next.js page generation"](https://www.davebitter.com/articles/next-js-page-generation).
## Deploying your Next.js app
The deployment of your Next.js app depends on a variety of factors. Let's take a statically generated site for the purpose of keeping it simple. You can run the following command to create a fresh build of your app:

![yarn build](/img/articles/create-next-app-build.png)

You then have to add a new NPM script called `export` that runs the command `next export`. Once you run that you will have the following output:

![yarn export](/img/articles/create-next-app-export.png)

![Outputted Create Next App export](/img/articles/create-next-app-export.jpg)*Outputted Create Next App export*

You're now free to host these static files wherever you want. In the case of going for serverless, you might want to check out my article [Implementing the latest web technologies to boost the Mirabeau blog](https://www.davebitter.com/articles/mirabeau-blog-latest-web-technologies).
## C'est tout!
That's it, in my opinion, you should be able to do most of what you want with these basic principles. I often write about Next.js. Please refer to [my Next.js articles](https://www.davebitter.com/tags/next-js) as well as the [Next.js documentation](https://nextjs.org/docs) if you are interested in going a bit deeper in the matter.

Finally, you can have a look at [my personal Next.js boilerplate](https://github.com/DaveBitter/next-boilerplate) based on this which includes all the things you might want to add like unit tests with [Jest](https://jestjs.io/) and [Enzyme](https://github.com/enzymejs/enzyme), [Storybook](https://storybook.js.org/), linting and more.

A simple, yet detailed introduction to Next.js

I am a Senior full-stack Front-end Engineer and Designer. Here, you can find my resume, a collection of my articles covering a wide range of topics and get in contact.

The nullish coalescing operator is a short-circuiting operator you can use to provide an alternative for a left-hand side operand by writing `??`. You might already have used `&&` or `||` before. So how is this different?  Let's take the following examples:
```jsx
const a = '' || 'unknown' // results in 'a' being 'unknown'
const b = 0 || 'unknown' // results in 'b' being 'unknown'
const c = false || 'unknown' // results in 'c' being 'unknown'
const d = NaN || 'unknown' // results in 'd' being 'unknown'
```
This is because `''`, `0`, `false` and `NaN` are falsey values. The nullish coalescing operator however will only return the right-hand side operand if the left-hand side operand is either `null` or `undefined`.
## Practical example
Let's say you want to display `unknown` if somebody's amount of points is not known (arbitrary React.js sample code):
```jsx
const person = {
    name: 'Roberta Woods',
    email: 'roberta.woods@example.com',
    location: 'California',
    points: 0
};

return <dl>
    <dt>Name</dt>
    <dd>{person.name || 'unknown'}</dd>

    <dt>Email</dt>
    <dd>{person.email || 'unknown'}</dd>

    <dt>Location</dt>
    <dd>{person.location || 'unknown'}</dd>

    <dt>Points</dt>
    <dd>{person.points || 'unknown'}</dd>
</dl>;
```
In this case, `points` will display `unknown` which isn't right. We know the number of points, it's `0`. Previously, a fix would have been to also check if `points` is `0` or a number in general and then display that. By using the nullish coalescing operator we can keep our code clean and simple:
```jsx
const person = {
    name: 'Roberta Woods',
    email: 'roberta.woods@example.com',
    location: 'California',
    points: 0
};

return return <dl>
    <dt>Name</dt>
    <dd>{person.name || 'unknown'}</dd>

    <dt>Email</dt>
    <dd>{person.email || 'unknown'}</dd>

    <dt>Location</dt>
    <dd>{person.location || 'unknown'}</dd>

    <dt>Points</dt>
    <dd>{person.points ?? 'unknown'}</dd>
</dl>;
```
That's it! I won't bother you with a bunch of other examples. This feature is one of those additions that you will probably find helpful in a variety of code you write and need to check for values. As always, thanks for reading!

Quick Bit | Nullish Coalescing (try to say it quickly ten times)

## A real-world use case
For one of the [Next.js]([https://nextjs.org/](https://nextjs.org/)) projects I was working on, I needed to add an asset prefix to the configuration if the [Node]([https://nodejs.org/en/](https://nodejs.org/en/)) environment wasn't "development". The first thing you might think of is to create a configuration object, write an if-statement and add a key to the configuration object if the statement is true. This would look something like this:
```js
require('dotenv').config();

const nextConfig = {
    poweredByHeader: false
};

if (process.env.NODE_ENV !== 'development' {
    nextConfig.assetPrefix = 'example.website';
}

export default nextConfig
```
In essence, we want to export an object with a few keys, one of which is optional. This is quite a bit of lines to do just that. I needed to declare a variable called `nextConfig` to optionally add a key to and then export it. This got me wondering if there is an easier way.
## The solution
The solution is quite elegant I think. This is what I came up with:
```js
require('dotenv').config();

export default {
    poweredByHeader: false,
    ...(process.env.NODE_ENV !== 'development' && { assetPrefix: 'example.website' }),
};
```
It might be a small decrease in lines of code, but imagine having multiple of these optional keys. In the first example, this would turn into quite a big file.

So Dave, why does this work? There are two parts to the solution. Firstly, I use the [Spread syntax]([https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax)) to take all the keys from an object and add to to the configuration object like so:

```js
require('dotenv').config();

export default {
    poweredByHeader: false,
    ...{ assetPrefix: 'example.website' }
};

// result: { poweredByHeader: false, assetPrefix: 'example.website' }
```
I then add the statement to check whether the Node environment is "development" using `&&`. If it is not, it will try the spread the value `false` in the object. That falsey value will be omitted from the configuration object. This way it will optionally add the key to the configuration object.

There we have it, We have a sweet one-liner to optionally add a key to an object. Thanks for reading!

Optionally add a key to an object in one line

You start by creating a public repository with the same name as your GitHub username. In my case, I create a repository called "DaveBitter". In that repository, you add a `README.md`. That's it. From here on you can use MarkDown to tell more about yourself, highlight skills, share social media links and anything you can think of. The README will now be used to display this content on your GitHub profile.

![My GitHub profile README](/img/articles/github-profile-readme.jpg)*My GitHub profile README*

As you can see, my README is fairly brief, but it does allow me to tell a bit more about myself, share a link to my articles and plug some social media channels. As always, some developers take full advantage and push for the limit. A collection with several of these examples can be found in [this collection repository](https://github.com/abhisheknaiidu/awesome-github-profile-readme).

The biggest reason I like this feature is how it converts a "dry" profile page into a more human and personal page. Looking at some of the above-linked examples makes me reminiscent of pages on an old and retired Dutch social media platform called Hyves.

That's all. Make sure to add one of these README files to make the web more personalized, fun and awesome!

API

Articles

Design handoff in the browser

I build a neumorphic Pomodoro to stay sane

A simple, yet detailed introduction to Next.js

Quick Bits

Quick Bit | Nullish Coalescing (try to say it quickly ten times)

Optionally add a key to an object in one line

GitHub profile README