Skip to content

README.md

Latest commit

 

History

History
83 lines (49 loc) · 4.06 KB

README.md

File metadata and controls

83 lines (49 loc) · 4.06 KB

TIL

Today I Learned

My collection of technical notes gathered daily across different technologies. The second brain system I'm most proud of. Inspired by simonw/til.

Search these TILs at:

So far, there are different topics and TILs.

Introduction

I have been torn aparted mentally when search for the answer for the question: How to record and organize everything I have learned so far.

My attempts when trying to implement a second brain:

Methodologies:

Applications:

However, they all share common pitfalls:

  • Deeply nested structure. Searching for specific knowledge requires wasting precious time.
  • Overlap between non-code/low-code and code-intensive knowledge.
  • Re-reading occurs rarely, sometimes never.
  • Learn in Private instead of Learn in Public.

TIL, or Today I Learned, is my newest approach to tackle all of the above problems.

The learning cycle

I've curated a FOUR-step process:

the-learning-cycle.svg

  • Step 1: Start with basic tutorial from 3rd-party learning materials. Roadmap.sh is also a great place to start. Avoid thoroughly reading official documentations until you're familiar with the tool.
  • Step 2: Run in local playground. Set up the development environment, write the code snippets, run the commands you found in Step 1.
  • Step 3: Write a TIL. Plug all the separate pieces into ONE grand picture: making cheatsheet (CLI commands, programming language code snippets, ...) to insights (why this feature existed, in which situation do we use it, ...)

    This is the hardest step.

  • Step 4: Practice in a real project. Remember what you learned, and if you don't, constantly re-check TIL and playground.
  • Refer to advanced learning materials: official documentations, senior engineers' blogs, best practices, ...

Personal Experience

  1. Everything you READ will be forgotten:

    • You will forget the long and comprehensive documentation page that you read a month ago.
    • You will forget the interesting blog post from your favorite bloggers that you read three months ago.
    • You will forget the APIs of your favorite programming languages and their frameworks/libraries that you used six months ago.
    • You will forget the commands, sub-commands, arguments, options of the CLI utilities you haven't touched for a year.

    => Unless, you write a TIL.

  2. You don't need to remember it!: Do not record anything that can be Googled/AI-generated under 5 seconds

  3. Do not record anything that can be Googled/AI-generated under 5 seconds: consider breaking that TIL into multiple smaller TILs.

    However, if the TIL is a single source of truth, or you want to avoid context switching to the fullest, a big TIL is not a problem. You should include a TL;DR, a Cheatsheet or a ToC at the start though.

  4. Always be grateful: you must include a ## References section at the bottom of your TIL.

FAQ

Q: When should I write a TIL note? When should I write a blog rather than a TIL?

A: Blog what you built and what other people built, record what you learned: Simon Willison's have two separated platforms for sharing his knowledge: Weblog (GitHub) and Today I Learned (GitHub). I realized he blogged about his projects, big tech innovations, ... and he wrote TIL for a random thing that he learned to solve a very fine-grained problem.

Table of Contents

Content categorized by technology name and organized by specific use cases.