'Top 10 Software Essays' Selected by a Software Engineer Who Spent Most of His Career at Microsoft and Google
The Software Essays that Shaped Me · Refactoring English
https://refactoringenglish.com/blog/software-essays-that-shaped-me/
◆1: “The Joel Test: 12 Steps to Better Code” by Joel Spolsky
Joel Spolsky, one of the greatest software bloggers of all time, has had a major influence on Lynch's approach to software. Spolsky's 'Joel Test' is a set of 12 questions employers can ask themselves to gauge how invested they are in their software teams. The questions are as follows:
1: Are you using source control?
2: Can you create a build in one step?
3: Are you creating builds every day?
4: Is there a bug database?
5: Are you fixing bugs before writing new code?
6. Do you have an up-to-date schedule?
7: Are there specifications?
8: Is the working environment for programmers kept quiet?
9: Are you using the best tools money can buy?
10: Are there any testers?
11: Are new job candidates writing code during the interview?
12: Are you conducting usability testing of your hallways?
While some of these questions are outdated, the key takeaways are the same across the board: 'Do they respect their developers?' and 'Do they prioritize their time and focus?' When Spolsky wrote this blog in 2000, not everyone realized that skilled developers were a valuable resource. Lynch wrote, 'Throughout my career, I've sought out employers who scored highly on the Joel Test, and I'm grateful to Joel for giving me the map to find them.'
Spolsky's columns have also been published as a book titled ' Joel on Software .'
◆2: “Parse, don't validate” by Alexis King
The essay explains that when validating data using Haskell 's type system, it is necessary to convert it to a new type. For example, in a system for registering usernames for an app, a malicious user could embed malicious code in the username field or embed a string of billions of characters, exhausting server resources. Converting data using functions can protect against such malicious activity. Lynch commented, 'This essay made me realize how useful compiler features can be in improving the security and reliability of applications.'
(PDF file) ◆3: “No Silver Bullet - Essence and Accident in Software Engineering” by Fred Brooks
This essay divides software development tasks into two categories: 'intrinsic complexity' and 'accidental complexity.' 'Intrinsic complexity' refers to tasks that must be performed in pairs, regardless of the tools or hardware. For example, if you're writing software to calculate a salesperson's bonus, you need to define the bonus formula and cover all the extreme cases. This is a task that must be performed regardless of the tools or hardware.
On the other hand, 'accidental complexity' refers to all the other work involved, such as dealing with memory leaks, waiting for code to compile, figuring out how to use third-party libraries, etc. The more tools and hardware resources you have, the less time you'll spend on accidental complexity.
Given these assumptions, Brooks concluded that no matter what advances in tools and hardware, it's impossible to increase developer productivity by a factor of 10. While modern code-generating AI casts doubt on this claim, Lynch writes, 'Even if AI eliminates programming as we know it, Brooks's essay gives me hope that we'll still need humans to manage the inherent complexity at any level of abstraction.'
◆4: “Choices” by Joel Spolsky
This essay discusses the creation of user interfaces and the subtle costs of empowering users. Spolsky states, 'Every time you offer a choice, you're asking the user to make a decision. That means they have to think about something and make a decision. This isn't necessarily a bad thing, but in general, you should always try to minimize the number of decisions the user has to make,' arguing that user interfaces should minimize the burden on users.
'Joel's essay focuses on the graphical user interface, but I think about it everywhere people might touch my code, whether it's the command line or when other developers call the functions I've written,' Lynch said. 'Joel's essay has helped me countless times to avoid forcing decisions on users that they could make for themselves.'
5. 'Application compatibility layers are there for the customer, not for the program' by Raymond Chen
Raymond Chen is one of the longest-serving developers on the Microsoft Windows team, and his blog has many informative articles about the history of programming on Windows. Lynch particularly remembers this article about Windows Vista compatibility mode.
One user wrote to Cheng, 'I have a program that was originally designed for Windows XP and Windows Server 2003, but it has problems running on Windows Vista. However, if I set the program to run in Windows XP compatibility mode, it works fine. What changes do I need to make to the installer so that it automatically runs in Windows XP compatibility mode when a user runs it on Windows Vista?'
Chen claims that the user's request is like saying, 'I usually throw trash on the sidewalk in front of the pet store, and every morning when the store opens, someone sweeps up the trash and throws it in the trash can. But on Sundays, the pet store is closed, so the trash is left there. How can I get the pet store to open on Sundays?' Lynch says that while she doesn't agree with Chen's specific claims, she finds the analogy interesting and provides a hint for encouraging users to take action.
6. “Don't Put Logic in Tests” by Erik Kuefler
In his essay, Kufler points out that adding operators or including loops and conditional statements to test code when performing unit testing of a program can hide subtle bugs. Unlike production code, test code emphasizes simplicity over flexibility, so instead of including logic to calculate input/output pairs, test code should be written specifically. Lynch was confident in his own test code, but after reading Kufler's essay, he realized he had been writing terrible essays throughout his career.
'Eric's essay taught me that test code should not be treated like production code. Test code and production code have very different purposes and constraints. Good test code must be clear above all else. Because test code has no test code of its own, the only way to verify its correctness is to inspect it. It should be immediately clear to the reader what behavior a test is asserting. To achieve this goal, it is possible to reduce complexity and accept redundancy,' said Lynch.
7. “A little bit of plain Javascript can do a lot” by Julia Evans
Lynch only wrote code for desktop apps and backend servers for the first 10 years of his career, and only started working with HTML and JavaScript in 2017. When he first began learning front-end development, Lynch had the impression that JavaScript was a 'miscellaneous language whose behavior differed depending on the browser,' and tried out various JavaScript frameworks to improve on that shortcoming.
However, after reading Evans' essay and learning about the potential of JavaScript, he decided to try programming using only JavaScript, without frameworks, build steps, Node.js, etc., and was surprised to find that it went better than when he was using frameworks.
Lynch said, 'My prejudices against JavaScript were wrong. Modern JavaScript is pretty good.' 'Browsers do a good job of ensuring consistent behavior across platforms and devices. I haven't integrated a JavaScript framework or build step into any new projects since 2020, and I've never regretted it.'
8. “Choose Boring Technology” by Dan McKinley
Lynch says he has never actually read the essay, only seen it quoted. However, he found the essay's ideas so intuitive that he didn't need to read it. McKinley's argument is that 'when starting a new project, it's tempting to use the latest cutting-edge technology, but new technology has bugs and weaknesses, and when you encounter them, you get stuck.' On the other hand, while well-used technology may be boring, it reduces the risk of getting stuck during development because solutions already exist for various problems you may encounter.
9. “I've locked myself out of my digital life” by Terence Eden
Eden is a writer who has written about a wide range of technology topics, but Lynch said he was particularly impressed by this essay, in which he posed a thought experiment: 'What would happen if lightning struck your house and destroyed all your possessions?' He concluded that if you lost access to your password manager, which stores all your passwords, you would be powerless.
Lynch said he always felt safe with all his data stored on multiple backup drives across continents, but reading this article made him think about 'all the threats that could wipe out all of my devices at once.' 'Online services are not good at helping users recover from disasters,' Lynch said. 'I use several services that assume I can't lose my phone, email account, or any of my digital devices. Since reading Terence's essay, I've thought more deeply about which services and devices are important to me and how I can recover from a situation like the one he describes.'
10. Brad Fitzpatrick on parsing user input
This isn't technically an essay, but rather one of several interviews with programmers featured in the book Coders at Work . Fitzpatrick, one of the interviewees in the book, candidly states, 'I would urge everyone to be okay with putting spaces and hyphens on their credit card applications because computers are good at removing them. Stop telling people how to format numbers.'
'I think of this quote every time I try to paste a phone number into a web form and it complains, 'No parentheses or spaces,' or even worse, it truncates the phone number because of the parentheses and then complains, 'No parentheses,'' Lynch said. 'Every time I create an input field in my software and think about unexpected characters, I hear Fitzpatrick's line, 'Computers are good at filtering out those junk.''
Related Posts:
in Note, Posted by log1h_ik