It didn't take me very long into my career to realize that writing software is hard, and that
trying to do so at scale is even harder. What exactly "scale" means can vary for different
people and across different contexts. For me, it's a combination of the subjective complexity
of a system, the number of people working on it, and the number of users it serves.

I've worked on or even co-designed systems that were meant to be used by a handful of
developers and serve a few thousand users, but trying to build the very same system to be
used by dozens of developers and serve a clientelle of hundreds of thousands or even millions
of end users is a very different undertaking. This is the kind of scale I'm talking about,
and my first attempt at building something that can handle such scale.

At my job, we've been trying to solve the issue of data fetching and server state management
across the different parts of our apps for a while. We've tried different approaches and
while most of them have worked reasonably well, none of them were "The One". That being said,
I think I might have found "The One", and while it's still in its early stages, I'm hopeful,
so take it chronologically.

# The problem

There are a few major things we've been struggling with:

- we don't really have a unified, consistent way of fetching and managing server data - it's
mostly a mixture of different libraries and patterns used across different places in the app
- we're dealing with lots of repetitive, boilerplate code, causing friction and productivity
decline, all while reinventing the wheel and making the codebase harder to maintain
- we don't have a reliable way to handle polling based on response headers our backend APIs
send us back
- we don't have a way to set global settings for a given API service (set of requests,
usually with the same base URL) in a single place - e.g. default error handling of 404
responses or disabling retries service-wide

## Thunks, SWR, and the like

Some parts of our apps dispatch thunk actions, then fetch data inside of them, then dispatch
the responses to the store along with "secondary" actions (e.g. setting loading state), then
let the components subscribe to the store and render the data. Sounds like a mouthful and a
lot of work, doesn't it? Well, now you know why my aversion for doing async stuff	in Redux
grew so much over the years. To eat a soup with a fork is simply not a good idea.

Other parts of our apps use SWR, and while I conceptually really root for SWR, I find it
lacking in features. It's lightweight and enjoyable for simple use cases, but once the
complexity goes up, SWR just doesn't cut it.

**Before I continue any further, I really want to emphasize that the problems I've just listed
are not unique to our software nor something that cannot be solved. For the most part, our
systems are doing what they're supposed to do, and they're doing it somewhat well, but I
believe we would be selling ourselves short if we didn't aspire to do better.**

## Failed attempts

We tried to come up with a Tanstack-Query-based proof of concept many months ago, but it
didn't really go anywhere as it was lacking in features and a bit difficult to maintain and
extend. Polling was missing altogether, and since some parts of our apps rely on it heavily
to keep the data fresh and user experience smooth, no wonder we axed the PoC shortly
afterwards. I have, however, learned a few valuable lessons from the experience.

# The solution attempt

Since I've been using Tanstack Query in my previous jobs, personal projects and since its
inception with mere 40k weekly NPM downloads, I decided to spearhead the effort to build a
new, unified, scalable and feature-rich server state library for our apps. The choice of
Tanstack Query as the foundation was more or less a no-brainer - it's stood the test of time,
proving its worth and value in many different projects of various sizes and complexities, it
is still actively maintained (shoutout to Tanner Linsley and Dominik Dorfmeister), and it
seems to be the most feature-rich and flexible library of its kind. Cool, now we have a
foundation we can build upon, but what about the rest?

## Back to the drawing board

It was time to go back to the drawing board, endless meetings with our seniors and EMs,
requirement specifications and gathering feedback from the rest of the team. 15+ hours of
meetings later, we came up with the following list of major requirements:

- **environment-agnostic** - we need our API services to be able to work in the browser as
well as Node, both inside and outside React components, thus splitting responsibilities
between the different layers of abstraction
- **polling** - we need to be able to poll our API services based on response headers
- **consistency** - we need a unified, consistent way of fetching and managing server data,
ideally without much boilerplate
- **global settings** - we need a way to set global settings for a given API service in a
single place
- **per-request customization** - we need to be able to attach custom data to requests, e.g.
to pass a different token or base URL without affecting the rest of the API service
- **great developer experience** - the abstaction layer should "make sense" and guide the
developer in the right direction

## Me, myself and Notion

Whenever I design systems and abstractions, I like to start from the end and think about what
would be the most intuitive way to use it while still conforming to the necessary
requirements. Having requirements finally written down, I started to jot down some ideas and
possible syntaxes in Notion. If you've ever built an abstraction layer on top of a
lower-level API, you probably know how hard it is to strike a balance between these two. I
came up with a few ideas:

<Prism language="tsx">
{`
// 1. The "classic" way
const { data, isLoading } = useQuery({
 queryKey: ['postById', id],
 queryFn: () => fetch('/api/post/' + id)
 ...options
})

// 2. The "failed attempt" way
const { data, isLoading } = useTypedQuery('getPostById', {
 params: { id },
 ...options
})

// 3. The "I don't know what I'm doing" way
const { data, isLoading } = useTypedQuery({
 fetcher: 'getPostById',
 params: { id },
 ...options
})
`}
</Prism>
 

Options 2 and 3 aren't necessarily bad, but they feel very similar and there's just something
about them that doesn't feel right. Maybe it's the having to pass the fetcher name as a
string or having to specify the `params` object separately. Who knows...

Then one evening, while randomly reading through tRPC's documentation, it hit me:

<Prism language="tsx">
{`
const result = myService.whatRequest.whatCanHappenWithIt()
`}
</Prism>
 

Which would translate to:

<Prism language="tsx">
{`
const query = postsService.getPostById.useQuery({ id }, options)

queryClient.invalidateQueries({
 queryKey: postsService.getPostById.getQueryKey({ id })
})
`}
</Prism>
 

This API felt so intuitive and natural that I couldn't believe I was about to conceptually
copy tRPC. A great benefit of this API is also the tight coupling between the query and its
query key, which makes it easy to invalidate the query when needed - all while preserving
the syntax and conceptual consistency `service.request.whatToDo()`.

Cool, so we're basically going to build a tRPC clone, but how exactly do we do that if tRPC
is a full-stack library and we only need the client part?

## Architecture & design decisions

### Why the `service.request.whatToDo()` syntax?

Most of all, it allows us to use a consistent API for not only executing queries and mutations,
but also when invalidating queries, manually setting query data, etc. Furthermore, it feels
intuitive, natural, and it just "makes sense".

### Why is `params` an object?

It allows for better type inference as we don't have to rely on the order of the arguments,
and it gives developers a better idea of what the query expects thanks to autocompletion and
type hints.
 

### Why is the underlying query key an object?

TkDodo wrote a great article on this topic, so I'm just going to redirect you [there](https://tkdodo.eu/blog/leveraging-the-query-function-context#object-query-keys).
 

### Why are some query options stripped away?

We don't want to expose all of the query options to the developer because some options are
manually set inside the abstraction layer and should not be changed - things like `queryKey`
and `queryFn` (which are managed by the abstraction itself), `context` (which is set
manually) and `meta` (which we don't use at all).
 

### Why Axios under the hood?

This isn't directly related to the API design, but it is related to our separation of concerns
and the environment-agnostic nature of our API services. Additionally, Axios's request config
is identical to the request options we expose to the developer, allowing for a seamless
customization and modification of base URLs, headers, etc.

## The final API

With all that being said, here's the final API I came up with, using an imaginary
`postsService` as an example. Notice the inspiration from tRPC:

<Prism language="tsx">
{`
// \`postsQueryApi\` is the hooks, \`postsUtils\` is the query client methods
const { postsQueryApi, postsUtils } = usePostsApi()

// 1. Fetching all posts
const allPostsQuery = postsQueryApi.getAllPosts.useQuery({})

// 2. Fetching a single post
const postByIdQuery = postsQueryApi.getPostById.useQuery({ id: 1 })

// 3. Fetching a single post with custom header and base URL attached
const postByIdQuery = postsQueryApi.getPostById.useQuery({ id: 1 }, {
 request: {
 baseURL: 'https://api.example.com',
 headers: {
 'Authorization': 'Bearer 123'
 }
 }
})

// 4. Creating a new post, invalidating the "all posts" query on success
const newPostMutation = postsQueryApi.createPost.useMutation({
 onSuccess: () => {
 postsUtils.getAllPosts.invalidate()
 }
})

// 5. Manually setting the query data - equivalent to \`queryClient.setQueryData\`
postsUtils.getPostById.setData({ id: 1 }, { title: 'Hello, world!' })

// 6. Partial query matching support for query invalidation via a callback
postsUtils.getPostById.invalidate(() => ({ ...partialParams }))

// 7. Optimistic update for creating a new post
const newPostMutation = postsQueryApi.createPost.useMutation({
 onMutate: async (newPost) => {
 // cancel the ongoing query
 postsUtils.getAllPosts.cancel()
 // get the previous posts data
 const prevData = postsUtils.getAllPosts.getData()
 // update cache with the new post
 postsUtils.getAllPosts.setData((oldData) => {
 return [newPost, ...oldData]
 })
 // return the previous data to be used in case of an error
 return { prevData }
 },
 onError: (error, newPost, context) => {
 // if the mutation fails, revert the cache back to the previous state
 if (context?.prevData) {
 postsUtils.getAllPosts.setData(context.prevData)
 }
 },
 onSettled: () => {
 // re-fetch the query to get the latest data
 postsUtils.getAllPosts.invalidate()
 }
})
`}
</Prism>
 

The query results and mutation results are identical to what you'd get from using Tanstack
Query directly, but the syntax is much more intuitive and consistent, there's no need to
create custom hooks if you want to reuse the same query in different places, and you can
do everything you need using just one or two variables.

Notice how at no point do we have to worry about query keys or query functions because the
abstraction layer handles that for us - all we have to do to work with the abstraction
properly is to call the right method with the right request, give it the necessary params
and options (TypeScript will help us with that), and we're good to go! This is the kind of
developer experience I've always wanted to have.

# Wrapping it all up

As I started building bigger and bigger apps with more complex server state logic using
Tanstack Query, I started to realize that even though the hooks are great, they're not
necessarily the most intuitive and scalable way of doing things. In order for your server
state logic to be scalable, you have to create a custom hook for every query and mutation,
give every query a query key and a query function, and then you have to manage all of that
yourself. This is where the idea of "tRPC Query" was born.

I'm really excited about this abstraction layer because its API takes all the great stuff
from Tanstack Query and elevates it to new heights - more consistent, more scalable, and
hopefully also more intuitive to use. It allows you to create many different API services
that host a virtually unlimited number of API requests - and as long as each service uses a
unique name, you can be sure that there won't be any naming conflicts. It abstracts away the
boring parts of Tanstack Query and lets you focus on the important stuff, all while preserving
the great developer experience and the flexibility of the underlying library.

I don't know what I would've otherwise created without stumbling upon the documentation page
of tRPC. When you come across a great idea that you can build upon, I suggest you start from
the end result and work your way back to the foundation. That's what I did here, it turned out
much better than I expected and I can't wait to see how it will help us scale our server state
management in the future.

The TypeScript language and ecosystem has experienced tremendous growth in the last few years.
It has become the de-facto standard language for frontend development, and I'm so happy about
that because it really is a stellar language. I switched to TypeScript in mid-2020 and to be
honest with you, there's no way I'm going back to JavaScript. There's simply too many benefits
to TypeScript that I can't live without anymore.

However, that hasn't always been the case. The first few months of going cold-turkey on
JavaScript and fully embracing TypeScript were quite painful. The emotional rollercoaster and
love-hate relationship with TypeScript was something I had not anticipated in the slightest.
Nevertheless, TypeScript is a skill that can - and should - be practiced and improved upon.

From my experience so far, most developers can get by with a fairly basic understanding of
TypeScript. There's nothing inherently wrong with that, typing your day to day React code
isn't that hard, after all. If you're a library maintainer or you simply want to get the most
out of the language, however, you'll need to go deeper. When you do, you'll be rewarded with
APIs that are robust and simple to use, libraries that are a joy to work with, and developer
experience that brightens your day.

I'm no expert on TypeScript and don't even aspire to be one - it's Turing complete, which means
you can do some truly insane stuff with it like typing a full [bubble sort algorithm](https://twitter.com/anuraghazru/status/1511776290487279616?t=aor9BDIhHh7Q-cQ_XpTmtA&s=19).
That said, I'd like to share the things that have had the most impact on my TypeScript skills.
Some of them are mindset shifts, others are practical tips.

Let's dive in!

# Mindset shifts

## Embrace the set theory

I learned the concept of set theory about 1,5 years ago and it has significantly improved my
understanding of TypeScript. Set theory is a branch of mathematics that deals with sets, which
are collections of objects. If that sounds like a mouthful, don't worry, the application of
set theory in TypeScript is much simpler than that.

Set theory in TypeScript is all about thinking of types as a list of all the possible values
that a type can hold. For example, the type `string` is a set of all the possible strings that
can exist. The type `number` is a set of all the possible numbers that can exist. And so on.
Let's look at them visualized in code:

<Prism language="tsx">
	{`
type MyString = string; // 'hey', 'hello', 'world', etc. - all the possible strings
type MyNumber = number; // 1, 2, 3, etc. - all the possible numbers
type MyBoolean = boolean; // true, false - booleans can only hold two values
	`}
</Prism>
 

This is probably nothing new, but what if we want to narrow down the set of possible values
to create a more useful string type? For example, we might want to create a string union
of array methods starting with letter "r". Let's look at how that would be done:

<Prism language="tsx">
	{`
type ArrMethods = keyof Array<any>; // gives you all methods as well as indexes
type StartingWithR = ArrMethods & \`r\${string}\`; // 'reduce' | 'reduceRight' | 'reverse'
	`}
</Prism>
 

Plain `ArrMethods` is a set of all the possible values that can exist on an array. By using
the `&` operator, we can narrow down the set of possible values to only those starting with
letter `'r'`. Because we only care that the keys start with "r", we can use the `string` type
to represent the rest of the string. This is a very powerful concept that can be used to
create very specific types.

By the way, have you ever wondered why we use `never` in conditional types?

<Prism language="tsx">
	{`
type Strings = 'hello' | 'there' | 'world'
type MyExtract<T, U> = T extends U ? T : never

type There = MyExtract<Strings, \`t\${string}\`> // 'there'
	`}
</Prism>
 

The reason is that `never` is an empty set. It cannot hold anything, so when TypeScript
sees `never` in a union, it will remove it from the union. It's like going to a store
with a shopping list (the condition in your type). When an item matches your list, you
put it in your cart. If it doesn't match, you leave it on the shelf. `never` is like
an empty shelf, so TypeScript will leave it on the shelf.

## Think of generics as arguments to a function

In TypeScript, understanding generics can be made simpler by thinking of them as arguments
to a function. Much like how functions take arguments to operate on different values,
generics allow types to work with different data types. When you define a generic, you're
essentially creating a template that can be filled with various types. This flexibility
enables you to write more reusable and adaptable code.

The following example shows how similar generics are to function arguments:

<Prism language="tsx">
	{`
// kind of like saying "function \`Query\` that takes \`TData\` as an argument"
type Query<TData> = {
 data: TData;
 isLoading: boolean;
}

type StringQuery = Query<string>; // { data: string; isLoading: boolean; }
type NumberQuery = Query<number>; // { data: number; isLoading: boolean; }

// function \`makeQuery\` that takes \`data\` as an argument
const makeQuery = data => ({
 data,
 isLoading: false,
});

const query1 = makeQuery('hello'); // { data: 'hello', isLoading: false }
const query2 = makeQuery(23); // { data: 23, isLoading: false }
	`}
</Prism>

## When designing APIs, begin from the end

Every time I'm designing a new API, be it a library or anything else, I never worry about
the implementation details. I never think about "Oh my god how am I going to type this?".
Instead, I start from the end and gather all necessary requirements and features first,
then sketch out possible syntaxes and APIs that would satisfy those requirements. I pay
close attention to how intuitive and natural the API feels. **Only then** do I start
thinking about how to implement it and type it properly.

There's no reason to worry about typings. If you can build it in JavaScript, you can build
it in TypeScript. The only difference is that you'll need to add some types to make it work,
and if you can't figure out how to do that, that's a great opportunity to get better at
TypeScript - it's a win-win situation.

# Practical tips

## Learn intermediate concepts

Once you grasp generics, it's time to look into things like conditional types, mapped types,
and utility types such as `ReturnType`, `Partial`, `Pick`, `Exclude` etc. Apart from all these
concepts, there are also techniques that are a bit more nuanced:

- type guards
- key remapping
- discriminated unions
- the `infer` keyword
- the `as const` keyword

Equipped with these concepts, you'll be able to write more robust code, create better APIs,
and improve the developer experience of your libraries. For example, just a few weeks ago
I had a use case where I needed to convert strings from snake case to camel case:

<Prism language="tsx">
	{`
type SnakeCase = 'hello_world' | 'hey' | 'typescript_is_cool';

type Camelize<S extends string> =
 S extends \`\${infer F}_\${infer L}\${infer R}\` ? \`\${F}\${Capitalize<L>}\${Camelize<R>}\` : S;

type Result = Camelize<SnakeCase>; // 'helloWorld' | 'hey' | 'typescriptIsCool'
	`}
</Prism>
 

You can see how combining these concepts can lead to some pretty powerful results. All I
needed to make this work was a conditional type, the `infer` keyword, the `Capitalize` utility
type, and recursion.

## Practice, practice, practice

There's no way around it - getting better at TypeScript requires a lot of practice. While it
might help to read about the concepts and watch YouTube tutorials, the only way to truly
understand them is by building your own types and using them in your code.

Try to make your own utility types that should work the same way as the built-in ones. For
example, your own `MyPick` that should imitate the built-in `Pick`. Once you start to feel
comfortable with what you know, try to build a library that uses these concepts.

Recently I've been working on a [Tanstack Query](https://tanstack.com/query/latest) wrapper
that would receive an API schema - a definition of all the endpoints and their return types -
and generate a fully typed client based on that schema. It looks a lot like creating my own
type-safe [tRPC client](https://trpc.io/docs/client/react) - it's almost the same syntactic
sugar, but also has some extra functionality on top. Here's what it looks like (simplified
for brevity):

<Prism language="tsx">
	{`
export type QueryApi<
 TApiInstance extends Record<keyof TApiInstance, Fetcher<any, any, any>>,
 K extends keyof TApiInstance
> = {
 useQuery: <TData = FetcherData<TApiInstance, K>, TError = Error>(
 params: FetcherParams<TApiInstance, K>,
 options?: Omit<
 UseQueryOptions<TData, TError>,
 "queryKey" | "queryFn" | "meta"
 > & { meta?: FetcherMeta<TApiInstance, K> }
 ) => UseQueryResult<TData, TError>;
 useMutation: <
 TData = FetcherData<TApiInstance, K>,
 TError = Error,
 TVariables = FetcherParams<TApiInstance, K>
 >(
 options?: Omit<
 UseMutationOptions<TData, TError, TVariables>,
 "mutationKey" | "mutationFn" | "meta"
 > & { meta?: FetcherMeta<TApiInstance, K> }
 ) => UseMutationResult<TData, TError, TVariables>;
 getQueryKey: <TParams extends FetcherParams<TApiInstance, K>>(
 params: TParams | (() => DeepPartial<TParams>)
 ) => readonly unknown[];
 getQueryFn: () => TApiInstance[K];
 getQueryPair: <
 TParams extends FetcherParams<TApiInstance, K>,
 TMeta extends FetcherMeta<TApiInstance, K>
 >(
 params: TParams,
 meta: TMeta
 ) => {
 queryKey: readonly unknown[];
 queryFn: () => Promise<FetcherData<TApiInstance, K>>;
 };
};

export type QueryApiClient<
 TApiInstance extends Record<keyof TApiInstance, Fetcher<any, any, any>>
> = {
 // pick properties from \`QueryApi\` depending on the key prefix,
 // so that the developer cannot use e.g. \`useMutation\` on a query
 [K in keyof TApiInstance]: K extends \`\${QueryPrefix}\${string}\`
 ? Pick<
 QueryApi<TApiInstance, K>,
 "useQuery" | "getQueryFn" | "getQueryKey" | "getQueryPair"
 >
 : K extends \`\${MutationPrefix}\${string}\`
 ? Pick<QueryApi<TApiInstance, K>, "useMutation">
 : never;
};
	`}
</Prism>
 

It's okay if the code above is giving you a headache, the relative complexity is not the
point. The point is being able to create type-safe, intuitive APIs that are easy to use
and a joy to work with thanks to TypeScript's ability to take developer experience to
a completely new level.

I've reached a point where being able to create APIs like the one above suffices for my
needs. I'm obviously nowhere near advanced or even expert level, but to be honest, I don't
really care, nor do I have a need or a compelling reason to get there. Make me a Redux or
even XState maintainer and it will be a very different story.

# Helpful learning resources

I can recommend the following resources to help you get better at TypeScript:

- [Matt Pocock](https://www.youtube.com/@mattpocockuk) - a true TypeScript wizard, he's also very active on Twitter
- [Andrew Burgess](https://www.youtube.com/@andrew-burgess) - great TypeScript videos, especially the hands-on ones
- [Frontend Masters](https://frontendmasters.com/topics/typescript/) - many courses to teach you TypeScript
- [Type Challenges](https://github.com/type-challenges/type-challenges) - the obvious choice for practice examples

Many things are about to change once you leave university and sign that very first full-time
contract. You will have to learn some basic time and work management skills, how to
communicate with your colleagues, and many other skills. A lot of these things won't exactly
come easy to you, often because you were never taught them in school. 

The purpose of this post is to provide the soon to be full-time developers with a little bit
of guidance on what to expect and how to prepare for the new chapter in their lives.

# The first day

<Highlight>
	Write things down. Everything. You can always delete the unnecessary later.
</Highlight>
 

You will be nervous, you will be excited, you will be anxiously awaiting the first steps in
your new workplace. Don't expect to get any work done on your first day - first days are
almost always allocated for onboarding, getting to know your colleagues and the company,
meeting your manager, getting your inbox, Slack and other systems set up, figuring out where
the toilet and dining area is, and so on.

Write things down. Everything. You can always delete the unnecessary later. It also helps
you relieve some of the stress when you know you don't have to hold everything in your head.
If there's an onboarding guide for newcomers on how to set up your development environment,
read it thoroughly and follow it. Best case scenario, the guide will be up to date and you
will be able to set up your environment without much trouble. Worst case scenario, the guide
doesn't even exist (yep, that also happens!), in which case you have your notes to later
create one yourself and help all the newcomers after you (wink).

Most of all, take it easy today. You will be overwhelmed with information, so make sure to
get plenty of rest when you get home. The first two days in my first full-time job were
so exhausting that I had to nap for 2 hours when I got back home. The second job was a lot
easier to handle, no naps required.

# The first 3 months

## Relax the expectations

If you're just starting out in your career and you're fresh out of university, you will
likely expect yourself to be able to perform close to the level of your colleagues. This is
a complete and utter nonsense for a multitude of reasons:

- You have no real world experience working on a project larger than your university assignments or those fancy side projects you've created.
- Communication in a team of professional developers, product managers and possibly stakeholders is quite different from what you're used to from university.
- Let's be honest - being good at something, anything, takes years of deliberate practice,
regular controlled exposure to new problems and challenges and a lot of reflection - and
you've only just started.

The most important thing to realize at this stage is that nobody expects you to be a
superstar right off the bat. You won't be given the responsibility and decision-making of a
senior developer. The first 3 months to about half a year are almost exclusively reserved
for you to learn the ropes, the codebase, the processes and so on. Approach this period with
an open mind and a willingness to learn and you will be just fine.

## Drop the ego

Closely related to the previous point. The biggest mistake you can make leaving uni is
thinking you know it all. I've been there - after mere 2 years of learning how to code,
I started an internship in a small startup as a React developer. It only took a week for me
to find out I can barely contribute. Needless to say it was a very humbling experience.

<Highlight>
	The purpose of university is to teach you enough basics to perform the job,
	not to make you an expert.
</Highlight>
 

The point is, you will be surrounded by people who have been doing this for years. When
you're a junior, speaking with a senior developer feels like they're speaking a different
language. You can barely understand half of what they're saying, yet they have this aura of
confidence and calm around them that makes you admire them.

So, drop the ego. The purpose of university is to teach you enough basics to perform the job,
not to make you an expert. Expertise is developed by continuous, deliberate exposure to increasingly difficult problems and then reflecting upon them.

## Don't sleepwalk

Maybe it's just me, but I wish someone told me not to get lost in the 9-5 routine from the
get-go, especially given my age. I was still 23 when I started my first full-time job, and while I'm not much older today, I wish the first months of full-time were more memorable.

It might be upsetting to see how everyone around you on the morning commute is stuck in the
same rat race and has the exact same goal as you - to get to work, do their job, come back
home and do whatever. It's that **'whatever'** that matters - don't let it be Netflix and chill.
It's perfectly fine to just turn off the brain after a long or challenging day, but it
shouldn't become the norm. Go out, go for a run, meet new people, learn a new skill, socialize
with your friends and family, plan a trip abroad, invite your colleagues for dinner - 
whatever will make the day more enjoyable, more exciting, more memorable. If you find
yourself spending most of your free time in front of a screen, in bed or both, it's probably
time to change something.

# Practical tips in your day to day work

Each day at work will be different, but there are a few common denominators that will impact
most of the day on the job.

## Context switching

It's almost guaranteed that you will not be working on just one thing at a time continuously.
Things come up and get in the way all the time. Try to batch related tasks together or work
on them in periodic intervals. For example, I periodically check Jira, my Gmail inbox, and
pull request reviews on Github about 4 times a day - in the morning, before lunch, after
lunch and before I leave. If something takes less than 2 minutes to do, I do it right away
so that I can forget about it afterwards. If it takes more, I schedule it in my calendar.

## Urgent fixes and on-call

This is a tricky one, you can never predict what happens. If you have to drop everything and
extinguish a fire, try to take a little step back, think about the problem and the individual
steps you need to take to fix it. Simple bullet points are enough. It's easy to get
overwhelmed and stressed out when you're in a hurry, and it never leads to quality decisions.

## Meetings, standups and syncs

As few as possible, as short as possible, as focused as possible. Leave the chit-chat for
the small talk in an open office, a coffee break, lunch, or after work. It's great if your
team allows for time to socialize, but socializing doesn't belong in meetings.

## Code reviews

Assume by default that your colleagues heartfully dislike reviewing pull requests - for one
reason or another. It's very common in many companies to have tons of PRs waiting for review
and becoming a blocker. Some companies try to solve this issue by introducing rules and
policies, but there's only so much you can do. Try to keep your PRs as small as possible, be
thorough with the PR's description, attach images to help your colleagues visualize the
outcome. If you're reviewing someone else's PR, think about how much feedback you should give.
It's generally not desirable to be too nitpicky, but it's also not desirable to be too lenient.

## Time estimations

ALWAYS (!) add a buffer to your estimations. How much of a buffer depends on the task and how
much experience you have with similar tasks, but make sure to always underpromise and
overdeliver rather than the other way around. Furthermore, projects releases in software
companies are almost always delayed, so people are used to them. That doesn't mean your team
shouldn't strive to deliver on time, but it's important to relax the expectations a little.

## Documentation

There are always two problems with documentation - it gets outdated quickly and nobody can
find it. Additionally, a third potential problem is that nobody wants to read it. Keep this
in mind when you're writing docs. Document the most critical pieces of information, and set
some time aside each month to review the docs and update them if necessary.

## Learning time and budgets

Every workplace is different, but this is mostly on you. Keeping up with the latest
technologies and trends is a must in this industry, not only to come up with better solutions
in your day to day work, but also to stay relevant in the job market. If your company doesn't
provide you with a learning budget, at least ask about their policy on learning time. Make
sure to set aside some time each week to learn a thing or two, also at home - it will pay off
in the long run and it will put you ahead.

## Communication with others

I don't have much to say here, except try to keep in mind who are you talking to and what
their background is. If you're talking to your manager or anyone else non-technical, you
can't expect them to understand how you batched 4 thunks into one, colocated form state,
and built a small wrapper around your API client. Speak in a language that the other person
will understand.

# Conclusion

I hope this post was helpful to you and alleviated some of the stress you might be feeling
about your first full-time job. It's completely normal to feel anxious and overwhelmed, but
it's also important to remember that we've all been there at first. There are many years
ahead of you to figure it all out, so take it easy and enjoy the ride. Good luck!


It dawned on me recently that it has been almost 5 years since I embarked on my web
development journey. Anyone who has consistently worked with anything over a stretch
of many years will be familiar with the overwhelming transition from 5 years ago to
today. In other words, a lot can happen in 5 years. Like... really, a LOT.

In high school, I studied IT, among other things. I remember vividly how excited I could
get, 'knowing' that I would never touch programming languages again in my life. They just
didn't click for me - C# was too complicated, PHP's syntax was a mess, and when I saw the
results of even markup languages like HTML and CSS, I couldn't imagine them being even
remotely useful for anything other than building a brutalist website to impress your
grandmother. They were anything but for me.

# How it all started

I moved to Denmark in August 2018 with the goal of learning to edit videos, some basic
filmmaking, cinematography, animations and such. I had been fiddling a bit with Camtasia
at home for a few years, but it never really materialized into anything significant, which
is why I wanted to go deeper at university.

I will likely never forget day 3 of school - the first day of actually diving into something,
rather than just setting up email inboxes and internal systems. To my surprise, the topic of
choice was HTML - and I was left disappointed. "Why this thing again?", I asked myself,
trying to handle the internal struggle of doing something I dearly disliked. It almost sounds
comical today, in the context of what followed, but I just didn't know any better.

When I came home that day, I started working on the homework we had been given during the
lectures. The assignment was to put a few headings and paragraphs into the document. We were
simply instructed to briefly introduce ourselves. It was on that day that I discovered
[FreeCodeCamp](https://www.freecodecamp.org). Being able to code on the left and immediately
see the result on the right was surprisingly mesmerizing. Suddenly, all the hatred I had
towards HTML dissolved. It almost never happened, and the rest is history.

# A very sobering experience

A little over a year later, I felt perhaps the most confident I've ever been. Any challenge
thrown at me at school felt like a walk in the park. I was consistently surpassing my peers
in coding, sweeping through assignments like it was nothing. If this sounds like a boastful
claim from a young man in his early 20s about to face reality, that's because it's supposed
to - I was squarely at the 'Peak of Mount Stupid' of the [Dunning-Kruger effect](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect).

In January 2020, I started my first internship at a small startup called Senti. As expected,
I had very little responsibilities, mostly just cosmetic improvements of the source code and
adding new small features to the product. Coming from a background of small coding tasks and
school assignments, I was aware things are going to be more difficult, but what I never saw
coming was the immense learning curve of coming to a new, much larger software project.
Needless to reiterate I had barely any responsibilities.

A few weeks in, I was reaching new bottoms of my desperation tank. I had entered phase 2 of
the Dunning-Kruger effect - the 'Valley of Despair'. I felt completely incompetent, stupid,
and as if everyone else is better than me. That's a very healthy (and necessary!) reaction
to being exposed to a problem requiring much more competence and experience.

# The Developer Starter Pack

The cool thing about being a programmer is that the necessary healthy skepticism towards
your abilities never goes away. The programming world is a bottomless ocean of many
different languages, frameworks, libraries and tools. There's simply so much that it's
impossible to know everything. No wonder why programmers mutually respect each other, and
why only a programmer can appreciate the skill and expertise of another programmer.

Having now clocked in over 1,5 years of full-time work experience, I can confidently say
that my expectations before entering the industry were very different from what my day looks
like today. I'm pretty sure writing down all the lessons learned would qualify for a
standalone blog post, but let's briefly look at a few:

- I used to think open offices were detrimental for programmers due to constant interruptions
that can occur. Now it's my preferred way of working unless people are VERY loud. After all,
noise-cancelling headphones are nothing new.
- It's important to write things down all the time. Don't rely on "I'll remember it" - you
won't. Furthermore, nobody is interested in having to explain the same thing 420 times.
- There are quiet days and then there are days where you get pulled in so many different
directions. Context switching is real, and it sucks. Your brain works like RAM.
- There are always loopholes and neglected areas. No one company has it all figured out,
because there's no perfect process.
- Work-life balance is important. Make it a habit that the moment you leave the office, you
don't think about work until 9am the next day.

# If I could do it all over...

It's actually quite simple - embrace the beginner mentality and never grow your ego above its
appropriate size would be my best advice. Schools and universities will only teach you enough
to get your foot in the door, they won't make you an expert. I know it's probably a cliche
thing to say, but perhaps the only way to let it really sink in is to have been there yourself.

We all think we're experts until we meet someone who REALLY knows their s..t. When you talk
to such person, you won't understand half of what they're saying, and that's the better case
scenario. There's always more to learn and master - languages evolve, new tools come out
almost every day (I'm looking at you, JavaScript frameworks!). I'm glad to have experienced
the programming world, because it encourages genuine respectfulness and solidarity, something
we could always enjoy more of in the whole world.


It happened seemingly out of nowhere. In the span of just a few short weeks, we've
experienced a massive leap forward in the field of artificial intelligence. OpenAI has
released GPT-4, Google is now adding their PaLM model to the Workspace suite, Microsoft is
integrating their GPT-powered Copilot into basically everything, Midjourney v5 has been
released and it's capable of generating images indistinguishable from real, captured ones,
and the list goes on. Above all that, however, is the release of ChatGPT, a large language
model that has gained [100 million users in less than 2 months](https://arstechnica.com/information-technology/2023/02/chatgpt-sets-record-for-fastest-growing-user-base-in-history-report-says/),
beating even TikTok by 7 months! Where is this all going? Let me try to paint my predictions.

# Short-term: a massive disruption is coming

We can already see the effects of these AI tools in the wild. ChatGPT is the new hot topic
among journalists, teachers, students, programmers and many others. I even use it to help me
write these blog posts! It can generate academic essays, proofread homework, write emails
in a plethora of different styles, generate advanced code snippets in all popular languages,
and even present possible recipes based on your picture of the ingredients you have in the
fridge. If that doesn't amaze you already, just give it a few more years.

It's no secret that ChatGPT and similar tools are already being used by millions of people and
quickly becoming mainstream. It reminds me of the early days of social media, when Facebook
was just a small college network. A few years later, it became the most popular social media
platform in the world. Thanks to the ubiquity of technology, the adoption of AI and their
integration into our daily lives will be even faster.

It's difficult to predict exactly how this will play out. Inevitably, people will lose jobs,
universities will have to rethink their curricula, knowledge workers' productivity will
skyrocket, many things will become easier or automated, new paradigms will emerge.

# Medium-term: breakthroughs in many industries

This is the part that gets me excited the most. ChatGPT is just the tip of the iceberg. Give
the AI development a decade or two and you'll be astounded. Imagine a person with an IQ of
the average Stanford PhD student, but with excellent expertise in every field of knowledge.
That's when we'll see the real breakthroughs - when AI becomes capable of generating new,
previously undiscovered knowledge.

Continuous cell repair to slow down aging, a cure for all forms of cancer, mainsteam adoption
of fusion energy, much more effective manufacturing processes, possibly even reversing the
effects of global warming... these are just a few of the things that could be achieved in
the next few decades, and I believe are very likely to be achieved by 2050 or at least in
our lifetimes.

If you find it hard to believe that AI could be capable of such things, keep in mind that
human progress has always been exponential, not linear. If you lived in the 1700s, you
probably wouldn't notice many changes in the world around you from the previous century.
If you lived in 1919 where planes were just becoming somewhat capable of flying, would you
believe that in just 50 years, we'd have people on the moon? Would you believe that in 100
years, we would live in a perfectly globalized world where a large portion of the population
has access to an abundance of food, drinking water, medical care, education, information and
entertainment? That we would be able to communicate with anyone in the world in real time,
from anywhere in the world? And that, dear reader, is the power of exponential progress. That
is the world we live in today.


# Long-term: singularity? (or not)

As I outlined in the previous section, I believe the true breakthrough will happen at a point
where AI becomes capable of generating new knowledge. It's almost impossible to tell what
happens after that, but it seems increasingly likely that we need to invent AGI in order for
humanity to become interstellar.

Now it's time to think truly big - what if AI could create materials stronger than diamonds,
lighter than air, manipulate individual atoms to create virtually any material, or even
outsource our brain and soul to a computer? What if we could build the [Dyson sphere](https://en.wikipedia.org/wiki/Dyson_sphere)
and harness all the energy of the Sun? How about time travel, teleportation or immortality?

It it absolutely wild to think about these things, but if you think about it, we're already
living in a world that would have been considered science fiction just a few decades ago.
I guess the only way to find out if I was right about my medium-term predictions set to
happen by 2050 is to wait until 2050 and look back :)

Running is one of the most popular sports in the world, and one of the most accessible - all
you really need is a pair of decent shoes and half an hour or more of time. Even though
I've been mostly doing strength training since 2016, I realized a few months ago that I
don't want to be either of the two extremes - neither a ripped bodybuilder who can't run
a mile, nor a skinny guy who can't do 10 pullups. I want to be able to do both, and
hopefully be able to do them somewhat well.

# First, a bit of history
I've been practicing various different kinds of sports throughout my life. I played tennis
for a few years as my first competitive sport, I played football, table tennis, even
basketball at times. In 2013, I moved away from doing competitive sports and started
doing calisthenics and bodyweight training. I've been doing that ever since, with the
occasional inclusion of cycling as my cardio supplement - and it's that combination of
both strength training and cardio that is, in my opinion, very powerful and effective.

During the two months of calisthenics and cycling I did in the summer of 2016, I managed
to end the summer break with about 2000 km total distance cycled. It might have even been
the best shape of my life at that point when it comes to endurance. Not only was I very
fit and strong, but cycling after 30 minutes almost felt like a meditative state. It was
very relaxing, almost zen-like - to be able to turn your brain off for 3 hours, forget
about everything and just perceive the music in your earphones, the road, and the beautiful
landscape around. I've been missing that zen-like feeling for a long time.

# Pavel started running, but wrong

## The incident
After my fiasco in the mountains of Montenegro in the summer of 2022, it dawned on me that
perhaps it's time for me to do something about my cardio a little bit. It wasn't a fiasco
per se, but climbing up the first hike at above 2000m altitude turned out to be a painstaking
struggle. I had to stop and rest a few times, and for sure I had expected more from myself.

And so, I started running. Bringing that 'no pain no gain' mentality from the gym, I thought
the way to improve my cardio is by what I've always done - by pedal to the metal and pushing
myself to the max. I ran 3km at a quite speedy pace, but my heart rate towards the end was
above 200 BPM - and in the upper 180s as average. Needless to say I was exhausted afterwards
and had to take a few days off from running.

<Highlight>
	I would wake up, put on my shoes, get destroyed on a 5K, come
	back, take a shower, and take a nap
</Highlight>

## ...but it kept getting worse
Unfortunately enough, I kept that mentality for a few more months, despising running and
hating every second of it. I would wake up, put on my shoes, get destroyed on a 5K, come
back, take a shower, and take a nap (!) for at least 20 minutes, simply because I was just
too tired to do anything else. Not to mention the fact that I was getting shin splints and
other injuries from running on hard surfaces, and I couldn't run consistently.

Weeks went by and I saw little to no improvement. I was stuck in a cycle of hopeless
perpetuity. "This can't be right", I thought. Turned out I was doing it all wrong. You don't
build your cardio by running as fast as you can all the time, you build it by running at an
easy pace for the vast majority of your training.

# The right way to run - at least for me
In mid December last year, I discovered the Maffetone Method. Its fundamental premise
is that you should run slower to run faster. Sounds counterintuitive, but from my experience
so far, it's true. By running at a pace where your heart rate is somewhere below or up to
180 BPM minus your age, you're training your body not only to use fat as primary fuel source,
but also to use oxygen more efficiently - which is the key to running faster. Your heart
will be able to pump more blood per stroke, and your muscles will be able to use more oxygen
to produce energy.

## I had to SLOOOOOOW down
From then on, I stopped looking at the pace and instead, I focused on my heart rate. My goal
was to keep it below 160 BPM and below 155 BPM as average. It was frustrating at first - I
was incredibly slow and, in order to maintain my heart rate, I had to transition into walking
sometimes. My initial pace was somewhere around 7:55/km which was a huge step down from my
previous 5:40/km pace - but I was determined to stick with it.

## 2 months in - where things stand
After about 2 months of running roughly 3 times per week, I've managed to improve my pace by
more than a minute per kilometer! That's a huge improvement over the course of just 2 months.
I'm now running at about 6:50/km or even faster sometimes. It's incredibly satisfying to see
my heart rate stay the same or slightly drop even though I'm running faster. Running itself
feels so much more enjoyable, I come home and feel like I could run that again. Thanks to
slowing down, I recover much faster and I'm able to run more often.

Almost all my runs are easy runs. I run tempo here and there, but rather occasionally. Below
are some stats from my Apple Watch:

<BlogImage
	src="/assets/blog/cardio-rocks-part-1/6k-before.jpeg"
	alt="Before - the beginnings with the Maffetone Method"
/>

<BlogImage
	src="/assets/blog/cardio-rocks-part-1/6k-after.jpeg"
	alt="The exact same run 1,5 months later"
/>

<BlogImage
	src="/assets/blog/cardio-rocks-part-1/cardio-recovery.jpeg"
	alt="Clear trend in cardio recovery since I started MAF training"
/>

# How I will continue
I'm going to continue running around 3 times per week, and keep the focus on my heart rate.
Once I get to a 5K pace of 6:00/km, I'll start doing some speedwork. In terms of the bigger
picture, I would like to be able to run the Copenhagen Half Marathon in under 2 hours.
There's only 7 months left until D-day, so I got plenty of work and conditioning to do!

My medium-term to-do list:
- Weekly long runs of 90-120 minutes
- Tempo 5K or other speedwork once every other week
- Keep up the schedule of 3 runs per week
- Increase cadence to 160-170 steps per minute
- Maintain 85%+ of runs at easy pace

Let's see how it goes! I'm no crystal ball, but I think it's feasible, despite my heavier
weight of 85kg. I'll write an update before the summer break to see how I've progressed.

I wasn't sure where to go. All I knew was that I'd like to see something that doesn't
break my budget. Having a few places in mind, browsing Skyscanner and trying to figure
out where to go, I pointed at Belgium.

# Planning

The very first thing I absolutely wanted to try that I've never done before was to
fit everything into a single 20L backpack. Is that even possible for 3 days? Well, we
will definitely find out. Next thing I absolutely wanted to try that I've never done
before was hostel accommodation. Up until the age 24, I've only done Airbnbs. Like...
can you even take a breather, or is it just a bunch of people in one room? I guess we
will find out about that, too.

Alright, cool, I booked my flight and accommodation. Packing list time. I had to
remember to only pack the essentials since I was travelling light and mobile. Alright,
4 T-shirts it is. And if I won't use all of them, so be it. Better safe than sorry.
The rest of the list was pretty straightforward and thankfully I didn't forget anything.

# Day 1 - arrival and tour de Bruxelles

After many grueling attempts, I managed to open my eyes at 4:15 AM. Everything was ready
to go. Getting to the airport was the easy part - but the realization that I was on trip
by myself without any friends or family was a bit overwhelming. I knew it was entirely
up to me to make it count, meet fellow travellers and hopefully do some exciting stuff
together. Or at least that's what I was hoping for - because I was definitely not planning
on spending my precious time in Belgium in solitude.

I landed at Brussels Airport around 3 hours later. It was time to start figuring things
out, as usual - how to get to all the places, where's the currency exchange, where's
the train station, etc. One rule of thumb is this: if you're not sure where to go, just
follow the crowd. All crowds lead to Rome. Or... do they?

<Highlight>
	All the small and cozy cafés, the beautiful architecture, the locals, the vibe - it
	was all there.
</Highlight>

 
The arrival to the city center got me in a state of bliss - the city was beautiful, and
I almost felt like I was in a more beautiful Paris. The amount of French written and
spoken around every corner only added to the feeling. It felt somewhat familiar, even
though I've never been to Paris. All the small and cozy cafés, the beautiful architecture,
the locals, the vibe - it was all there.

It was about time for some sightseeing. Visiting the EU Parliament is free of charge, and
I definitely recommend it. The entire district is very modern, clean and full of
enthusiastic people. Next stop was the Grand Place - the main square of Brussels. I can
almost guarantee that you've never seen more Gothic architecture in one place. This was
also the place where I met my first fellow traveller who brought others along, and we had
agreed to take a walking tour together.

Our hilarious, talkative and energetic tour guide took us on a 3-hour tour adventure through
the city. From now on, remember that the best waffle is the one with only chocolate - all
the creamy ones only get mushy! I'm glad I had that exact one. After the tour was over, we
decided to grab some food, head back to our hostel, have drinks, chat, play pool and just
have a good time. It was a great way to end the day.

# Day 2 - picturesque Bruges

It wouldn't be a trip to Belgium without visiting Bruges. Victoriously leaving the hostel
where I survived my first night without any problems, I headed to the Bruxelles-Zuid
station. I got to witness how the platform was transformed from a quiet, empty place to a
bustling crowd of people in a matter of minutes. I was on my way to Bruges.

The Belgian countryside looks almost identical to the one in France. In fact, I probably
wouldn't be able to tell the difference. The train ride was a bit uncomfortable due to
the overwhelming amount of people who got the same idea as me - to go to Bruges on a
beautiful Saturday morning - but all that was forgotten once I arrived in the city.

<Highlight>
	Bruges is a city that looks like it's straight out of a fairy tale.
</Highlight>

 
Despite the crowds of tourists, I was taken away immediately. The streets, the people,
the small boutiques and cafés, the architecture, the chocolate shops - it all adds to
a very unique atmosphere. Bruges is a city that looks like it's straight out of a fairy
tale. It's no wonder that it was declared a UNESCO World Heritage Site in 2000. Some
people also call it the Venice of the North, and I can definitely see why - some houses
are almost floating on the water!

I took it to the chocolate shops later that day. If there was a thing as a chocolate
capital of Europe, it would definitely be Bruges. I've never seen so many different
kinds of chocolate in one place - and it wasn't even so expensive! I can imagine that
the shops are even more crowded during the Christmas season, but on the flip side,
it must look even nicer.

<BlogImage src="/assets/blog/my-trip-to-belgium/bruges.jpeg" alt="Bruges canals, pure beauty!" />


I had a great time visiting Bruges. The city is incredibly charming, has a very unique
vibe, and is definitely worth a visit. I would recommend to visit Bruges on a weekend
during Christmas, as I can imagine that it would be even more beautiful than it already
is. It definitely has a lot to offer and its architecture is something that you probably
won't see anywhere else. I would definitely go back there again.

# Day 3 - Brussels and departure

I had reached out to another fellow traveller who was also staying at the same hostel,
and we decided to take it to the Atomium. It's a 102-meter-high structure made of 9
spheres that are connected by tubes. At first glance, it looks a lot bigger than in the
pictures. You might get particularly impressed by the lighting effects that are used
in the tubes - it's hypnotizing to watch, and nothing for epileptics.

The view from the top is quite nice, too. You can see a lot of Brussels from there. I
would recommend to bundle it with a visit to the Mini-Europe park, which is located
right next to it. It's a miniature park that features 350 models of European landmarks
and monuments. Just keep in mind that the bundle ticket is 30 EUR for an adult, which
isn't exactly cheap. If you catch good weather, however, it's definitely worth spending
the few hours and the ticket price to see both of them.

<BlogImage src="/assets/blog/my-trip-to-belgium/atomium.jpeg" alt="Atomium from the Mini Europe garden" />


The Parc du Cinquantenaire is also a great place to visit. Its main attraction is perhaps
the Triumphal Arch, which is a 50-meter-high arch that was built to commemorate the
founding of the Belgian state. The arch gives off a very noble and majestic vibe. I took
a walk around the park, bought some original Belgian chocolate and headed back to the
airport.

# Conclusion

I think Belgium is a bit underrated. Sure, it's not the most popular destination in
Europe nor it is Paris or Amsterdam, but there's definitely something unique about it
that makes it stand out. Perhaps it's the combination of the Gothic architecture, the
extraordinary amount of chocolate shops, the beer, the French vibe and the beautiful
countryside. Bruges is a city that absolutely cannot be dismissed, so if your only
city of interest is Brussels, I highly recommend to take a day trip to Bruges. It's
definitely worth it and you won't regret it.

What I remember from Belgium the most is how the time slowed down. Being surrounded by
so many coffee shops and cafés in the center makes time seem to stand still. As if the
city itself is telling you to take it easy and enjoy the moment. I think that's a lesson
that we all need to learn from time to time. I'm glad I got to experience it first-hand.

The last few months have got me thinking quite a lot about how I would learn a new language
from scratch if I had to. It's a question with a lot of ambiguity and specificity at the
same time, because I've been partially able to follow through on my own advice by learning
Danish, and while there's still a ton of work ahead, I think I have a pretty good idea of
what I would do differently from what 'conventional wisdom' says if I had to start from scratch.

The following lines are not meant to be taken as a comprehensive guide to learning a new
language, but rather as a collection of thoughts and ideas that I've found useful in my own
journey, shaped by thousands upon thousands of hours of both active and passive learning. Some
of the ideas are not exactly things you'd like to hear or do, but I think they're worth
considering nonetheless, particularly given the value they can provide.

# Begin with the end in mind
I don't mind overemphasizing this point because it's the most fundamental one. A ship without
an end destination is a ship that will never reach the harbor. The same goes for learning a
language - if you don't know where you're headed, not only will it take you much longer to get
there, but you'll have a much more difficult time tracking your progress, not to mention the
increased likelihood of giving up along the way. I'm not saying you need to be crazy
specific, but having a relatively clear end destination in mind will do wonders for your
language learning journey.

Whether it's being able to talk to your friends in their native language, the ability to order
food in a restaurant or move to the country where the language is spoken and sign up for
a full academic course, the last thing you want to do here is shy away from being ambitious.
No matter how unattainable it may seem, **I highly encourage you not to settle for less**
just because you think it's more realistic.

<Highlight>
	**BAD** - "I want to be able to speak"
	 
	**GOOD** - "I want to be able to hold a basic conversation about anything with a native
	speaker without having to ask them to repeat themselves too often"
</Highlight>

# Know what to expect
Now that you've pinned it down, it's time to address the elephant in the room - your
process, practice and what you'll be doing will vary greatly depending on how far you'd like
to take the language. If you're just looking to be able to order food in a restaurant, you
can likely get away with basic grammar, pronunciation and vocabulary. On the flip side, if
your goal is to sound like a native and/or appear on live TV and have absolutely no accent,
you'll need to put in A LOT more work.

In the following sections, I'll try to briefly describe the steps I would take if I had to
learn a new language from scratch, and I'll be focusing more on learners who are looking to
reach a high level of proficiency - CEFR C1 and above. I'll also try to debunk common myths
and misconceptions about language learning, and lastly, try to give you some tips regardless
of your target level.

That being said, I think it's important to underscore the following:
<Highlight>
	The single biggest differentiator between where your language is today and where
	you would like it to be is the repeated daily practice of the language, no matter how
	insignificant it may seem in the moment. Practice adds up exponentially over time.
</Highlight>

# Beginner to intermediate
I won't bore you with a list of things you should be able to do at each level since that's
something you can easily find online.

When you're starting from scratch, the first thing you should be working on is the 'skeleton'
of the language - basic grammar, how sentences are constructed, etc. As much as I don't like
Duolingo, it's a good place to start, but don't expect it to teach you everything, especially
speaking. Once you're able to form basic sentences (e.g. "The gray cat is not playing"), start
practicing your 'output skills' - speaking and writing.

For intermediate learners, the goal would be to try to expand your vocabulary and express
yourself in a more colorful way. You should also be able to understand most of what you hear
around you, and be able to hold a basic conversation with a native speaker. Understanding all
grammar (for non-grammar-heavy languages) should be a given at this point. Try to slowly work
your way up to watching the news, listening to podcasts and reading books in the language.
You don't have to understand everything, but you should be able to understand the majority of
what you hear and read.

# Advanced to native-like
Reaching this level of proficiency requires a lot of work. Apart from things you can look up,
you'll need a near-native level for things like:

- participating in complex or political discussions
- reading books and watching movies without subtitles
- expressing slang and idioms correctly and effortlessly
- being in a highly academic or workplace environment
- flirting
 
Apart from the steps outlined in the previous section, you can also consider:
- intensive listening - listening to a short (15-30s) segment where your aim is to understand
every single word that is being said
- reading out loud - this will do wonders for your pronunciation and speaking skills
- reading books - books are the holy grail of reading skills
- pronunciation drills - find a native speaker pronouncing a word you're struggling with and
record yourself saying it. Listen to the recording and try to imitate the native speaker. Repeat
until you're satisfied with your pronunciation. It took me 2 months to nail down the
pronunciation of the word 'comfortable', so don't be discouraged if it takes you a while.

For reading, perhaps the biggest obstacle will be overcoming the 'sufficiently advanced' plateau
where you're quite comfortable reading and understanding the language, but you still don't
understand more than 98% of what you read. This is a very common phenomenon, and it's
something you'll have to work through. I'd say the best way to overcome this plateau is to read
books that are slightly above your level, but not too much, and then gradually increase the
difficulty level as you get more comfortable. Reading this material will also help you
tremendously with writing, although a lot of output is non-negotiable.

When it comes to speaking, your best bet would be to reach out to a native speaker who can help
you with your pronunciation and accent. There are many platforms on the web where you can find
native speakers who are willing to help you out. If you can't find anyone, no matter how
ridiculous this may sound, you can always talk to yourself. I know it sounds weird, but it's
actually a very effective way of practicing your speaking skills. I've done it myself and it
worked wonders for the coherence of my speech. For pronunciation and accent, I can only
recommend reading out loud - taking a short paragraph from a book or article and reading it
out loud. This requires, however, that you know exactly how to pronounce each word you're
reading, which is why this technique requires sufficient listening skills. When implemented
correctly, however, it's a very effective way of improving your pronunciation and accent.

You may also notice that reading out loud will get you tired very quickly in the beginning.
This is perfectly normal, and in my case, I could only manage 20 minutes of doing it at first.
Almost a year later, however, I could do it for 3 hours straght.

# Let's debunk some myths
... because there are a few!

## You need to move to the country where the language is spoken
In today's world of the internet, you can learn a language from anywhere. All you really need
is a stable internet connection, good resources and the will to learn. There are many learners
just like you who are looking to improve their language skills with a native. One resource is
[Reddit](https://www.reddit.com/r/language_exchange/).

## You need to attend classes
I dislike classes for two main reasons - they tend to be expensive and they create the notion
that you have to passively wait to be taught things rather than proactively seek them out on
your own. I'm not saying that classes are bad - they definitely work for a large pool of
people, but I think they're overrated. Don't think you absolutely HAVE TO attend classes
to learn a language - you simply don't.

## You need grammar/vocabulary drills
Let me tell you a little secret - I have **NEVER** picked up a grammar book for learning
English, and I'd say my grammar is decent-at-worst. Grammar and vocabulary drills are
infamously boring and disliked by most people, and for a good reason. The good news is,
you can skip them altogether and learn from articles, blog posts, books, etc. Your brain
is a pattern recognition machine, and it will pick up the patterns and meaning on its
own, you just have to give it some context.

## English is easy, Japanese is hard
Depends who you ask, actually. For a Chinese person, learning Japanese is probably much
easier than learning English since the two languages have developed in a completely
different time and space, and in many aspects, Japanese is closer to Chinese than English.
For a native English speaker, Spanish will be easier. You can hopefully see how saying that
one language is more difficult than another is a bit of a stretch.

What does apply, however, is that every language has its quirks and nuances and things that
are very specific for learning that particular language. For example, English has a lot of
phrases, Danish will kill you with pronunciation, and Czech will fry your brain with how
complex its grammar is.

# Random tips here and there

## Focus on the process, not the goal
You'll only be disappointed if you keep looking at how much there's still left to learn. A much
better approach would be to take one step at a time, and then look back after a few months and
see how much you've grown in the meantime.

## Celebrate the small victories
No matter your goal, it will take you a while. Praising yourself and celebrating your progress
can go a long way - as soon as you notice progress at something, that's already a reason to
celebrate! I remember listening to a live NBC broadcast during the 2020 presidential election
in the US, and crying because I could understand everything word by word. That's something I
would have never thought of doing just 4 years prior, so I made sure to drop some tears of joy.

## Don't take tests and scores too seriously
Make sure you're learning the language for its practical usability, not for a random number
on a paper you can show off. A language is first and foremost a communication tool, not a thing
to be meticulously studied or measured on a scale. Just because you scored 190 points on a test
and your friend got 192 points doesn't mean he's more skilled. Focus on the practical usability
of the language instead of scores, numbers and levels and you'll be just fine.

## Imitate, imitate, imitate
If there's only one advice I would give people, it's the above. Try to imitate native speakers
as much as possible, and in all aspects - grammar, spelling, vocabulary, pronunciation...
they're the best teachers, after all, even if they don't know what they're doing.

<Highlight>
	First of all, welcome to my **brand new blog!** 🎉
	I'm really excited to finally have a place to share my thoughts and ideas with the world.
</Highlight>

 
As the very first post,
I thought it would be nice to give you a little insight into how this website was built.

# The problem(s)

The last time I built my own website was in early 2020. A lot has changed since then.
New frameworks have been released, existing frameworks have been enhanced with new features,
and many libraries have died - the ever changing world of web development.

Apart from the aging problem, there was another one on the horizon - my previous website
didn't really look all that good. I wanted something that was more modern, more minimalistic,
and less boring. And one day while scrolling through [Twitter](https://twitter.com/),
I had a winner.

# Mantine UI to the rescue!

The [Mantine UI](https://mantine.dev/) library is a React UI library that provides
a lot of components that are easy to use and look great out of the box. I was beyond
happy to finally have found a great replacement for Material UI, Ant Design, Chakra UI
and all the other libraries that I had tried in the past. It felt like a breath of
fresh air.

Discovering Mantine gave me the kick I needed to get cracking. But since building a
website from scratch is a lot of work, I decided to write down all the necessary steps
first, and tackle them one at a time.

# The steps themselves

In general, the steps I took to build this website looked something like:

1. Figure out the purpose, features, and requirements of the website
2. Come up with content (paragraphs, images etc.) that will serve that purpose
3. Build a site map (a diagram that shows the structure of the website)
4. Design the website (layout etc.)
5. Build the skeleton and simple components first
6. Add the content, localized for different languages
7. Polish the look with transitions, optimize performance, and add SEO
8. Build the whole blog system
9. Set up analytics

## Purpose, features and requirements
During this stage, you would usually ask yourself what do you want the visitor of your
website to take away. In my case, I wanted the visitor to have a convenient way of
reaching out to me, show my work experience, my skills, hobbies, passions, and some
volunteering experience. I also wanted to have a blog where I could write cool posts
like this one.

In terms of design and tech, I wanted the website to be clean, minimalistic, responsive,
reasonably fast and easy to navigate. Lastly, I wanted the website to be localized in all
the languages I speak in order to accommodate for the different audiences.

## Content
This was the trickiest part - writing down all headings, paragraphs, images, sections...
Coming up with content that isn't monotone and doesn't shift too much when changing
languages is by no means easy. A few weeks later, though, I had a good amount of content
that I was happy with.

## Site map
This is a diagram that shows the structure of the website. It's a great way to visualize
the content and make sure that it's all there. I actually skipped this part organized
the content into sections and pages in Notion instead.

## Design
I used [Figma](https://www.figma.com/) to design the website. I think I've learned more
about Figma in the few short days of designing with it than all the previous years combined.

Here's a little sneak peek of the design:

<BlogImage src="/assets/blog/how-this-website-was-built/figma.png" alt="Figma designs" />

## Skeleton
This meant building a few atomic components of UI that will be used for the majority of the
content displayed. Things like text, images, whitespace, buttons, what font sizes should be
used, what colors, font faces, thicknesses of the font, etc.

## Localized content
This was actually quite tedious. I had to write down all the content in English first,
and then translate it into the other languages. I used [DeepL](https://www.deepl.com/)
to translate the content, and then went through it manually to make sure it's all correct.

## Polish
This is where I added transitions, animations, and other small details that make the website
feel more alive. I also optimized the performance of the website, and added SEO. Here are
some of the results:

<BlogImage src="/assets/blog/how-this-website-was-built/lighthouse.jpg" alt="Lighthouse stats" />

## Blog system
This was one of the most time-consuming parts. I had to build a blog system that would allow
me to write posts in MDX files, and then display them on the website. I might want to enhance
the blog system in the future as well.

## Analytics
This is the last item on the list, and I'm still not quite sure which tool I'd like to use
here. Let's also keep in mind GDPR and other privacy laws that might come into play.

# Conclusion
I'm very happy with the result. The new website looks MUCH cleaner, fresher, and more modern.
Finally more like a 2022 website. I'm also very happy with the blog system that I built. It's
very easy to write posts, and even have tags for different topics. If there are any other
features that you'd like to see, please let me know! I have some in mind, but my strategy here
is 'underpromise and overdeliver', so I'll keep them to myself for now 😄

“Wait, you even have a blog?”

Get lost in the reading

Server state at scale

How to get better at TypeScript

Full-time developer starter pack

We know it all... until we don't

ChatGPT & friends

Cardio rocks! Part one

My trip to Belgium

How to (not only) English

How this website was built