目录
master
分支1
标签0
+ 疑修
Web IDE
Charles-Axel Dein
Add error and simplicity articles
1个月前481次提交
README.md

Table of Contents

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

  • 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

Books

Articles

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

Topics

Accounting

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:

More specific topics:

Attitude, habits, mindset

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

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

  • 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

Career growth

About senior engineers:

Choosing your next/first opportunity

Getting to Staff Eng

Characters sets

Chess

(yes - chess gets its own section :)

Clouds

Code reviews

Coding & code quality

Communication

See also the Writing section

Compilers

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)

Data analysis & data science

Databases

See also the SQL section.

Scaling databases:

NoSQL

Postgres

“Just use postgres”:

Data formats

Data science/data engineering

Debugging

Also see the Incident Response section in this doc

Design (visual, UX, UI, typography)

I highly recommend reading The Non-Designer’s Design Book. This is a pretty short book that will give you some very actionable design advices.

Articles :

Typograhy: see “Typography” section

Resources:

Design (OO modeling, architecture, patterns, anti-patterns, etc.)

Here’s a list of good books:

One of the absolute references on architecture is Martin Fowler: checkout his Software Architecture Guide.

Articles:

  • O’Reilly’s How to make mistakes in Python
  • Education of a Programmer: a developer’s thoughts after 35 years in the industry. There’s a particularly good section about design & complexity (see “the end to end argument”, “layering and componentization”).
  • Domain-driven design, Wikipedia.
  • On the Spectrum of Abstraction 🎞, Cheng Lou
  • The “Bug-O” Notation, Dan Abramov
  • Antipatterns
  • Inheritance vs. composition: a concrete example in Python. Another slightly longer one here. One last one, in Python 3.
  • Composition Instead Of Inheritance
  • Complexity and Strategy: interesting perspective on complexity and flexibility with really good examples (e.g. Google Apps Suite vs. Microsoft Office).
  • The Architecture of Open Source Applications
  • The Robustness Principle Reconsidered
    • Jon Postel: “Be conservative in what you do, be liberal in what you accept from others.” (RFC 793)
    • Two general problem areas are impacted by the Robustness Principle: orderly interoperability and security.
  • Basics of the Unix Philosophy, Eric S Raymond
  • Eight Habits of Expert Software Designers: An Illustrated Guide
  • No Silver Bullet - Essence and Accident in Software Engineering, Frederick P. Brooks, Jr. (1986)
    • There are four properties of software systems which make building software hard: Complexity, Conformity, Changeability and Invisibility
    • There are ways to address this:
      • Exploiting the mass market to avoid constructing what can be bought. (“Buy vs. Build”)
      • Using rapid prototyping as part of a planned iteration in establishing software requirements.
      • Growing software organically, adding more and more function to systems as they are run, used, and tested
      • Identifying and developing the great conceptual designers of the rising generation.
      • (also included in The Mythical Man-Month)
  • Out of the Tar Pit, Ben Moseley, Peter Marks (2006) introduces the distinction between essential and accidental complexity
    • Complexity is the root cause of the vast majority of problems with software today. Unreliability, late delivery, lack of security — often even poor performance in large-scale systems can all be seen as deriving ultimately from unmanageable complexity.
    • Quoting Djikstra: “testing is hopelessly inadequate….(it) can be used very effectively to show the presence of bugs but never to show their absence.”
    • Functional programming goes a long way towards avoiding the problems of state-derived complexity, thanks to immutability and clear separation of state and logic.
  • A Note on Essential Complexity
    • The goal of the software engineer is to minimize accidental complexity and assist with essential complexity.
  • Software Design is Knowledge Building
    • Programming should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand. This suggestion is in contrast to what appears to be a more common notion, that programming should be regarded as a production of a program and certain other texts.
    • The building of the program is the same as the building of the theory of it by the team of programmers.
  • Cognitive load is what matters
    • A well-crafted monolith with truly isolated modules is often much more flexible than a bunch of microservices.
    • Three decades on, microkernel-based GNU Hurd is still in development, and monolithic Linux is everywhere
    • “Reduce cognitive load by limiting the number of choices.” (Rob Pike)
    • The same rule applies to all sorts of numeric statuses (in the database or wherever) - prefer self-describing strings.
    • With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. (Hyrum’s Law)
    • DDD is about problem space, not about solution space.
    • Familiarity is not the same as simplicity
    • The more mental models there are to learn, the longer it takes for a new developer to deliver value.
  • CUPID: for joyful coding
    • Composable: plays well with others
    • Unix philosophy: does one thing well
    • Predictable: does what you expect
    • Idiomatic: feels natural
    • Domain-based: the solution domain models the problem domain in language and structure
  • Nobody Gets Promoted for Simplicity

“Simplicity is a great virtue, but it requires hard work to achieve and education to appreciate. And to make matters worse, complexity sells better.” — Edsger Dijkstra

You can use an eraser on the drafting table or a sledge hammer on the construction site. (Frank Lloyd Wright)

Resources:

Design: database schema

  • A humble guide to database schema design, Mike Alche
    • Use at least third normal form
    • Create a last line of defense with constraints
    • Never store full addresses in a single field
    • Never store firstname and lastname in the same field
    • Establish conventions for table and field names.
  • YAGRI: You are gonna read it: store created_at, created_by etc.

Design: patterns

Design: simplicity

  • Simple Made Easy 🎞, Rich Hickey. This is an incredibly inspiring talk redefining simplicity, ease and complexity, and showing that solutions that look easy may actually harm your design.

Dev environment & tools

Tools

Article about tools:

  • The return of fancy tools
    • Simple tools make you think a little more
    • Drucker: “I’m not writing it down to remember it later, I’m writing it down to remember it now.”
    • Frictionless note-taking produces notes, but it doesn’t produce memory.

Docker

See also the Python-specific section in charlax/python-education.

  • Best Practices Around Production Ready Web Apps with Docker Compose
    • Avoiding 2 Compose Files for Dev and Prod with an Override File
    • Reducing Service Duplication with Aliases and Anchors
    • Defining your HEALTHCHECK in Docker Compose not your Dockerfile
    • Making the most of environment variables
    • Using Multi-stage builds to optimize image size
    • Running your container as a non-root user
  • Docker Best Practices for Python Developers
    • Use multi-stage builds
    • Pay close attention to the order of your Dockerfile commands to leverage layer caching
    • Smaller Docker images are more modular and secure (watch out for Alpine though)
    • Minimize the number of layers (RUN, COPY, ADD)
    • Use unprivileged containers
    • Prefer COPY over ADD
    • Cache python packages to the docker host
    • Prefer array over string syntax
    • Understand the difference between ENTRYPOINT and CMD
    • Include a HEALTHCHECK instruction
    • Whenever possible, avoid using the latest tag.
    • Don’t store secrets in images
    • Use a .dockerignore file (include **/.git, etc.)
    • Lint and Scan Your Dockerfiles and Images (e.g. with hadolint)
    • Log to stdout or stderr
  • Docker Containers Security

Documentation

The palest ink is more reliable than the most powerful memory. – Chinese proverb

Dotfiles

Articles

Editors & IDE

Vim

Feel free to check my vim configuration and my vim cheatsheet.

Other editors:

Email

Engineering management

Checkout my list of management resources.

Exercises

The best way to learn is to learn by doing.

Practice:

Experimentation

Functional programming (FP)

  • Goodbye, Object Oriented Programming
  • Functional Programming & Haskell 🎞: some good reasons to learn FP!
  • Functional Programming Fundamentals: short introduction to FP and its advantages.
  • OO vs FP, Robert C. Martin, The Clean Code Blog. A pretty interesting take on the differences between OOP and FP from an expert in OOP.
    • OO is not about state. Objects are bags of functions, not bags of data.
    • Functional Programs, like OO Programs, are composed of functions that operate on data.
    • FP imposes discipline upon assignment.
    • OO imposes discipline on function pointers.
    • The principles of software design still apply, regardless of your programming style. The fact that you’ve decided to use a language that doesn’t have an assignment operator does not mean that you can ignore the Single Responsibility Principle.
  • Parse, don’t validate
    • Use a data structure that makes illegal states unrepresentable
    • Push the burden of proof upward as far as possible, but no further
    • Let your datatypes inform your code, don’t let your code control your datatypes
    • Don’t be afraid to parse data in multiple passes
    • Avoid denormalized representations of data, especially if it’s mutable
    • Use abstract datatypes to make validators “look like” parsers
  • 🏙 Functional Programming
  • Monads in 15 minutes
  • hemanth/functional-programming-jargon: jargon from the functional programming world in simple terms
  • The definitive guide to learning functional programming, Exercism

Games development

Graphics

Hardware

HTTP

Humor

Incident response (oncall, alerting, outages, firefighting, postmortem)

Also see this section on my list of management resources, “Incident response”.

Also see the Debugging section in this doc.

Alerting:

  • My Philosophy On Alerting
    • Pages should be urgent, important, actionable, and real.
    • Err on the side of removing noisy alerts – over-monitoring is a harder problem to solve than under-monitoring.
    • Symptoms are a better way to capture more problems more comprehensively and robustly with less effort.
    • Include cause-based information in symptom-based pages or on dashboards, but avoid alerting directly on causes.
    • The further up your serving stack you go, the more distinct problems you catch in a single rule. But don’t go so far you can’t sufficiently distinguish what’s going on.
    • If you want a quiet oncall rotation, it’s imperative to have a system for dealing with things that need timely response, but are not imminently critical.
    • This classical article has now become a chapter in Google’s SRE book.
  • 🏙 The Paradox of Alerts: why deleting 90% of your paging alerts can make your systems better, and how to craft an on-call rotation that engineers are happy to join.

Postmortem

“Let’s plan for a future where we’re all as stupid as we are today.”

– Dan Milstein

Example outline for a postmortem:

  • Executive Summary
    • Impact
    • Root cause
  • Impact
    • Number of impacted users
    • Lost revenue
    • Duration
    • Team impact
  • Timeline
    • Detection
    • Resolution
  • Root cause analysis
    • E.g. with 5 whys method
  • Lessons learned
    • Things that went well
    • Things that went poorly
  • Action items (include direct links to task tracking tool)
    • Tasks to improve prevention (including training)
    • Tasks to improve detection (including monitoring and alerting)
    • Tasks to improve mitigation (including emergency response)

Internet

Interviewing

Note: this is about you as an interviewee, not as an interviewer. To check out my list of resources for interviewers, go to my engineering-management repository.

Questions you should ask:

Résumé:

See also the exercises section in this document.

Kubernetes

Large Language Model (LLM)

Learning & memorizing

Learn how to learn!

About flashcards:

About Zettelkasten and PKM (personal knowledge management): see Personal knowledge management

Richard Feynman’s Learning Strategy:

  1. Step 1: Continually ask “Why?”
  2. Step 2: When you learn something, learn it to where you can explain it to a child.
  3. Step 3: Instead of arbitrarily memorizing things, look for the explanation that makes it obvious.

Most people overestimate what they can do in 1 year and underestimate what they can do in a decade. – Bill Gates

Frankly, though, I think most people can learn a lot more than they think they can. They sell themselves short without trying. One bit of advice: it is important to view knowledge as sort of a semantic tree — make sure you understand the fundamental principles, ie the trunk and big branches, before you get into the details/leaves or there is nothing for them to hang on to. — Elon Musk

“Experience is something you don’t get until just after you need it.” ― Steven Wright

Tell me and I forget. Teach me and I remember. Involve me and I learn. – Benjamin Franklin

Education is the kindling of a flame, not the filling of a vessel. – Socrates

That which we persist in doing becomes easier for us to do; not that the nature of the thing itself is changed, but that our power to do is increased. – Ralph Waldo Emerson

A wise man can learn more from a foolish question than a fool can learn from a wise answer. – Bruce Lee

A lecture has been well described as the process whereby the notes of the teacher become the notes of the student without passing through the mind of either. — Mortimer Adler

Fools learn from experience. I prefer to learn from the experience of others. — Bismark

Linux (system management)

Low-code/no-code

Low-level, assembly

Machine learning/AI

Math

Marketing

Network

Observability (monitoring, logging, exception handling)

See also: Site Reliability Engineering (SRE)

Logging

  • Do not log dwells on some logging antipatterns.
    • Logging does not make much sense in monitoring and error tracking. Use better tools instead: error and business monitorings with alerts, versioning, event sourcing.
    • Logging adds significant complexity to your architecture. And it requires more testing. Use architecture patterns that will make logging an explicit part of your contracts
    • Logging is a whole infrastructure subsystem on its own. And quite a complex one. You will have to maintain it or to outsource this job to existing logging services
  • Lies My Parents Told Me (About Logs)
    • Logs are cheap
    • I can run it better myself
    • Leveled logging is a great way to separate information
    • Logs are basically the same as events
    • A standard logging format is good enough
  • Logging - OWASP Cheat Sheet Series
  • The Audit Log Wall of Shame: list of vendors that don’t prioritize high-quality, widely-available audit logs for security and operations teams.
  • Guide on Structured Logs
  • What an error log level should mean
  • Logging Sucks - Your Logs Are Lying To You

Error/exception handling

Metrics

  • Meaningful availability
    • A good availability metric should be meaningful, proportional, and actionable. By “meaningful” we mean that it should capture what users experience. By “proportional” we mean that a change in the metric should be proportional to the change in user-perceived availability. By “actionable” we mean that the metric should give system owners insight into why availability for a period was low. This paper shows that none of the commonly used metrics satisfy these requirements…
  • 📃 Meaningful Availability paper.
    • This paper presents and evaluates a novel availability metric: windowed user-uptime

Monitoring

Open source

Operating system (OS)

Over-engineering

  • 10 modern software over-engineering mistakes
  • A good example of over-engineering: the Juicero press (April 2017)
  • You Are Not Google: the UNPHAT method to avoid cargo cult.
    • Don’t even start considering solutions until you Understand the problem. Your goal should be to “solve” the problem mostly within the problem domain, not the solution domain.
    • eNumerate multiple candidate solutions. Don’t just start prodding at your favorite!
  • Overthinking
    • 1st poison: education.
    • 2nd poison: marketing.
    • 3rd poison: ego
    • Solution: Stop trying to connect all the dots ahead of time. Embrace uncertainty and start doing.
  • Don’t Let Architecture Astronauts Scare You, Joel
    • Sometimes smart thinkers just don’t know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don’t actually mean anything at all.
    • Your typical architecture astronaut will take a fact like “Napster is a peer-to-peer service for downloading music” and ignore everything but the architecture, thinking it’s interesting because it’s peer to peer, completely missing the point that it’s interesting because you can type the name of a song and listen to it right away.

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.”

— John Gall, General systemantics, an essay on how systems work, and especially how they fail…, 1975 (this quote is sometime referred as “Galls’ law”)

“Software engineering is what happens to programming when you add time and other programmers.”

— Rob Pike, Go at Google: Language Design in the Service of Software Engineering

You can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something — your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.

— Steve Jobs

Performance

Personal knowledge management (PKM)

Personal productivity

Check out this section on my list of management resources, “Personal productivity”.

Perspective

  • At 31, I have just weeks to live. Here’s what I want to pass on
    • First, the importance of gratitude.
    • Second, a life, if lived well, is long enough.
    • Third, it’s important to let yourself be vulnerable and connect to others.
    • Fourth, do something for others.
    • Fifth, protect the planet.
  • Life Is Not Short
    • “The most surprising thing is that you wouldn’t let anyone steal your property, but you consistently let people steal your time, which is infinitely more valuable.” — Seneca

Privacy

Problem solving

Product management for software engineers

See the Product management section on my entrepreneurship-resources list of resources.

Project management

See the Project management section on my engineering-management list of resources.

Programming languages

I would recommend learning:

  • JavaScript and maybe another interpreted language (Python, Ruby, etc.). Interpreted languages are useful for quick one-off automation scripts, and fastest to write for interviews. JavaScript is ubiquitous.
  • A compiled language (Java, C, C++…).
  • A more recent language to see where the industry is going (as of writing, Go, Swift, Rust, Elixir…).
  • A language that has first-class support for functional programming (Haskell, Scala, Clojure…).

A bit more reading:

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

– Bjarne Stroustrup (C++ creator)

List of resources:

Python

For Python check out my professional Python education repository.

JavaScript

In this repository: check ./training/front-end/

JavaScript is such a pervasive language that it’s almost required learning.

Garbage collection

Programming paradigm

Public speaking (presenting)

Reading

Refactoring

  • The Rule of Three, Coding Horror
    • Every programmer ever born thinks whatever idea just popped out of their head into their editor is the most generalized, most flexible, most one-size-fits all solution that has ever been conceived.
    • It is three times as difficult to build reusable components as single use components.
    • A reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.
  • Refactor vs. Rewrite
  • Tripping over the potholes in too many libraries
  • Build It Yourself
    • It’s 2025 and it’s faster for me to have ChatGPT or Cursor whip up a dependency free implementation of these common functions, than it is for me to start figuring out a dependency.
  • Refactoring with Codemods to Automate API Changes, martinfowler.com

Regex

Releasing & deploying

Versioning

Checklists

Feature flags

Testing in production

  • Why We Leverage Multi-tenancy in Uber’s Microservice Architecture
  • Developing in Production
    • Complex systems have emergent behavior, producing epiphenomenon that only appears with sufficient scale.
    • Wood’s theorem: As the complexity of a system increases, the accuracy of any single agent’s own model of that system decreases rapidly.
    • The more tools and code that you add to create elements in a system, the harder it is to replicate an environment encompassing those tools and code.
    • At the core of testing in production is the idea of splitting deployments (of artifacts) from releases (of features).
  • Testing in Production: the hard parts, Cindy Sridharan
    • The whole point of [actual] distributed systems engineering is you assume you’re going to fail at some point in time and you design the system in such a way that the damage, at each point is minimized, that recovery is quick, and that the risk is acceptably balanced with cost.
    • How can you cut the blast radius for a similar event in half?
      • Differentiate between deployment (0 risk) and release
      • Build a deploy-observe-release pipeline
      • Make incremental rollouts the norm (canaries, %-based rollouts, etc.)
      • Test configuration changes just like you test code
      • Default to roll back, avoid fixing forward (slow!)
      • Eliminate gray failures - prefer crashing to degrading in certain cases
      • Prefer loosely coupled services at the expense of latency or correctness
      • Use poison tasters (isolate handling of client input)
      • Implement per-request-class backpressure
      • Have proper visibility from a client/end-user standpoint (client-side metrics)
  • Testing in Production, the safe way
  • Multi-Tenancy in a Microservice Architecture

Reliability

See also System architecture

Books:

  • 📖 Site Reliability Engineering, Google
    • Written by members of Google’s SRE team, with a comprehensive analysis of the entire software lifecycle - how to build, deploy, monitor, and maintain large scale systems.
  • 📖 Incident Metrics in SRE, Štěpán Davidovič, Google
    • Canonical definition of TTD (Time To Detect) TTM (Mitigate), TTR (Recover), TBF (Time Between Failure)

Quotes:

Quality is a snapshot at the start of life and reliability is a motion picture of the day-by-day operation. – NIST Reliability is the one feature every customer users. – An auth0 SRE.

Articles:

Resources:

Integration patterns (dependency management)

Resiliency

Security

Training for developers:

List of resources:

Research papers

Shell (command line)

SQL

State

  • A Map of Sync categorizes state sync into 9 dimensions.
    • Data model:
      • Size: How large is the data set that a single client can access?
      • Update rate: How often do clients send updates?
      • Structure: Is the data rich with structure or flat and unstructured?
    • Systems requirements:
      • Input latency: How long can updates be delayed while maintaining a good user experience?
      • Offline: How many interactions does the app need to support offline?
      • Concurrent clients: How many concurrent clients will look at the same data?
    • Programming model:
      • Centralization: How centralized is the programming model and infrastructure? Flexibility: How flexible are sync policies, especially around conflict resolution?
      • Consistency: What types of invariants can the application assert about its data model, and how strong can these invariants be?

System administration

System architecture

See also Reliability, Scalability

Reading lists:

Blogs:

  • High Scalability: great blog about system architecture, its weekly review article are packed with numerous insights and interesting technology reviews. Checkout the all-times favorites.

Books:

Articles:

Architecture patterns

Microservices/splitting a monolith

Scalability

See also: Reliability, System architecture

Site Reliability Engineering (SRE)

See: Reliability

Technical debt

  • TechnicalDebt, Martin Fowler.
  • Fixing Technical Debt with an Engineering Allocation Framework
    • You don’t need to stop shipping features to fix technical debt
    • Communicate the business value
  • Ur-Technical Debt
    • Today, any code that a developer dislikes is branded as technical debt.
    • Ward Cunningham invented the debt metaphor to explain to his manager that building iteratively gave them working code faster, much like borrowing money to start a project, but that it was essential to keep paying down the debt, otherwise the interest payments would grind the project to a halt.
    • Ur-technical debt is generally not detectable by static analysis.
  • 3 Kinds of Good Tech Debt

Testing

Why test:

  • Why bother writing tests at all?, Dave Cheney. A good intro to the topic.
    • Even if you don’t, someone will test your software
    • The majority of testing should be performed by development teams
    • Manual testing should not be the majority of your testing because manual testing is O(n)
    • Tests are the critical component that ensure you can always ship your master branch
    • Tests lock in behaviour
    • Tests give you confidence to change someone else’s code

How to test:

Test pyramid:

End-to-end tests:

Tools

The future life expectancy of some non-perishable things, like a technology or an idea, is proportional to their current age — Lindy’s Law

Type system

  • Counterexamples in Type Systems: a library of runtime issues that weren’t caught by the type system
  • Use Your Type System
    • Your models should each have their own ID type. Public and even private functions should often avoid dealing in floats or integers alone.

Typography

Version control (Git)

Learning Git, courses and books:

Cheat sheets:

More specific topics:

Work ethics, productivity & work/life balance

Check out this section on my list of engineering-management resources, “Personal productivity”.

Web development

In this repository: check training/web-dev/ and ./training/front-end/

Learning guide and resources:

Topics:

URLs:

  • The Great Confusion About URIs
    • A URI is a string of characters that identifies a resource. Its syntax is <scheme>:<authority><path>?<query>#<fragment>, where only <scheme> and <path> are mandatory. URL and URN are URIs.
    • A URL is a string of characters that identifies a resource located on a computer network. Its syntax depends on its scheme. E.g. mailto:billg@microsoft.com.
    • A URN is a string of characters that uniquely identifies a resource. Its syntax is urn:<namespace identifier>:<namespace specific string>. E.g. urn:isbn:9780062301239
  • Examples of Great URL Design
  • Four Cool URLs - Alex Pounds’ Blog
  • Your URL Is Your State

Writing (communication, blogging)

➡️ See also my engineering-management list

Guides & classes about technical writing:

Write like an Amazonian

If you’re overthinking, write. If you’re underthinking, read. – @AlexAndBooks_

Resources & inspiration for presentations

Keeping up-to-date

Website and RSS feeds (I use Feedly):

Security:

Newsletters:

Blogs:

Concepts

Glossary

My other lists

关于
pythonhtml
README.md
4.8 MB
邀请码
    Gitlink（确实开源）
  • 加入我们
  • 官网邮箱：gitlink@ccf.org.cn
    • QQ群
  • QQ群
    • 公众号
  • 公众号

版权所有：中国计算机学会技术支持：开源发展技术委员会
京ICP备13000930号-9 京公网安备 11010802032778号