This is the third post in the reading notes series for How to Stop Sucking and Be Awesome Instead (published in Chinese as 《程序员的修炼——从优秀到卓越》). The author, Jeff Atwood, is one of the founders of Stack Overflow. His articles cover a wide range of topics. He is a seasoned programmer, manager, and entrepreneur. This book discusses many things beyond programming. Whether you are a junior engineer or a senior engineer, this book is worth reading. As your experience grows, every time you re-read this book, you will gain new insights. Just as the Chinese subtitle, “From Good to Great,” suggests, the author points out the path for you, but whether you can succeed depends on your own cultivation.
I will excerpt some wonderful remarks from the book and sometimes add my own insights or experiences. The outline of the reading notes is consistent with the outline of the book itself. This is also a method I learned from another source and have been using: “How to Read a Book”. I record it for my own frequent review and for readers’ reference. Below is the The Programmer’s Apprenticeship reading note series:
- The Programmer’s Apprenticeship - 01: The Art of Fighting Back
- The Programmer’s Apprenticeship - 02: The Way of Programming
- The Programmer’s Apprenticeship - 03: Web Design Principles
- The Programmer’s Apprenticeship - 04: Reflections on Testing
- The Programmer’s Apprenticeship - 05: Know Your Users
- The Programmer’s Apprenticeship - 06: All About the Internet
- The Programmer’s Apprenticeship - 07: Games and Programming
- The Programmer’s Apprenticeship - 08: The Beauty of Reading
Reading note (reviewed October 2026): This post preserves the structure and personal reflections of the 2018 notes. The old homepage, Home-button, and app/web comparisons need their historical context; the updates below identify current metrics, browser capabilities, and target-size requirements by source and version.
Criteria for Judging Websites
In Judging Websites (October 16, 2012), Jeff describes spending about 30 seconds on each Rails Rumble homepage before forming an initial judgment. This illustrates the need to explain a site quickly; it is not a measured attention span shared by every visitor.
The author offered some suggestions to the contestants. Your website homepage needs to give people a “wow” feeling at first sight:
- Load quickly, accounting for mobile devices and network conditions. “Users lose patience after one second” is not a universal threshold for every site.
- What on earth is this? Don’t leave incoming users in a fog. Let users know what this webpage is for as soon as they enter.
- Show me an example.
- Clearly tell me what to do, and clear away obstacles.
- Embrace your audience, even if it means excluding other audiences.
Performance update (October 2026): Core Web Vitals separates loading, interactivity, and visual stability. Current “good” thresholds are LCP ≤ 2.5 seconds, INP ≤ 200 milliseconds, and CLS ≤ 0.1, assessed at the 75th percentile separately for mobile and desktop. INP is not total page-load time, and CLS is not a time measurement. A single local run cannot replace a distribution of real-user measurements, and passing these metrics does not establish overall usability.
In any Web application, the basic sketch of the homepage design is the first thing you should do, because it is the crucial initial design draft and your vision statement.
Pursue Simplicity
Pursuing simplicity means carrying it through the design. The comparison here concerns historical Yahoo and Google homepages: Google’s search page appeared restrained, while a portal carried more information. This is a reading-time observation, not a description of their current pages. Complexity also needs to be judged against the different tasks of search and portal sites.
Google’s simplicity puts complex things behind the scenes, instead of dumping them all on the user.
Will Apps Replace Websites?
We should start with simple design and scale up proportionately when necessary, rather than making things complicated from the start and then being forced to shrink. This is similar to the Mobile-First design philosophy.
What advantages can native apps offer?
- Platform-specific performance optimization, with actual speed depending on implementation and workload
- Platform-native UI controls
- Interaction and layout integrated with system capabilities
- Offline functionality when implemented; not every app works offline
What advantages can websites offer?
- Access through supported browsers, subject to API, input, and layout compatibility
- Usually accessible directly from a link without installation
- Most updates are deployed by the service, although caches and service workers can affect when users receive them
- Shared functionality and design, without a guarantee of identical behavior on every device
Apps and websites can share technology and design, but cross-platform frameworks do not eliminate differences in permissions, distribution, or device capabilities. PWAs can be installed when browser requirements are met, and service workers with appropriate caching can support some offline access. These features require implementation and browser support, normally with HTTPS in production. Calling a site a PWA does not make every feature work offline. A mobile-first approach should follow the audience, tasks, and devices.
When I read this in 2018, I thought the boundary between webpages and apps would blur until they became one. Looking back, that was my expectation at the time; it is not an established or inevitable outcome.
Remember Not to Stick to Conventions
We need to adopt the “right” way of doing things, not the “standard” way:
- Fully understand the current specification and the reasons for its formation (Know what and also know why).
- Deviation from this specification requires justification.
- Collect user usage data during the experiment (A/B Test).
- Make decisions based on data.
Doing Android system optimization is best done following the steps above: first understand the code logic, then understand why the code is written this way, then think about how to optimize. During this period, you need to find bottlenecks, make changes, get user data, and compare user data to choose the optimal solution.
Weird Single-Button Design
This section concerns early iPhones with a physical Home button and the difficulty of reaching navigation controls one-handed on larger screens. Home returns to the Home Screen; it is not the same as going back one page inside an app. For Face ID models, Apple’s gesture guide uses a swipe from the bottom to return home. In-app back buttons and navigation gestures depend on the interface. The old Home-button discussion does not describe every current iPhone.
Usability Is Not Just Highbrow Art
When nobody attends to usability, obstacles to completing tasks can go unnoticed. Usability is not the only factor in a project’s success, however. Jeff’s Usability On The Cheap and Easy (2010) emphasizes starting with low-cost observation of people doing real tasks.
- Usability testing is one of the most effective measures people can take to improve a website.
- Team members can learn and participate in basic usability testing; purchasing eye-tracking equipment is not a prerequisite.
The author also recommends Jakob Nielsen and Kara Pernice’s Eyetracking Web Usability (2009), published in Chinese as 《用眼动追踪提升网站可用性》. Eye tracking adds observations, but looking at an element does not by itself establish comprehension or task success.
The Other Side of Fitts’s Law
Fitts’s law relates pointing movement time to target distance and width. Under comparable conditions, nearer targets with greater effective width are generally quicker to acquire. It does not by itself explain the usability of an entire interface.
In The Opposite of Fitts’ Law (March 23, 2010), Jeff summarizes two suggestions from “Visualizing Fitts’s Law.” Their application depends on the input method:
- When a mouse pointer is constrained by a screen boundary, a target that reaches that boundary can be easier to acquire. A traversable edge between monitors may not offer that benefit, and a finger on a touchscreen is not constrained like a mouse cursor.
- Make the clickable area as large as possible. The larger the target, the easier it is to click.
Do not prevent accidental activation by making a necessary control too small to use. For destructive actions, prefer clear labels, separation from routine actions, and confirmation or undo according to risk. WCAG 2.2 2.5.8 Target Size (Minimum), at Level AA, generally requires pointer targets of at least 24×24 CSS pixels, with exceptions for spacing, equivalent controls, inline targets, user-agent controls, and essential presentation. This concerns the active target area, not just the visible icon.
Usability and Learnability
Website writing should adopt the “inverted pyramid” style: Tell the reader the conclusion at the beginning of the article, then write the most important supporting information, and finally introduce the relevant background.
You should try to put the most important information at the top, whether you are making a webpage, writing a program, writing an email, or making a resume, etc.
The author also recommends Joel Spolsky’s User Interface Design for Programmers, known in Chinese as 《写给程序员的UI设计指南》. The author’s site provides material from the book.
Just One More
If you want to add another UI element, please be sure that the UI element you add is not the last straw that breaks the camel’s back.
Dare to Say No
Innovation is not about accepting everything, but about saying no to everything except key features.
User Interface is Hard
This section reminds programmers to check whether an interface is usable. Components and design systems reduce work on basic controls, styling, and some interactions, but they do not decide the information hierarchy, task flow, error feedback, or keyboard and assistive-technology behavior for us. Visual consistency and usability still need separate evaluation against the tasks users must complete.
The following Douban blurbs are historical excerpts; their traffic figures are not 2026 statistics.
How to Stop Sucking and Be Awesome Instead is a compilation of the best articles from the Coding Horror blog. The book is divided into 8 chapters, covering topics such as time management, programming methods, web design, testing, user needs, the Internet, game programming, and technical reading. The topics selected by the author are all pain points in a programmer’s career. Many articles have high click-through rates and reply rates on blogs and the Internet. —— from Douban
Jeff Atwood founded the Coding Horror blog (codinghorror.com) in 2004 to record his thoughts and bits and pieces of his software development experience. Today, the blog has nearly 100,000 visits per day. Readers participate in comments, and various views and wisdom collide passionately there. —— from Douban
The writing style of How to Stop Sucking and Be Awesome Instead is humorous, understanding, and caring; it is suitable for programmers at all stages from novice to veteran, and also suitable for students of computer science and related majors who are about to become programmers. How to Stop Sucking and Be Awesome Instead can help readers pay more attention to the human nature and humanistic factors of technical work, thereby achieving a successful turning point in their programmer career. —— from Douban
About Me && Blog
Below is my personal introduction and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”
- Blogger Intro: Includes personal WeChat and WeChat group links.
- Blog Content Navigation: A guide for my blog content.
- Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
- Android Performance Optimization Knowledge Planet: The paid community stopped operating in 2026 and no longer accepts new members; this link preserves its history.
One person can walk faster, a group can walk further
