Programmer’s Reading List: 100 Technical Articles I Like (21-40)

roman-kraft-pOfLjZmvvaU-unsplash-1280.jp

Programmers are perhaps one of the most sharing groups on the internet, not only do they love to open source the software they write, they also love to share their knowledge by writing articles. Since I started my career, I’ve read a lot of technical articles, and some of them are great. Some of these articles have inspired me with their deep technical insights, while others have explained a technique in a masterful way like a butcher’s tool, which has made me feel very happy after reading them.

As one of those programmers who “love to share”, I want to be a referrer and share the good articles I read. I named this seriesThe Programmer’s Reading List: 100 of My Favorite Technical Articles.。

Limited by my own specialties and interests, the articles in the list are biased towards the following areas:Programmer’s Literacy, Software Engineering, Backend Development, Technical Writing, Python Language, Go Language。

Below is the second part of the reading list, containing articles 21 through 40.

Series Index:

list of items

21. Life is Short

Life is short, how exactly should you spend your time? Legendary investor and programmer Paul Graham gives his advice in this article. To summarize, there are 3: Do everything you can to avoid bullshit, such as useless meetings and online fights; Don’t procrastinate on important things, and realize that some things won’t be waiting for you forever; and Value every drop of time you have.

By any stretch of the imagination, none of the above suggestions can be called all that new. However, the author has infused the content with a different kind of soul by honestly sharing his own experiences and feelings. Maybe you’ll be like me and gain some new insights after reading it.

22. The “product-conscious” software engineer

The longer you work as a programmer, the odds are you’ll hear the term “product awareness” more and more often. Everyone says product awareness is good, but it’s out of sight, out of mind, so what exactly is it? Does it mean that programmers should draw their own wireframes? Or does it mean that programmers should write user stories?

The author of this article has made a comprehensive interpretation of “product awareness” from the perspective of a software engineer. Simply put, product awareness is to pay attention to the product, product curiosity, empathy for the user; product awareness of people in the technical program, not only think about the engineering perspective, but also rely on the overall “product + engineering” perspective to think about decision-making.

“Product awareness” – one of the most powerful levers of thinking for engineers.

23. “Python’s range is not an iterator”.

range is one of the most commonly used built-in objects in the Python language, with the function of producing a sequence of numbers such asrange(10) => 0, 1, ..., 9The iterator is an iterator that is often mistaken for an iterator. As a frequent visitor to iterations in loops, range is often mistaken for an iterator. However, as the title of the article suggests, range is not an iterator, even though it can be iterated over.

But what is range if not an iterator? In this article, the author answers this question with concise explanations and code snippets. What may seem like a lot of words, is actually quite important Python fundamental concepts.

? On the topic of iterators and iterable objects, I also highly recommend another piece I wrote myself:Python Craftsmanship, Chapter 6 6.1.1 “Iterators and Iterable Objects”。

24. All About TLS/SSL Certificates

A science article related to certificates.

This is a popular science article, but it’s not like other popular science articles. In addition to some light-hearted stories, you’ll be “surprised” by shell commands and large sections of pseudo-code that appear out of nowhere. Seemingly incongruous material, carefully orchestrated by the author, plays like a symphony orchestra, creating a beautiful and smooth piece of music that is a breath of fresh air to read.

25. Making Difficult Things Easy

Maybe it’s nonsense, but I still want to say: technical people generally have a “complexity worship” complex. When practicing a technology, one often steps into many potholes and encounters many difficulties, but most people don’t talk about it, as if complaining about the complexity of a technology makes them look incompetent.

This is especially true when the technologies are recognized as “basic” (e.g., DNS, HTTP). Technologists accept complexity, understand it, and eventually take it for granted.

That’s why I really like this share by Julia Evans. It points out that behind many of the so-called “basic techniques” there are so many complexities that are hard to grasp. Many people fall foul of them, but not all of them step forward to improve the status quo.

So, we need to make complex things easier. To address this, the article picks a few representative technologies, such as DNS, BASH, SQL, etc., and offers practical advice, including: share useful tools and reference documentation, sift through the big list of features you actually use, show what’s not visible, and more.

26. 《The Hiring Post》

The author works for a security company called Matasano. One day, he received a report describing a new attack technique against DSAs. Due to the complexity of the steps and the stringent conditions, the author considered the attack to be somewhat impractical and difficult to implement (time was measured in months). Nevertheless, he shared the report with the team (forgetting to mention “impractical”).

Two days later, a newcomer to the team named Alex approached him and said he had completed a working exploit program.

Alex was very good at what he did, but if you turn the clock back a few years, he wouldn’t have been recruited at all. His resume was mediocre, and the company relied on resumes and interviews to recruit talent. It wasn’t until later that Matasano optimized its recruiting strategy and uncovered more and more talent like Alex.

Continuing with the opening vignette, the author explores some of the problems with talent acquisition in the technology industry. For example, many highly competent candidates often fail interviews because the hiring process doesn’t make sense. In contrast, some people who are good at interviewing and can always talk about abstract concepts can easily get an offer, and the article gives some advice on how to address these issues, such as warming up the candidates, using test questions that are close to the workplace, and so on. It’s worth reading.

27. “How I Write HTTP Services in Go After 13 Years”.

A best practices article on the Go language, covering only the HTTP infrastructure in the standard library, and no other third-party web frameworks or libraries. The author has over ten years of Go programming experience.

In addition to showing specific techniques for writing and organizing code, the article also talks about some of the design considerations behind “why we do it this way”, including: functions with long parameter lists, request encoding and decoding processing, combining http.Handler with closures, E2E testing and unit testing, and so on. Handler with closures, E2E testing and unit testing, and so on. Through these considerations, we can feel the author’s many years of experience and wisdom.

28. “Rust std fs slower than Python!

A wonderful short detective story.

One day, Xuanwo received a report from a user about a strange case: a piece of file manipulation code in a Rust implementation of the Python SDK was executing slower than native Python code. After a bit of troubleshooting, something even worse happened: not only Rust, but even the same C code was slower than Python. But how can this be, when the Python language interpreter itself is written in C?

Like any great detective novel, at the end, when the suspense is pushed to its peak and the identity of the murderer is revealed, you say to yourself, “Unexpected and reasonable.”

29. Choosing Boring Technologies.

As technicians, we like to experiment with new technology, it makes us happy. But many times, “boring” technology is preferable to shiny new things.

When we find a technology “boring” and hate it, it’s because we know it too well to get anything new out of it (like Django for me). But don’t forget that this also means that we know every pitfall of the technology. Adopting it in our projects makes it easier for us to focus on core business issues.

I like the metaphor of “innovation tokens” in this article. “Innovation tokens” are a type of token used to handle creative tasks.finiteCapabilities. Assuming you have a total of 3 Innovation Tokens, how would you spend them? Perhaps innovation in the core functionality of a product requires more tokens than a novel technology stack.

30. Structured Pattern Matching in Python 3.10.

In version 3.10, Python added a new “structured pattern matching” syntax (match …). case). Because it looks very similar to the switch … case statement, many people think that “structured pattern matching” is switch in disguise. But in fact, it is quite different from the switch statement, and in the author’s words: it is better understood as “iterative unpacking”.

This article, published in 2021 (just before the release of Python 3.10), briefly describes the capabilities of Structured Pattern Matching and lists some of the code scenarios in which it is most useful. In the summary, the author takes a slightly pessimistic and complex view of the future of the syntax.

Of the articles related to Structured Pattern Matching, apart from a few PEPs, I think this is the one worth reading.

31. “You want modules, not microservices”.

The beginning of the article is interesting. From an article about microservices, the author extracts 10 advantages of microservice frameworks. He then analyzed them one by one and found that at least half of them could be applied to “modules” as they are.

“Focus on a small piece of code”, “independent development”, “versioning”, “independent release” –None of these capabilities are available in modules. By the way, the “modules” we are talking about here are the technical concepts that were born in the 1970s and are now standard in all programming languages.

After analyzing the similarities between modules and microservices, the article continues to layer in an attempt to answer an important question: what exactly is the essential paradox that microservices architectures address?

32. “I don’t like the default HTTP Handlers in Go”.

While writing HTTP handler functions, the authors realized that there was a design problem with these functions that would motivate people to write buggy code. The problem is one that most Go developers know about (and have probably committed): forgetting to return the response body after writing it back, causing the code to continue execution incorrectly. To optimize it, the authors propose an idea.

Technically, this is a very simple article, and the final solution is just “one more layer of encapsulation”. However, I like the author’s attention to detail, and I agree with the values of the article: optimizing tools and environments to eliminate the possibility of human error.

33. A More Human-Friendly Timeout and Cancellation

When doing network programming, “timeout configuration” is a very important but often overlooked detail. Improper timeout configuration is like a grain of sand in the sole of your shoe, at first you don’t even realize it exists, but as time accumulates, the sand will wear through the sole of your foot and cause great harm.

“As the most common way to configure timeouts, why is theget(url, timeout=10)Is this type of API not good enough?”

Starting from this problem, the author lists and analyzes some common timeout API designs, and finally describes in detail the features of the trio library. The author considers it to be a “more human-friendly” design.

34. “20 Years as a Software Engineer, 20 Things Learned”.

After 20 years in the business, software engineer Justin Etheredge looks back on his career and draws 20 lessons. They’re short, sweet, and insightful, and most of them resonated with me when I read them.

Take for example #5: “The best engineers think like designers”. There have been many times when I’ve gotten stuck on a problem and struggled to find an optimal solution. But when I change my mindset and learn to think like a designer from the user’s (or caller’s, or reliant’s) perspective, the answer comes to me. Take #9 for example: “You can never ask ‘why’ too many times” – curiosity and the desire to learn are the best catalysts for technical excellence.

35. Why Your Mock Doesn’t Work

When writing test code in Python, you often use the mock module. When you’re new to mock, many of you have encountered the problem that it doesn’t work. Obviously, usingmock.patch(...)The module is replaced, and the code executes with the original values.

This article by Ned Batchelder explains the “mock not working” problem in detail. Since it’s written about a common problem, the knowledge in the article may not be new to you. But even so, I highly recommend it. The article is clearly structured and accurately worded, and every schematic and code in it appears at just the right time. Even if not for the sake of learning knowledge, after skimming through it, it is soothing. There is a lot to be learned about technical writing.

Another article by the author is also recommended:Python Names and Values.The content is related to the mock article.

36. Practical Go: Real-World Advice for Writing Maintainable Go Programs.

There’s not a lot of “Go code readability” information on the Internet, and this is probably one of the best you’ll find.

This article contains dozens of comprehensive suggestions for improving the maintainability of Go code, covering a wide range of topics from variable naming to API design. What I like most about it, besides the quality of the writing, is that the author has carefully paired each suggestion with example code that makes the content very easy to read and digest. A dry classic that deserves to be read by every Go engineer.

37. Writing Systems Software: Code Commentary

This article by Redis author antirez is one of my favorites on the topic of code comments. By organizing all the comments in the redis project, antirez divides them into 9 categories, each with a different function.

This paper is unique in that it builds on the consensus of “explaining the ‘why?’ in code with annotations” and focuses on the less conventional “pedagogical/guidance annotations”. The article mentions that guideline annotations are the most common way to explain the ‘why? The article mentions that guideline comments are the most numerous comments in redis, and that they populate the entire project, and that they are credited with making the Redis source code readable.

In a way, this article influenced my coding habits. Looking back at it again, the old adage that people refer to over and over flashes through my mind, “Code is primarily written to be read, and incidentally executed by computers.”

38. Writing Code that’s Easy to Delete, Not Easy to Extend

There is a plain consensus among programmers that “duplicate code is bad, reuse code is good.” This article reflects on that consensus from a different perspective. People are so used to discussing the benefits of reuse that they tend to overlook its drawbacks: the more a piece of code is reused, the more it is coupled to more users, which naturally makes it harder to modify.

Once code is written, it needs to be maintained, and business development makes old code obsolete. Rethinking the maintainability of software projects with this in mind reveals that “easy to delete” becomes a good characterization of code. It may not be as easy to read as it sounds, but it is thought provoking.

39. How to Ask Good Questions

Asking good questions is a top skill in interpersonal communication (Rating: SSR✨). Asking a good question at a critical time can make communication twice as effective and things fall into place.

This article by Julia Evans encapsulates several lessons and tips related to questioning, such as: stating and confirming to the other person what you know about the current state of affairs; choosing who to ask questions to; making concepts that aren’t obvious enough clear by asking questions, and so on. Not only is the content good, but the writing style is as friendly, clear and easy to read as ever – highly recommended.

40. Writing Code Every Day

Programmer John Resig(JQuery library author)He has encountered an annoying problem. He wanted to complete some interest projects (side projects), but found it difficult to move forward while maintaining full-time productivity. He often spends every weekend frantically rushing to get more done, but the stress and anxiety are always so overwhelming that it’s hard to maintain his status.

One day, inspired by others, John decided to change his strategy:Write code every dayThe program was originally a hobby project that took an entire weekend to complete. What started out as an entire weekend devoted to a hobby project was now split up into every day, with no less than 30 minutes of programming. Six months later, he realized that the new strategy was working wonders, and he had achieved more than he bargained for: he had developed several new websites, rewritten several frameworks, and completed a large number of new modules. What’s more, the anxiety that once plagued him dissipated.

I love this article, it’s the programmer’s version of “Pawn of the Day” and John is a great role model.

结语

This is all part 2 of the Programmer’s Reading List, enjoy reading!

题图来源：Photo by Roman Kraft on Unsplash