Skip to main content

Programming

Instructing computers to work for humans.

Sometimes, it's also not about a specific tool, programming language or technical design, it's to build useful product that solve problems. Solve useful problems, not solving problems that you think you can solve. The hot new framework or cool clean code architecture doesn't matter if the product is not useful.

Resources​

  • Open Source Society University
    • I did not learn programming with this guide but seems like it has some good reference materials
    • Key aspects: programming, math, tools, systems, theory, security, applications and ethics
    • For me, The Missing Semester of Your CS Education is the most interesting, probably because I went through a university CS curriculum.
  • The Missing Readme
    • A guide for the new software engineer, highly recommend
  • The Pragmatic Programmer
    • Similar to the missing readme, also highly recommend it for all software engineers
    • I would say reading it from time to time gives different insights
    • It might not have taught me something that I don't know, but it summarizes the concepts and serves as a good reminder of how to approach different problems as a software engineer
  • Professional Programming | GitHub @charlax
    • Learning resources for curious software engineers by topics
    • Honestly the dream of this Wiki is to be like this list
  • The Grug Brained Developer
    • The tone is what it is, but it's a pragmatic opinion on different aspect of programming, worth re-reading
    • On testing, agile, saying no, tooling, types, logging, etc.

Sites​

YouTube Channels:

  • Fireship — 100 seconds explanation, code report and tutorials

Still a bit like resources, but targets a specific area of computer science/programming.

  • Vim Motions Playlist by ThePrimeagen
    • A YouTube playlist by ThePrimeagen to get started on Vim motions
    • A helpful guide to navigate faster in editors, a nice skill to acquire for all programmers
    • Vim motions, the navigation, is different from using Vim, the text editor
    • Case study on MongoDB MongoCrypt implementation
  • What a good debugger can do (HN)
    • Breakpoints: column breakpoints, conditional breakpoints, tracing breakpoints, data breakpoints
    • Data visualization, expression evaluation, concurrency and multithreading, hot reload, time travel, omniscient debugging
    • Omniscient debugging: pre-calculate all the program states, store them in a database and index them for efficient queries
  • What I've learned about formal methods in half a year | Jacob — A writeup introducing formal methods
  • GPU Programming: When, Why and How? | GitHub @enccs
    • Not just graphics computation, but the use of GPU to accelerate computations
    • The use of GPU in high-performance computing (HPC) systems
  • Most tech content is bullshit | Aleksandra (HN)
    • Tech consuming: consuming content from the web, instead of creating
    • Reasons: Laziness, time limitation, comfortability, lack of confidence
    • Instead, spend the effort to understand and analyze content, rather than blindly copying
  • Hidden features in GitHub
    • For example, . for github.dev, an online VSCode instance that can edit, push commits, and review PR.
  • What Every Developer Should Know about GPU Computing
    • More about the hardware computation and memory design, and how instructions are executed
    • Streaming multiprocessors (SMs): GPU consists of multiple SMs, each with multiple cores
    • Each SM has many registers, a low latency SRAM shared memory and a L1 cache. Then, shared L2 cache and global memory
    • Execute kernel on the GPU: grid of thread blocks, each consists of multiple threads
    • Wraps: group of threads. Single Instruction Multiple Threads: threads in a warp execute the same instruction
  • A decade of developing programming language
    • 10 lessons learn from building a programming language
    • E.g. avoid self-hosting compiler, which means using the language built to build the compiler for that language
  • Code is run more than read (HN)
    • maintainer > author when we say code is read more than written
    • user > dev: but actually the code need to be usable
    • user > ops > dev: the code need to be able to operate in production
    • biz > user > ops > dev: the code need to be valuable to the organization
    • This stops us from having unmaintainable code, unusable software, or "works locally" software
  • It works on my machine. Why?
    • Lists of possible differences in runtime environment or the code
  • Effective Changelogs
    • Write a changelog file, distributed together with the package
    • Include version number and date, in chronological order
    • Use icons and group changes, give context or brief summary if needed
    • Only add brief and factual update focus on user impact
  • Fixing a Bug in Google Chrome as a First-Time Contributor
    • An interesting read of the process of debugging, fixing, submitting a change list, writing tests and releasing
  • Legacy Shmegacy

    Interestingly, in most cases the legacy label is about the people who assign it, not the code it labels

    • Don't write crappy code and don't adapt new tech for no real benefit
    • Face it, learn it, and "delegacify". Be a problem solver not a problem creator
  • The birth of prettier (HN)
    • The story of searching for solutions, building and perfecting prettier
    • 80-20 rule does not apply to formatter, it has to be 100% working
    • Snapshot testing: see if the differences between snapshot is intended or not
    • Idempotency test: prettier(input) == prettier(prettier(input))
    • Challenges: comments, chained methods, expanded last argument, object literals, missing semicolons
    • Making it easy to maintain consistency lower the stakes of "tabs vs spaces" debates
    • Funding and maintaining the project is the ongoing challenge

Cognitive Load:

  • Cognitive Loads in Programming
    • This is the article that brings my attention to cognitive load
    • Easy is not the same as simple. Complex doesn't necessarily mean hard.
    • Easy means low cost of creation, while simple means low cost of consumption
    • Reduce the extraneous cognitive load, the load generated by how the information is present
    • For example, reduce the unnecessary abstractions that make things hard to understand
  • Cognitive Load Developer's Handbook | GitHub @zakirullin
    • Examples of things to avoid: inheritance nightmare, too many small classes/modules, shallow microservices
  • Cognitive Load Theory in Software Development
    • We have limited working memory, we cannot remember more chunks, but instead, we can aim for larger chunks
    • A section on how to learn effectively to expand and improve developers' processing power
  • The Source of Readability
    • Tips to make code readable, e.g.:
    • "Code locality": code that is read together should be written together, e.g. no global variables
    • Write less code: having 2-3 designs, just stopping as soon as it "works" is too tempting
    • Keep modules deep: small interfaces with more functionality, to avoid being forced to understand complicated interfaces
  • On Importance of naming in Programming
    • Clean code is about naming the logics in the right way actually
    • Good name doesn't misdirect, doesn't omit and doesn't assume
    • Long names might just mean the function is too complex
  • Cognitive Load is what matters
    • Meaningful intermediate variables, early returns rather than nested ifs, composition over inheritance, monolith with isolated modules rather than shallow modules and shallow microservices

Working as a Software Engineer:

  • The Ten Commandments of Egoless Programming | Coding Horror
    1. Understand and accept that you will make mistakes
    2. You are not your code — don't take problems personally when one is uncovered
    3. Someone else will always know more — seek advice especially when you think it's not needed
    4. Don't rewrite code without consultation — rewriting code is not fixing code
    5. Treat people who know less than you with respect, deference, and patience — e.g. nontechnical people
    6. The only constant in the world is change — be open to change
    7. The only true authority stems from knowledge, not from the position
    8. Fight for what you believe, but gracefully accept defeat — ideas will be overruled, don't take revenge
    9. Don't be "the coder in the corner" — be open and collaborative
    10. Critique code instead of people — be kind to the coder, not to the code
  • A -10x Engineer (HN) — wasting 400 engineering hours per week
  • A Senior Engineer's Guide to FAANG Interviews | interviewing.io
    • The usual process / specific rules for each company (FAANG + Microsoft)
  • Don't Let Architecture Astronauts Scare You | Joel Spolsky
    • Too much conceptual abstraction but never focus on the actual problem in reality
    • Solve the real issues, not fancy, interesting, boastful architectures

      Architecture people are solving problems that they think they can solve, not problems that are useful to solve

  • A senior engineer/EM job search story | Gergely
    • 350 job applications to get 3 offers
    • 2 helpful things: New York City's Salary Transparency Law and the power of LinkedIn intro and headline
  • Career advice for young system programmers
    • Do open source in the right way. Play with real systems and make meaningful contributions to standout
  • The Engineer’s Guide to Career Growth — Advice from My Time at Stripe and Facebook (HN)
    • Raylene Yung, engineering manager at Facebook then Stripe
    • Lessons: be valuable but not critical, establish emotion equilibrium, focus on learning not just climbing the ladder
    • Advices for early engineers, ICs, tech lead, managers, to whom leading organizations
  • The best engineering interview question I've ever gotten
    • Implement multiplication in memcached, which only has addition support
    • Part 2: includes solution and explanation why this is great
  • Fundamentals | Mark Seemann
    • Rather than aiming to stay current with specific technologies, learn the fundamentals
    • Understanding fundamentals increase the change of learning new tech just in time
    • E.g.: design patterns, functional programming abstractions, SQL, HTTP, shell scripting, algorithms and data structures
  • Essays on programming I think about a lot
    • A collection of 10+ good articles on programming, highly recommend
    • All of them worth to be listed in this wiki
    • From code structure, system design, hiring, engineering mindset, etc.
  • Goodhart's Law in Software Engineering

    When a measure becomes a target, it ceases to be a good measure.

  • The Best Programmers I Know
    • Many points but can be categorized to keep learning, drill down to error messages and documentations
    • Know the tools, help others, write and build reputation
    • Be patience, be honest, don't guess and keep things simple