
## Running FFmpeg in the Browser

I recently started a little project that involves running FFmpeg directly in the browser using [ffmpeg.wasm](https://ffmpegwasm.netlify.app/). The project is still **very** early and I'm not totally sure where I'm going to take it or if I'll continue working on it long-term. For now, I'm having fun learning about WebAssembly, while also expanding my knowledge of FFmpeg. At the time of writing the [site](https://lovely-gecko-4fbf77.netlify.app/) simply allows you to select a video file to "upload", which then results in an FFmpeg command running to generate a JPEG from a frame of the video. Nothing too exciting, but I've had some thoughts about potentially creating an FFmpeg command builder or providing autocompletion for FFmpeg commands. This could allow for quick feedback while iterating on creating FFmpeg commands. If any of this sounds interesting, head over to the [repo](https://github.com/aaronmbos/browser-ffmpeg) on GitHub and give it a star.

If you've got to this point in the post and don't really know much about FFmpeg, that's totally cool. I have a particular interest in it given that I work on software every day that relies on it. With that being said this post is more focused on the potential of WebAssembly in the browser rather than discussing the details of FFmpeg.

## FFmpeg.wasm

As a quick example of what is possible with WebAssembly I want to go into a little bit of detail about the [ffmpeg.wasm project](https://github.com/ffmpegwasm/ffmpeg.wasm) itself. FFmpeg is a C program that is used for just about anything you can imagine in the world of video and audio processing. As you may know, C code does not run natively in the browser, so how does ffmpeg.wasm work? The answer is WebAssembly. I'll dive into some of the details in the next section but at a high-level ffmpeg.wasm works by transpiling the original C code into WebAssembly. Since WebAssembly can run in the browser, it brings the media processing powers of FFmpeg to the web.

A few other popular examples of WebAssembly being used on the web are [Figma](https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/), [Adobe Acrobat on the Web](https://blog.developer.adobe.com/acrobat-on-the-web-powered-by-webassembly-782385e4947e), and .NET's client framework [Blazor](https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor). I'm sure there are hundreds of other great examples out there as well. WebAssembly is not necessarily "new", but it is growing in popularity. In the next section, we'll look at a few features that make WebAssembly such an appealing tool for building with performance in mind on the web.

## WebAssembly

I've touched on some examples of WebAssembly in the wild, but I haven't gone into what makes it "special". WebAssembly, commonly referred to as "Wasm", is not a programming language that you'll find many (if any) people writing by hand. The best way to describe Wasm is a "compilation target". I like to think of WebAssembly as the result of compiling code from another language like C, Rust, Go, C#, etc. The main goal of Wasm is to enable high-performance applications on the Web. In my opinion, there are three key features of Wasm that contribute to the overall goal of "high-performance web applications".

1. Fast
1. Safe
1. Portable

### Key Feature: Speed

Wasm is able to achieve near-native performance in the browser by taking advantage of common hardware capabilities. Another factor in the speed of Wasm is that the code itself is a low-level, efficient binary format that is quicker for browsers to load and execute. While I wasn't able to find any "official" benchmarks comparing Wasm to JS, it seems that Wasm _typically_ runs 1-3 times faster than JS in the browser. This may not seem like a lot, but in applications where performance matters, that difference can make or break the user experience of the application.

### Key Feature: Security

Speed is great, but another very important feature of Wasm is security. I would argue that in most cases speed is irrelevant if the execution environment isn't safe for users or developers. For that reason, Wasm executes in a memory-safe, sandboxed environment, which claims to prevent data corruption and security breaches. Wasm provides no access to the environment that the code is executed on. Wasm is able to access system resources and perform IO when it is allowed by the embedder (the embedder defines the environment that Wasm will be hosted in).

### Key Feature: Portability

While this post and most of the focus on WebAssembly is scoped to running it on the web, one of the key features of the Wasm code format is that it is platform agnostic. Wasm's architecture does its best not to make assumptions about the underlying hardware that it is run on. This means that Wasm is built to take advantage of both common and modern hardware components. Wasm has started to become more common on the web, but it is possible to run it outside of the web given its platform-agnostic architecture. An example of WebAssembly outside of the browser is "WASI" or [The WebAssembly System Interface](https://wasi.dev/), the goals of WASI appear to align well with Wasm in general, but seem to be more targeted at portability and security.

I think that overall Wasm's speed, security, and portability make it an attractive tool for enabling high-performance code on the web. This post is by no means meant to be a deep dive into everything that Wasm has to offer, but rather an introduction to a technology that operates at a different level than what most developers are used to dealing with. There is a lot of great information available for WebAssembly and if you're interested in learning more I think the [specification](https://webassembly.github.io/spec/core/index.html) is a great place to start. It provides some high-level information along with everything you'd expect from a formal specification.


The introduction of WebAssembly (Wasm) has enabled developers to create experiences on the web that rival native performance. In this post, I'll provide an introduction to WebAssembly and also share an example of how it is leveraged to run FFmpeg directly in the browser.

Running FFmpeg in the Browser with Wasm


## What are conventional comments?

Code review is an integral part of working on software collaboratively. The collaboration may be at work with team members, on an open source project with other contributors, or on a school project with classmates. Regardless of the situation, code review is almost guaranteed to be required before merging changes.

Code review is also time consuming. The back and forth communication on initial and follow-up changes can go on for hours, days, and even weeks before the final approval is given for a set of changes. With that being said, wouldn't it make sense to look for ways to make code reviews as simple as possible? I think so.

This is where conventional comments come in. At their core, **conventional comments** (not to be confused with [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/)) are code review comments that follow a predefined set of standards. We'll go into some examples of standards later in this post, but ultimately the standards can be as rigid or flexible as needed to fit the needs of the team.

## Structure of conventional comments

As I mentioned previously, there isn't a globally defined standard for structuring conventional comments, but I think this [site](https://conventionalcomments.org/) provides a great starting point. In my experience, I haven't needed to deviate too much from the comment structure defined on the referenced site.

```
<label> [decorations]: <subject>
[discussion]
```

The `label` and `subject` are required fields (surrounded by `<>`), whereas the `decorations` and `discussion` fields are optional (surrounded by `[]`). Following this comment format provides a platform for **description, but not distracting** context for each comment. The conventional comment site provides a lot of great examples as well as a list of great labels and decorations to get started. In my day to day I've used the following labels most commonly.

- suggestion: propose an improvement or change (could be blocking or non-blocking)
- nitpick: trivial request based on preference
- question: ask submitter for clarification or relevance
- thought: useful for providing helpful context and sparking discussion

While this list it thorough, it is not exhaustive. The great thing about this format is that it can be adapted to fit the requirements of any team that applies it.

## Why are conventional comments helpful?

If you've never experienced bad code reviews or never considered ways to improve the code review process, you may be wondering why conventional comments are beneficial? In my opinion conventional comments benefit both the submitter of the code review and also the individual reviewing the code.

From the **reviewer** side of the coin conventional comments allow for clear expression of intention and tone in each comment. This reduces the chance for friction or confusion that could result from an unclear or ill-thought-out comment. In this same vein I think conventional comments force commenters to put a litte extra thought and care into the comments that are left, which leads to higher quality reviews.

Since conventional comments reduce confusion and friction, this results in a quicker code review process with potentially less back and forth. The submitter should understand the action that needs to happen when responding to a conventional comment. For example, the change requested in this comment needs to be addressed before approval.

> suggestion (blocking): Let's move this guard clause earlier to exit sooner in the case of failure.

From the perspective of the code review **submitter**, the fact that the the "gray area" is removed with the use of conventional comments is key. There shouldn't be any ambiguity as to what should happen as the result of a comment.

The final benefit of using a conventional comment format is parasability. We can easily request and parse PR comments to understand what kind of review is taking place. Are we most leaving "nitpick" comments? Maybe we need to adjust the linter or format tool settings to catch some of these issues during development. Are there a lot of "issue" comments? Maybe engineers need to be more better about understanding requirements before and throughout development.

These are all reasons why conventional comments can benefit code reviews for any team, even if the team doesn't think code review is an immediate concern.

Analyzing PR comments with GitHub API

To demonstrate the value behind the parsability aspect of conventional comments I'd like to share a simple example using the GitHub API to request PR comments on a repo. This example is pretty basic, but I think it shows the potential for understanding the nature of comments being submitted by reviewers in a repo.

I can think of a use case where a report is generated to understand the number of nitpicks, suggestions, issues, etc have been made on PRs for a given repo over a period of time. This can all be done easily with a standardized format.

The script below is written in Ruby and is pretty straightforward. It does require a valid token for GitHub authorization which I've omitted from the example.

1. Make a request to the GitHub API
2. Parse the response as JSON
3. Print the necessary to the console

```ruby
require 'net/http'
require 'json'

uri = URI('https://api.github.com/repos/aaronmbos/nextjs-blog/pulls/comments')

req = Net::HTTP::Get.new(uri)
req['Accept'] = 'application/vnd.github+json'
req['Authorization'] = "Bearer #{gh_token}"
req['X-GitHub-Api-Version'] = '2022-11-28'

res = Net::HTTP.start(uri.hostname, uri.port, use_ssl: true) do |http|
  http.request(req)
end

JSON.parse(res.body).each { |comment| puts "#{comment['body']} by @#{comment['user']['login']}" }
```

The particular repo that I am querying only has a single PR [here](https://github.com/aaronmbos/nextjs-blog/pull/1). As you can see the output from the script reflects the current comments that have been made on the PR.

![conventional-comment-script](https://res.cloudinary.com/aaron-bos/image/upload/v1675131516/conventional-comment-script_qrkq66.png)

In this post, I've provided an opinionated overview of what I believe to be the value of conventional comments for teams. There's no one-size-fits-all solution and I hope that you are able to take some of these opinions and apply them to improve your team's code reviews!


In this post, I'll present my case for using conventional comments in code reviews. I've been an advocate of conventional comments for about a year and have enjoyed using them. I'm hoping to share the benefits so others can adopt their own standards for code review. Let's dive in!

My Case for Conventional Comments


Collections are an integral part of almost any application that we build or maintain as software engineers. The concept of traversing collections with a for-loop is often one of the first paradigms learned by new engineers. Collection-like objects exist in most, if not all, languages. In C# we have several options when it comes to collections and each option comes with tradeoffs. As software engineers, it is our job to choose the right tool for the job. The decision of what kind of collection to use for a given scenario needs to consider the context in which the collection will be used. We should ask ourselves _Will the collection be iterated, searched, or manipulated heavily in the most common use cases?_ The collection type we choose for a given scenario could have massive performance impacts on the application and its users.

We will focus on a few collection types in C# to determine how they perform in regard to [Big O notation](https://en.wikipedia.org/wiki/Big_O_notation) when searching for and manipulating elements of each collection type. This post doesn't require you to be an expert in Big O notation, but it does assume a basic understanding of the topic. I will be focusing on the following collection types.

- `List<T>`
- `Dictionary<TKey, TValue>` & `HashSet<T>`
- Sorted collections

There are many other collection types that could be covered, but I wanted to focus on the types that I've used and seen most in my career. If you're interested in learning more about the Big O notation in regard to other .NET collection types, I would highly encourage digging into it for yourself!

## `List<T>`

I would consider `List<T>` to be the most commonly used collection type in the .NET ecosystem. That means we should understand how we can use it effectively and its performance when carrying out certain tasks. In terms of Big O notation, I'd say that most `List<T>` operations can be expected to be linear or **O(n)**. A linear algorithm's runtime is directly affected by the size of the input being processed. As the input size grows the runtime should grow linearly proportional to the input growth.

### Manipulating lists

Manipulating a collection is a common operation and typically involves adding or removing items from the collection. Normally the add and remove functionality is a linear operation. Below is a screenshot of benchmark results adding a random number to a `List<T>` at increasing sizes. As the size of the list grows, the mean runtime also grows _nearly linearly_.

![list-add-linear](https://res.cloudinary.com/aaron-bos/image/upload/v1673574244/list-add-linear_a5kyly.png)

While typically list manipulation runtimes are linear, there is an exception when adding to lists. When a list is created, there is an overloaded constructor that accepts an integer to indicate the `Capacity` of the list. If we create a list with a defined capacity and the `Count` property at the time of adding is **less than** the `Capacity`, then adding to a list is **O(1)** or constant time. The reason for this is that the underlying array does not need to be expanded to accommodate the new element. This means that the speed of the operation is not affected by the size of the input (in this case the size of the collection). We can see this in action in the benchmarks below. As the input size grows linearly, the runtime of adding an element to the list remains constant.

![capacity-list-add-constant](https://res.cloudinary.com/aaron-bos/image/upload/v1673574477/capacity-list-add-constant_h7wsya.png)

### Searching lists

When working with collections we often need to search the collection for a particular element. This could be with `.Find`, `.Contains`, `.IndexOf`, `.Where`, and other methods that look for a particular element in a collection. For this reason, it's important to understand that the runtime of searching for an element in a list is also O(n) or linear. The algorithm to find an element most likely needs to iterate through each element to find the one that it is looking for. In the worst-case scenario, the item isn't in the list and we've had to look at every element. We can see this in the benchmarks below using the `.Find` method to find a specific element in a list.

![list-find-linear](https://res.cloudinary.com/aaron-bos/image/upload/v1673574868/list-find-linear_vtswgr.png)

## `Dictionary<Tkey, TValue>` and `HashSet<T>`

In this section, we are going to focus on a couple of hash-based collection types, which are `Dictionary<TKey, TValue>` and `HashSet<T>`. While these are different types they both rely on hashing algorithms to store and keep track of the elements that are contained inside their collections. As we look at manipulation and searching operations we'll see some similarities with `List<T>`, but there are also some key differences that make these hash-based types appealing in certain scenarios.

### Manipulating hash-based collections

Both `Dictionary<Tkey, TValue>` and `HashSet<T>` are unsorted collection types, just like `List<T>`. We can also expect these hash-based collections to perform similarly to lists when it comes to manipulating elements. The documentation states that when adding items from a dictionary or hash set without a defined `Capacity`, the operation will have a linear, or **O(n)**, runtime. If we have defined a value for `Capacity` and the `Count` value is less than the capacity when adding, the operation will be performed in constant time or **O(1)**.

Interestingly enough when I performed benchmarks of this data, I noticed that the `Add` method performed almost identically when explicitly setting the capacity and when not. I took a look at the source code for the `Dictionary` class [here](https://github.com/dotnet/runtime/blob/6aaaaaa5c7b1160a237bb381074e707c3ea1e9b4/src/libraries/System.Private.CoreLib/src/System/Collections/Generic/Dictionary.cs#L473), which was quite interesting but a little challenging to follow while navigating in GitHub. For the dataset and benchmarks the `Add` method was performed in constant time.

![dict-add-benchmark](https://res.cloudinary.com/aaron-bos/image/upload/v1673574868/dict-add-benchmark_eurauo.png)

When it comes to removing elements from a dictionary or hash set, the operation is **always** performed in constant time. The reason for this is that the stored hashed values can be easily found in the underlying hash table for each of these collection types. Let's take a look at some benchmarks that confirm these behaviors and their runtimes. The example below shows the benchmark results for removing elements from `HashSet<T>`.

![hash-set-remove-constant](https://res.cloudinary.com/aaron-bos/image/upload/v1673575775/hash-set-remove-constant_pqew6h.png)

### Searching hash-based collections

We've seen some of the efficiencies that we can gain from using hash-based collections when manipulating data. Now we're going to look at their performance when searching for specific elements. There was one operation that we discussed previously that may provide a tip as to what the search performance might be...and that was the `Remove` operation. If we think about what needs to happen to remove an element from a hash-based collection, we first need to **find the element**, then we need to remove it. Searching is essentially the same operation without the removal, so if you remember that removal is performed in constant time we should be able to assume that searching is also performed in constant time or **O(1)**. Fortunately, that's a correct assumption as we'll see the runtimes approaching constant time in the following examples. The examples will show indexing into a dictionary and also calling `HashSet<T>.TryGetValue`.

![dict-index](https://res.cloudinary.com/aaron-bos/image/upload/v1673581722/dict-index_czkosn.png)

![hashset-trygetvalue](https://res.cloudinary.com/aaron-bos/image/upload/v1673581700/hash-set-trygetvalue_dvphan.png)

## Sorted Collections

So far we've looked at `List<T>`, `Dictionary<TKey, TValue>`, and `HashSet<T>` and how they perform different actions through the lens of big O notation. I wanted to take a quick look generally at sorted collections and their runtimes for the operations we've examined for previous types. Those operations are adding, removing, and searching each of the collections. One similarity between sorted collections and the ones discussed already is that the runtime is still O(n) when the internal capacity of the underlying data structure needs to grow due to the operation.

In most circumstances, we can expect sorted collections to perform operations in logarithmic time or **O(log n)**. This means that the runtime does change as the input size grows, but less drastically as the input size continues to grow.

![ologn](https://res.cloudinary.com/aaron-bos/image/upload/v1673664700/ologn_a8jdrn.png)

Although I haven't used sorted collections often in my day-to-day, I think it's useful to examine at least one benchmark to confirm their behavior, but also to be aware of their performance features. If there is a data set that we know will always be sorted, maybe it makes sense to use a `SortedList<TKey, TValue>` instead of a `List<T>`. Decisions always come with tradeoffs and being fully aware of the options and their implications is key to making the most correct decision. Let's take a look at the performance benchmarks for adding to and searching a `SortedList<TKey, TValue>` and confirm that we see close to logarithmic runtimes.

![sorted-list-add-get](https://res.cloudinary.com/aaron-bos/image/upload/v1673664773/sorted-list-add-get_cwxlfs.png)

The goal of this post wasn't to share the runtimes for each of these operations on the different collection types. That can be found easily in the documentation. The main goal was to present this information in a way that highlights the performance features of each operation and type in given scenarios. With this information, we should be prepared to choose the correct collection for any problem that is thrown our way.

If you'd like to check out any of the benchmark code, head over to this [repo](https://github.com/aaronmbos/dotnet-collections-big-o). If I'm being honest this was my first introduction to [BenchmarkDotnet](https://benchmarkdotnet.org/) and it was a great learning experience. While the benchmarks mostly represent the runtimes as expected, there may be some margin of error due to the way that the benchmarks had to be set up. Unfortunately performing very fast mutations isn't super simple to benchmark, so some of the setups for each benchmark run may be included in the executed times.


We use collections in our code daily, but do we ever step back and consider how they perform in the context of Big O Notation benchmarks? In this post, we'll examine the different collection types in .NET to see how their behaviors relate to well-known Big O notation functions. Let's dive in!

Collections in .NET Through the Lens of Big O Notation


For me, the end of the year is always an exciting time. It is a natural time to take a step back and reflect on the last 12 months. I also like to use this time to set goals and expectations for the upcoming year, which creates a cycle where I can review my progress and adjust expectations on a consistent schedule. Given that this is a technical blog I'm going to keep this post focused on the posts and work that I've done over the past year and also plan to do in the coming year.

## Reflecting on Posts in 2022

In 2022 I published 36 blog posts (including this one), which is 12 more posts than I wrote last year. This means that I accomplished my target of publishing three posts per month (on average). I've had a bit of time to reflect on this post cadence and there were definitely times during the year when my posts felt a bit rushed. This may not have been solely due to the cadence, but also due to external factors (life, job change, etc.). In contrast, my 2021 goal was to publish two posts per month and I don't recall feeling so many instances of last-minute posts. I'll be revisiting post cadence when looking ahead to 2023.

After reviewing all of the posts that I wrote this year, I think they can mostly be grouped into three main categories.

1. Documenting my process of learning TypeScript
1. Mastering the local development experience with VS Code and Neovim
1. Grab bag topics that involved language features or personal experience

While I'm proud of the posts that I wrote this year, I feel like many of them lacked a bit of depth. I think this was partially due to the increased cadence, but also to a lack of planning on my part. Given that I planned to post three times in a month I could have been much more forward-thinking in breaking down a topic and providing valuable depth over the course of multiple posts. What ended up happening was that I jumped from topic to topic with little cohesion. This isn't all bad since I don't really want my posts to be reliant on each other. You should be able to jump into any post and gain value without the requirement of reading a previous post (although knowledge from a previous post _can be helpful_).

In my recap [post](https://aaronbos.dev/posts/2021-year-review) from last year, I mentioned that I wanted to cover a wider range of topics beyond C#, .NET, and SQL. I definitely accomplished this by covering TypeScript, JavaScript, C#, Neovim, VS Code, and personal thoughts/opinions. Ultimately I'd like to continue this variety while providing more depth in each post.

## 2022 Feature Roadmap Review

Beyond the goals that I set for myself last year, I also planned to make a number of improvements to this site, which we're encompassed in a "[roadmap](https://github.com/aaronmbos/personal-site#feature-roadmap)". The roadmap included the following:

- Implement dark mode | **Q1** | [PR](https://github.com/aaronmbos/personal-site/pull/1)
- Share directly to Twitter from post | **Q2** | [PR](https://github.com/aaronmbos/personal-site/pull/2)
- TypeScript migration | **Q2** | [PR](https://github.com/aaronmbos/personal-site/pull/3)
- React to posts with emojis | **Q3** | [PR](https://github.com/aaronmbos/personal-site/pull/4)
- Search blog posts | **Q4** | [PR](https://github.com/aaronmbos/personal-site/pull/14)

I'm happy to say that I accomplished each of these milestones on time. A big contributor to my success in accomplishing these features was using the mini-roadmap as a guideline for me to stay focused throughout the year. I didn't want to fall into the trap of tinkering with my blog site while not actually producing content. At the same time, the features that I included in the roadmap were valuable enough for me to prioritize over the course of the year. I'm going to continue to remain focused on generating quality content, while also not losing sight that this blog is a project for me to improve my software development skills, which does involve making incremental improvements to the site itself.

Overall I'm generally happy about the way 2022 transpired in the context of both blog posts and site improvements. The whole point of this blog is to continuously learn new things, which I think I accomplished this year.

## Goals for 2023

With 2022 just about in the rear-view mirror it's time to take a look ahead to 2023 to share my goals and expectations in regard to my blog and learning throughout the year. Ultimately I don't expect too many things to change from the previous two years since I'm overall happy with the progress I've made. In terms of changes for this blog specifically, I will be doing a couple of things differently.

1. Post cadence with go from three to **two posts per month**
1. Incorporate book reviews as regular or additional posts

In 2021 I completed two posts per month, which felt like a reasonable pace for my first year of blogging. As I mentioned previously my goal for 2022 was three posts per month, which I accomplished. I've decided to drop the cadence back down to two posts per month for a few reasons. First, I feel like writing two posts per month allows me a bit more time to research and go into more depth on topics that I'm interested in. Secondly, posting once every ten days may not seem like a lot, but it doesn't leave much room for working on other things throughout the month. Finally, I don't want to feel rushed or pressured to get to the next post. I'd like to move at a more comfortable and sustainable pace. With all of this being said, if I find myself with additional things to blog about I won't hesitate to throw in an extra post during a month.

With a more comfortable posting cadence, I plan to do more reading this year. My book reviews will all be focused on software-related topics like computer science, software architecture, career advancement, etc. I enjoy reading about all of these topics but have failed to get my thoughts and opinions into the blog over the last two years. These book review posts may be part of the regular two-post-per-month cadence or they may be additional. It will most likely be handled on a case-by-case basis depending on what I have in the hopper at each point in time.

## 2023 Feature Roadmap

Like 2022, I plan to follow a quarterly roadmap for site improvements this year. I'm won't be implementing any earth-shattering updates, but I'm excited to polish up a few aspects of the site that have been in need of some attention as the number of posts on the site has grown.

- Framework upgrades | **Q1**
- Migrate posts from markdown files to database | **Q2**
- Improve search experience | **Q3**
- Add pagination to posts page | **Q4**

In quarter one I'm going to be updating the frameworks and dependencies that my blog uses to their latest versions. I'm currently using NextJS 12 and React 16, but I'd like to get on the latest versions for all of my dependencies so that I can take advantage of any new features.

In quarter two I'm going to migrate my posts from markdown files to a database. This could be a bit of a lift considering that I'll need to set up some tooling for CRUD operations and site builds. I previously had my posts and backend CMS running in Heroku, but when they removed their free tier I decided to pull the posts into the git repo temporarily. I never viewed this as a long-term solution, but more so to make sure I didn't lose any data when free Heroku dynos were spun down in November of 2022.

In quarter three I'll be working on the search experience. Currently, the search is functional, but not polished. I'll be implementing a few features that improve searches like auto-completion and result pagination. These features could have been added at the time of release, but I didn't think they were necessary to get the bits deployed and in use.

Finally, in quarter four I'll be adding pagination to the posts page. This should be relatively straightforward. NextJS has support for SSR (Server Side Rendering), which will be key in setting up the pagination. My hope is that I will be able to reuse some of the pagination work from search result pagination in this as well.

All in all 2023 is shaping up to be an exciting year. If you're a regular visitor to my blog or just happened to land on this post, I just want to say thanks for the support and I look forward to providing another year of interesting and valuable content. Cheers 🍻!


As the calendar year comes to a close, I'll take a moment to reflect on the posts and site improvements this year and also provide a sneak peek at what will be coming in 2023. Let's dive in!

Looking Back at 2022 and Ahead to 2023


Social media has engrained itself into the fabric of our lives to the point of addiction. The dopamine hits we receive from the likes, comments, retweets, and other interactions lead us to spend more time looking at our screens than most of us would like to admit. I've done my best to overcome this by setting screen time limits and deleting apps from my phone, but the end result always falls short of my ambitions. Regardless of my method of control I always found myself endlessly scrolling Twitter or just picking my phone up to refresh Instagram. My viewpoint of social media may be a little pessimistic and while I believe that it has been a net positive on the world, over time it has lost several aspects of what made it so special in the first place (at least for me).

I've been on social media since the days of MySpace. From there I moved to Facebook, then added Instagram, then Twitter, then Snapchat, then Reddit, and I even gave TikTok a try. Social media has made a huge impact on my life. My wife and I connected via mutual friends on Facebook. I was reached out to on Twitter for an exciting career opportunity. My parents can keep up with their grandkids via Instagram posts and stories. I'm sure thousands of others can share similar stories. **So why did I leave?**

## Time

Steve Jobs has been attributed with saying that _the most precious resource we all share is time_. Whether you believe that or not is up to you, but for me, it is 100% true. We all have responsibilities that place constraints on the amount of time that we have available each day. As my number of responsibilities has grown the amount of time that I have outside of those responsibilities has dwindled. This may not be the case for everyone, but I assume it is for some. What this means for me is that the time that I don't have dedicated to my necessary obligations should be managed with great care.

I recently had the opportunity to take a step back and evaluate what is important to me. This list will most likely be different for everyone, but mine looks like this.

- Be the best husband that I can be.
- Be the best father that I can be.
- Maintain a high standard of physical and mental health.
- Be the best software engineer that I can be.

These are the priorities that I schedule my life around. They all require time and effort. You'll notice that having the most Twitter followers, getting the most retweets, or commenting on posts didn't make my list. For me, spending time on social media felt like a waste of time. Looking at my screen time numbers at the end of each day felt demoralizing. Time spent on these social media platforms that provide an endless list of posts and ads just seems to melt away. [Paul Graham](<https://en.wikipedia.org/wiki/Paul_Graham_(programmer)>) wrote an [essay](http://paulgraham.com/vb.html) several years ago explaining how short life actually is. I would highly recommend giving it a read because I think it resonates with my decision to step away from social media.

I recently made the decision to delete my Twitter, Facebook, Instagram, Snapchat, and Reddit accounts. I made the conscious decision to stay on LinkedIn and HackerNews (I'll go into why in the next section). Each of these apps is not inherently bad and if I'm being honest, **bits and pieces** of each of them could probably contribute to my core priorities positively. In the end, the decision came down to the time spent on the platforms not being worth the value received from them.

## Value

Taking ownership of my time was a massive driver for quitting social media, but it wasn't the only driver. As I mentioned before, I'm still on LinkedIn and HackerNews. The reason that I'm willing to stay on those platforms is that they provide enough value for me to feel good about spending time using their products. LinkedIn provides a lot of professional value to me and I honestly don't spend much time at all scrolling my news feed. HackerNews provides me with a lot of relevant tech news and helps me stay up to date, but doesn't require a lot of time. I typically don't get involved in commenting on posts, but do enjoy stumbling across posts that I am interested in. The HackerNews news feed is also paged, which means I don't find myself endlessly scrolling for more information.

My decisions about what I'm willing to spend time on are mostly based on the value they provide relating to my "core priorities". I'm happy to spend an abundant amount of time with family and friends. I'm more than happy to spend time learning and writing blog posts. I won't hesitate to spend time working out or getting some extra sleep when possible. These are things that provide a lot of intrinsic value to me and therefore merit a majority of my time.

As I was able to analyze my priorities it became obvious to me that social media provided me value in some ways, but also took up a disproportionate amount of time versus the time that I could spend on activities that provide much more value like watching a movie with my wife, playing with my kids, or improving my skills as a software engineer.

These sorts of decisions always involve trade-offs. I was willing to trade the value that social media provided me with more fruitful activities that will hopefully lead me to a happier and more productive life. This was an extremely personal decision and I have nothing against people who enjoy spending time on social media. Just remember life is short and I don't think we'll ever look back on our lives wishing we spent more time doom-scrolling on Twitter.


In this post, I'll share why I recently decided to step away from a handful of social media platforms. I'll also touch on how I plan to replace the value that social media provided me with other alternatives. Let's dive in!

Hey! 👋

My name is Aaron Bos and this is my blog.

Recent Posts