Forem: Joonhyeok Ahn (Joon)

How not to create another bug while fixing one

Joonhyeok Ahn (Joon) — Fri, 14 Apr 2023 20:57:26 +0000

Many developers make mistakes of making more bugs while trying to fix a bug. People will trust you more if you don't produce these unnecessary outcomes.

Here are 5 tips that I've learned over time

Understand the root cause of the bug: Before you start fixing the bug, make sure you understand the root cause of the problem. This will help you to identify potential side effects of the fix. Any reports, logs, or system dashboard can be useful information.
Write test cases: Before fixing the bug, write test cases that cover the problem. These test cases should be able to reproduce the bug and should also cover any related scenarios. After you have fixed the bug, run these test cases to verify that the bug has been fixed and that there are no new issues.
Isolate changes: When fixing a bug, try to isolate the changes to the smallest possible area of code. This will help you to identify any potential issues that may arise from the changes you make. And if you are not sure what side effects your changes can make, try to communicate with other members first..!
Review your code: Have someone else review your code before you merge it into the main codebase. A fresh set of eyes may identify issues that you missed. Even if you already covered the automated tests, running a quick manual test will never hurt.
Monitor: After you have fixed the bug, monitor the application for any regressions. This involves checking that the fix did not introduce new issues. Again, any reports, logs, or system dashboard can be useful.

I was able to produce less bugs after I started applying these tactics to the daily workflow. So try these and become more reliable dev in your team!

If you like this content, please follow https://bitethecode.substack.com and https://github.com/bitethecode. I will try to share what I've learned with y'all!

Understanding of context in Go

Joonhyeok Ahn (Joon) — Sun, 12 Mar 2023 19:50:54 +0000

Context is a standard interface allowing you to carry request-scoped values, cancelation signals, and deadlines across API boundaries and between processes. The concept seems straightforward, but it wasn't obvious when I tried applying it to the codebase. After experimenting, I’m sharing what I learned about the context in Go today.

The Usage

Request scoped data

With context, you can pass around request scoped data such as body, headers, or params to downstream. For example, context can contain auth token and this can be passed to middleware or controller for further usage.

ctx := context.WithValue(context.Background(), "auth_token", "token")
fmt.Println(ctx.Value("auth_token")) // prints "token"

You can add key value pair to context with WithValue function. When we pass down this derived context, any context from the derived one can see this value.

Cancellation

This function returns a derived context from the context passed. A new Done channel is added, which is closed when the cancel function is invoked or the parent context Done channel is closed.

ctx, cancel := context.WithCancel(context.Background())
defer cancel()

The general rule is only the function that creates derived context should call the cancel function to avoid any unexpected outcomes. Also, always call cancel to release the children's resources held by the parent context. Otherwise, it can lead to a possible memory leak.

Timeout/Deadlines

func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc) {
    return WithDeadline(parent, time.Now().Add(timeout))
}

Under the hood, timeout and deadlines serve to avoid holding resources for a while. When timeout exceeds or context is canceled, the Done channel will be closed. If that happens, ctx.Err will not be nil. So you can find the error cause by a switch statement.

How to create context?

There are a few ways to create context.

context.Background() this will return the empty context. Most times you can use this as a parent context that will be passed down.
context.TODO() this will also return the empty context. Yet, you can use it as a placeholder when you are not sure and want to defer decision.
r.Context() this will return the request's context. I use it for most cases since I'm handling API heavily.

What is context tree?

In Go, we usually use derived context. The typical workflow is it starts from the parent context, a new context is derived with added additional information, and is passed down to the next layer. So, essentially it makes a context tree. This can be beneficial as you can cancel all the context at once.

Apply context cancel

package main

import (
    "context"
    "fmt"
    "time"
)

func main() {
   ctx, cancel := context.WithTimeout(context.Background(),time.Duration(3*time.Second))

    go func(ctx context.Context) {
        // simulate a process that takes 4 second to complete
        time.Sleep(4 * time.Second)
    }(ctx)

    select {
    case <-ctx.Done():
        switch ctx.Err() {
        case context.DeadlineExceeded:
            fmt.Println("context timeout exceeded")
        case context.Canceled:
            fmt.Println("context cancelled by force. whole process is complete")
        }
    }
}

Let me explain the code snippet above. The main program creates a new context with a cancelation signal that will be triggered after 3 seconds. Then it starts a long-running go routine that listens for the context to be canceled. As the go routine takes more than time out configured, the go routine will be canceled. As the main program is listening to the context channel, it will print out “context timeout exceeded" after the context is canceled.

A few notes

If background workers share context for context in the HTTP cycle, this can be canceled when the context from the request is canceled. If you don't want this, you should create a brand new context for background processing using context.Background()
Pass request-scoped data only using context. Other data should be passed via function arguments.
Be careful of goroutine leaks

Conclusion

Context library is so nice and simple, we have to use it with caution as it can result in unexpected behavior in the codebase. I wish you understand better the context after reading this.

If you like this follow @bitethecode and Github

Stand out among developers with customized Github profile

Joonhyeok Ahn (Joon) — Fri, 24 Feb 2023 17:09:26 +0000

Why Github Profile?

Github allows developers to customize their profiles. People can see your profile when they access to "github.com/your-user-name". With this, you can share who you are and what you do as a developer. One big benefit is you can save your time building a portfolio site from a scratch. It's also a perfect place to showcase what you do since it stores all your Git history.

So, let's customize your Github profile and advertise yourself.

Example

This is my Github profile. I tried to keep it simple and sweet but you can make yours however you want.

How to start it?

Log in to Github
Create a new repository
Name a repository name with your username
Make sure to set public

Then, you will have a newly created repository with README.md. You can customize your profile by modifying this file.

What is README.md?

The readme is based on markdown. With markdown, you can add your flavor to the plain text. For example, you can make a certain sentence bold. Or you can add tables to your docs.

If you never used markdown before, start with this. As we can use markdown in other places, I recommend spending time playing with it.

What to put in?

The general rule

I'd like to think Github profile as a resume. If you put too many highlights, people will get distracted by your messy resume and lose interest. So, keep in mind that simplicity is the best.

Who you are

First of all, tell people who you are. Your name, your job title, or your interest. Tell people who you are.

What you do

Next, let people know what you are working on.

If you have a job,

what is your job title
what is your current tech stack
what is your role in your current position

If you don't have a job,

what do you want to be
what do you study or prepare now

You may capture the opportunities by sharing this information when future employers look through your Github profile.

Highlights

Not everything you do is equally significant to the audience. Instead of putting A-Z, make a few bullet points. What is your highlights? What are the projects that you are proud of the most? Remember, keep it simple and sweet.

Add flavors

Utilizing the packages

There are free packages you can use to make your profile more visually enjoyable. I will introduce a few I use for mine.

One popular is Github Streaks. It provides a visual of your total contributions and streaks.

Another popular one is Github Stats. It provides a visual of your Git history.

These packages are easy to set up. If you access to the sites, you can simply copy and paste code. And replace the username with yours then magic will happen.

Github Actions

Github actions is CI/CD platform that allows you to automate your workflow. You can make your profile more delightful with Github actions.

To use Github actions,

Go to your Github profile repository and click the Actions tab
Click the new workflow

Configure Yaml to your own needs. A few notes about configuration.
1. You can change the workflow name as you want.
2. You can schedule this workflow to make it run automatically.
3. You can use solutions that other developers already built.

This is the workflow I'm using to fetch what I've written on my blog.

You can find more Github actions in here.

Conclusion

Today I covered Github profile. It can be daunting to set up the profile at once. So start with the bare minimum and update as you go. As every developer is using Github for their development work, having the right profile can bring you unexpected opportunities. You can use mine if you want to have a kick starter Github Profile.

If you like this, follow @bitethecode and Github for more useful content..!

Useful links

The Right Backend Roadmap

Joonhyeok Ahn (Joon) — Mon, 06 Feb 2023 21:29:43 +0000

Intro

When I started working as a software engineer a few years ago, I wasn't clear on what I should learn to be better at my job. When I tried to search on the internet, I was even more confused. Every day, trends changed. And so many people put emphasis on their own roadmaps to draw attention. I was able to discern what is important over time. Yet, I wished there were people and resources that can point in the right direction.

So, what matters?

We cannot learn everything at once with limited time and energy. We should focus our energy on what matters. I will cover the most important topics that every backend developer should know.

The basics of programming languages

Pick up one language and be decent about it. Here are a few options for you.

Java
Go
Php
Python
Javascript

Please, don't judge which language is the best this year. People always have their own preferences and there is a trend. These will change. Yet, you will always be on top of the game if you have a fundamental understanding.

So, learn about

Variables
Functions
Control flows
Loops
Data Types e.g) array, map
Class/Interface
Errors

Also, put the time to understand Object Oriented Programming. OOP makes software development easier with modularity, reusability, etc.

If you master these, you should be able to easily pick up another language.

Frameworks

Most dev teams use frameworks. Frameworks provide common functionalities and boilerplate code. So, we can save our time and energy from mundane tasks. Many programming languages have their popular frameworks. Pick one and learn about

Errors
Logging
Configuration
MVC (model, view, and controller)
Workers

From there, you can take in more when needed.

APIs

APIs are the fundamental blocks in building software. The benefit of APIs is services can communicate without knowing how it's implemented. Let's say we are building restaurant software. API consumers ask for information about menus. API returns the data without letting consumers know how it's working behind the curtain.

You can build APIs via RESTful. Or graph. Take one and learn it.

Make sure you understand these first.

CRUD (create, read, update, and delete)
Authenticate and authorize
Version
Request and response
JSON
Status code

Database

Any backend services use the database to store records. People can choose either RDMS (Relational Database Management System) or NoSQL. It's your choice. Yet, it's beneficial to understand how SQL is working first.

Learn about

How to design the database with entities, attributes, and relationships
Types of keys e.g) primary key, foreign key
Type of joins e.g) inner join, outer join, etc
ACID
Transactions
SQL syntax

Also, learn about

How to connect backend services to the database
How to use ORM
How to lazy load
How to avoid the N+1 issue

Testing

I will start with an assumption that we all think testing is important for building software. There are different types of testings

manual testing
unit testing
e2e testing

Start with unit tests. Unit tests make sure the smallest testable parts are tested for various scenarios. With unit tests, we can

catch bugs earlier
refactor easier.
reduce code complexity

So, learn about

how to write unit tests
TDD
integration, e2e, or manual tests

Conclusion

Today I covered what you should know as a backend engineer. For sure, there will be more to learn over time, you should have strong pillars first to build a strong house. Your fundamentals will carry you anywhere you go!

Which social media are you on?

Joonhyeok Ahn (Joon) — Wed, 01 Feb 2023 19:07:49 +0000

I used to have Twitter only.
I like Twitter as great minds from different fields share thoughts and be friends, but it's daunting a few times. I felt behind and imposter with the nature of frenetic pace in Twitter.

Yet, I still want to keep a few social media as I want to to make connections or share what I learn.

Which social media do you use as a developer?

Docker tutorial - dive into docker-compose

Joonhyeok Ahn (Joon) — Mon, 30 Jan 2023 18:48:07 +0000

published

Content

Intro
What is Yaml?
The essential syntax
Further explanation about services
Build with compose commands
Conclusion

Intro

Now you should be able to run the Docker container with your image. In reality, there will be more services involved in software development. You might have your core service, database, cache, and more when you are building the backend. We can run Docker containers with the CLI and connect to components, yet it can be tricky. Docker provides a tool Compose to run multi-containers with ease.

What is Yaml?

Compose uses the YAML file to configure the multi containers. Yaml is one of the DSLs and is usually used for configuration purposes.

The essential syntax

Compose also offers a quite few syntaxes but I will cover only the most used from my own experience.

services:
  frontend:
    image: awesome/webapp
    ports:
      - "443:8043"
    networks:
      - front-tier
      - back-tier
    configs:
      - httpd-config
    secrets:
      - server-certificate

  backend:
    image: awesome/database
    volumes:
      - db-data:/etc/data
    networks:
      - back-tier

volumes:
  db-data:
    driver: flocker
    driver_opts:
      size: "10GiB"

configs:
  httpd-config:
    external: true

secrets:
  server-certificate:
    external: true

networks:
  # The presence of these objects is enough to define them
  front-tier: {}
  back-tier: {}

According to the official docs, a Compose file must declare the services top element. Values will be service definitions. And the service contains the configuration that will be applied to each container. There are frontend and backend services in our case. A Compose file can have volumes as a top element, which serves as a persistent layer. A Compose file can also have networks as a top element. Any containers belonging to the networks can communicate. For example, frontend and backend services can communicate via the back-tier network. Configs and secrets are read-only elements for configuration purposes.

Further explanation about services

In most cases, services will be our main interest. Let's deep dive into it.

web:
    build: .
    image: awesome/web
    ports:
      - "3000:3000"
    networks:
      - front-tier
      - back-tier
    depends_on:
      - db:
          condition: service_healthy
    environment:
      - SERVER_ENVIRONMENT: development
    configs:
      - httpd-config
    secrets:
      - server-certificate
    volumes:
      - db-data:/etc/data

build specifies the build instruction. . tells the compose to find the Dockerfile in the current directory. If the build exists, it's okay to omit image declaration.

image specifies the image to start the container from. The Compose will try to install the image first if not existed. Then it will run other instructions.

ports specifies the exposed ports. The syntax is HOST[ip:]port:CONTAINER's port
3000:3000 means to map port 3000 in the machine to port 3000 in the container.

depends_on specifies the dependencies in start-up and shutdown. In the above example, Compose will create db. Then it will wait until the db is healthy before creating the web. This can be useful when we have dependencies and services that we have to create in order.

environment specifies the variables set in the container. You can also specify the variables with env_file . If both are present, the environment will take precedence.

volumes specifies the instruction on how to mount the volume for persisting data. The syntax is [SOURCE VOLUME:]CONTAINER_PATH. If the source volume is empty, the compose will create a directory. Then it will mount it as a volume to the target path inside the container.

From my experience, these specifications have covered the majority of use cases.

Build with compose commands

The typical workflow for development will be code, build, test, and push. You can take advantage of the compose to speed up your development process. I see this quite useful when a team onboards newcomers. Compose can save the setup time for new comers when they are not familiar with the system yet,

Here are a few useful CLI for your disposal.

docker-compose up create and start containers. If pass the parameter -d, you can run them in detached mode.
docker-compose down stop and remove containers, networks, images, and volumes.
docker-compose stop stop services without any destructive operations.
docker-compose logs shows the logs from the containers.
docker-compose exec executes a command in a running container.

With these commands, you can manage many containers without hassle.

Conclusion

I covered the concept of docker-compose and useful commands. Try to run multi containers of yours. I will cover useful commands and aliases you can apply to your workflow in the next article.

If you like this content, follow

How to prepare the future as a software engineer

Joonhyeok Ahn (Joon) — Fri, 20 Jan 2023 18:40:01 +0000

There are multiple rounds of massive layoffs in tech. Software engineers were once considered one of the most secure positions, but not anymore. So, what are you supposed to prepare for the uncertain future? The answer is obvious. Make you irreplaceable.

Here are a few you can do to make yourself more valuable.

Participate in open-source projects

Involving in open-source projects can seem daunting. Yet, it’s fun and beneficial once you start it. The biggest benefit is you can learn about your topic in depth. I was able to learn more about the CI/CD process and logs by contributing to a few backend projects. Plus, you can learn from more experienced engineers via peer review. This expands my understanding of development in general. Last but not least, open-source contributions are proof of your work. This can be your new resume.

Build your own projects

Working on side projects sounds boring. Yet, we can’t ignore the benefits. I don’t recommend building an Instagram clone. What I recommend is to build what you wish you had. As a software engineer, you may have ideas, but you may have never implemented them. “This sucks”, “How this poor service makes money?”. Fix them, publish them. Your side projects can be your full-time in the future. At least, you will learn way more about engineering than watching Udemy courses. Your project will make you stand out among the crowd.

Study data structures and algorithms

I observed a ton of engineers don’t like to work at their current places, yet they stick to it as they are more afraid of technical interviews. Whether you like it or not, tech companies still do a technical round to find the best candidate. I don’t say it’s the best approach to finding great candidates. Yet, it's the price you have to pay for opportunities. For those who want to learn data structures and algorithms, I'm writing everything about tech interviews here → Ace Interview. Star it and use it for your own sake.

Conclusion
If you are preparing for yourself, you should never worry about your job. Life can be uncertain, yet we can still remain calm if we are willing to.

If you like this content, follow @bitethecode or Github

Docker tutorial - understanding of Dockerfile

Joonhyeok Ahn (Joon) — Mon, 16 Jan 2023 19:28:52 +0000

Content

What is Dockerfile?
Why do we need it?
Essential commands
Baking an image
Starting a container
Conclusion

What is Dockerfile?

Dockerfile is a text file that contains a set of instructions. If run, we can build an image. Then we can run containers with a built image

Why do we need it?

We can use pre-built images like Postgres. Yet, we have to build images for our core services though. To containerize this, we have to make Dockerfile. Thanks to its simplicity, we can start building our images with a few commands.

Essential commands

The following commands are the basic ingredients to build an image.

FROM tells the base image to start the process. E.g) linux-alpine
RUN and CMD tell commands to run.
The difference is RUN will get executed while building an image. CMD will get executed by default when we launch the built image.
ADD copies the files from the source to the destination inside the container.
ENV sets the environment variables
ARG variables are only available while building an image.
EXPOSE tells the Docker container to listen to specific ports.
WORKDIR sets the working directory for commands like RUN

Baking an image

Now you understand the basic commands, let's look at the following one.

# syntax=docker/dockerfile:1
FROM node:18-alpine
WORKDIR /app
COPY . .
RUN yarn install --production
CMD ["node", "src/index.js"]
EXPOSE 3000

With the base image node, it will copy all from /app to /app. Next, it will run yarn install for dependencies. Once it finishes the installation. The process completes.

Tip: CMD and EXPOSE will get run when starting a container based on this image.

To build an image, run

docker build -t first-try.

This will build an image. If you pass ., Docker will look for Dockerfile in the current directory. After building an image, it will tag the image you pass. In this case, I tag it as a "first-try".
Tip: tag is not required. It's more for a human-readable label.

Starting a container

Once we have the Docker image baked, we can run a container. Run,

docker run -d first-try

Tip: -d is the option for detached mode. If you pass this option, Docker will run in the background.

To see your container's status, run docker ps.

Conclusion

Now, you should be able to build an image and run containers with your image. What if we need to run more complicated software? What if it has a database or cache? Docker provides a tool docker compose for running a multi-container codebase. We will look into it in the next article.

If you like this content, follow @bitethecode or my Github

How to start off January well

Joonhyeok Ahn (Joon) — Tue, 10 Jan 2023 18:48:48 +0000

January is the most important month as it can set the tone of your year. If you still don't know how to spend your very first month in 2023, do this!

Dry yourself
There are fewer social events in January. So use this time not to drink! Keep your brain sharp.

Use this month to set 1 good habit
Researches say it takes at least 21 days to build a new habit. You have 21 days left. Here are a few good examples.

Writing 30 minutes

Studying 30 minutes

Work out for 30 minutes

Talk with your beloved ones without digital devices

Choose one of them and start today. And never break a streak.

Set up your goals People may say you have too much stuff to do. Wrong. That means people don't have clarity about goals. So spend time to find which ones you really want to achieve this year. Then set up the right priorities.

That's it! If you like this content follow @bitethecode!

New Youtube Channel for Every Software Engineers

Joonhyeok Ahn (Joon) — Sat, 07 Jan 2023 15:35:08 +0000

I decided to start Youtube to share what I learn about software development along with the project Things I wish I had.
I will focus on backend development, data structures & algorithms, and open source projects. If you like to see more useful content in depth, start follow https://www.youtube.com/@the-writer-dev. You will not regret..! Thanks!

Git tutorials - understanding of rebase and merge

Joonhyeok Ahn (Joon) — Tue, 03 Jan 2023 16:13:02 +0000

Content

Intro
Why branches start diverging
Git merge
Git rebase
When to use merge or rebase
Conclusion

Intro

In a previous article, I explained how to reconcile merge conflicts. I will explain in depth why we see diverging branches and options to resolve them.

Why branches start diverging

Image by Atlassian
As shown above, any dev teams protect the master branch. So you have to branch off the master branch and start making changes. In the meantime, others can update the master branch. If those diverging branches were not overlapping the codebase, that's fine. Yet, we will see the changes in the identical parts. Then Git doesn't know which one takes for consolidation.

So we need to reconcile conflicts before pushing our changes to the prod.

Git merge

Image by Atlassian
Merging is one way to resolve discords. Merging creates a new commit that combines the history of two branches. So, merging doesn't rewrite Git history. Yet, the Git history can become messy when we bring changes from many branches.

Image from Stackoverflow

How to merge it?

The idea is simple. Go to the target branch and merge the branch you want to bring changes. If there are no conflicts, merging is successful. If not, you have to resolve the conflicts. To do so, refer to the previous article [[Git - Ch3]]

git checkout dev
git merge master

Git rebase

Image by Gitlab
Rebasing is another way to resolve discords. Unlike merging, rebasing doesn't create a new commit. Instead, it brings commits from the branch you want to incorporate and replay all your commits on top of it. Rebasing is nice as it doesn't create a merge commit. It also guarantees the linear Git history, which is cleaner than merging.

How to rebase?

Go to the target branch and rebase the branch. Go to the target branch and rebase the branch you want to bring changes. If there are no conflicts, the rebase is successful.

git checkout dev
git rebase master

When to use merge or rebase

I see the pros and cons of merge/rebase. It has been a debate ever since I started the dev career. The answer is nothing wrong with either approach. It will be beneficial to pick one method and be consistent. So, you can use the following questions to find out which way is better for your team.

Is your team familiar with rebase?

If not, the answer is obvious. As rebasing will rewrite history, this can be a destructive operation.

Is your team big?

If your team size is small, both approaches should work well. If your team size is big, consider rebasing for clean Git history.

Are the branch represents grouped information?

If your team uses a branch-per-feature model, merging will be easier to revert as it contains a set of relative commits.

Conclusion

There is no single answer for all situations. So, check your team's context to find which way will be the best.
Next time, I will cover rebase, which can use for other tasks like squeezing commits.

For more useful content, follow me @bitethecode or on Github!

What books I read this year

Joonhyeok Ahn (Joon) — Fri, 23 Dec 2022 18:16:33 +0000

Content

Intro
Lessons from Atomic Habits
A few more strategies
List of books I read
Conclusion

Intro

When I was a kid, I loved reading. I heard from my family that I was holding books even when I ate. Yet, I started losing interest in books over time. I had to study, graduate, and make a living. I made excuses. "I don't have enough time to read!". This year, I happened to read a book called "Atomic Habits" written by James Clear. After I finished reading it, I decided to bring my reading habits back to life.

Lessons from Atomic Habits

The author says there are four steps in any habit we do.

cue
craving
response
reward

Let's think about a typical example. You feel bored while waiting for a bus (cue & craving). Then you open SNS and you feel entertained (response & reward). For any habit, we can either make these four patterns work for reinforcing a good habit or stopping a bad one.

When looking back, I stopped reading not because I didn't have enough time. I stopped as there was more entertaining media - Youtube, Netflix, or SNS. To bring reading to life, I needed to work on two things.

spend less time in entertaining media
spend more time in reading

The author gives a few strategies for forming a habit.

Make it obvious.
Make it attractive.
Make it easy.
Make it satisfying.

These tactics were enough to reduce screen time. First, I removed Youtube, LinkedIn, and other social media from my phone and laptop. Second, I put my phone in different places while I'm working or spending time with family. By making the device boring and inaccessible, I felt I became less attached to it.

A few more strategies

While I'm working on less screen time, I need to make a routine for reading.

Set up reading time

I felt tired when I tried reading after work. Even when I had time after dinner, I didn't have the mental capacity to read through and take it in. So, I tried reading in the morning. It turned out wonderful. The obvious benefit was that my brain was ready for taking in what books offer after 7 hours of sleep. Another one was the tranquility that morning offers. When I woke up around 5 am, the whole world was silent. I didn't have to see the emails or messages. I only focus on what I'm reading. I slowly became addicted to this positive experience. For these reasons, I kept waking up early in the morning and staying in my den for reading.

Paper books are better

I used to read ebooks. You can read books regardless of your location and time. Yet, I noticed the phone is distracting. Alarms and notifications wait for the response. So, I started reading paper books. You have to carry the physical books and it costs more money. Yet, I found a few beautiful points while reading paper books. First, each book uses different textures and fonts. This gives a new experience for each book. Also, I involve more in reading by highlighting lines or scribbling. Lastly, I could remember more than ebooks after reading.

Languages don't matter

I thought I should read in English all the time if I wanted to improve my English skills over time. This led me not to read about novels, essays, or short forms as they include more descriptive and poetic expressions. Once I threw that bias about the languages, I could expand categories and read any forms if I'm interested.

Fight with biases

I did have biases about books. Here are a few you might be familiar with.

You have to finish it once you start
You have to read in order
You have to read different categories

These biases made reading unattractive. So, I decided to take different approaches. Instead of obsessing about reading the entire book, I stopped reading when it starts boring or hard to read. I moved on to other books without feeling guilty. I also stopped obsessing about reading in order. I went to the index page and picked up the chapters that hooked my eyes. Finally, I stopped obsessing about reading in variety based on recommendations. Instead, I started reading that interested me.

I learned that there is no perfect way for reading books.

List of books I read

There might be books I missed. Yet.. here is the best I can remember.

Books written in English

Atomic Habits
Deep Work
So Good They Can't Ignore You
Essentialism
Hooked
Rework
The 7 Habits of Highly Effective People
The Miracle Morning
The Almanack Of Naval Ravikant
Wabi Sabi
Ikigai
Daily Stoic
Courage Is Calling
Ego Is Enemy
Make Time
How To Win Friends And Influence People
How To Stop Worrying And Start Living
The Psychology of Money
Rest: Why You Get More Done When You Work Less
The Scout Mindset
The 4 Hour Work Week
Ultralearning
This Is Marketing
The Power Of Less
On Writing Well
The Manager Path
Pragmatic Programmer
The Go Programming Language

Books written in Korean

무뎌진 감정이 말을 걸어올 때
해변의 카프카
완전한 행복
인생은 소설이다
책의 역습
사이보그가 되다
언어의 온도
2인조
보통의 존재
울분
니체의 말
기억 1,2
죽음 1,2
문명 1,2
달러구트 꿈 백화점 1,2
미드나잇 라이브러리
하루의 취향
오늘 밤, 세계에서 이 사랑이 사라진다해도
오늘은 이만 좀 쉴게요

Conclusion

I didn't expect I could read this much when I started this year. I ended up reading more than 50 books. The numbers look amazing. The most beautiful thing is that books became the default mode. And I enjoy reading time more than screen time. So, if you want to make a habit of reading like me, don't overwhelm yourself with high expectations. Instead, start small. Start reading what you enjoy. And keep it. You can see the wonder over time.

Forem: Joonhyeok Ahn (Joon)

How not to create another bug while fixing one

Understanding of context in Go

The Usage

Request scoped data

Cancellation

Timeout/Deadlines

How to create context?

What is context tree?

Apply context cancel

A few notes

Conclusion

Stand out among developers with customized Github profile

Why Github Profile?

Example

How to start it?

What is README.md?

What to put in?

The general rule

Who you are

What you do

Highlights

Add flavors

Utilizing the packages

Github Actions

Conclusion

Useful links

The Right Backend Roadmap

Intro

So, what matters?

The basics of programming languages

Frameworks

APIs

Database

Testing

Conclusion

Which social media are you on?

Docker tutorial - dive into docker-compose

published

Content

Intro

What is Yaml?

The essential syntax

Further explanation about services

Build with compose commands

Conclusion

Links

How to prepare the future as a software engineer

Participate in open-source projects

Build your own projects

Study data structures and algorithms

Docker tutorial - understanding of Dockerfile

Content

What is Dockerfile?

Why do we need it?

Essential commands

Baking an image

Starting a container

Conclusion

How to start off January well

New Youtube Channel for Every Software Engineers

Git tutorials - understanding of rebase and merge

Content

Intro

Why branches start diverging

Git merge

How to merge it?

Git rebase

How to rebase?

When to use merge or rebase

Is your team familiar with rebase?

Is your team big?

Are the branch represents grouped information?

Conclusion

What books I read this year

Content

Intro

Lessons from Atomic Habits

A few more strategies

Set up reading time