Professional Programming - about this list

Give me six hours to chop down a tree and I will spend the first four sharpening the axe. (Abraham Lincoln)

A collection of full-stack resources for programmers.

The 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.

Principles

• This page is not meant to be comprehensive. I am trying to keep it light and not too overwhelming.
• The selection of articles is opinionated.
• 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.

Items:

• 🧰 : list of resources
• 📖 : book
• 🎞 : video/movie extract/movie/talk
• 🏙 : slides/presentation
• ⭐️ : must-read
• 📃 : paper

Contributing to this list

Feel free to open a PR to contribute!

I will not be adding everything: as stated above, I am trying to keep the list concise.

Must-read books

I've found these books incredibly inspiring:

• 📖 The Pragmatic Programmer: From Journeyman to Master: hands-on the most inspiring and useful book I've read about programming.
• 📖 Code Complete: A Practical Handbook of Software Construction: a nice addition to The Pragmatic Programmer, gives you the necessary framework to talk about code.
• 📖 Release It!: 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.
• 📖 Scalability Rules: 50 Principles for Scaling Web Sites
• 📖 The Linux Programming Interface: A Linux and UNIX System Programming Handbook: 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.
• 📖 Structure and interpretation of Computer Programs (free): One of the most influential textbooks in Computer Science (written and used at MIT), SICP has been influential in CS education. Byte recommended SICP "for professional programmers who are really interested in their profession".

There are some free books available, including:

• 📖 Professional software development: 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.
• 🧰 vhf/free-programming-books
• 🧰 EbookFoundation/free-programming-books

Must-read articles

• Practical Advice for New Software Engineers
• On Being A Senior Engineer
• Lessons Learned in Software Development: one of those articles that give you years of hard-earned lessons, all in one short article. Must read.
• Things I Learnt The Hard Way
  • Spec first, then code
  • Tests make better APIs
  • Future thinking is future trashing
  • Documentation is a love letter to your future self
  • Sometimes, it's better to let the application crash than do nothing
  • Understand and stay away of cargo cult
  • "Right tool for the job" is just to push an agenda
  • Learn the basics functional programming
  • ALWAYS use timezones with your dates
  • ALWAYS use UTF-8
  • Create libraries
  • Learn to monitor
  • Explicit is better than implicit
  • Companies look for specialists but keep generalists longer
  • The best secure way to deal with user data is not to capture it
  • When it's time to stop, it's time to stop
  • You're responsible for the use of your code
  • Don't tell "It's done" when it's not
  • Pay attention on how people react to you
  • Beware of micro-aggressions
  • Keep a list of "Things I Don't Know"
• Signs that you're a good programmer (not everything in here is great - some of the points are counterproductive)
  • The instinct to experiment first
  • Emotional detachment from code and design
  • Eager to fix what isn't broken
  • Fascinated by the incomprehensible
  • Compelled to teach
  • Incorruptible patience
  • A destructive pursuit of perfection
  • Encyclopedic grasp of the platform
  • Thinks In Code
  • When In Rome, Does As Romans Do
  • Creates their own tools
  • Indifferent to Hierarchy
  • Excited by failure
  • Indifferent to circumstances
  • Substitutes impulse for commitment
  • Driven by experiences
• 7 absolute truths I unlearned as junior developer
  • Early in your career, you can learn 10x more in a supportive team in 1 year, than coding on your own
  • Every company has problems, every company has technical debt.
  • Being overly opinionated on topics you lack real-world experience with is pretty arrogant.
  • Many conference talks cover proof of concepts rather than real-world scenarios.
  • Dealing with legacy is completely normal.
  • Architecture is more important than nitpicking.
  • Focus on automation over documentation where appropriate.
  • Having some technical debt is healthy.
  • Senior engineers must develop many skills besides programming.
  • We’re all still junior in some areas.
• How to Build Good Software
  • A good high-level summary of fundamental engineering practices.
  • The root cause of bad software has less to do with specific engineering choices, and more to do with how development projects are managed.
  • There is no such thing as platonically good engineering: it depends on your needs and the practical problems you encounter.
  • Software should be treated not as a static product, but as a living manifestation of the development team’s collective understanding.
  • Software projects rarely fail because they are too small; they fail because they get too big.
  • 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.
  • 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.
• How to be a -10x Engineer
  • Nullify the output of 10 engineers.
  • Hold 10 engineers hostage in a technical discussion.
  • Waste 10 weeks of wages on cloud costs.
  • Waste 400 hours of engineering on bad architecture.
  • Incur 400 hours of bug triage.
• A Bunch of Programming Advice I'd Give To Myself 15 Years Ago
  • If you (or your team) are shooting yourselves in the foot constantly, fix the gun
  • Assess the trade-off you’re making between quality and pace, make sure it’s appropriate for your context
  • Spending time sharpening the axe is almost always worth it
  • If you can’t easily explain why something is difficult, then it’s incidental complexity, which is probably worth addressing
  • Try to solve bugs one layer deeper
  • Don’t underestimate the value of digging into history to investigate some bugs
  • Bad code gives you feedback, perfect code doesn’t. Err on the side of writing bad code
  • Make debugging easier
  • When working on a team, you should usually ask the question
  • Shipping cadence matters a lot. Think hard about what will get you shipping quickly and often
• Expert Generalists, martinfowler.com, proposes an interesting take on the "T-shaped engineer"
  • The Characteristics of an Expert Generalist: Curiosity, Collaborativeness, Customer Focus, Favor Fundamental Knowledge, Blend of Generalist and Specialist Skills, Sympathy for Related Domains
  • Assessing Expert Generalists: hiring and career progression
  • Growing Expert Generalists: From Tools to Fundamentals
    • "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."
  • Expert Generalists still need Specialists
  • Expert Generalists in the Age of LLMs
    • "Similarly to a specialist, an LLM can rapidly answer questions that an Expert Generalist will have when working in a new domain."
    • "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."

Other general material and list of resources

Other lists

• liuchong/awesome-roadmaps: A curated list of roadmaps.

Books

• 📖 The Imposter's Handbook - $30. From the author: "Don't have a CS Degree? Neither do I - That's why I wrote this book."
• 📖 The Computer Science Book
• 📖 The Software Engineer's Guidebook: Gergely Orosz's guidebook to the software engineering industry. Extremely complete.

Articles

• mr-mig/every-programmer-should-know: a collection of (mostly) technical things every software developer should know
• Famous Laws Of Software Development
• The Amazon Builders' Library
  • There is a list of the best articles in this Twitter Thread
• kdeldycke/awesome-falsehood: Falsehoods Programmers Believe in
• hellerve/programming-talks
• TechYaks: list of talks
• Talks that changed the way I think about programming
• What every computer science major should know
• kamranahmedse/developer-roadmap
• mtdvio/every-programmer-should-know: a collection of (mostly) technical things every software developer should know about
• Mike Acton’s Expectations of Professional Software Engineers
• Things they didn't teach you about Software Engineering
  • Domain knowledge is more important than your coding skills
  • Code is secondary. Business value is first.
  • You work with uncertainty most of the time
• We overestimate our short-term ability, but underestimate our long-term ability.
  • Specialisation is for insects.
• Want an unfair advantage in your tech career? Consume content meant for other roles
  • Cross-functional understanding is critical in modern tech companies
  • Helps to avoid underestimating the importance and difficulty other roles
  • Helps you to be strategic in your interaction with people in that role
• Teach Yourself Programming in Ten Years
• Mistakes You Apparently Just Have to Make Yourself
• The Best Programmers I Know
• Laws of Software Engineering

Axioms

• Precepts - Urbit
  • Data is better than code.
  • Correctness is more important than performance.
  • Deterministic beats heuristic.
  • One hundred lines of simplicity is better than twenty lines of complexity.
  • 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.
  • 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.
  • If there's clearly a right way to do something and a wrong way, do it the right way. Coding requires incredible discipline.
  • The best way to get the right answer is to try it the wrong way.
  • Practice tells you that things are good or bad; theory tells you why.
  • Not being qualified to solve a problem is no reason not to solve it.
  • 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.
• Embedded Rules of Thumb
• 50 Ideas That Changed My Life
• Reflections on 10,000 Hours of Programming
• 20 Things I've Learned in my 20 Years as a Software Engineer

Courses

• Google Tech Dev Guide
• The Missing Semester of Your CS Education, MIT. Includes lectures about the shell, editors, data wrangling, git, debugging and profiling, meta programming, security and cryptography.
• Mathematics for the adventurous self-learner, Neil Sainsbury
• jwasham/coding-interview-university: a complete computer science study plan to become a software engineer.
• Teach Yourself Computer Science: an opinionated set of the best CS resources.
• ossu/computer-science: free self-taught education in Computer Science!

Topics

Accounting

• Engineers Do Not Get To Make Startup Mistakes When They Build Ledgers

Agentic coding

• Anatomy of the .claude/ Folder
• Beyond the Prompt: Claude Code

Algorithm and data structures

• Read the CLRS. You can watch and download the course on OCW - there are newer courses as well.
• Or The Algorithm Design Manual (Skiena)
• Try out some algorithms on Project Euler
• CS 61B Spring 2023

Other resources:

• Algorithms, Jeff Erickson

Here are some useful & interesting algo & DS visualizations:

• Grokking Algorithms
• Essential Algorithms
• Data Structure Visualization
• 🎞 15 Sorting Algorithms in 6 Minutes
• Hashing
• Visualizing Algorithms
• B-trees and database indexes
• Big O visualizations
• Algorithm explained like Ikea instructions
• Decision Trees

Example implementations:

• trekhleb/javascript-algorithms: algorithms and data structures implemented in JavaScript
• The Algorithms

Algorithms in distributed systems:

• Raft Consensus Algorithm

API design & development

General REST content:

• Architectural Styles and the Design of Network-based Software Architectures, Roy Fielding (the inventor of REST)
• A collection of useful resources for building RESTful HTTP+JSON APIs.
• Best practices for REST API design, Stack Overflow Blog
• 📖 Undisturbed REST: a guide to designing the perfect API: very complete book about RESTful API design.

Example guidelines:

• Microsoft's Rest API guidelines
• Zalando RESTful API and Event Scheme Guidelines
• Google's API Design Guide: a general guide to design networked API.
• AIP-1: AIP Purpose and Guidelines
  • AIP stands for API Improvement Proposal, which is a design document providing high-level, concise documentation for API development.

More specific topics:

• Why you should use links, not keys, to represent relationships in APIs, Martin Nally, Google
  • "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."
• Give me /events, not webhooks
  • Events can unlock much-needed webhook features, like allowing your webhook consumers to replay or reset the position of their webhook subscription.
• Unlocking the Power of JSON Patch

Attitude, habits, mindset

• Mastering Programming, Kent Beck.
• The traits of a proficient programmer
• The tao of programming: a set of parables about programming.
• Taking Ownership Is The Most Effective Way to Get What You Want
• Finding Time to Become a Better Developer
• Ten minutes a day: how Alex Allain wrote a book in less than 200 hours, by writing 10 minutes every day.
• The care and feeding of software engineers (or, why engineers are grumpy)
  • 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.
  • Both engineers and product managers tend to think, incorrectly, that product specifications or requirements are equivalent to the furniture manual from Ikea.
  • This is one of the top things that make engineers grumpy: constantly shifting priorities.
  • Even though many engineers will complain that product managers change their minds, almost none will account for that in their time estimates.
  • Computer science programs aren’t about preparing you for the tasks you’ll face in industry.
  • When there are more engineers than can be used, engineering time ends up going away from developing and towards planning, synchronization, and coordination.
  • Involve engineers in the creative process
  • Give engineers opportunities to be creative.
  • Encourage time off.
  • Let 'em code
  • Express appreciation
• The Product-Minded Software Engineer, Gergely Orosz
  • Great product engineers know that minimum lovable products need the right depth
  • 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
  • Engage in user research and customer support
  • Bring well-backed product suggestions to the table
  • Offer product/engineering tradeoffs
• 40 Lessons From 40 Years, Steve Schlafman
  • 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.
  • 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.
  • You’ll never get what you don’t ask for or actively seek out. Go for it!
  • It’s not about the light at the end of the tunnel. It’s the tunnel. Show up every day and enjoy the process.
  • A great teammate always puts the organization and its purpose ahead of their own self interests.
  • Pick your spots. We have limited time and our brains can only process so much. Focus is key. Choose wisely.
  • Every person is likely struggling with something. Be kind. Be helpful.
• On Coding, Ego and Attention
  • Beginner’s mind accepts the fact that absolute knowledge is infinite and thus keeping score is a waste of time.
  • Mastery is simply the accumulation of momentum, not the accumulation of knowledge.
  • 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.
• Fixed vs. Growth: The Two Basic Mindsets That Shape Our Lives
• What does a great software engineer look like?
• Good sleep, good learning, good life
• 🎞 Steve Jobs: if you don't ask for help, you won't get very far
• Programming quotes
• Be Kind
  • Being kind is fundamentally about taking responsibility for your impact on the people around you.
  • It requires you be mindful of their feelings and considerate of the way your presence affects them.
• Warren Buffett Says This 1 Simple Habit Separates Successful People From Everyone Else
  • The difference between successful people and really successful people is that really successful people say no to almost everything.
• How to get lucky?
• Programmers should stop celebrating incompetence, DHH
  • The magic of programming is largely just things you don't know yet.
  • It's not fine to think you shouldn't be on some paths towards mastery, if you intend to make programming your career.
• There’s no speed limit
• Don't Wait for Motivation, Act for Momentum
  • Start with a tiny task. Then ride its momentum.
• The Most Important Coding Habits
  • The Most Important Coding Habits
  • Daily stretches
  • Take regular breaks
  • Don’t code late at night
  • Improve your coding environment
• Advice for new software devs who've read all those other advice essays
• Microservices aren't the problem. Incompetent people are
• High Agency (30-min read)
• What is "good taste" in software engineering?: it's all about contextual tradeoff.

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.

Dan Heller, Building a Career in Software

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

• The Grug Brained Developer: habits of self-aware programmer. Like Tao of Programming, different style.

Good judgment comes from experience. Experience comes from bad judgment.

Procrastination

• News is bad for you – and giving up reading it will make you happier, The Guardian
  • News misleads
  • News is irrelevant
  • News has no explanatory power
  • News is toxic to your body
  • News increases cognitive errors
  • News inhibits thinking
  • News works like a drug
  • News wastes time
  • News makes us passive
  • News kills creativity

Authentication/authorization

• Authorization in a microservices world
• Authorization Logic: Rules are hard because they evolve over time
• The Copenhagen Book provides a general guideline on implementing auth in web applications

Automation

• Automation Should Be Like Iron Man, Not Ultron

Best practices

• Software engineering practices

Beyond software engineering & random

• Why Software Engineers like Woodworking

Biases

Biases 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.

• Cognitive bias cheat sheet. #hiring

Business

• Payments 101 for a Developer
• The 4 biggest problems with homemade billing systems
• 🦑 The 14 pains of building your own billing system

Buy vs. Build

• Choose Boring Technology
• Build vs. Buy
  • 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.
• Platform Engineering: Build vs Buy
  • 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.

Cache

• Caching challenges and strategies, Amazon Builders Library

Career growth

• The Conjoined Triangles of Senior-Level Development looks into how to define a senior engineer.
• Ten Principles for Growth as an Engineer, Dan Heller.
• Don't Call Yourself a Programmer, Patrick McKenzie.
• On being an Engineering Manager
• The career advice I wish I had at 25
  • A career is a marathon, not a sprint
  • Most success comes from repetition, not new things
  • If work was really so great all the rich people would have the jobs
  • Management is about people, not things
  • Genuinely listen to others
  • Recognise that staff are people with finite emotional capacity
  • Don’t just network with people your own age
  • Never sacrifice personal ethics for a work reason
  • Recognise that failure is learning
• Career advice I wish I’d been given when I was young
  • Don’t focus too much on long-term plans.
  • Find good thinkers and cold-call the ones you most admire.
  • Assign a high value to productivity over your whole lifespan.
  • Don’t over-optimise things that aren’t your top priority.
  • Read a lot, and read things that people around you aren’t reading.
  • Reflect seriously on what problem to prioritise solving.
  • Read more history.
• Why Good Developers are Promoted into Unhappiness, Rob Walling. Or why management might not be for you.
• A guide to using your career to help solve the world’s most pressing problems
• What's a senior engineer's job? You need to be more than just an individual contributor.
• From Coding Bootcamp Graduate to Building Distributed Databases
  • Read Books (and papers), not Blog Posts
  • Take responsibility for your career trajectory
• 🏙 The Well Rounded Engineer includes lots of great book recommendations.
  • Paradigm polyglot (learn different languages & paradigms)
  • Database polyglot
  • Protocol polyglot (preferably TCP/IP and HTTP)
  • Proficiency with build tooling, packaging and distribution
  • Debugging, observability
  • Deployment, infra and devops
  • Software architecture and scaling
  • Ability to write toy compilers, interpreters and parsers
  • Ability to write toy games
  • Ability to understand algorithmic analysis
• Some career advice, Will Larson.
  • Advice you get is someone’s attempt to synthesize their experiences, not an accurate statement about how the world works.
  • Build a reservoir of prestige.
  • 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.
  • Great relationships will follow you everywhere you go. Bad ones too.
  • Early in your career, try to work at as many different kinds of companies and in different product vertical as you can.
• Evil tip: avoid "easy" things
• The Ultimate Code Kata
• Traits of a senior software engineer: impact, perception, visibility, influence, mentoring
• Software Engineering - The Soft Parts
  • Think critically and formulate well-reasoned arguments
  • Master the fundamentals
  • Focus on the user and all else will follow
  • Learn how to learn
• How To Own Your Growth As A Software Engineer
• The Forty-Year Programmer
  • The Better You Get, the Less You Look Like Everybody Else
  • You Learn Deep Principles by Doing the Basics
  • Look to Other Fields, Learn From Other Fields
  • Be Careful About Productivity Tips
• Senior Engineers are Living in the Future
• What would a map of your career look like?
• How to be successful at Amazon (or any other large company for that matter)
• Being good isn’t enough
  • The biggest gains come from combining disciplines.
• Stop Avoiding Politics is a good contrarian take on the current (negative) connotation of the word "politics".
  • 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.
  • "Good politics is just being strategic about relationships and influence in the service of good outcomes."
  • Examples: building relationships before you need them, understanding the incentives, managing up effectively, creating win-win situation, being visible.
  • "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."
• 21 Lessons from 14 Years at Google
• Publishing your work increases your luck

About senior engineers:

• Falsehoods Junior Developers believe about becoming Senior

Choosing your next/first opportunity

• Career Decisions - by Elad Gil - Elad Blog

Getting to Staff Eng

• I became a FAANG Staff Engineer in 5 years. These are the 14 lessons I learned along the way.
  • Software engineering isn’t just coding. Actually, coding is a small part of it.
  • Pipeline your work
  • Be open to feedback and listen. Like, seriously, listen.
  • Great feedback is hard to find; treasure it.
  • Keep an eye on the horizon (but not both).
  • Figure out what matters and let the rest go.
  • Comparison really is the thief of joy.
  • Mentorship is a beautiful thing.
  • Good days, in general, don’t just “happen”.
  • Advice and guidance are just that; they aren’t rules.
• Guides for reaching Staff-plus engineering roles, Will Larson
  • Being visible
  • Additional resources on Staff-plus engineering
• Staff archetypes, Will Larson

Characters sets

• The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
• The Absolute Minimum Every Software Developer Must Know About Unicode in 2023 (Still No Excuses!)

Chess

(yes - chess gets its own section :)

• Chessprogramming wiki
• Compressing chess moves

Clouds

• open-guides/og-aws: a practical guide to AWS

Code reviews

• How to do a code review, Google's engineering practices documentation.
• Post-Commit Reviews: an interesting idea to increase developer velocity (there are some caveats though).
• How to Make Your Code Reviewer Fall in Love with You
  • Review your own code first
  • Write a clear changelist description
  • Automate the easy stuff
  • Answer questions with the code itself
  • Narrowly scope changes
  • Separate functional and non-functional changes
  • Respond graciously to critiques
  • Artfully solicit missing information
  • Award all ties to your reviewer
  • Minimize lag between rounds of review
• How to Do Code Reviews Like a Human
• Ask HN: How do you review code?: great discussion on HackerNews, full of interesting ideas.
• Maslow's pyramid of code reviews
  • Another one on the same topic: The Code Review Pyramid
• Code review in remote teams: very complete set of rules.
• No code reviews by default
  • Responsibility over convention

Coding & code quality

• Write code that is easy to delete, not easy to extend
• The Ten Commandments of Egoless Programming
• 📖 Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin. Describes numerous useful best practices. A bit long. There's also a clean code cheatsheet.
• What Software Craftsmanship is about
  • We’re tired of writing crap.
  • We will not accept the stupid old lie about cleaning things up later.
  • We will not believe the claim that quick means dirty.
  • We will not allow anyone to force us to behave unprofessionally.
• Tips on naming boolean variables
  • There is a convention to prefix boolean variables and function names with "is" or "has".
  • Try to always use is, even for plurals (isEachUserLoggedIn is better than areUsersLoggedIn or isUsersLoggedIn)
  • Avoid custom prefixes (isPaidFor is better than wasPaidFor)
  • Avoid negatives (isEnabled is better than isDisabled)
• How To Write Unmaintainable Code
• kettanaito/naming-cheatsheet: : comprehensive language-agnostic guidelines on variables naming. Home of the A/HC/LC pattern.
• 🧰 Quality Engineering Guides
• What Makes Code Hard To Read: Visual Patterns of Complexity
• zakirullin/cognitive-load: 🧠 Cognitive Load is what matters
• How to create software quality

Communication

See also the Writing section

• How to communicate effectively as a developer
  • Lots of concrete advice and examples for short, medium and long-form writing
• What Do You Visualize While Programming?

Compilers

• The Compiler Writer Resource Page
• kanaka/mal: mal - Make a Lisp
• Let's Build a Compiler, Jack W. Crenshaw, 1988
• Writing a C Compiler, in Zig

Configuration

• The downsides of JSON for config files, Martin Tournoij.
  • Can't add comments
  • Excessive quotation and syntax noise
  • Using DC (declarative configuration) to control logic is often not a good idea.
• Your configs suck? Try a real programming language
  • Most modern config formats suck
  • Use a real programming language
• Code rant: The Configuration Complexity Clock
  • 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.
  • 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.

Continuous Integration (CI)

• Continuous Integration, MartinFowler.com

Data analysis & data science

• Ways to make fake data look meaningful
  • Don’t share the raw data
  • Don’t share your methodology
  • Don’t include confidence intervals
  • Don’t challenge your own data
• 📖 Python Data Science Handbook, O'Reilly

Databases

See also the SQL section.

• A plain English introduction to CAP Theorem
• PACELC 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)."
• Zero downtime database migrations (code examples are using Rails but this works great for any programming language)
• Readings in Database Systems, 5th Edition
• Comparing database types: how database types evolved to meet different needs
• How does a relational database work
• Use the index, Luke
• Course introduction — MySQL for Developers, PlanetScale
• Why you should probably be using SQLite | Epic Web Dev
• 📖 Database Internals

Scaling databases:

• How Figma's Databases Team Lived to Tell the Scale: interesting story about sharding

Internals

• How Query Engines Work
• Let's Build a Simple Database
• Algorithms Behind Modern Storage Systems, ACM Queue
• sorted string tables (SST) from first principles

NoSQL

• NOSQL Patterns
• NoSQL Databases: a Survey and Decision Guidance
• The DynamoDB docs has some great pages:
  • Read Consistency
  • From SQL to NoSQL
  • NoSQL Design for DynamoDB
• Redis Explained

Postgres

• Safe Operations For High Volume PostgreSQL (this is for PostgreSQL but works great for other DBs as well).
• Transaction Isolation in Postgres, explained
• PostgreSQL exercises
• Postgres operations cheat sheet
• Postgres: don't Do This
• PostgreSQL and UUID as primary key
• Postgres lock explained

"Just use postgres":

• Just use Postgres
• Postgres is Enough
• It’s 2026, Just Use Postgres

Data formats

• Falsehoods Programmers Believe About Phone Numbers, Google's libphonenumber.
• Rules for Autocomplete: rough specifications for autocomplete fields
• Falsehoods programmers believe about addresses
• Falsehoods Programmers Believe About Names
• kdeldycke/awesome-falsehood: falsehoods programmers believe in
• Understanding UUIDs, ULIDs and String Representations
• Falsehoods Programmers Believe About Falsehoods Lists
• Australia/Lord_Howe is the weirdest timezone
• A love letter to the CSV format
• Falsehoods Programmers Believe About Aviation
• Schemas - Schema.org
• ZIP Code First

Data science/data engineering

…view the full README on GitHub.