Mustafa's zettelkasten 📔

Search

SearchSearch
        • GoLang - useful resources
        • setting up neovim
      • 100% is the wrong reliability target
      • abstraction
      • ACID
      • Acing System Design Interviews
      • active record pattern
      • adapter design pattern
      • amdahl's law
      • analyzing business domains
      • article - complexity in software design
      • availability and reliability
      • behavioural design patterns
      • benefits of code consistency
      • benefits of general-purpose modules
      • Benefits of Ports & Adapters Pattern
      • benefits of well-written code comments
      • benefits of well-written comments
      • better together or better apart
      • blog - Transactional Outbox Pattern
      • bounded context ownership boundaries
      • bounded context physical boundaries
      • bounded context vs subdomains
      • bounded contexts context map
      • bounded contexts in real life
      • builder design pattern
      • building boundaries with bounded context
      • business problem discovery
      • CAP Theorem
      • capture more design information with code comments
      • causes of complexity
      • chain of responsibility design pattern
      • change amplification
      • choosing names
      • classitis
      • code comments might be worthless
      • code reading
      • code repetition
      • cognitive load
      • command design pattern
      • comments get out of date
      • common distributed system patterns
      • Communication and Coordination
      • communication for software projects
      • comparing subdomains
      • comparing subdomains competitive advantage
      • comparing subdomains complexity
      • comparing subdomains solution strategy
      • comparing subdomains volatility
      • complexity
      • complexity in software design
      • complexity is incremental
      • conjoined methods
      • consistency
      • consistency in databases
      • contention in distributed systems
      • converting business domain to a model
      • core subdomain
      • corrupting data by distributed transaction
      • corrupting data by implicit distributed transaction
      • corrupting data by lack of transactional behaviour
      • costs of hexagonal architecture pattern
      • creational design patterns
      • Customer Reliability Engineering
      • database dirty reads
      • database durability
      • database durability techniques
      • database engineering
      • database internals
      • database isolation levels
      • database lost updates
      • database non-repeatable reads
      • database phantom reads
      • database read phenomenas
      • database transaction
      • DDD - bounded context
      • DDD - domain abstraction
      • DDD - domain activities
      • DDD - domain objects
      • DDD - hexagonal architecture
      • decorator design pattern
      • deep modules
      • dependancy inversion
      • dependencies
      • design it twice
      • design patterns
      • designing reactive distributed systems
      • developer excuses not to write code
      • DevOps Vs SRE
      • different layer different abstraction
      • discovering domain knowledge
      • dispatcher
      • distributed systems
      • distributed systems - async communication
      • distributed systems - Back Pressure Pattern
      • distributed systems - communication styles
      • distributed systems - CQRS
      • Distributed Systems - Design Patterns for Event-Driven Architecture
      • distributed systems - Event Carried State Transfer
      • distributed systems - event sourcing
      • distributed systems - outbox pattern
      • distributed systems - saga pattern
      • Docker Basics
      • Docker Security
      • domain driven design
      • Domain Driven Design a Practical Guide
      • domain knowledge discovery
      • dual write problem
      • effective modeling
      • encapsulation
      • error budget
      • event-based communication
      • eventual consistency
      • examples of code consistency
      • exceptions reasons
      • facade design pattern
      • factory design pattern
      • fighting against complexity
      • file storage vs object storage
      • functional programming
      • general purpose module
      • general purpose module 1
      • general purpose modules vs special purpose modules
      • general-purpose and special-purpose code separation
      • generic subdomain
      • Go Lang
      • Go Lang - doc.go
      • Go Lang - Functional Option Pattern
      • Go lang - Modules
      • Go Lang - Rules of A Go Package
      • Go Lang - Variadic Functions
      • GoLang - constants
      • GoLang - Idiomatic Naming Conventions
      • GoLang - primitive types
      • gunther's universal law
      • Hexagonal Architecture & CQRS
      • Hexagonal Architecture Actor
      • Hexagonal Architecture Adapter
      • Hexagonal Architecture and DDD anti-corruption layer
      • Hexagonal Architecture Application, Core or System
      • Hexagonal Architecture Elements
      • Hexagonal Architecture Explained
      • hexagonal architecture glossary
      • Hexagonal Architecture Interactor
      • Hexagonal Architecture Interface
      • Hexagonal Architecture Port
      • Hexagonal Architecture vs Clean Architecture
      • higher-level comments
      • higher-order functions
      • homelab - grafana dashboards to collect personal metrics
      • homeLab - index
      • homelab - install k3s on ubuntu
      • homelab - running private docker registry
      • horizontal scaling
      • How Hexagonal Architecture is Related to DDD
      • how information hiding reduces complexity
      • how module abstraction can go wrong
      • how much to invest in strategic programming
      • how much to invest in strategic programming?
      • how SLOs help balance operational and project work
      • how SLOs help build features faster
      • how SLOs help businesses make decisions
      • how to avoid database phantom reads
      • how to ensure code consistency
      • how to prevent information leakage
      • how to set SLOs for SLIs
      • how to write better code comments
      • how to write better comments - don't repeat the code
      • how to write better comments - pick conventions
      • how transaction script pattern can lead to data corruption
      • i don't have time to write comments
      • implementation code comments
      • in-sync replica set
      • Index
      • information hiding
      • information hiding and information leakage
      • information leakage
      • information leakage types
      • inheritance
      • interface comments
      • interface segregation
      • iterator design pattern
      • kafka
      • kafka common terms
      • kafka consumer group
      • kafka high water mark
      • kafka in-sync replicas
      • kafka topic partitions
      • kafka use cases
      • kafka workflow as a pub-sub
      • kafka workflow as a queue
      • keep the code comments near the code
      • key characteristics of distributed systems
      • Kubernetes
      • Kubernetes - pods - arguments and commands
      • Kubernetes - configMaps
      • Kubernetes - env variables
      • Kubernetes - Master vs Worker Nodes
      • Kubernetes - Node Selectors
      • Kubernetes - replication controller and replicaSets
      • Kubernetes - Resource Requirements
      • Kubernetes - secrets
      • Kubernetes - security contexts
      • Kubernetes - Service Accounts
      • Kubernetes - Taints and Tolerations
      • Kubernetes Architecture
      • Kubernetes Cluster
      • Kubernetes Commands
      • Kubernetes Components
      • Kubernetes Configuration
      • Kubernetes deployments
      • Kubernetes Namespaces
      • Kubernetes Node
      • Kubernetes Pod
      • Kubernetes scheduler
      • Kubernetes YAML Definition Files
      • laws of scalability
      • lddd - analyzing business domains
      • lddd - bounded context ownership boundaries
      • lddd - bounded context physical boundaries
      • lddd - bounded context shared kernel
      • lddd - bounded context vs subdomains
      • lddd - bounded contexts context map
      • lddd - bounded contexts in real life
      • lddd - building boundaries with bounded context
      • lddd - business problem discovery
      • lddd - communication
      • lddd - comparing subdomains
      • lddd - converting business domain to a model
      • lddd - discovering domain knowledge
      • lddd - effective modeling
      • lddd - Identifying Subdomain Boundaries
      • lddd - implementing simple business logic
      • lddd - inconsistent models
      • lddd - integrating bounded context with cooperation pattern
      • lddd - integrating bounded context with customer-supplier pattern
      • lddd - integrating bounded context with separate-ways or duplication
      • lddd - integrating bounded contexts
      • lddd - integrating bounded contexts with anticorruption layer
      • lddd - integrating bounded contexts with conformist pattern
      • lddd - integrating bounded contexts with open-host service
      • lddd - integrating bounded contexts with partnership
      • lddd - knowledge discovery
      • lddd - managing domain complexity
      • lddd - model boundaries
      • lddd - modeling the business domain
      • lddd - scope of a bounded context
      • lddd - semantic domains
      • lddd - size of a bounded context
      • lddd - subdomains as coherent use cases
      • lddd - tackling complex business logic
      • lddd - ubiquitous language refined
      • lddd - what is a bounded context?
      • lddd - what is a model
      • lddd - who are the domain experts
      • Learning Domain Driven Design
      • linear scalability
      • liskove substation
      • low-level comments
      • managing domain complexity
      • message queueing
      • Microservice Patterns
      • mindmap - A Philosophy Of Software Design - POSD
      • mindmap - learning domain driven design
      • model boundaries
      • modifying existing code
      • modular design
      • module abstraction
      • module depth
      • module division and complexity
      • module implementation
      • module interface
      • modules should be deep
      • my technical toolbox
      • names should be consistent
      • names should be precise
      • object oriented design
      • Object-oriented programming
      • obscurity
      • observability
      • observer design pattern
      • open-closed
      • Outbox Pattern vs Two-Phase Commit
      • partition tolerance
      • pass-through methods
      • pass-through variables
      • philosophy of software design
      • PHP
      • PHP - ArrayObject
      • PHP - attributes
      • PHP - class constant
      • PHP - readonly
      • platform engineering
      • Pod YAML Definition
      • polymorphism
      • POSD - modifying existing code
      • procedural programming
      • programming paradigms
      • prototype design pattern
      • publish-subscribe
      • pull complexity downwards
      • pure functions
      • questions to find the right balance between general and special purpose approach
      • reactive distributed systems
      • reactive principles
      • read committed isolation level
      • read uncommitted isolation level
      • repeatable read isolation level
      • Resiliency
      • running docker mysql localy
      • scalability
      • scalability vs performance
      • scope of a bounded context
      • separation of concerns
      • serializable isolation level
      • shallow modules
      • single responsibility
      • singleton design pattern
      • Site Reliability Engineering
      • size of a bounded context
      • SLAs
      • SLIs
      • SLOs
      • snapshot isolation level
      • software design red flags
      • SOLID
      • special purpose module
      • splitting and joining methods
      • state design pattern
      • strategic programming
      • strategic programming investment types
      • strategic vs tactical programming
      • strategy design pattern
      • strong consistency
      • structural design patterns
      • supporting subdomain
      • symptoms of complexity
      • tactical programming
      • tactical tornado
      • targeting reliability
      • template method design pattern
      • temporal decomposition
      • the effect of coherency delay
      • the happiness test
      • the kano model
      • the myth of good code is self-documented
      • the reactive manifesto
      • things that can make the code more obvious
      • things that make the code less obvious
      • Tmux
      • transaction script pattern
      • transactional outbox pattern
      • types of code comments
      • types of distributed systems architectures
      • types of subdomains
      • TypeScript
      • TypeScript - Enum
      • TypeScript - Numbers
      • TypeScript - Type Annotations and Type Inference
      • TypeScript - Types and Type System
      • ubiquitous language
      • unknown unknowns
      • use different git email based on repository path
      • using the ubiquitous language
      • vertical scaling
      • visitor design pattern
      • what is a bounded context
      • what is a domain
      • what is a messaging system
      • what is a subdomain
      • what is new in PHP 8.0
      • what is new in PHP 8.1
      • what is new in PHP 8.2
      • when is interface duplication okay
      • when is interface duplication okay?
      • when to bring modules together
      • Why Code Comments Is More Important Than You Think
      • why conventions is important
      • why do you need a read-only database transaction
      • why do you need a read-only database transaction?
      • why exception adds complexity
      • why pass-through methods are bad
      • why reactive architecture
      • why to write code comments
      • write code comments first
      • write code comments for better abstraction
      • your code can be more obvious
      • zooKeeper
        • avoid cramming in writing
        • books are teachers
        • how to take smart notes
      • A System For Writing
      • avoid multitasking
      • become an expert writer by practicing
      • building a seconded brain
      • building notes bottom-up
      • compare PKB notes
      • fleeting notes
      • folgezettel
      • get laser-focused
      • good workflow properties
      • how to add new permanent notes
      • how to avoid confirmation bias when taking notes
      • how to take a fleeting note
      • how to take reference note
      • HTNS - let the work carry you forward
      • HTNS - nobody ever starts from scratch
      • HTSN - Everything You Need To Do
      • HTSN - Everything You Need To Know
      • HTSN - Steps To Successful Writing
      • HTSN - Writing a Paper step-by-step
      • HTSN - writing is the only thing that matters
      • improve thinking by making permanent notes
      • improve understanding with literature notes
      • index notes
      • knowledge building blocks
      • knowledge workers
      • literature notes
      • literature notes vs reference notes
      • Luhmann's ZettelKasten
      • make a career one note at a time
      • new fleeting note workflow
      • Niklas Luhmann
      • note taking mistakes
      • On Writing Well
      • PARA
      • permanent notes
      • PKM - Index
      • project notes
      • Rapid Logging
      • reduce the number of decisions
      • reference notes
      • reference notes vs fleeting notes
      • taking notes and quotes from content to your PKM
      • understand what you read
      • What is PKM
      • what makes a fleeting note a permanent one
      • Why Having a Knowledge Base Is Important
      • why there was no much interest in zettelkasten at the beginning
      • why to take notes
      • workflow simplicity is essential
      • Writing To Learn
      • zettelkasten
      • zettelkasten as a workflow
      • zettelkasten as an object
      • zettelkasten cross-reference links
      • zettelkasten is organized bottom-up
      • zettelkasten method explained
      • zettelkasten note categories
    Home

    ❯

    b.PKM

    ❯

    HTSN - Steps To Successful Writing

    HTSN - Steps To Successful Writing

    Feb 02, 20251 min read

    • PKM
    • book
    • avoid multitasking
    • get laser-focused
    • reduce the number of decisions
    • become an expert writer by practicing
    • understand what you read
    • make a career one note at a time
    • avoid cramming in writing
    • building notes bottom-up
    • compare PKB notes

    ”every note is just an element in the network of references and back references in the system, from which it gains its quality” Luhmann 1922

    Graph View

    Backlinks

    • how to take smart notes

    Created with Quartz v4.2.3 © 2025

    • GitHub
    • Discord Community