A Programmer's Reading List: 100 Articles I Enjoyed (1-50)

Posted in 2025-03-29

Programmers are perhaps one of the most sharing groups on the internet. Not only do they like to open source their software, but they also like to share their knowledge by writing articles. Since I started my career, I have read many technical articles, including some outstanding works. Some of them have inspired me with profound technical insights, while others have explained a technology with exceptional skill, leaving me thoroughly impressed.

As one of those programmers who loves to share, I'd like to act as a recommender and share some great articles I've read with everyone. I've named this series "A Programmer's Reading List: 100 Articles I Enjoyed".

Due to my professional background and interests, the articles in the list focus on the following areas: general programming knowledge, software engineering, backend development, technical writing, Python, Go. 

Below is the first part of the reading list, containing articles 1 to 50.

Index:

The list

1. "10 Things Software Developers Should Learn about Learning"

Learning is important for everyone, especially software developers. This article explores key concepts about "learning", beginning with an explanation of how human memory works, and progressing to topics such as the differences between experts and novices, and the importance of spaced repetition.

The article offers some thought-provoking insights. For example, the concept of "abstract and concrete": new knowledge is initially abstract to beginners, becomes concrete through numerous examples, and becomes abstract again when fully mastered. It also challenges the notion that solving puzzles correlates with programming ability, which contradicts the common belief that "smarter people are better at programming".

2. "Managing My Motivation, as a Solo Dev"

The author, an independent developer, shares insights on managing self-motivation. The article offers many practical tips for improving self-motivation, such as:

  • Creating a bot to remind you of new software subscriptions - an external motivator;
  • Pausing at 90% completion of daily development tasks and leaving the rest for the next day - creating anticipation;
  • To avoid being overwhelmed by the guilt of "achieving nothing today," starting with high-output tasks before moving on to others.

3. "One Billion Row Challenge in Golang - From 95s to 1.96s"

A very good article on Go language performance tuning covers these topics: file reading performance tuning, producer-consumer model tuning, channel vs. mutex, custom hash algorithms, etc.

The author's thought process, the toolchain used, and the optimization methods are very standardized, and the whole tuning process is progressive. The article is also very well written. It is well worth reading.

4. "Is High Quality Software Worth the Cost?"

For most things, the pursuit of higher quality inevitably leads to higher costs, but is this also true for software? Martin Fowler divides software quality into two categories: external and internal.

Since the internal quality of software is difficult for outsiders to perceive, the cost of improving internal quality is often questioned. However, investing in internal quality does not increase costs; in fact, it can reduce overall costs. The article explains why this is the case through a detailed analysis and comparison.

5. "The Wrong Abstraction"

If you want to build a building, if the foundation is not solid, you will end up with a crooked and flawed structure. In programming, abstraction is the foundation, and good abstraction is the prerequisite for all good things.

This article explores the relationship between reuse and abstraction, and the author insightfully points out a fact: the fear of "sunk costs" often breeds wrong abstractions, which in turn leads to the deterioration of project quality.

A short and powerful classic not to be missed.

6. "Google technical writing courses: Writing Helpful Error Messages"

In software development, error messages are a very subtle presence. Poor error messages are frustrating and are a constant reminder that "the devil is in the details."

In response, the Google team offers recommendations for writing error messages, including: be descriptive, providing solutions, writing for the target audience, writing in the right tone, and so on. I think this should be an essential lesson for every programmer.

7. "Inside python dict — an explorable explanation"

It's no exaggeration to say that there are a plethora of articles online that introduce the internals of Python dictionaries. However, this one is quite special, mainly because of the "explorable" aspect in the title.

In the article, the author simulates the dictionary data type with some Python code. These codes can be clicked to execute on the page, and the process is fully visualized. For example, when a hash collision occurs in the dictionary, there's a very detailed animation that looks fascinating.

8. "Willingness to look stupid"

People naturally care about other people's opinions, and everyone hopes to be seen as a "smart person" rather than a "fool". However, the author of this article shares an uncommon perspective: Doing things that make you look stupid has more upsides than downsides. For instance, asking stupid questions often leads to a deeper understanding of things; learning in ways that others consider stupid is more effective.

9. "Why we're sticking with Ruby on Rails"

Most of the code for the well-known open source software GitLab is contained in a monolithic Rails project. GitLab uses a "modular monolith" architecture instead of the more trendy microservices architecture. The author explains in the article why GitLab chose this path: "Microservices architecture introduces accidental complexity, but does little to reduce essential complexity.

I strongly agree with a sentence in the article: Architecture follows needs, not the other way around.

10. "ChatGPT Is a Blurry JPEG of the Web"

This article was published on the verge of the big language model explosion: GPT-3.5 had already been released, and GPT-4 was about to emerge. Although the main tone of the article is somewhat negative (with reason), the numerous brilliant analogies and the author's beautiful prose are truly admirable. You may not agree with the author's views on large models, but it's hard not to be moved by the profound insights expressed throughout.

As I read this article, I kept wondering, "How can this be written so well?" I scrolled to the top of the page and carefully checked the author's name - the mystery was revealed: "No wonder, the author is Ted Chiang!"

Note: Ted Chiang is a contemporary American science fiction writer whose work has won multiple awards, including the Nebula Award and the Hugo Award.

11. "Lessons learned reinventing the Python notebook"

An article summarizing product design. The focus of the article is marimo—a Python notebook software similar to Jupyter. The content of this article includes: how to use directed acyclic graphs to ensure that notebooks are always reproducible; why simple design with strong constraints is superior to complex design with weak constraints, and more.

I love reading this kind of article because excellent product design lessons written by technical people are as rare as pearls.

12. "Breakpoint Tracking is an Inefficient Debugging Method(Chinese)"

I used to think that programming was like solving math problems, where different people's solutions might be slightly different, but ultimately lead to the same destination. In the past two years, however, I've discovered that programming is more like painting or writing, where each person following their own path.

The title of this article may be a bit startling, but if you read it carefully, you can actually sense a unique programming wisdom-a kind of philosophical thought from a programmer with decades of experience.

13. "Being Glue"

In addition to coding, a software engineer's daily tasks include many other responsibilities, such as writing documents and optimizing toolchains, which the author collectively calls "glue work."

Although glue work may seem minor, it is essential to the success or failure of a project. The article highlights an overlooked fact: engineers who do more glue work are often less likely to be promoted, despite their responsibilities. The author offers some practical advice on this issue.

14. "Embrace the Grind"

The article begins with a magic trick reveal, leading into the author's story of how he saved the entire development team by embracing the grinds. This is interwoven with reflections on the programmer's saying "laziness is a programmer's virtue."

Rereading this article, I was reminded of a phrase I recently came across in a book: "Amateurs seek immediate feedback and a sense of accomplishment, while professionals keep going even when things become tedious."

15. "It's probably time to stop recommending Clean Code"

As a classic book, "Clean Code" has long appeared on various programming book lists. However, the author of this article finds that much of the content in this book, published over a decade ago, is outdated, and many of its code examples are of poor quality.

In this article, the author performs an almost "brutal" code review of some Java code snippets from the book. The article's points of view are somewhat controversial, but they have valid reasons.

16. "What I think about when I edit"

As a professional technical writer, author Eva often helps others edit technical documents. Over time, she has summarized 9 editing suggestions, such as clarifying the topic of the article and justifying repetition.

As you read this article. You will easily notice that although the article is rich in information, it reads very smoothly and comfortably - I think this is the magic that excellent "editing" brings.

The title of the article is rather grand, but it's actually just a short essay, with the Python sample code being no more than 10 lines.

During a hackathon, the author and his colleagues discovered a memory leak issue in the py-amqp library. After submitting a PR, they discovered similar issues in popular libraries such as redis-py. The problem is related to Python's try/except blocks and can be quite deceptive.

18. "Principles of User Interface Design"

The article summarizes 19 principles of UI design, including "Clarity is job #1", "Keep users in control", and "Progressive disclosure". My favorite is the 17th principle: "Great design is invisible," which reminds me of some excellent open source software libraries.

Although labeled UI design, these principles are not exclusive to designers; I believe everyone can benefit from them. As programmers, we are essentially doing UI design every time we write a new function.

19. "Your Database Skills Are Not 'Good to Have'"

In the article, author Andrei first tells a story from 20 years ago: clever use of MySQL to meet a challenging business need. He then introduces the theme of the article: today, the focus on database skills should not be overlooked.

I agree with the author's views on relational databases and tools like ORM. Sometimes when projects encounter performance problems, simply adding an index or optimizing the query can solve the problem, yet many people are quick to suggest: "Let's cache! Switch the DB!"—which is often unnecessary.

20. "Software Estimation Is Hard. Do It Anyway."

In software development, time estimation is a headache. We've all had similar experiences: a task we confidently promised to complete in 3 days ended up taking more than two weeks.

Eventually, time estimation became a tedious game of deciding whether to allow for a 1X or 2X buffer. But as the title of this article suggests, estimating development time, while difficult, is unavoidable. This series of articles provides some related tips that I believe can inspire you.

21. "Life Is Short"

Given the brevity of life, how should we spend our time? The legendary investor and programmer Paul Graham offers his advice in an article. In summary, there are three points: try to avoid bullshit activities like pointless meetings and online arguments; don't put off important things, acknowledging that some things won't wait for you indefinitely; and value every moment of your time.

From any perspective, this advice isn't particularly groundbreaking. However, by sincerely sharing his own experiences and feelings, the author brings a unique depth to the content. Perhaps, like me, you'll gain some new insights after reading it.

22. "The Product-Minded Software Engineer"

The longer you work as a programmer, the more you'll likely hear the term "product-minded." Everyone praises product mindset, but what is this elusive concept? Does it mean that programmers should design wireframes or write user stories?

The author of this article offers a broad interpretation of "product-minded" from a software engineer's perspective. Simply put, being product-minded means focusing on the product, being curious about it, and having empathy for the user. Those with product mindset not only take the engineering aspects into account, but also think from a combined "product + engineering" perspective when making decisions.

"Product mindset" - one of the most powerful cognitive tools for engineers.

23. "Python: range is not an iterator"

range is one of the most commonly used built-in objects in Python, designed to produce a sequence of numbers, such as range(10) => 0, 1, ..., 9. Frequently used in loops, range is often mistaken for an iterator. However, as the title of the article suggests, while range can be iterated over, it is not actually an iterator.

So if it's not an iterator, what exactly is range? In the article, the author uses clear explanations and code snippets to provide an answer. It may seem like splitting hairs, but this is actually a fundamental concept in Python.

24. "All I Know About Certificates"

An educational article about certificates.

While it is educational, this article differs from typical educational articles. In addition to some light-hearted stories, you'll unexpectedly encounter shell commands and large chunks of pseudocode. These seemingly incongruous elements are skillfully orchestrated by the author into a harmonious and flowing symphony, leaving the reader with a refreshing experience.

25. "New talk: Making Hard Things Easy"

Maybe it's nonsense, but I'll say it anyway: Technologists often tend to "worship complexity." When working with technology, people often encounter many pitfalls and difficulties, yet most refrain from mentioning them, as if admitting a technology's complexity would make them appear less capable.

This is especially true when it comes to universally recognized "fundamental technologies" like DNS and HTTP. Technologists tend to accept, understand, and eventually take complexity for granted.

That's why I really appreciate Julia Evans' insights. She points out that many so-called " fundamental technologies" hide numerous complex elements that are difficult to master. While many people struggle with them, not everyone is committed to improving the situation.

Therefore, we need to simplify the complex. The article discusses several representative technologies, such as DNS, BASH, and SQL, and offers practical suggestions such as sharing useful tools and references, focusing on what you actually use from extensive feature lists, and making hidden things visible.

26. "The Hiring Post"

The author works for a security company called Matasano. One day he received a report about a new type of attack on DSA. Because of the complex steps and strict conditions, the author thought this attack method was impractical and difficult to implement (taking months). Nevertheless, he shared the report with his team (forgetting to mention that it was "impractical").

Two days later, a rookie named Alex approached him with a working exploit program.

Alex is exceptionally talented, but a few years ago, the company wouldn't have hired him. His resume was unremarkable, and in those days the company relied on resumes and interviews for hiring. It was only after Matasano improved its recruiting strategy that they discovered more talents like Alex.

Following the initial story, the author examines some of the problems with hiring in the technology industry. For example, highly qualified candidates often fail interviews due to flawed hiring processes, while those who are adept at interviewing and can speak fluently about abstract concepts easily secure offers. The article offers suggestions such as allowing candidates to warm up and using test questions that reflect actual work scenarios. It's well worth a read.

27. "How I write HTTP services in Go after 13 years"

An article on best practices in Go, focusing exclusively on the HTTP infrastructure in the standard library, without any third-party web frameworks or libraries. The author has more than ten years of Go programming experience and shows a profound knowledge.

In addition to demonstrating specific coding and organizational techniques, the article discusses the reasons behind certain approaches, such as handling functions with long parameter lists, encoding and decoding requests, using closures with http.Handler, E2E testing, and unit testing. These insights reflect the author's years of accumulated experience and wisdom.

28. "Rust std fs slower than Python!? No, it's hardware!"

The article reads more like a fascinating short detective story than a technical article.

One day, Xuanwo received a report about a curious problem: a file operation code in a Rust-implemented Python SDK was running slower than native Python code. Upon investigation, an even stranger situation arose - not only was Rust slower, but the same C code was also slower than Python. But how could this be, since the Python interpreter itself is written in C?

Like any gripping detective story, when the suspense peaks and the culprit is revealed, you'll find yourself saying: "Unexpected, but it makes sense".

29. "Choose Boring Technology"

As tech enthusiasts, we love trying out new technologies, which brings us joy. However, often, the "boring" technology is a wiser choice than the shiny new gadget.

When we find a technology "boring" and don't like it, it's often because we're too familiar with it and can't find anything new or exciting in it (like Django is for me). But remember, this also means that we know all of its pitfalls very well. Using it in a project allows us to focus more on core business issues.

I really like the "innovation token" metaphor in this article. An "innovation token" represents a limited capacity to tackle creative tasks. Suppose you have 3 innovation tokens; how would you spend them? Perhaps focusing on core product functionality is a better use of those tokens than experimenting with a novel technology stack.

30. "Structural pattern matching in Python 3.10"

In version 3.10, Python introduced the "structural pattern matching" syntax (match ... case). While it is very similar to the switch ... case statement, many people mistakenly believe that "structural pattern matching" is just a rewritten switch. In fact, it is quite different from the switch statement. As the author puts it, it is better understood as "iterative unpacking".

This article, published in 2021 (just before the release of Python 3.10), briefly introduces the features of "structural pattern matching" and highlights some of the code scenarios where it is most applicable. In the conclusion, the author expresses a slightly pessimistic and nuanced view about the future of this syntax.

Among the articles related to structural pattern matching, I think this is one of the most worthwhile reads, aside from a few PEPs.

31. "You Want Modules, Not Microservices"

The beginning of the article is quite interesting. The author extracts 10 advantages from an article on microservices architecture, analyzes them one by one, and finds that at least half can be applied directly to "modules."

"Focusing on a small piece of code," "independent development," "versioning," "independent release" - these are all capabilities that modules inherently possess. The "module" referenced here is the technical concept developed in the 1970s, which is now a standard feature in all programming languages.

After exploring the similarities between modules and microservices, the article dives deeper into answering a crucial question: what fundamental problem is microservices architecture trying to solve?

32. "I Don’t Like Go’s Default HTTP Handlers"

While writing HTTP handler functions, the author noticed a design flaw that often leads to buggy code. Many Go developers are aware of (or have made) this mistake: forgetting to return after writing the response body, causing the code to continue executing incorrectly. To address this, the author suggests a solution.

Technically, this is a straightforward article, and the final solution is simply "add another layer of encapsulation". However, I appreciate the author's attention to detail and the philosophy of the article: by optimizing tools and environments, we can minimize human error.

33. "Timeouts and cancellation for humans"

When doing network programming, "timeout configuration" is a very important but often overlooked detail. An improper timeout configuration is like a grain of sand in the sole of a shoe. At first you may not even notice its presence, but over time the sand will wear through the sole and cause significant harm.

"Why is a common API like get(url, timeout=10) not good enough for timeout configuration?"

Starting with this question, the author lists and analyzes some common timeout API designs, and finally introduces the related features of the trio library in detail. The author considers it a more "human-friendly" design.

34. "20 Things I’ve Learned in my 20 Years as a Software Engineer"

After 20 years in the industry, software engineer Justin Etheredge reflects on his career and summarizes 20 things he has learned. These lessons are succinct, insightful, and resonated with me after reading.

For example, the third point: "The best software engineers think like designers." Many times I have been stuck on a problem, pondering deeply, unable to find the optimal solution. But when I shifted my perspective and learned to think like a designer, from the user's (or function caller's or dependent's) point of view, the answer became obvious. Another example is the ninth point: "Nobody asks 'why' enough" - a strong curiosity and desire to learn are the best catalysts to enhance our technical skills.

35. "Why your mock doesn’t work"

When writing test code in Python, the mock module is often used. Many people run into problems where the mock doesn't work the first time they use it. Even though mock.patch(...) was used to replace a module, the original value is still referenced when the code is executed.

Ned Batchelder's article explains the "mock not working" issue in detail. Since this is a common problem, the knowledge points in the article may not be new to you. But even so, I highly recommend it. The structure of the article is clear, the wording is precise, and every diagram and code segment appears just right. Even if it's not for learning, it can be quite refreshing to skim through. In terms of technical writing, there's a lot to learn from it.

I also recommend another article by the author: "Python Names and Values", which is related to this article.

36. "Practical Go: Real world advice for writing maintainable Go programs"

There aren't many resources on the web about "Go code readability", this article may be one of the best available.

This piece offers dozens of suggestions for improving the maintainability of Go code, covering a wide range of topics from variable naming to API design, making it very thorough. What I appreciate most, aside from the excellent writing quality, is how the author includes carefully chosen example code with each suggestion, making the content very accessible and the insights easy to absorb. It's a classic full of valuable insights, a must read for every Go engineer.

37. "Writing system software: code comments."

When it comes to "code comments," this article by Redis author antirez is a favorite of mine. By categorizing all the comments in the Redis project, antirez divides them into 9 types, each serving a different purpose.

What sets this article apart is its focus on the idea of explaining the "why?" in code with comments, especially highlighting "instructional/guiding comments," which are less common. The article notes that guiding comments are the most common in Redis, are thoroughly embedded throughout the project, and contribute significantly to the readability of the Redis source code.

To some extent, this article influenced my coding habits. Rereading it, I'm reminded of the old saying: "Programs are meant to be read by humans and only incidentally for computers to execute."

38. "Write code that is easy to delete, not easy to extend."

Programmers generally agree: "Duplicate code is bad, reusable code is good." This article challenges that consensus from a different angle. While the benefits of reuse are often discussed, its drawbacks are overlooked: the more a piece of code is reused, the more it becomes coupled to different users, making it harder to modify.

Once written, code needs to be maintained, and business evolution means that older code becomes increasingly obsolete. In this sense, rethinking the maintainability of software projects reveals that "easy to delete" becomes a desirable property for code. This article may not be the easiest to read, but its points may be thought-provoking.

39. "How to ask good questions"

In interpersonal communication, "being good at asking questions" is a top-tier skill (Rating: SSR✨). Asking a good question at a critical moment can make communication twice as effective and allow things to fall into place naturally.

Julia Evans' article includes several experiences and techniques related to asking questions, such as stating and confirming what you know about the current situation, choosing whom to ask, and clarifying less obvious concepts through questioning. Not only does the article have good content, but it is also written in a friendly, clear, and easy-to-read style. Highly recommended.

40. "Write Code Every Day"

Programmer John Resig (author of the jQuery library) was facing a problem. He wanted to work on some side projects, but found it difficult to make progress while maintaining the efficiency of his full-time job. He often worked intensively every weekend to get more done, but the pressure and anxiety were overwhelming and it was difficult to maintain his efforts.

One day, encouraged by others, John decided to take a different approach: write code every day. Instead of devoting entire weekends to side projects, he broke his time into daily sessions, spending no less than 30 minutes coding each day. Six months later, he found that this new approach yielded remarkable results, allowing him to develop several new websites, rewrite several frameworks, and complete numerous new modules. More importantly, the anxiety that once plagued him also disappeared.

I really appreciate this article; it represents the programmer's version of "one step at a time," and John is an excellent role model.

41. "The Law of Leaky Abstractions"

Using AI, you spend 5 minutes developing a new feature. During verification, however, you discover that the feature doesn't work properly under certain conditions. To fix the bug, you have to debug it line by line. Once the problem is solved, you look at the clock and see that an hour has passed.

Does this experience sound familiar? Back in 2002, programmer Joel Spolsky identified this phenomenon and coined it the "Law of Leaky Abstractions." The software world is a layered structure of abstractions, like TCP beneath HTTP, and IP beneath TCP, with each layer claiming to be perfect: "You don’t need to worry about any details beneath me."

But in reality, all abstractions eventually leak. When they do, it's like trying to find a single bug in 1000 lines of code written by AI-it's very difficult, but we have no choice.

42. "How to Design a Good API and Why it Matters"

This material is from an internal talk given by Joshua Bloch (then Chief Java Architect) at Google. Although 17 years have passed, it still feels relevant today and continues to provide guidance for modern software development.

Joshua systematically covered all aspects of API design, including:

  • Collecting user use cases with a critical eye;
  • Before writing code, first describe the API in the simplest terms (within one page) and discuss and refine it with the relevant people;
  • If you're unsure about providing a certain feature, don't provide it initially (adding it later is much easier than removing it);
  • APIs should coexist harmoniously with the platforms they're used on, for example, SDKs should not be directly ported from one language to another.

If you've never thought about API design before, take a look; it could significantly change the way you develop software in the future.

43. "My Principles for Building Software" & "Applying 'Make Invalid States Unrepresentable'"

There are many articles about software development principles. What makes this one special is that the author, Kevin, emphasizes the impact of data on software design.

For example, Kevin suggests prioritizing data structures over code in design because the former is more important. As Fred Brooks, author of The Mythical Man-Month, once said, "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious."

Another principle Kevin mentions is "make invalid states unrepresentable. In the business logic of software, there are often "invalid states". Handling them usually requires extra work in the code. However, by designing the data structure so that invalid states cannot be represented, the complexity of the program can be reduced. There is a specific application of this principle in "Applying 'Make Invalid States Unrepresentable'".

Besides these principles, other principles in the article, such as "Focus Your Learning on Concepts, not Technologies" and "Avoid Trading Local Simplicity for Global Complexity" are full of wisdom.

44. "No, it is not a compiler error. It is never a compiler error."

The normal operation of a piece of code depends on countless components and libraries hidden behind it. When a bug occurs, it's not wise for programmers to immediately question these trusted libraries instead of suspecting their own code. As the article's title suggests: "It is never a compiler error".

However, compilers are also written by humans, and they aren't always correct. When a compiler makes a mistake, the problem can be unexpectedly bizarre. In the latter part of the article, the author, who has long believed that "compilers don't make mistakes," actually encountered a compiler error.

45. "The one of changing a washing machine the day before New Year's Eve(Chinese)"

A programmer's washing machine, which had been in use for 6 years, broke down and wouldn't spin. Since he had previously spent a lot of money to replace the drain pump, he thought the same problem was recurring and decided to replace it with a new machine. Unexpectedly, after installation, the new washer couldn't spin either.

What seemed to be just a typical annoying issue, the author sees differently. In the second part of the article, he unexpectedly shifts from the washing machine to software development. From error codes to manuals, from debugging to choosing brands, it's really intriguing. Very insightful observations and thoughts.

46. "What Color is Your Function?"

Someone invented a programming language that is unique because its functions are distinguished by color: "red" and "blue". The color affects not only how they look, but also how you use them; for example, red functions can only call other red functions, not blue ones.

Although this starts with a seemingly incomprehensible premise, the article's topic is actually quite serious. The author Bob shares his thoughts on asynchronous programming styles (guess what the "color" of the function represents?), covering callbacks, Promises, threads, and await/async.

Beyond the insightful opinions, the article is well written, with serious content occasionally interspersed with a touch of the author's humor. For those who love asynchronous programming, this is a must-read masterpiece.

47. "Healthy Documentation"

Programmers are strange; they have conflicting attitudes about many things, and "documentation" is one of them.

As consumers, every programmer hopes that every API, function, and system they adopt has detailed and accurate documentation. However, when they become producers, they are rarely willing to invest effort in "writing documentation" - often preferring to "write a hundred lines of code rather than a single line of text".

Nevertheless, the importance of documentation in software development is undeniable. As the author mentioned: "Anything that is not documented is a wasted resource and will cause problems in the future". By writing documentation, we materialize the knowledge in our minds and thus help others in the future. For individuals, documentation is not only a tool for learning, communicating, and sharing knowledge, but also a shortcut to establishing personal influence. For teams, if each member values the importance of documentation and is willing to write clear and reliable documentation to replace endless meetings, this "documentation-first" atmosphere will greatly benefit the team's long-term development.

48. "How to Do Code Reviews Like a Human (Part One)"

An article on code review covers many beginner and advanced experiences, including: don't spend review time on style and formatting issues, let tools handle it; comments should be phrased as "requests" rather than "commands"; reviews aren't just about finding bugs, good code should be praised, etc.

Highly recommended for every programmer who needs to participate in code reviews.

49. "Everything you need to know about Python 3.13 – JIT and GIL went up the hill"

Python 3.13 introduced many exciting changes, such as Just-In-Time (JIT) compilation using "copy-and-patch" technology and the removal of the Global Interpreter Lock (GIL) with a "free threading" mode, among others.

Drew's article covers these changes. The article is written in a very accessible style and is comprehensive, including both introductory concepts and practical code experiments with benchmarks. It is packed with information, yet the length is just right. Highly recommended.

50. "After 14 years in the industry, I still find programming difficult"

This is the 50th in the list, marking the halfway point in the entire "A programmer's reading list" series. After careful consideration, I decided to contribute my own piece as a little encouragement to myself.

Is programming difficult? Answers vary. As a teenager in college, I found programming very challenging, with various algorithms and APIs making my head spin. I hoped that years later, extensive development experience would make programming as easy as eating a cookie.

Now, more than a decade later, programming seems only a little easier, still far from being "as easy as eating a cookie".

In this article, I share some of my thoughts and conclusions about programming. For example, creating an efficient environment for trial and error is crucial, and the essence of programming is "creation". I hope it inspires you.

Conclusion

This concludes the first part of the "A programmer's reading list." Happy reading!

Cover image source: Photo by Farsai Chaikulngamdee on Unsplash