charlax
charlax
professional-programming
Python

A collection of learning resources for curious software engineers

Last updated Jul 8, 2026
51.2k
Stars
4.0k
Forks
4
Issues
+62
Stars/day
Attention Score
99
View on GitHub ↗ Open in github.dev
Topics
#architecture#computer-science#concepts#documentation#engineer#learning#lessons-learned#professional#programmer#programming-language#read-articles#scalability#software-engineering
Language breakdown
Python 72.3%
HTML 27.7%
▸ Files click to expand
README

Table of Contents

- Principles - Contributing to this list - Must-read books - Must-read articles - Other general material and list of resources - Other lists - Books - Articles - Axioms - Courses - Topics - Accounting - Agentic coding - Algorithm and data structures - API design & development - Attitude, habits, mindset - Procrastination - Authentication/authorization - Automation - Best practices - Beyond software engineering & random - Biases - Business - Buy vs. Build - Cache - Career growth - Choosing your next/first opportunity - Getting to Staff Eng - Characters sets - Chess - Clouds - Code reviews - Coding & code quality - Communication - Compilers - Configuration - Continuous Integration (CI) - Data analysis & data science - Databases - Internals - NoSQL - Postgres - Data formats - Data science/data engineering - Debugging - Design (visual, UX, UI, typography) - Design (OO modeling, architecture, patterns, anti-patterns, etc.) - Design: database schema - Design: patterns - Design: simplicity - Dev environment & tools - Docker - Documentation - Dotfiles - Editors & IDE - Vim - Email - Engineering management - Exercises - Experimentation - Fonts - Functional programming (FP) - Games development - Generative AI - Graphics - Hardware - HTTP - Humor - Incident response (oncall, alerting, outages, firefighting, postmortem) - Postmortem - Internet - Interviewing - Kubernetes - Large Language Model (LLM) - Learning & memorizing - Licenses (legal) - Linux (system management) - Low-code/no-code - Low-level, assembly - Machine learning/AI - Math - Marketing - Network - Observability (monitoring, logging, exception handling) - Logging - Error/exception handling - Metrics - Monitoring - Open source - Operating system (OS) - Over-engineering - Performance - Personal knowledge management (PKM) - Personal productivity - Perspective - Privacy - Problem solving - Product management for software engineers - Project management - Programming languages - Python - JavaScript - Garbage collection - Programming paradigm - Public speaking (presenting) - Reading - Refactoring - Regex - Releasing & deploying - Versioning - Checklists - Feature flags - Testing in production - Reliability - Integration patterns (dependency management) - Resiliency - Search - Security - Research papers - Shell (command line) - SQL - State - System administration - System architecture - Architecture patterns - Microservices/splitting a monolith - Scalability - Site Reliability Engineering (SRE) - Technical debt - Testing - Tools - Type system - Typography - Version control (Git) - Work ethics, productivity & work/life balance - Web development - Writing (communication, blogging) - Resources & inspiration for presentations - Keeping up-to-date - Concepts - My other lists

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:

There are some free books available, including:

Must-read articles

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

Books

Articles

- There is a list of the best articles in this Twitter Thread - Domain knowledge is more important than your coding skills - Code is secondary. Business value is first. - You work with uncertainty most of the time - Specialisation is for insects. - 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

Axioms

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

Courses

Topics

Accounting

Agentic coding

Algorithm and data structures

Other resources: Here are some useful & interesting algo & DS visualizations: Example implementations: Algorithms in distributed systems:

API design & development

General REST content:

Example guidelines: - AIP stands for API Improvement Proposal, which is a design document providing high-level, concise documentation for API development.

More specific topics:

- "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." - Events can unlock much-needed webhook features, like allowing your webhook consumers to replay or reset the position of their webhook subscription.

Attitude, habits, mindset

- 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 - 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 - 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. - 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. - 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. - The difference between successful people and really successful people is that really successful people say no to almost everything. - 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. - Start with a tiny task. Then ride its momentum. - The Most Important Coding Habits - Daily stretches - Take regular breaks - Don’t code late at night - Improve your coding environment
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
Good judgment comes from experience.
Experience comes from bad judgment.

Procrastination

- 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

Automation

Best practices

Beyond software engineering & random

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.

Business

Buy vs. Build

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

Career growth

- 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 - 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. - Read Books (and papers), not Blog Posts - Take responsibility for your career trajectory - 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 - 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. - Think critically and formulate well-reasoned arguments - Master the fundamentals - Focus on the user and all else will follow - Learn how to learn - 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 - 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." About senior engineers:

Choosing your next/first opportunity

Getting to Staff Eng

- 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. - Being visible - Additional resources on Staff-plus engineering

Characters sets

Chess

(yes - chess gets its own section :)

Clouds

Code reviews

- 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 - Another one on the same topic: The Code Review Pyramid - Responsibility over convention

Coding & code quality

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

Communication

See also the Writing section

- Lots of concrete advice and examples for short, medium and long-form writing

Compilers

Configuration

- Can't add comments - Excessive quotation and syntax noise - Using DC (declarative configuration) to control logic is often not a good idea. - Most modern config formats suck - Use a real programming language - 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)

Data analysis & data science

- Don’t share the raw data - Don’t share your methodology - Don’t include confidence intervals - Don’t challenge your own data

Databases

See also the SQL section.

Scaling databases:

Internals

NoSQL

- Read Consistency - From SQL to NoSQL - NoSQL Design for DynamoDB

Postgres

"Just use postgres":

Data formats

Data science/data engineering

- Data platforms based on the data lake architecture have common failure modes that lead to unfulfilled promises at scale. - 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.

Debugging

Also see the Incident Response section in this doc

- The real problem reveals itself when the technique becomes a part of a template. - Action items can be very distant from the root cause. - Related article: The Evolution of SRE at Google
  • The Infinite Hows criticizes the five whys method and advocates for a different set of questions to learn from the most from incidents.
- See also: Human errors: models and management - "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." - "Human error becomes a starting point, not a conclusion." (Dekker, 2009) - "When we ask 'how?', we’re asking for a narrative." - "When it comes to decisions and actions, we want to know how it made sense for someone to do what they did." - At each "why" step, only one answer will be selected for further investigation. Asking "how" encourage broader exploration. - "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) - "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) - Bounded rationality: rational individuals will
README truncated. View on GitHub
🔗 More in this category
public-apis
public-apis/public-apis
A collective list of free APIs
★ 447.8k
 EbookFoundation
EbookFoundation/free-programming-books
:books: Freely available programming books
★ 391.5k
 vinta
vinta/awesome-python
An opinionated list of Python frameworks, libraries, tools, and resources
★ 307.0k
 tensorflow
tensorflow/tensorflow
An Open Source Machine Learning Framework for Everyone
★ 196.3k
 donnemartin
donnemartin/system-design-primer
Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards.
★ 356.6k
 TheAlgorithms
TheAlgorithms/Python
All Algorithms implemented in Python
★ 222.5k
 NousResearch
NousResearch/hermes-agent
The agent that grows with you
★ 212.4k
 Significant-Gravitas
Significant-Gravitas/AutoGPT
AutoGPT is the vision of accessible AI for everyone, to use and to build on. Our mission is to provide the tools, so that you can focus on what matters.
★ 185.4k
 huggingface
huggingface/transformers
🤗 Transformers: the model-definition framework for state-of-the-art machine learning models in text, vision, audio, and multimodal models, for both inference and training.
★ 162.4k
 yt-dlp
yt-dlp/yt-dlp
A feature-rich command-line audio/video downloader
★ 176.2k
 langgenius
langgenius/dify
Production-ready platform for agentic workflow development.
★ 148.4k
 anthropics
anthropics/skills
Public repository for Agent Skills
★ 159.3k

© 2026 GitRepoTrend · charlax/professional-programming · Updated daily from GitHub