[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-695":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":16,"forks30d":16,"starsTrendScore":19,"compositeScore":20,"rankGlobal":10,"rankLanguage":10,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":24,"hasPages":22,"topics":25,"createdAt":10,"pushedAt":10,"updatedAt":39,"readmeContent":40,"aiSummary":41,"trendingCount":16,"starSnapshotCount":16,"syncStatus":42,"lastSyncTime":43,"discoverSource":44},695,"professional-programming","charlax\u002Fprofessional-programming","charlax","A collection of learning resources for curious software engineers","",null,"Python",51106,3995,1004,1,0,65,314,55,45,"MIT License",false,"master",true,[26,27,28,29,30,31,32,33,34,35,36,37,38],"architecture","computer-science","concepts","documentation","engineer","learning","lessons-learned","professional","programmer","programming-language","read-articles","scalability","software-engineering","2026-06-12 02:00:17","\u003C!-- START doctoc generated TOC please keep comment here to allow auto update -->\n\u003C!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->\n## Table of Contents\n\n- [Professional Programming - about this list](#professional-programming---about-this-list)\n  - [Principles](#principles)\n  - [Contributing to this list](#contributing-to-this-list)\n  - [Must-read books](#must-read-books)\n  - [Must-read articles](#must-read-articles)\n  - [Other general material and list of resources](#other-general-material-and-list-of-resources)\n    - [Other lists](#other-lists)\n    - [Books](#books)\n    - [Articles](#articles)\n    - [Axioms](#axioms)\n    - [Courses](#courses)\n  - [Topics](#topics)\n    - [Accounting](#accounting)\n    - [Agentic coding](#agentic-coding)\n    - [Algorithm and data structures](#algorithm-and-data-structures)\n    - [API design & development](#api-design--development)\n    - [Attitude, habits, mindset](#attitude-habits-mindset)\n      - [Procrastination](#procrastination)\n    - [Authentication\u002Fauthorization](#authenticationauthorization)\n    - [Automation](#automation)\n    - [Best practices](#best-practices)\n    - [Beyond software engineering & random](#beyond-software-engineering--random)\n    - [Biases](#biases)\n    - [Business](#business)\n    - [Buy vs. Build](#buy-vs-build)\n    - [Cache](#cache)\n    - [Career growth](#career-growth)\n      - [Choosing your next\u002Ffirst opportunity](#choosing-your-nextfirst-opportunity)\n      - [Getting to Staff Eng](#getting-to-staff-eng)\n    - [Characters sets](#characters-sets)\n    - [Chess](#chess)\n    - [Clouds](#clouds)\n    - [Code reviews](#code-reviews)\n    - [Coding & code quality](#coding--code-quality)\n    - [Communication](#communication)\n    - [Compilers](#compilers)\n    - [Configuration](#configuration)\n    - [Continuous Integration (CI)](#continuous-integration-ci)\n    - [Data analysis & data science](#data-analysis--data-science)\n    - [Databases](#databases)\n      - [Internals](#internals)\n      - [NoSQL](#nosql)\n      - [Postgres](#postgres)\n    - [Data formats](#data-formats)\n    - [Data science\u002Fdata engineering](#data-sciencedata-engineering)\n    - [Debugging](#debugging)\n    - [Design (visual, UX, UI, typography)](#design-visual-ux-ui-typography)\n    - [Design (OO modeling, architecture, patterns, anti-patterns, etc.)](#design-oo-modeling-architecture-patterns-anti-patterns-etc)\n      - [Design: database schema](#design-database-schema)\n      - [Design: patterns](#design-patterns)\n      - [Design: simplicity](#design-simplicity)\n    - [Dev environment & tools](#dev-environment--tools)\n    - [Docker](#docker)\n    - [Documentation](#documentation)\n    - [Dotfiles](#dotfiles)\n    - [Editors & IDE](#editors--ide)\n      - [Vim](#vim)\n    - [Email](#email)\n    - [Engineering management](#engineering-management)\n    - [Exercises](#exercises)\n    - [Experimentation](#experimentation)\n    - [Fonts](#fonts)\n    - [Functional programming (FP)](#functional-programming-fp)\n    - [Games development](#games-development)\n    - [Generative AI](#generative-ai)\n    - [Graphics](#graphics)\n    - [Hardware](#hardware)\n    - [HTTP](#http)\n    - [Humor](#humor)\n    - [Incident response (oncall, alerting, outages, firefighting, postmortem)](#incident-response-oncall-alerting-outages-firefighting-postmortem)\n      - [Postmortem](#postmortem)\n    - [Internet](#internet)\n    - [Interviewing](#interviewing)\n    - [Kubernetes](#kubernetes)\n    - [Large Language Model (LLM)](#large-language-model-llm)\n    - [Learning & memorizing](#learning--memorizing)\n    - [Licenses (legal)](#licenses-legal)\n    - [Linux (system management)](#linux-system-management)\n    - [Low-code\u002Fno-code](#low-codeno-code)\n    - [Low-level, assembly](#low-level-assembly)\n    - [Machine learning\u002FAI](#machine-learningai)\n    - [Math](#math)\n    - [Marketing](#marketing)\n    - [Network](#network)\n    - [Observability (monitoring, logging, exception handling)](#observability-monitoring-logging-exception-handling)\n      - [Logging](#logging)\n      - [Error\u002Fexception handling](#errorexception-handling)\n      - [Metrics](#metrics)\n      - [Monitoring](#monitoring)\n    - [Open source](#open-source)\n    - [Operating system (OS)](#operating-system-os)\n    - [Over-engineering](#over-engineering)\n    - [Performance](#performance)\n    - [Personal knowledge management (PKM)](#personal-knowledge-management-pkm)\n    - [Personal productivity](#personal-productivity)\n    - [Perspective](#perspective)\n    - [Privacy](#privacy)\n    - [Problem solving](#problem-solving)\n    - [Product management for software engineers](#product-management-for-software-engineers)\n    - [Project management](#project-management)\n    - [Programming languages](#programming-languages)\n      - [Python](#python)\n      - [JavaScript](#javascript)\n      - [Garbage collection](#garbage-collection)\n    - [Programming paradigm](#programming-paradigm)\n    - [Public speaking (presenting)](#public-speaking-presenting)\n    - [Reading](#reading)\n    - [Refactoring](#refactoring)\n    - [Regex](#regex)\n    - [Releasing & deploying](#releasing--deploying)\n      - [Versioning](#versioning)\n      - [Checklists](#checklists)\n      - [Feature flags](#feature-flags)\n      - [Testing in production](#testing-in-production)\n    - [Reliability](#reliability)\n      - [Integration patterns (dependency management)](#integration-patterns-dependency-management)\n      - [Resiliency](#resiliency)\n    - [Search](#search)\n    - [Security](#security)\n    - [Research papers](#research-papers)\n    - [Shell (command line)](#shell-command-line)\n    - [SQL](#sql)\n    - [State](#state)\n    - [System administration](#system-administration)\n    - [System architecture](#system-architecture)\n      - [Architecture patterns](#architecture-patterns)\n      - [Microservices\u002Fsplitting a monolith](#microservicessplitting-a-monolith)\n    - [Scalability](#scalability)\n    - [Site Reliability Engineering (SRE)](#site-reliability-engineering-sre)\n    - [Technical debt](#technical-debt)\n    - [Testing](#testing)\n    - [Tools](#tools)\n    - [Type system](#type-system)\n    - [Typography](#typography)\n    - [Version control (Git)](#version-control-git)\n    - [Work ethics, productivity & work\u002Flife balance](#work-ethics-productivity--worklife-balance)\n    - [Web development](#web-development)\n    - [Writing (communication, blogging)](#writing-communication-blogging)\n  - [Resources & inspiration for presentations](#resources--inspiration-for-presentations)\n  - [Keeping up-to-date](#keeping-up-to-date)\n  - [Concepts](#concepts)\n  - [My other lists](#my-other-lists)\n\n\u003C!-- END doctoc generated TOC please keep comment here to allow auto update -->\n\n# Professional Programming - about this list\n\n> Give me six hours to chop down a tree and I will spend the first four sharpening the axe. (Abraham Lincoln)\n\nA collection of full-stack resources for programmers.\n\nThe goal of this page is to make you a more proficient developer. You'll find only resources that I've found truly inspiring, or that have become timeless classics.\n\n## Principles\n\n- This page is not meant to be comprehensive. I am trying to keep it light and not too overwhelming.\n- The selection of articles is opinionated.\n- I don't necessarily agree with or endorse every single line that is written in every single one of those resources. The same applies to their authors: I don't endorse everything each of those authors has said and will ever say.\n\nItems:\n\n- 🧰 : list of resources\n- 📖 : book\n- 🎞 : video\u002Fmovie extract\u002Fmovie\u002Ftalk\n- 🏙 : slides\u002Fpresentation\n- ⭐️ : must-read\n- 📃 : paper\n\n## Contributing to this list\n\nFeel free to open a PR to contribute!\n\nI will not be adding everything: as stated above, I am trying to keep the list concise.\n\n## Must-read books\n\nI've found these books incredibly inspiring:\n\n- 📖 [The Pragmatic Programmer: From Journeyman to Master](https:\u002F\u002Fpragprog.com\u002Ftitles\u002Ftpp20\u002F): hands-on the most inspiring and useful book I've read about programming.\n- 📖 [Code Complete: A Practical Handbook of Software Construction](http:\u002F\u002Fwww.amazon.com\u002FCode-Complete-Practical-Handbook-Construction\u002Fdp\u002F0735619670): a nice addition to The Pragmatic Programmer, gives you the necessary framework to talk about code.\n- 📖 [Release It!](https:\u002F\u002Fsmile.amazon.com\u002FRelease-Design-Deploy-Production-Ready-Software\u002Fdp\u002F1680502395): this books goes beyond code and gives you best practices for building production-ready software. It will give you about 3 years worth of real-world experience.\n- 📖 [Scalability Rules: 50 Principles for Scaling Web Sites](https:\u002F\u002Fsmile.amazon.com\u002FScalability-Rules-Principles-Scaling-Sites\u002Fdp\u002F013443160X)\n- 📖 [The Linux Programming Interface: A Linux and UNIX System Programming Handbook](http:\u002F\u002Fwww.amazon.com\u002FThe-Linux-Programming-Interface-Handbook\u002Fdp\u002F1593272200): outside of teaching you almost everything you need to know about Linux, this book will give you insights into how software evolves, and the value of having simple & elegant interfaces.\n- 📖 [Structure and interpretation of Computer Programs](https:\u002F\u002Fweb.mit.edu\u002F6.001\u002F6.037\u002Fsicp.pdf) (free): One of the most influential textbooks in Computer Science (written and used at MIT), SICP has been influential in CS education. [Byte](\u003Chttps:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FByte_(magazine)>) recommended SICP \"for professional programmers who are really interested in their profession\".\n\nThere are some free books available, including:\n\n- 📖 [Professional software development](http:\u002F\u002Fmixmastamyk.bitbucket.io\u002Fpro_soft_dev\u002F): pretty complete and a good companion to this page. The free chapters are mostly focused on software development processes: design, testing, code writing, etc. - and not so much about tech itself.\n- 🧰 [vhf\u002Ffree-programming-books](https:\u002F\u002Fgithub.com\u002Fvhf\u002Ffree-programming-books)\n- 🧰 [EbookFoundation\u002Ffree-programming-books](https:\u002F\u002Fgithub.com\u002FEbookFoundation\u002Ffree-programming-books\u002Ftree\u002Fmain\u002Fbooks)\n\n## Must-read articles\n\n- [Practical Advice for New Software Engineers](http:\u002F\u002Fproduct.hubspot.com\u002Fblog\u002Fpractical-advice-for-new-software-engineers)\n- [On Being A Senior Engineer](http:\u002F\u002Fwww.kitchensoap.com\u002F2012\u002F10\u002F25\u002Fon-being-a-senior-engineer\u002F)\n- [Lessons Learned in Software Development](http:\u002F\u002Fhenrikwarne.com\u002F2015\u002F04\u002F16\u002Flessons-learned-in-software-development\u002F): one of those articles that give you years of hard-earned lessons, all in one short article. Must read.\n- [Things I Learnt The Hard Way](https:\u002F\u002Fblog.juliobiason.me\u002Fthoughts\u002Fthings-i-learnt-the-hard-way\u002F)\n  - Spec first, then code\n  - Tests make better APIs\n  - Future thinking is future trashing\n  - Documentation is a love letter to your future self\n  - Sometimes, it's better to let the application crash than do nothing\n  - Understand and stay away of cargo cult\n  - \"Right tool for the job\" is just to push an agenda\n  - Learn the basics functional programming\n  - ALWAYS use timezones with your dates\n  - ALWAYS use UTF-8\n  - Create libraries\n  - Learn to monitor\n  - Explicit is better than implicit\n  - Companies look for specialists but keep generalists longer\n  - The best secure way to deal with user data is not to capture it\n  - When it's time to stop, it's time to stop\n  - You're responsible for the use of your code\n  - Don't tell \"It's done\" when it's not\n  - Pay attention on how people react to you\n  - Beware of micro-aggressions\n  - Keep a list of \"Things I Don't Know\"\n- [Signs that you're a good programmer](https:\u002F\u002Fskatgame.net\u002Fmburo\u002F\u002Fcourses\u002F350\u002Fsigns-that-you-re-a-good-programmer.html) (not everything in here is great - some of the points are counterproductive)\n  - The instinct to experiment first\n  - Emotional detachment from code and design\n  - Eager to fix what isn't broken\n  - Fascinated by the incomprehensible\n  - Compelled to teach\n  - Incorruptible patience\n  - A destructive pursuit of perfection\n  - Encyclopedic grasp of the platform\n  - Thinks In Code\n  - When In Rome, Does As Romans Do\n  - Creates their own tools\n  - Indifferent to Hierarchy\n  - Excited by failure\n  - Indifferent to circumstances\n  - Substitutes impulse for commitment\n  - Driven by experiences\n- [7 absolute truths I unlearned as junior developer](https:\u002F\u002Fmonicalent.com\u002Fblog\u002F2019\u002F06\u002F03\u002Fabsolute-truths-unlearned-as-junior-developer\u002F)\n  - Early in your career, you can learn 10x more in a supportive team in 1 year, than coding on your own\n  - Every company has problems, every company has technical debt.\n  - Being overly opinionated on topics you lack real-world experience with is pretty arrogant.\n  - Many conference talks cover proof of concepts rather than real-world scenarios.\n  - Dealing with legacy is completely normal.\n  - Architecture is more important than nitpicking.\n  - Focus on automation over documentation where appropriate.\n  - Having some technical debt is healthy.\n  - Senior engineers must develop many skills besides programming.\n  - We’re all still junior in some areas.\n- [How to Build Good Software](https:\u002F\u002Fknowledge.csc.gov.sg\u002Fethos-issue-21\u002Fhow-to-build-good-software\u002F)\n  - A good high-level summary of fundamental engineering practices.\n  - The root cause of bad software has less to do with specific engineering choices, and more to do with how development projects are managed.\n  - There is no such thing as platonically good engineering: it depends on your needs and the practical problems you encounter.\n  - Software should be treated not as a static product, but as a living manifestation of the development team’s collective understanding.\n  - Software projects rarely fail because they are too small; they fail because they get too big.\n  - Beware of bureaucratic goals masquerading as problem statements. If our end goal is to make citizens’ lives better, we need to explicitly acknowledge the things that are making their lives worse.\n  - Building software is not about avoiding failure; it is about strategically failing as fast as possible to get the information you need to build something good.\n- [How to be a -10x Engineer](https:\u002F\u002Ftaylor.town\u002F-10x)\n  - Nullify the output of 10 engineers.\n  - Hold 10 engineers hostage in a technical discussion.\n  - Waste 10 weeks of wages on cloud costs.\n  - Waste 400 hours of engineering on bad architecture.\n  - Incur 400 hours of bug triage.\n- [A Bunch of Programming Advice I'd Give To Myself 15 Years Ago](https:\u002F\u002Fmbuffett.com\u002Fposts\u002Fprogramming-advice-younger-self\u002F)\n  - If you (or your team) are shooting yourselves in the foot constantly, fix the gun\n  - Assess the trade-off you’re making between quality and pace, make sure it’s appropriate for your context\n  - Spending time sharpening the axe is almost always worth it\n  - If you can’t easily explain why something is difficult, then it’s incidental complexity, which is probably worth addressing\n  - Try to solve bugs one layer deeper\n  - Don’t underestimate the value of digging into history to investigate some bugs\n  - Bad code gives you feedback, perfect code doesn’t. Err on the side of writing bad code\n  - Make debugging easier\n  - When working on a team, you should usually ask the question\n  - Shipping cadence matters a lot. Think hard about what will get you shipping quickly and often\n- [Expert Generalists](https:\u002F\u002Fmartinfowler.com\u002Farticles\u002Fexpert-generalist.html), martinfowler.com, proposes an interesting take on the \"T-shaped engineer\"\n  - The Characteristics of an Expert Generalist: Curiosity, Collaborativeness, Customer Focus, Favor Fundamental Knowledge, Blend of Generalist and Specialist Skills, Sympathy for Related Domains\n  - Assessing Expert Generalists: hiring and career progression\n  - Growing Expert Generalists: From Tools to Fundamentals\n    - \"Why does our attention keep drifting toward tool expertise? It isn't because people are shortsighted or lazy; it's because the fundamentals are hard to see amid the noise.\"\n  - Expert Generalists still need Specialists\n  - Expert Generalists in the Age of LLMs\n    - \"Similarly to a specialist, an LLM can rapidly answer questions that an Expert Generalist will have when working in a new domain.\"\n    - \"Rather than looking for “the answer”, they prompt them to generate questions, explaining mechanisms, and providing examples and even tools that help explore the underlying mechanisms of an idea.\"\n\n## Other general material and list of resources\n\n### Other lists\n\n- [liuchong\u002Fawesome-roadmaps: A curated list of roadmaps.](https:\u002F\u002Fgithub.com\u002Fliuchong\u002Fawesome-roadmaps)\n\n### Books\n\n- 📖 [The Imposter's Handbook](https:\u002F\u002Fbigmachine.io\u002Fproducts\u002Fthe-imposters-handbook) - \\$30. From the author: \"Don't have a CS Degree? Neither do I - That's why I wrote this book.\"\n- 📖 [The Computer Science Book](https:\u002F\u002Fthecomputersciencebook.com\u002Fbook\u002F)\n- 📖 [The Software Engineer's Guidebook](https:\u002F\u002Fwww.engguidebook.com\u002F): Gergely Orosz's guidebook to the software engineering industry. Extremely complete.\n\n### Articles\n\n- [mr-mig\u002Fevery-programmer-should-know: a collection of (mostly) technical things every software developer should know](https:\u002F\u002Fgithub.com\u002Fmr-mig\u002Fevery-programmer-should-know)\n- [Famous Laws Of Software Development](https:\u002F\u002Fwww.timsommer.be\u002Ffamous-laws-of-software-development\u002F)\n- [The Amazon Builders' Library](https:\u002F\u002Faws.amazon.com\u002Fbuilders-library\u002F?cards-body.sort-by=item.additionalFields.customSort&cards-body.sort-order=asc)\n  - There is a list of the best articles in this [Twitter Thread](https:\u002F\u002Ftwitter.com\u002Fg_bonfiglio\u002Fstatus\u002F1673650452846505985)\n- [kdeldycke\u002Fawesome-falsehood](https:\u002F\u002Fgithub.com\u002Fkdeldycke\u002Fawesome-falsehood): Falsehoods Programmers Believe in\n- [hellerve\u002Fprogramming-talks](https:\u002F\u002Fgithub.com\u002Fhellerve\u002Fprogramming-talks)\n- [TechYaks](https:\u002F\u002Ftechyaks.com\u002F): list of talks\n- [Talks that changed the way I think about programming](http:\u002F\u002Fwww.opowell.com\u002Fpost\u002Ftalks-that-changed-the-way-i-think-about-programming\u002F)\n- [What every computer science major should know](http:\u002F\u002Fmatt.might.net\u002Farticles\u002Fwhat-cs-majors-should-know\u002F)\n- [kamranahmedse\u002Fdeveloper-roadmap](https:\u002F\u002Fgithub.com\u002Fkamranahmedse\u002Fdeveloper-roadmap)\n- [mtdvio\u002Fevery-programmer-should-know](https:\u002F\u002Fgithub.com\u002Fmtdvio\u002Fevery-programmer-should-know): a collection of (mostly) technical things every software developer should know about\n- [Mike Acton’s Expectations of Professional Software Engineers](https:\u002F\u002Fadamj.eu\u002Ftech\u002F2022\u002F06\u002F17\u002Fmike-actons-expectations-of-professional-software-engineers\u002F)\n- [Things they didn't teach you about Software Engineering](https:\u002F\u002Fvadimkravcenko.com\u002Fshorts\u002Fthings-they-didnt-teach-you\u002F)\n  - Domain knowledge is more important than your coding skills\n  - Code is secondary. Business value is first.\n  - You work with uncertainty most of the time\n- [We overestimate our short-term ability, but underestimate our long-term ability.](https:\u002F\u002Fpaavandesign.com\u002Fblog\u002Fostaulta\u002F)\n  - Specialisation is for insects.\n- [Want an unfair advantage in your tech career? Consume content meant for other roles](https:\u002F\u002Fmatthewgrohman.substack.com\u002Fp\u002Fwant-an-unfair-advantage-in-your)\n  - Cross-functional understanding is critical in modern tech companies\n  - Helps to avoid underestimating the importance and difficulty other roles\n  - Helps you to be strategic in your interaction with people in that role\n- [Teach Yourself Programming in Ten Years](https:\u002F\u002Fnorvig.com\u002F21-days.html)\n- [Mistakes You Apparently Just Have to Make Yourself](https:\u002F\u002Fmedium.com\u002F@mcfunley\u002Fmistakes-you-apparently-just-have-to-make-yourself-cc2dd2bfc25c)\n- [The Best Programmers I Know](https:\u002F\u002Fendler.dev\u002F2025\u002Fbest-programmers\u002F)\n- [Laws of Software Engineering](https:\u002F\u002Flawsofsoftwareengineering.com\u002F)\n\n### Axioms\n\n- [Precepts - Urbit](https:\u002F\u002Furbit.org\u002Fblog\u002Fprecepts\u002F)\n  - Data is better than code.\n  - Correctness is more important than performance.\n  - Deterministic beats heuristic.\n  - One hundred lines of simplicity is better than twenty lines of complexity.\n  - If your abstractions are leaking, it's not due to some law of the universe; you just suck at abstracting. Usually, you didn't specify the abstraction narrowly enough.\n  - If you avoid changing a section of code for fear of awakening the demons therein, you are living in fear. If you stay in the comfortable confines of the small section of the code you wrote or know well, you will never write legendary code. All code was written by humans and can be mastered by humans.\n  - If there's clearly a right way to do something and a wrong way, do it the right way. Coding requires incredible discipline.\n  - The best way to get the right answer is to try it the wrong way.\n  - Practice tells you that things are good or bad; theory tells you why.\n  - Not being qualified to solve a problem is no reason not to solve it.\n  - If you don't understand a system you're using, you don't control it. If nobody understands the system, the system is in control.\n- [Embedded Rules of Thumb](https:\u002F\u002Fembeddedartistry.com\u002Fblog\u002F2018\u002F04\u002F26\u002Fembedded-rules-of-thumb\u002F)\n- [50 Ideas That Changed My Life](https:\u002F\u002Fwww.perell.com\u002Fblog\u002F50-ideas-that-changed-my-life)\n- [Reflections on 10,000 Hours of Programming](https:\u002F\u002Fmatt-rickard.com\u002Freflections-on-10-000-hours-of-programming\u002F)\n- [20 Things I've Learned in my 20 Years as a Software Engineer](https:\u002F\u002Fwww.simplethread.com\u002F20-things-ive-learned-in-my-20-years-as-a-software-engineer\u002F)\n\n### Courses\n\n- [Google Tech Dev Guide](https:\u002F\u002Ftechdevguide.withgoogle.com\u002F)\n- [The Missing Semester of Your CS Education](https:\u002F\u002Fmissing.csail.mit.edu\u002F), MIT. Includes lectures about the shell, editors, data wrangling, git, debugging and profiling, meta programming, security and cryptography.\n- [Mathematics for the adventurous self-learner](https:\u002F\u002Fwww.neilwithdata.com\u002Fmathematics-self-learner), Neil Sainsbury\n- [jwasham\u002Fcoding-interview-university](https:\u002F\u002Fgithub.com\u002Fjwasham\u002Fcoding-interview-university): a complete computer science study plan to become a software engineer.\n- [Teach Yourself Computer Science](https:\u002F\u002Fteachyourselfcs.com\u002F): an opinionated set of the best CS resources.\n- [ossu\u002Fcomputer-science](https:\u002F\u002Fgithub.com\u002Fossu\u002Fcomputer-science): free self-taught education in Computer Science!\n\n## Topics\n\n### Accounting\n\n- [Engineers Do Not Get To Make Startup Mistakes When They Build Ledgers](https:\u002F\u002Fnews.alvaroduran.com\u002Fp\u002Fengineers-do-not-get-to-make-startup)\n\n### Agentic coding\n\n- [Anatomy of the .claude\u002F Folder](https:\u002F\u002Fblog.dailydoseofds.com\u002Fp\u002Fanatomy-of-the-claude-folder)\n\n### Algorithm and data structures\n\n- Read the [CLRS](https:\u002F\u002Fmitpress.mit.edu\u002Fbooks\u002Fintroduction-algorithms). You can watch and download the course on [OCW](http:\u002F\u002Focw.mit.edu\u002Fcourses\u002Felectrical-engineering-and-computer-science\u002F6-046j-introduction-to-algorithms-sma-5503-fall-2005\u002F) - there are newer courses as well.\n- Or [The Algorithm Design Manual](https:\u002F\u002Fwww.amazon.com\u002FAlgorithm-Design-Manual-Steven-Skiena\u002Fdp\u002F1849967202?ie=UTF8&qid=1297127794&ref_=sr_1_1&sr=8-1) (Skiena)\n- Try out some algorithms on [Project Euler](https:\u002F\u002Fprojecteuler.net\u002F)\n- [CS 61B Spring 2023](https:\u002F\u002Fsp23.datastructur.es\u002F)\n\nOther resources:\n\n- [Algorithms](http:\u002F\u002Fjeffe.cs.illinois.edu\u002Fteaching\u002Falgorithms\u002F), Jeff Erickson\n\nHere are some useful & interesting algo & DS visualizations:\n\n- [Grokking Algorithms](https:\u002F\u002Fwww.amazon.com\u002Fdp\u002F1617292230\u002Fref=cm_sw_su_dp)\n- [Essential Algorithms](https:\u002F\u002Fwww.amazon.com\u002FEssential-Algorithms-Practical-Approach-Computer\u002Fdp\u002F1118612108?ie=UTF8&*Version*=1&*entries*=0)\n- [Data Structure Visualization](https:\u002F\u002Fwww.cs.usfca.edu\u002F~galles\u002Fvisualization\u002FAlgorithms.html)\n- 🎞 [15 Sorting Algorithms in 6 Minutes](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=kPRA0W1kECg&ab_channel=TimoBingmann)\n- [Hashing](https:\u002F\u002Fsamwho.dev\u002Fhashing\u002F)\n- [Visualizing Algorithms](https:\u002F\u002Fbost.ocks.org\u002Fmike\u002Falgorithms\u002F)\n- [B-trees and database indexes](https:\u002F\u002Fplanetscale.com\u002Fblog\u002Fbtrees-and-database-indexes)\n- [Big O visualizations](https:\u002F\u002Fsamwho.dev\u002Fbig-o\u002F)\n- [Algorithm explained like Ikea instructions](https:\u002F\u002Fidea-instructions.com\u002F)\n- [Decision Trees](https:\u002F\u002Fmlu-explain.github.io\u002Fdecision-tree\u002F)\n\nExample implementations:\n\n- [trekhleb\u002Fjavascript-algorithms](https:\u002F\u002Fgithub.com\u002Ftrekhleb\u002Fjavascript-algorithms): algorithms and data structures implemented in JavaScript\n- [The Algorithms](https:\u002F\u002Fthe-algorithms.com\u002F)\n\nAlgorithms in distributed systems:\n\n- [Raft Consensus Algorithm](https:\u002F\u002Fraft.github.io\u002F)\n\n### API design & development\n\nGeneral REST content:\n\n- [Architectural Styles and the Design of Network-based Software Architectures](https:\u002F\u002Fwww.ics.uci.edu\u002F~fielding\u002Fpubs\u002Fdissertation\u002Ftop.htm), Roy Fielding (the inventor of REST)\n- [A collection of useful resources for building RESTful HTTP+JSON APIs.](https:\u002F\u002Fgithub.com\u002Fyosriady\u002Fapi-development-tools)\n- [Best practices for REST API design](https:\u002F\u002Fstackoverflow.blog\u002F2020\u002F03\u002F02\u002Fbest-practices-for-rest-api-design\u002F), Stack Overflow Blog\n- 📖 [Undisturbed REST: a guide to designing the perfect API](https:\u002F\u002Fwww.mulesoft.com\u002Fsites\u002Fdefault\u002Ffiles\u002Fresource-assets\u002Febook-UndisturbedREST_v1.pdf): very complete book about RESTful API design.\n\nExample guidelines:\n\n- [Microsoft's Rest API guidelines](https:\u002F\u002Fgithub.com\u002FMicrosoft\u002Fapi-guidelines\u002Fblob\u002Fmaster\u002FGuidelines.md)\n- [Zalando RESTful API and Event Scheme Guidelines](https:\u002F\u002Fopensource.zalando.com\u002Frestful-api-guidelines\u002F)\n- [Google's API Design Guide](https:\u002F\u002Fcloud.google.com\u002Fapis\u002Fdesign\u002F): a general guide to design networked API.\n- [AIP-1: AIP Purpose and Guidelines](https:\u002F\u002Fgoogle.aip.dev\u002F1)\n  - AIP stands for API Improvement Proposal, which is a design document providing high-level, concise documentation for API development.\n\nMore specific topics:\n\n- [Why you should use links, not keys, to represent relationships in APIs](https:\u002F\u002Fcloud.google.com\u002Fblog\u002Fproducts\u002Fapplication-development\u002Fapi-design-why-you-should-use-links-not-keys-to-represent-relationships-in-apis), Martin Nally, Google\n  - \"Using links instead of foreign keys to express relationships in APIs reduces the amount of information a client needs to know to use an API, and reduces the ways in which clients and servers are coupled to each other.\"\n- [Give me \u002Fevents, not webhooks](https:\u002F\u002Fblog.sequin.io\u002Fevents-not-webhooks\u002F)\n  - Events can unlock much-needed webhook features, like allowing your webhook consumers to replay or reset the position of their webhook subscription.\n- [Unlocking the Power of JSON Patch](https:\u002F\u002Fzuplo.com\u002Fblog\u002F2024\u002F10\u002F10\u002Funlocking-the-power-of-json-patch)\n\n### Attitude, habits, mindset\n\n- [Mastering Programming](https:\u002F\u002Fwww.prod.facebook.com\u002Fnotes\u002Fkent-beck\u002Fmastering-programming\u002F1184427814923414#), Kent Beck.\n- [The traits of a proficient programmer](https:\u002F\u002Fwww.oreilly.com\u002Fideas\u002Fthe-traits-of-a-proficient-programmer)\n- [The tao of programming](http:\u002F\u002Fwww.mit.edu\u002F~xela\u002Ftao.html): a set of parables about programming.\n- [Taking Ownership Is The Most Effective Way to Get What You Want](http:\u002F\u002Fwww.theeffectiveengineer.com\u002Fblog\u002Ftake-ownership-of-your-goals)\n- [Finding Time to Become a Better Developer](https:\u002F\u002Fmedium.freecodecamp.org\u002Ffinding-time-to-become-a-better-developer-eebc154881b2)\n- [Ten minutes a day](https:\u002F\u002Fmedium.com\u002F@alexallain\u002Ften-minutes-a-day-e2fa1084f924): how Alex Allain wrote a book in less than 200 hours, by writing 10 minutes _every_ day.\n- [The care and feeding of software engineers (or, why engineers are grumpy)](https:\u002F\u002Fhumanwhocodes.com\u002Fblog\u002F2012\u002F06\u002F12\u002Fthe-care-and-feeding-of-software-engineers-or-why-engineers-are-grumpy\u002F)\n  - In the triumvirate of software, product managers, designers, and software engineers, only the engineers are expected to turn off their creative minds and just produce.\n  - Both engineers and product managers tend to think, incorrectly, that product specifications or requirements are equivalent to the furniture manual from Ikea.\n  - This is one of the top things that make engineers grumpy: constantly shifting priorities.\n  - Even though many engineers will complain that product managers change their minds, almost none will account for that in their time estimates.\n  - Computer science programs aren’t about preparing you for the tasks you’ll face in industry.\n  - When there are more engineers than can be used, engineering time ends up going away from developing and towards planning, synchronization, and coordination.\n  - Involve engineers in the creative process\n  - Give engineers opportunities to be creative.\n  - Encourage time off.\n  - Let 'em code\n  - Express appreciation\n- [The Product-Minded Software Engineer](https:\u002F\u002Fblog.pragmaticengineer.com\u002Fthe-product-minded-engineer\u002F), Gergely Orosz\n  - Great product engineers know that minimum lovable products need the right depth\n  - Product-minded engineers quickly map out edge cases and think of ways to reduce work on them: often bringing solutions that require no engineering work\n  - Engage in user research and customer support\n  - Bring well-backed product suggestions to the table\n  - Offer product\u002Fengineering tradeoffs\n- [40 Lessons From 40 Years](https:\u002F\u002Fmedium.com\u002F@schlaf\u002F40-lessons-from-40-years-de39d2c622d6), Steve Schlafman\n  - If you want to make progress on the things that matter most, you need to decide who you’re going to disappoint. It’s inevitable.\n  - The best investment you can make is your own education. Never stop learning. The second best investment you can make is building your network through authentic and meaningful interactions. It is what you know and who you know.\n  - You’ll never get what you don’t ask for or actively seek out. Go for it!\n  - It’s not about the light at the end of the tunnel. It’s the tunnel. Show up every day and enjoy the process.\n  - A great teammate always puts the organization and its purpose ahead of their own self interests.\n  - Pick your spots. We have limited time and our brains can only process so much. Focus is key. Choose wisely.\n  - Every person is likely struggling with something. Be kind. Be helpful.\n- [On Coding, Ego and Attention](https:\u002F\u002Fjosebrowne.com\u002Fon-coding-ego-and-attention\u002F)\n  - Beginner’s mind accepts the fact that absolute knowledge is infinite and thus keeping score is a waste of time.\n  - Mastery is simply the accumulation of momentum, not the accumulation of knowledge.\n  - Dealing with ego distraction has taught me to love the problem solving process. It’s taught me to love and respect the learning process. As a result I’m more productive. I’m less anxious. I’m a better teammate. I’m a better friend and a better thinker.\n- [Fixed vs. Growth: The Two Basic Mindsets That Shape Our Lives](https:\u002F\u002Fwww.brainpickings.org\u002F2014\u002F01\u002F29\u002Fcarol-dweck-mindset\u002F)\n- [What does a great software engineer look like?](https:\u002F\u002Ffwouts.com\u002Farticles\u002Fgreat-software-engineer)\n- [Good sleep, good learning, good life](https:\u002F\u002Fsupermemo.guru\u002Fwiki\u002FGood_sleep,_good_learning,_good_life)\n- 🎞 [Steve Jobs: if you don't ask for help, you won't get very far](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=zkTf0LmDqKI&ab_channel=SiliconValleyHistoricalAssociation)\n- [Programming quotes](https:\u002F\u002Fwww.ronaldsvilcins.com\u002F2020\u002F12\u002F10\u002Fprogramming-quotes\u002F)\n- [Be Kind](https:\u002F\u002Fboz.com\u002Farticles\u002Fbe-kind)\n  - Being kind is fundamentally about taking responsibility for your impact on the people around you.\n  - It requires you be mindful of their feelings and considerate of the way your presence affects them.\n- [Warren Buffett Says This 1 Simple Habit Separates Successful People From Everyone Else](https:\u002F\u002Fwww.inc.com\u002Fmarcel-schwantes\u002Fwarren-buffett-says-this-is-1-simple-habit-that-separates-successful-people-from-everyone-else.html)\n  - The difference between successful people and really successful people is that really successful people say no to almost everything.\n- [How to get lucky?](https:\u002F\u002Fjjude.com\u002Fluck)\n- [Programmers should stop celebrating incompetence](https:\u002F\u002Fworld.hey.com\u002Fdhh\u002Fprogrammers-should-stop-celebrating-incompetence-de1a4725), DHH\n  - The magic of programming is largely just things you don't know yet.\n  - It's not fine to think you shouldn't be on some paths towards mastery, if you intend to make programming your career.\n- [There’s no speed limit](https:\u002F\u002Fsive.rs\u002Fkimo)\n- [Don't Wait for Motivation, Act for Momentum](https:\u002F\u002Fsalman.io\u002Fblog\u002Fmomentum-motivation\u002F)\n  - Start with a tiny task. Then ride its momentum.\n- [The Most Important Coding Habits](https:\u002F\u002Fpuppycoding.com\u002F2023\u002F07\u002F22\u002Fhealthy-coding-habits\u002F)\n  - The Most Important Coding Habits\n  - Daily stretches\n  - Take regular breaks\n  - Don’t code late at night\n  - Improve your coding environment\n- [Advice for new software devs who've read all those other advice essays](https:\u002F\u002Fbuttondown.email\u002Fhillelwayne\u002Farchive\u002Fadvice-for-new-software-devs-whove-read-all-those\u002F)\n- [Microservices aren't the problem. Incompetent people are](https:\u002F\u002Fnondv.wtf\u002Fblog\u002Fposts\u002Fmicroservices-arent-the-problem-incompetent-people-are.html)\n- [High Agency](https:\u002F\u002Fwww.highagency.com\u002F) (30-min read)\n- [What is \"good taste\" in software engineering?](https:\u002F\u002Fwww.seangoedecke.com\u002Ftaste\u002F): it's all about contextual tradeoff.\n\n> Imposter syndrome is underrated: a lot of talk goes into overcoming imposter syndrome. I say embrace self-skepticism and doubt yourself every day. In a fast-moving industry where lots of your knowledge expires every year, even the most junior people around you constantly cook up skills you don't have; you stay competitive by applying with the determination (and even fear) of the novice. The upside of this treadmill is that every engineer is on it: just because you're an imposter doesn't mean that other people are more deserving than you, because they're imposters too. You should advocate for yourself, take risks, pat yourself on the back when things go well, and, as you start to build a track record of solving problems, trust your skills and adaptability. Just make no mistake: you're only as good as the last problem you solve.\n\nDan Heller, Building a Career in Software\n\n> I had learned already never to empty the well of my writing, but always to stop when there was still something there in the deep part of the well, and let it refill at night from the springs that fed it. -- Ernest Hemingway\n\n- [The Grug Brained Developer](https:\u002F\u002Fgrugbrain.dev): habits of self-aware programmer. Like Tao of Programming, different style.\n\n> Good judgment comes from experience.\n> Experience comes from bad judgment.\n\n#### Procrastination\n\n- [News is bad for you – and giving up reading it will make you happier](https:\u002F\u002Fwww.theguardian.com\u002Fmedia\u002F2013\u002Fapr\u002F12\u002Fnews-is-bad-rolf-dobelli), The Guardian\n  - News misleads\n  - News is irrelevant\n  - News has no explanatory power\n  - News is toxic to your body\n  - News increases cognitive errors\n  - News inhibits thinking\n  - News works like a drug\n  - News wastes time\n  - News makes us passive\n  - News kills creativity\n\n### Authentication\u002Fauthorization\n\n- [Authorization in a microservices world](https:\u002F\u002Fwww.alexanderlolis.com\u002Fauthorization-in-a-microservices-world)\n- [Authorization Logic: Rules are hard because they evolve over time](https:\u002F\u002Fwww.osohq.com\u002Fpost\u002Frules-are-hard-logic-for-authorization)\n- [The Copenhagen Book](https:\u002F\u002Fthecopenhagenbook.com\u002F) provides a general guideline on implementing auth in web applications\n\n### Automation\n\n- [Automation Should Be Like Iron Man, Not Ultron](http:\u002F\u002Fqueue.acm.org\u002Fdetail.cfm?id=2841313)\n\n### Best practices\n\n- [Software engineering practices](https:\u002F\u002Fsimonwillison.net\u002F2022\u002FOct\u002F1\u002Fsoftware-engineering-practices\u002F#tested-dev-environments)\n\n### Beyond software engineering & random\n\n- [Why Software Engineers like Woodworking](https:\u002F\u002Fwww.zainrizvi.io\u002Fblog\u002Fwhy-software-engineers-like-woodworking\u002F)\n\n### Biases\n\nBiases don't only apply to hiring. For instance, the fundamental attribution bias also applies when criticizing somebody's code written a long time ago, in a totally different context.\n\n- [Cognitive bias cheat sheet](https:\u002F\u002Fbuster.medium.com\u002Fcognitive-bias-cheat-sheet-55a472476b18). #hiring\n\n### Business\n\n- [Payments 101 for a Developer](https:\u002F\u002Fgithub.com\u002Fjuspay\u002Fhyperswitch\u002Fwiki\u002FPayments-101-for-a-Developer)\n- [The 4 biggest problems with homemade billing systems](https:\u002F\u002Fwww.getlago.com\u002Fblog\u002Fthe-4-biggest-problems-with-homemade-billing-systems)\n- [🦑 The 14 pains of building your own billing system](https:\u002F\u002Farnon.dk\u002Fthe-14-pains-of-billing\u002F)\n\n### Buy vs. Build\n\n- [Choose Boring Technology](https:\u002F\u002Fboringtechnology.club\u002F)\n- [Build vs. Buy](https:\u002F\u002Fentropicthoughts.com\u002Fbuild-vs-buy)\n  - The reason we want to buy as much as possible is that an organisation has a limited capacity for expertise, so we don’t want to have to become experts on things that don’t make up a competitive advantage.\n- [Platform Engineering: Build vs Buy](https:\u002F\u002Fkanenarraway.com\u002Fposts\u002Fplatform-engineering-build-vs-buy\u002F)\n  - If someone tells me they can build something cheaper than a vendor, I’m immediately skeptical because I don’t think most people can accurately forecast the actual cost of maintenance in the long term.\n\n### Cache\n\n- [Caching challenges and strategies](https:\u002F\u002Faws.amazon.com\u002Fbuilders-library\u002Fcaching-challenges-and-strategies\u002F), Amazon Builders Library\n\n### Career growth\n\n- [The Conjoined Triangles of Senior-Level Development](https:\u002F\u002Ffrontside.com\u002Fblog\u002F2016-07-07-the-conjoined-triangles-of-senior-level-development) looks into how to define a senior engineer.\n- [Ten Principles for Growth as an Engineer](https:\u002F\u002Fmedium.com\u002F@daniel.heller\u002Ften-principles-for-growth-69015e08c35b), Dan Heller.\n- [Don't Call Yourself a Programmer](https:\u002F\u002Fwww.kalzumeus.com\u002F2011\u002F10\u002F28\u002Fdont-call-yourself-a-programmer\u002F), Patrick McKenzie.\n- [On being an Engineering Manager](https:\u002F\u002Fnickmchardy.com\u002F2019\u002F02\u002Fon-being-an-engineering-manager.html)\n- [The career advice I wish I had at 25](https:\u002F\u002Fwww.linkedin.com\u002Fpulse\u002Fcareer-advice-i-wish-had-25-shane-rodgers\u002F?trk=hp-feed-article-title-like)\n  - A career is a marathon, not a sprint\n  - Most success comes from repetition, not new things\n  - If work was really so great all the rich people would have the jobs\n  - Management is about people, not things\n  - Genuinely listen to others\n  - Recognise that staff are people with finite emotional capacity\n  - Don’t just network with people your own age\n  - Never sacrifice personal ethics for a work reason\n  - Recognise that failure is learning\n- [Career advice I wish I’d been given when I was young](https:\u002F\u002F80000hours.org\u002F2019\u002F04\u002Fcareer-advice-i-wish-id-been-given-when-i-was-young\u002F)\n  - Don’t focus too much on long-term plans.\n  - Find good thinkers and cold-call the ones you most admire.\n  - Assign a high value to productivity over your whole lifespan.\n  - Don’t over-optimise things that aren’t your top priority.\n  - Read a lot, and read things that people around you aren’t reading.\n  - Reflect seriously on what problem to prioritise solving.\n  - Read more history.\n- [Why Good Developers are Promoted into Unhappiness](https:\u002F\u002Frobwalling.com\u002F2007\u002F06\u002F27\u002Fwhy-good-developers-are-promoted-into-unhappiness\u002F), Rob Walling. Or why management might not be for you.\n- [A guide to using your career to help solve the world’s most pressing problems](https:\u002F\u002F80000hours.org\u002Fkey-ideas\u002F)\n- [What's a senior engineer's job?](https:\u002F\u002Fjvns.ca\u002Fblog\u002Fsenior-engineer\u002F) You need to be more than just an individual contributor.\n- [From Coding Bootcamp Graduate to Building Distributed Databases](https:\u002F\u002Fmedium.com\u002Fswlh\u002Ffrom-coding-bootcamp-graduate-to-building-distributed-databases-29acbb723d8)\n  - Read Books (and papers), not Blog Posts\n  - Take responsibility for your career trajectory\n- 🏙 [The Well Rounded Engineer](https:\u002F\u002Fspeakerdeck.com\u002Fswanandp\u002Fthe-well-rounded-engineer) includes lots of great book recommendations.\n  - Paradigm polyglot (learn different languages & paradigms)\n  - Database polyglot\n  - Protocol polyglot (preferably TCP\u002FIP and HTTP)\n  - Proficiency with build tooling, packaging and distribution\n  - Debugging, observability\n  - Deployment, infra and devops\n  - Software architecture and scaling\n  - Ability to write toy compilers, interpreters and parsers\n  - Ability to write toy games\n  - Ability to understand algorithmic analysis\n- [Some career advice](https:\u002F\u002Flethain.com\u002Fcareer-advice\u002F), Will Larson.\n  - Advice you get is someone’s attempt to synthesize their experiences, not an accurate statement about how the world works.\n  - Build a reservoir of prestige.\n  - Some folks are so good at something that they end up being irreplaceable in their current role, which causes them to get stuck in their role even if they’re a good candidate for more interesting ones.\n  - Great relationships will follow you everywhere you go. Bad ones too.\n  - Early in your career, try to work at as many different kinds of companies and in different product vertical as you can.\n- [Evil tip: avoid \"easy\" things](http:\u002F\u002Fyosefk.com\u002Fblog\u002Fevil-tip-avoid-easy-things.html)\n- [The Ultimate Code Kata](https:\u002F\u002Fblog.codinghorror.com\u002Fthe-ultimate-code-kata\u002F)\n- [Traits of a senior software engineer](https:\u002F\u002Fsergiomartins8.hashnode.dev\u002Fwhy-is-a-senior-engineer-senior): impact, perception, visibility, influence, mentoring\n- [Software Engineering - The Soft Parts](https:\u002F\u002Faddyosmani.com\u002Fblog\u002Fsoftware-engineering-soft-parts\u002F)\n  - Think critically and formulate well-reasoned arguments\n  - Master the fundamentals\n  - Focus on the user and all else will follow\n  - Learn how to learn\n- [How To Own Your Growth As A Software Engineer](https:\u002F\u002Fjes.al\u002F2022\u002F07\u002Fhow-to-own-your-growth-as-a-software-engineer\u002F)\n- [The Forty-Year Programmer](https:\u002F\u002Fcodefol.io\u002Fposts\u002Fthe-forty-year-programmer\u002F)\n  - The Better You Get, the Less You Look Like Everybody Else\n  - You Learn Deep Principles by Doing the Basics\n  - Look to Other Fields, Learn From Other Fields\n  - Be Careful About Productivity Tips\n- [Senior Engineers are Living in the Future](https:\u002F\u002Fwww.zerobanana.com\u002Fessays\u002Fliving-in-the-future\u002F)\n- [What would a map of your career look like?](https:\u002F\u002Ftomcritchlow.com\u002F2023\u002F04\u002F26\u002Fcareer-maps\u002F)\n- [How to be successful at Amazon (or any other large company for that matter)](https:\u002F\u002Fwww.reddit.com\u002Fr\u002Fcscareerquestions\u002Fcomments\u002F4x0ugj\u002Fhow_to_be_successful_at_amazon_or_any_other_large\u002F)\n- [Being good isn’t enough](https:\u002F\u002Fjoshs.bearblog.dev\u002Fbeing-good-isnt-enough\u002F)\n  - The biggest gains come from combining disciplines.\n- [Stop Avoiding Politics](https:\u002F\u002Fterriblesoftware.org\u002F2025\u002F10\u002F01\u002Fstop-avoiding-politics\u002F) is a good contrarian take on the current (negative) connotation of the word \"politics\".\n  - In a way, it is unfortunate that \"politics\" got that connotation since Aristotle rightfully considered politics the highest form of practical wisdom, since it has to do with humans as social animals.\n  - \"Good politics is just being strategic about relationships and influence in the service of good outcomes.\"\n  - Examples: building relationships before you need them, understanding the incentives, managing up effectively, creating win-win situation, being visible.\n  - \"The alternative to good politics isn’t no politics. It’s bad politics winning by default. It’s the loud person who’s wrong getting their way because the quiet person who’s right won’t speak up.\"\n- [21 Lessons from 14 Years at Google](https:\u002F\u002Faddyo.substack.com\u002Fp\u002F21-lessons-from-14-years-at-google)\n- [Publishing your work increases your luck](https:\u002F\u002Fgithub.com\u002Freadme\u002Fguides\u002Fpublishing-your-work)\n\nAbout senior engineers:\n\n- [Falsehoods Junior Developers believe about becoming Senior](https:\u002F\u002Fvadimkravcenko.com\u002Fshorts\u002Ffalsehoods-junior-developers-believe-about-becoming-senior\u002F)\n\n#### Choosing your next\u002Ffirst opportunity\n\n- [Career Decisions - by Elad Gil - Elad Blog](https:\u002F\u002Fblog.eladgil.com\u002Fp\u002Fcareer-decisions)\n\n#### Getting to Staff Eng\n\n- [I became a FAANG Staff Engineer in 5 years. These are the 14 lessons I learned along the way.](https:\u002F\u002Fmedium.com\u002Fgeekculture\u002Fi-became-a-faang-staff-engineer-in-5-years-here-are-the-14-lessons-i-learned-along-the-way-f70ac078875c)\n  - Software engineering isn’t just coding. Actually, coding is a small part of it.\n  - Pipeline your work\n  - Be open to feedback and listen. Like, seriously, listen.\n  - Great feedback is hard to find; treasure it.\n  - Keep an eye on the horizon (but not both).\n  - Figure out what matters and let the rest go.\n  - Comparison really is the thief of joy.\n  - Mentorship is a beautiful thing.\n  - Good days, in general, don’t just “happen”.\n  - Advice and guidance are just that; they aren’t rules.\n- [Guides for reaching Staff-plus engineering roles](https:\u002F\u002Fstaffeng.com\u002Fguides\u002F), Will Larson\n  - [Being visible](https:\u002F\u002Fstaffeng.com\u002Fguides\u002Fbeing-visible)\n  - [Additional resources on Staff-plus engineering](https:\u002F\u002Fstaffeng.com\u002Fguides\u002Flearning-materials)\n- [Staff archetypes](https:\u002F\u002Fstaffeng.com\u002Fguides\u002Fstaff-archetypes\u002F), Will Larson\n\n### Characters sets\n\n- [The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)](http:\u002F\u002Fwww.joelonsoftware.com\u002Farticles\u002FUnicode.html)\n- [The Absolute Minimum Every Software Developer Must Know About Unicode in 2023 (Still No Excuses!)](https:\u002F\u002Ftonsky.me\u002Fblog\u002Funicode\u002F)\n\n### Chess\n\n(yes - chess gets its own section :)\n\n- [Chessprogramming wiki](https:\u002F\u002Fwww.chessprogramming.org\u002FMain_Page)\n- [Compressing chess moves](https:\u002F\u002Fmbuffett.com\u002Fposts\u002Fcompressing-chess-moves\u002F)\n\n### Clouds\n\n- [open-guides\u002Fog-aws](https:\u002F\u002Fgithub.com\u002Fopen-guides\u002Fog-aws): a practical guide to AWS\n\n### Code reviews\n\n- [How to do a code review](https:\u002F\u002Fgoogle.github.io\u002Feng-practices\u002Freview\u002Freviewer\u002F), Google's engineering practices documentation.\n- [Post-Commit Reviews](https:\u002F\u002Fmedium.com\u002F@copyconstruct\u002Fpost-commit-reviews-b4cc2163ac7a): an interesting idea to increase developer velocity (there are some caveats though).\n- [How to Make Your Code Reviewer Fall in Love with You](https:\u002F\u002Fmtlynch.io\u002Fcode-review-love\u002F)\n  - Review your own code first\n  - Write a clear changelist description\n  - Automate the easy stuff\n  - Answer questions with the code itself\n  - Narrowly scope changes\n  - Separate functional and non-functional changes\n  - Respond graciously to critiques\n  - Artfully solicit missing information\n  - Award all ties to your reviewer\n  - Minimize lag between rounds of review\n- [How to Do Code Reviews Like a Human](https:\u002F\u002Fmtlynch.io\u002Fhuman-code-reviews-1\u002F)\n- [Ask HN: How do you review code?](https:\u002F\u002Fnews.ycombinator.com\u002Fitem?id=11416746): great discussion on HackerNews, full of interesting ideas.\n- [Maslow's pyramid of code reviews](https:\u002F\u002Fwww.dein.fr\u002Fposts\u002F2015-02-18-maslows-pyramid-of-code-review)\n  - Another one on the same topic: [The Code Review Pyramid](https:\u002F\u002Fwww.morling.dev\u002Fblog\u002Fthe-code-review-pyramid\u002F)\n- [Code review in remote teams](https:\u002F\u002Fweb.hypothes.is\u002Fblog\u002Fcode-review-in-remote-teams\u002F): very complete set of rules.\n- [No code reviews by default](https:\u002F\u002Fwww.raycast.com\u002Fblog\u002Fno-code-reviews-by-default\u002F)\n  - Responsibility over convention\n\n### Coding & code quality\n\n- [Write code that is easy to delete, not easy to extend](http:\u002F\u002Fprogrammingisterrible.com\u002Fpost\u002F139222674273\u002Fwrite-code-that-is-easy-to-delete-not-easy-to)\n- [The Ten Commandments of Egoless Programming](http:\u002F\u002Fblog.codinghorror.com\u002Fthe-ten-commandments-of-egoless-programming\u002F)\n- 📖 [Clean Code: A Handbook of Agile Software Craftsmanship](https:\u002F\u002Fwww.goodreads.com\u002Fbook\u002Fshow\u002F3735293-clean-code), Robert C. Martin. Describes numerous useful best practices. A bit long. There's also a [clean code cheatsheet](cheatsheets\u002FClean-Code-V2.4.pdf).\n- [What Software Craftsmanship is about](https:\u002F\u002Fblog.cleancoder.com\u002Funcle-bob\u002F2011\u002F01\u002F17\u002Fsoftware-craftsmanship-is-about.html)\n  - We’re tired of writing crap.\n  - We will not accept the stupid old lie about cleaning things up later.\n  - We will not believe the claim that quick means dirty.\n  - We will not allow anyone to force us to behave unprofessionally.\n- [Tips on naming boolean variables](https:\u002F\u002Fdev.to\u002Fmichi\u002Ftips-on-naming-boolean-variables-cleaner-code-35ig)\n  - There is a convention to prefix boolean variables and function names with \"is\" or \"has\".\n  - Try to always use is, even for plurals (`isEachUserLoggedIn` is better than `areUsersLoggedIn` or `isUsersLoggedIn`)\n  - Avoid custom prefixes (`isPaidFor` is better than `wasPaidFor`)\n  - Avoid negatives (`isEnabled` is better than `isDisabled`)\n- [How To Write Unmaintainable Code](https:\u002F\u002Fgithub.com\u002FDroogans\u002Funmaintainable-code\u002Fblob\u002Fmaster\u002FREADME.md)\n- [kettanaito\u002Fnaming-cheatsheet](https:\u002F\u002Fgithub.com\u002Fkettanaito\u002Fnaming-cheatsheet): : comprehensive language-agnostic guidelines on variables naming. Home of the A\u002FHC\u002FLC pattern.\n- 🧰 [Quality Engineering Guides](https:\u002F\u002Fqeunit.com\u002Fguides\u002F)\n- [What Makes Code Hard To Read: Visual Patterns of Complexity](https:\u002F\u002Fseeinglogic.com\u002Fposts\u002Fvisual-readability-patterns\u002F)\n- [zakirullin\u002Fcognitive-load: 🧠 Cognitive Load is what matters](https:\u002F\u002Fgithub.com\u002Fzakirullin\u002Fcognitive-load)\n- [How to create software quality](https:\u002F\u002Flethain.com\u002Fquality\u002F)\n\n### Communication\n\nSee also the Writing section\n\n- [How to communicate effectively as a developer](https:\u002F\u002Fwww.karlsutt.com\u002Farticles\u002Fcommunicating-effectively-as-a-developer\u002F)\n  - Lots of concrete advice and examples for short, medium and long-form writing\n- [What Do You Visualize While Programming?](https:\u002F\u002Fdillonshook.com\u002Fwhat-do-you-visualize-while-programming\u002F)\n\n### Compilers\n\n- [The Compiler Writer Resource Page](https:\u002F\u002Fc9x.me\u002Fcompile\u002Fbib\u002F)\n- [kanaka\u002Fmal](https:\u002F\u002Fgithub.com\u002Fkanaka\u002Fmal): mal - Make a Lisp\n- [Let's Build a Compiler](https:\u002F\u002Fcompilers.iecc.com\u002Fcrenshaw\u002F), Jack W. Crenshaw, 1988\n- [Writing a C Compiler, in Zig](https:\u002F\u002Far-ms.me\u002Fthoughts\u002Fc-compiler-1-zig\u002F)\n\n### Configuration\n\n- [The downsides of JSON for config files](https:\u002F\u002Farp242.net\u002Fweblog\u002FJSON_as_configuration_files-_please_dont.html), Martin Tournoij.\n  - Can't add comments\n  - Excessive quotation and syntax noise\n  - Using DC (declarative configuration) to control logic is often not a good idea.\n- [Your configs suck? Try a real programming language](https:\u002F\u002Fbeepb00p.xyz\u002Fconfigs-suck.html)\n  - Most modern config formats suck\n  - Use a real programming language\n- [Code rant: The Configuration Complexity Clock](https:\u002F\u002Fmikehadlow.blogspot.com\u002F2012\u002F05\u002Fconfiguration-complexity-clock.html)\n  - I’m not saying that it’s never appropriate to implement complex configuration, a rules-engine or a DSL, Indeed I would jump at the chance of building a DSL given the right requirements, but I am saying that you should understand the implications and recognise where you are on the clock before you go down that route.\n  - Initially there was hope that non-technical business users would be able to use the GUI to configure the application, but that turned out to be a false hope; the mapping of business rules into the engine requires a level of expertise that only some members of the development team possess.\n\n### Continuous Integration (CI)\n\n- [Continuous Integration](https:\u002F\u002Fmartinfowler.com\u002Farticles\u002FcontinuousIntegration.html), MartinFowler.com\n\n### Data analysis & data science\n\n- [Ways to make fake data look meaningful](https:\u002F\u002Fdanbirken.com\u002Fstatistics\u002F2013\u002F11\u002F19\u002Fways-to-make-fake-data-look-meaningful.html)\n  - Don’t share the raw data\n  - Don’t share your methodology\n  - Don’t include confidence intervals\n  - Don’t challenge your own data\n- 📖 [Python Data Science Handbook](https:\u002F\u002Fjakevdp.github.io\u002FPythonDataScienceHandbook\u002F), O'Reilly\n\n### Databases\n\nSee also the SQL section.\n\n- [A plain English introduction to CAP Theorem](http:\u002F\u002Fksat.me\u002Fa-plain-english-introduction-to-cap-theorem)\n- [PACELC theorem](https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FPACELC_theorem): \"in case of network partitioning (P) in a distributed computer system, one has to choose between availability (A) and consistency (C) (as per the CAP theorem), but else (E), even when the system is running normally in the absence of partitions, one has to choose between latency (L) and consistency (C).\"\n- [Zero downtime database migrations](https:\u002F\u002Fblog.rainforestqa.com\u002F2014-06-27-zero-downtime-database-migrations\u002F) (code examples are using Rails but this works great for any programming language)\n- [Readings in Database Systems, 5th Edition](http:\u002F\u002Fwww.redbook.io\u002F)\n- [Comparing database types: how database types evolved to meet different needs](https:\u002F\u002Fdataguide.prisma.io\u002Fintro\u002Fcomparing-database-types)\n- [How does a relational database work](http:\u002F\u002Fcoding-geek.com\u002Fhow-databases-work\u002F)\n- [Use the index, Luke](https:\u002F\u002Fuse-the-index-luke.com\u002F)\n- [Course introduction — MySQL for Developers](https:\u002F\u002Fplanetscale.com\u002Flearn\u002Fcourses\u002Fmysql-for-developers\u002Fintroduction\u002Fcourse-introduction), PlanetScale\n- [Why you should probably be using SQLite | Epic Web Dev](https:\u002F\u002Fwww.epicweb.dev\u002Fwhy-you-should-probably-be-using-sqlite)\n\nScaling databases:\n\n- [How Figma's Databases Team Lived to Tell the Scale](https:\u002F\u002Fwww.figma.com\u002Fblog\u002Fhow-figmas-databases-team-lived-to-tell-the-scale\u002F): interesting story about sharding\n\n#### Internals\n\n- [How Query Engines Work](https:\u002F\u002Fhowqueryengineswork.com\u002F00-introduction.html)\n- [Let's Build a Simple Database](https:\u002F\u002Fcstack.github.io\u002Fdb_tutorial\u002F)\n- [Algorithms Behind Modern Storage Systems](https:\u002F\u002Fqueue.acm.org\u002Fdetail.cfm?id=3220266), ACM Queue\n- [sorted string tables (SST) from first principles](https:\u002F\u002Fwww.bitsxpages.com\u002Fp\u002Fsorted-string-tables-sst-from-first)\n\n#### NoSQL\n\n- [NOSQL Patterns](http:\u002F\u002Fhoricky.blogspot.nl\u002F2009\u002F11\u002Fnosql-patterns.html)\n- [NoSQL Databases: a Survey and Decision Guidance](https:\u002F\u002Fmedium.baqend.com\u002Fnosql-databases-a-survey-and-decision-guidance-ea7823a822d#.9fe79qr90)\n- The DynamoDB docs has some great pages:\n  - [Read Consistency](https:\u002F\u002Fdocs.aws.amazon.com\u002Famazondynamodb\u002Flatest\u002Fdeveloperguide\u002FHowItWorks.ReadConsistency.html)\n  - [From SQL to NoSQL](https:\u002F\u002Fdocs.aws.amazon.com\u002Famazondynamodb\u002Flatest\u002Fdeveloperguide\u002FSQLtoNoSQL.html)\n  - [NoSQL Design for DynamoDB](https:\u002F\u002Fdocs.aws.amazon.com\u002Famazondynamodb\u002Flatest\u002Fdeveloperguide\u002Fbp-general-nosql-design.html)\n- [Redis Explained](https:\u002F\u002Farchitecturenotes.co\u002Fredis\u002F)\n\n#### Postgres\n\n- [Safe Operations For High Volume PostgreSQL](https:\u002F\u002Fwww.braintreepayments.com\u002Fblog\u002Fsafe-operations-for-high-volume-postgresql\u002F) (this is for PostgreSQL but works great for other DBs as well).\n- [Transaction Isolation in Postgres, explained](https:\u002F\u002Fwww.thenile.dev\u002Fblog\u002Ftransaction-isolation-postgres)\n- [PostgreSQL exercises](https:\u002F\u002Fpgexercises.com\u002F)\n- [Postgres operations cheat sheet](https:\u002F\u002Fwiki.postgresql.org\u002Fwiki\u002FOperations_cheat_sheet)\n- [Postgres: don't Do This](https:\u002F\u002Fwiki.postgresql.org\u002Fwiki\u002FDon't_Do_This)\n- [PostgreSQL and UUID as primary key](https:\u002F\u002Fmaciejwalkowiak.com\u002Fblog\u002Fpostgres-uuid-primary-key\u002F)\n- [Postgres lock explained](https:\u002F\u002Fpostgreslocksexplained.com\u002F)\n\n\"Just use postgres\":\n\n- [Just use Postgres](https:\u002F\u002Fmccue.dev\u002Fpages\u002F8-16-24-just-use-postgres)\n- [Postgres is Enough](https:\u002F\u002Fgist.github.com\u002Fcpursley\u002Fc8fb81fe8a7e5df038158bdfe0f06dbb)\n- [It’s 2026, Just Use Postgres](https:\u002F\u002Fwww.tigerdata.com\u002Fblog\u002Fits-2026-just-use-postgres)\n\n### Data formats\n\n- [Falsehoods Programmers Believe About Phone Numbers](https:\u002F\u002Fgithub.com\u002Fgooglei18n\u002Flibphonenumber\u002Fblob\u002Fmaster\u002FFALSEHOODS.md), Google's `libphonenumber`.\n- [Rules for Autocomplete](http:\u002F\u002Fjeremymikkola.com\u002Fposts\u002F2019_03_19_rules_for_autocomplete.html): rough specifications for autocomplete fields\n- [Falsehoods programmers believe about addresses](https:\u002F\u002Fwww.mjt.me.uk\u002Fposts\u002Ffalsehoods-programmers-believe-about-addresses\u002F)\n- [Falsehoods Programmers Believe About Names](https:\u002F\u002Fwww.kalzumeus.com\u002F2010\u002F06\u002F17\u002Ffalsehoods-programmers-believe-about-names\u002F)\n- [kdeldycke\u002Fawesome-falsehood](https:\u002F\u002Fgithub.com\u002Fkdeldycke\u002Fawesome-falsehood): falsehoods programmers believe in\n- [Understanding UUIDs, ULIDs and String Representations](https:\u002F\u002Fsudhir.io\u002Fuuids-ulids)\n- [Falsehoods Programmers Believe About Falsehoods Lists](https:\u002F\u002Fkevin.deldycke.com\u002F2016\u002Ffalsehoods-programmers-believe-about-falsehoods-lists)\n- [Australia\u002FLord_Howe is the weirdest timezone](https:\u002F\u002Fssoready.com\u002Fblog\u002Fengineering\u002Ftruths-programmers-timezones\u002F)\n- [A love letter to the CSV format](https:\u002F\u002Fgithub.com\u002Fmedialab\u002Fxan\u002Fblob\u002Fmaster\u002Fdocs\u002FLOVE_LETTER.md)\n- [Falsehoods Programmers Believe About Aviation](https:\u002F\u002Fflightaware.engineering\u002Ffalsehoods-programmers-believe-about-aviation\u002F)\n- [Schemas - Schema.org](https:\u002F\u002Fschema.org\u002Fdocs\u002Fschemas.html)\n- [ZIP Code First](https:\u002F\u002Fzipcodefirst.com\u002F)\n\n### Data science\u002Fdata engineering\n\n- [A dirty dozen: twelve common metric interpretation pitfalls in online controlled experiments](https:\u002F\u002Fblog.acolyer.org\u002F2017\u002F09\u002F25\u002Fa-dirty-dozen-twelve-common-metric-interpretation-pitfalls-in-online-controlled-experiments\u002F)\n- [datastacktv\u002Fdata-engineer-roadmap](https:\u002F\u002Fgithub.com\u002Fdatastacktv\u002Fdata-engineer-roadmap): roadmap to becoming a data engineer\n- [Awesome Data Engineering Learning Path](https:\u002F\u002Fawesomedataengineering.com\u002F)\n- [Emerging Architectures for Modern Data Infrastructure](https:\u002F\u002Fa16z.com\u002F2020\u002F10\u002F15\u002Fthe-emerging-architectures-for-modern-data-infrastructure\u002F)\n- [How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh](https:\u002F\u002Fmartinfowler.com\u002Farticles\u002Fdata-monolith-to-mesh.html)\n  - Data platforms based on the data lake architecture have common failure modes that lead to unfulfilled promises at scale.\n  - We need to consider domains as the first class concern, apply platform thinking to create self-serve data infrastructure, and treat data as a product.\n- [MLOps](https:\u002F\u002Fmadewithml.com\u002Fcourses\u002Fmlops\u002F)\n- [Uber's Big Data Platform: 100+ Petabytes with Minute Latency](https:\u002F\u002Feng.uber.com\u002Fuber-big-data-platform\u002F)\n- [SQL should be the default choice for data transformation logic](https:\u002F\u002Fwww.robinlinacre.com\u002Frecommend_sql\u002F)\n\n### Debugging\n\nAlso see the Incident Response section in this doc\n\n- [Rubber Duck Problem Solving](http:\u002F\u002Fblog.codinghorror.com\u002Frubber-duck-problem-solving\u002F)\n- [Rubber Ducking](http:\u002F\u002Fc2.com\u002Fcgi\u002Fwiki?RubberDucking)\n- [Five Whys](https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002F5_Whys)\n- [The Five Lies Analysis](https:\u002F\u002Fserce.me\u002Fposts\u002F14-10-2021-the-five-lies-analysis)\n  - The real problem reveals itself when the technique becomes a part of a template.\n  - Action items can be very distant from the root cause.\n  - Related article: [The Evolution of SRE at Google](https:\u002F\u002Fwww.usenix.org\u002Fpublications\u002Floginonline\u002Fevolution-sre-google)\n- [The Infinite Hows](http:\u002F\u002Fwww.kitchensoap.com\u002F2014\u002F11\u002F14\u002Fthe-infinite-hows-or-the-dangers-of-the-five-whys\u002F) criticizes the five whys method and advocates for a different set of questions to learn from the most from incidents.\n  - See also: [Human errors: models and management](https:\u002F\u002Fapp.box.com\u002Fs\u002F7z35l09amvr1vwxouh2s)\n  - \"The issue with the Five Whys is that it’s tunnel-visioned into a linear and simplistic explanation of how work gets done and events transpire.\"\n  - \"Human error becomes a starting point, not a conclusion.\" (Dekker, 2009)\n  - \"When we ask 'how?', we’re asking for a narrative.\"\n  - \"When it comes to decisions and actions, we want to know how it made sense for someone to do what they did.\"\n  - At each \"why\" step, only one answer will be selected for further investigation. Asking \"how\" encourage broader exploration.\n  - \"In accident investigation, as in most other human endeavours, we fall prey to the What-You-Look-For-Is-What-You-Find or WYLFIWYF principle. This is a simple recognition of the fact that assumptions about what we are going to see (What-You-Look-For), to a large extent will determine what we actually find (What-You-Find).\" (Hollnagel, 2009, p. 85) (see [illustration of WYLFIWYF](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=vJG698U2Mvo))\n  - \"A final reason why a 'root cause' may be selected is that it is politically acceptable as the identified cause. Other events or explanations may be excluded or not examined in depth because they raise issues that are embarrassing to the organization or its contractors or are politically unacceptable.\" (Nancy Leveson, Engineering a Safer World, p. 20)\n  - [Bounded rationality](https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FBounded_rationality): rational individuals will select a decision that is satisfactory rather than optimal\n  - The article provide concrete ways and questions to solicit stories from people, which will yield better insights.\n    - What were you expecting to happen?\n    - If you had to describe the situation to your colleague at that point, what would you have told?\n    - Did this situation fit a standard scenario?\n    - What were you trying to achieve?Were there multiple goals at the same time?Was there time pressure or other limitations on what you could do?\n    - [See template here](http:\u002F\u002Fwww.kitchensoap.com\u002Fwp-content\u002Fuploads\u002F2014\u002F09\u002FVelocity2014-PM-Fac-Handout-Debrief.pdf)\n- [Linux Performance Analysis in 60,000 Milliseconds](http:\u002F\u002Ftechblog.netflix.com\u002F2015\u002F11\u002Flinux-performance-analysis-in-60s.html)\n- [Post-Mortems at HubSpot: What I Learned From 250 Whys](https:\u002F\u002Fproduct.hubspot.com\u002Fblog\u002Fbid\u002F64771\u002Fpost-mortems-at-hubspot-what-i-learned-from-250-whys)\n- [Debugging zine](https:\u002F\u002Fjvns.ca\u002Fdebugging-zine.pdf), Julian Evans\n- [If you understand a bug, you can fix it](https:\u002F\u002Fwizardzines.com\u002Fcomics\u002Funderstand-can-fix\u002F)\n- [The Thirty Minute Rule](https:\u002F\u002Fdaniel.feldroy.com\u002Fposts\u002Fthirty-minute-rule): if anyone gets stuck on something for more than 30 minutes, they should ask for help\n- [How to create a Minimal, Reproducible Example](https:\u002F\u002Fstackoverflow.com\u002Fhelp\u002Fminimal-reproducible-example), Stack Overflow\n- [Some ways to get better at debugging](https:\u002F\u002Fjvns.ca\u002Fblog\u002F2022\u002F08\u002F30\u002Fa-way-to-categorize-debugging-skills\u002F), Julia Evans\n  - Learn the codebase\n  - Learn the system (e.g., HTTP stack, database transactions)\n  - Learn your tools (e.g., `strace`, `tcpdump`)\n  - Learn strategies (e.g., writing code to reproduce, adding logging, taking a break)\n  - Get experience: according to a study, \"experts simply formed more correct hypotheses and were more efficient at finding the fault.\"\n- [What exactly is the 'Saff Squeeze' method of finding a bug?](https:\u002F\u002Fstackoverflow.com\u002Fquestions\u002F23865274\u002Fwhat-exactly-is-the-saff-squeeze-method-of-finding-a-bug)\n  - A systematic technique for deleting both test code and non-test code from a failing test until the test and code are small enough to understand.\n- [tcpdump is amazing](https:\u002F\u002Fjvns.ca\u002Fblog\u002F2016\u002F03\u002F16\u002Ftcpdump-is-amazing\u002F), Julia Evans\n- [What we talk about when we talk about ‘root cause’](https:\u002F\u002Fgithub.com\u002Freadme\u002Fguides\u002Froot-cause)\n- [David A. Wheeler's Review of \"Debugging\" by David J. Agans](https:\u002F\u002Fdwheeler.com\u002Fessays\u002Fdebugging-agans.html)\n- [Troubleshooting: The Skill That Never Goes Obsolete](https:\u002F\u002Fwww.autodidacts.io\u002Ftroubleshooting\u002F)\n  - Includes links to interesting debugging stories\n- [Falsehoods software teams believe about user feedback](https:\u002F\u002Fthoughtbot.com\u002Fblog\u002Ffalsehoods-software-teams-believe-about-user-feedback)\n\n### Design (visual, UX, UI, typography)\n\nI highly recommend reading [The Non-Designer's Design Book](http:\u002F\u002Fwww.amazon.com\u002Fgp\u002Fproduct\u002F0133966151\u002Fref=pd_lpo_sbs_dp_ss_1?pf_rd_p=1944687602&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=0321534042&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=1R7MVQP0BCP7GP9VZGYX). This is a pretty short book that will give you some very actionable design advices.\n\n- If you're working on data, Edward Tufte's [The Visual Display of Quantitative Information](http:\u002F\u002Fwww.amazon.com\u002FVisual-Display-Quantitative-Information\u002Fdp\u002F0961392142\u002Fref=sr_1_1?ie=UTF8&qid=1458046603&sr=8-1&keywords=tufte) is considered a classic.\n- The [Universal Principles of Design](http:\u002F\u002Fwww.amazon.com\u002FUniversal-Principles-Design-Revised-Updated\u002Fdp\u002F1592535879\u002Fref=sr_1_1?ie=UTF8&qid=1458046663&sr=8-1&keywords=universal+principles+of+design) will give you enough vocabulary and concepts to describe design challenges into words.\n- [Book recommendations from HackerNews](https:\u002F\u002Fnews.ycombinator.com\u002Fitem?id=12711060)\n- 🏙[Design for Non-Designers](https:\u002F\u002Fspeakerdeck.com\u002Ftracymakes\u002Fdesign-for-non-designers-beyond-tellerand-dusseldorf-2018)\n\nArticles :\n\n- [10 Usability Heuristics Every Designer Should Know](https:\u002F\u002Fuxdesign.cc\u002F10-usability-heuristics-every-designer-should-know-129b9779ac53)\n  - Visibility of System Status\n  - The Match Between The System And The Real World\n  - Every system should have a clear emergency exit\n  - Don't forget that people spend 90% of their time interacting with other apps\n  - Recognition Rather Than Recall (recognition = shallow form of retrieval from memory, e.g. a familiar person, recall = deeper retrieval)\n  - ”Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” – Antoine de Saint-Exupery\n  - Help Users Recognize, Diagnose, And Recover From Errors\n- [How to pick more beautiful colors for your data visualizations](https:\u002F\u002Fblog.datawrapper.de\u002Fbeautifulcolors\u002F)\n- [Visual design rules you can safely follow every time](https:\u002F\u002Fanthonyhobday.com\u002Fsideprojects\u002Fsaferules\u002F)\n- [Malleable software: Restoring user agency in a world of locked-down apps](https:\u002F\u002Fwww.inkandswitch.com\u002Fessay\u002Fmalleable-software\u002F)\n\nTypograhy: see \"Typography\" section\n\nResources:\n\n- 🧰 [bradtraversy\u002Fdesign-resources-for-developers](https:\u002F\u002Fgithub.com\u002Fbradtraversy\u002Fdesign-resources-for-developers): design and UI resources from stock photos, web templates, CSS frameworks, UI libraries, tools...\n\n### Design (OO modeling, architecture, patterns, anti-patterns, etc.)\n\nHere's a list of good books:\n\n- 📖 [Design Patterns: Elements of Reusable Object-Oriented Software](http:\u002F\u002Fwww.amazon.com\u002Fdp\u002F0201633612\u002F): dubbed \"the gang of four\", this is almost a required reading for any developer. A lot of those are a bit overkill for Python (because everything is an object, and dynamic typing), but the main idea (composition is better than inheritance) definitely is a good philosophy.\n  - And their nefarious nemesis [Re","professional-programming 项目是一个面向有好奇心的软件工程师的学习资源集合。该项目以Python语言为基础，涵盖了从基础概念到高级实践的各种学习材料，包括但不限于算法与数据结构、API设计、代码质量提升、持续集成等技术话题，以及职业发展、沟通技巧等软技能内容。它适合任何希望扩展知识面、提高技术水平或寻找职业发展方向的软件开发者使用。MIT许可证下开放，社区活跃度高，便于贡献和共享。",2,"2026-06-11 02:38:43","top_all"]