Daily Productive Sharing 222 - A Reading List for Software Engineers

One helpful tip per day:)

(The English version follows)

#reading

今天的推荐是一份软件工程师的阅读推荐列表，哪怕没有时间一一读完，看看下面这些标题也很受用：

• Computers can be understood
• The Wrong Abstraction
• Falsehoods Programmers Believe About Names
• The Product-Minded Engineer
• Write code that is easy to delete, not easy to extend
• Repeat yourself, do more than one thing, and rewrite everything
• The Law of Leaky Abstractions
• Building Robust Systems with ACID and Constraints
• Transactionally Staged Job Drains in Postgres
• Implementing Stripe-like Idempotency Keys in Postgres
• Notes on Distributed Systems for Young Bloods
• End-to-End Arguments in System Design
• Inventing on Principle

如果你觉得今天分享有帮助，不妨把它分享给你的朋友

原链

Essays on programming I think about a lot

需要更棒的简历，不妨试试我们的 CV Consultation

如果你也想成为更高效的人，欢迎加入我们的 TG group

Today's recommendation is a list of recommended reading for software engineers. Even if you have no time to read them all, look at the following titles is also very useful:

• Computers can be understood
• The Wrong Abstraction
• Falsehoods Programmers Believe About Names
• The Product-Minded Engineer
• Write code that is easy to delete, not easy to extend
• Repeat yourself, do more than one thing, and rewrite everything
• The Law of Leaky Abstractions
• Building Robust Systems with ACID and Constraints
• Transactionally Staged Job Drains in Postgres
• Implementing Stripe-like Idempotency Keys in Postgres
• Notes on Distributed Systems for Young Bloods
• End-to-End Arguments in System Design
• Inventing on Principle

If you find today's sharing helpful, why not share it with your friends?

Link

Essays on programming I think about a lot

Need a superb CV, please try our CV Consultation

Excerpt

Nelson Elhage, Computers can be understood. The attitude embodied in this essay is one of the things that has made the biggest difference to my effectiveness as an engineer

Dan McKinley, Choose Boring Technology. When people ask me how we make technical decisions at Wave, I send them this essay. It’s probably saved me more heartbreak and regret than any other

Sandy Metz, The Wrong Abstraction. This essay convinced me that “don’t repeat yourself” (DRY) isn’t a good motto. It’s okay advice, but as Metz points out, if you don’t choose the right interface boundaries when DRYing up, the resulting abstraction can quickly become unmaintainable

Patrick McKenzie, Falsehoods Programmers Believe About Names. When programming, it’s helpful to think in terms of “invariants,” i.e., properties that we assume will always be true. I think of this essay as the ultimate reminder that reality has no invariants

Thomas Ptacek, The Hiring Post. This essay inspired me to put a lot of effort into Wave’s work-sample interview, and the payoff was huge—we hired a much stronger team, much more quickly, than I expected to be able to. It’s also a good reminder that most things that most people do make no sense

Gergely Orosz, The Product-Minded Engineer. I send this essay to coworkers all the time—it describes extremely well what traits will help you succeed as an engineer at a startup

tef, Write code that is easy to delete, not easy to extend. _The Wrong Abstraction_argues that reusable code, unless carefully designed, becomes unmaintainable. tef takes the logical next step: design for disposability, not maintainability. This essay gave me lots of useful mental models for evaluating software designs.

tef also wrote a follow-up, Repeat yourself, do more than one thing, and rewrite everything, that he thinks makes the same points more clearly—though I prefer the original because “easy to delete” is a unifying principle that made the essay hang together really well.

Joel Spolsky, The Law of Leaky Abstractions. Old, but still extremely influential—“where and how does this abstraction leak” is one of the main lenses I use to evaluate designs:

Reflections on software performance by Nelson Elhage, the only author of two different essays in this list! Nelson’s ideas helped crystallize my philosophy of tool design, and contributed to my views on impatience.

Brandur Leach’s series on using databases to ensure correct edge-case behavior: Building Robust Systems with ACID and Constraints, Using Atomic Transactions to Power an Idempotent API, Transactionally Staged Job Drains in Postgres, Implementing Stripe-like Idempotency Keys in Postgres.

Jeff Hodges, Notes on Distributed Systems for Young Bloods. An amazing set of guardrails for doing reasonable things with distributed systems (and note that, though you might be able to get away with ignoring it for a while, any app that uses the network is a distributed system). Many points would individually qualify for this list if they were their own article—I reread it periodically and always notice new advice that I should have paid more attention to.

J.H. Saltzer, D.P. Reed and D.D. Clark, End-to-End Arguments in System Design. Another classic. The end-to-end principle has helped me make a lot of designs much simpler.

Bret Victor, Inventing on Principle