/Antipattern

Falsehoods Programmers Believe About Names

- Patrick McKenzie tl;dr: As a public service, I’m going to list assumptions your systems probably make about names. All of these assumptions are wrong. Try to make less of them next time you write a system which touches names. (1) People have exactly one canonical full name. (2) People have exactly one full name which they go by. (3) People have, at this point in time, exactly one canonical full name. (4) People have, at this point in time, one full name which they go by. (5) People have exactly N names, for any value of N.

featured in #523

Status Games

- Phil Booth tl;dr: “Here are some ways that I've seen engineers pathologically try to elevate their own status: (1) Build a new thing that doesn't need to exist. (2) Build a thing using different technology that the rest of the team are unfamiliar with. (3) Rewrite from scratch something that was already working fine. (4) Work on easy changes that touch many lines of code but don't impact the business. (5) Claim to be working on big and/or complicated changes, which nobody else has visibility of.” Phil discusses how to defuse these games early before they escalate. 

featured in #520

Avoiding The Soft Delete Anti-Pattern

- Tim Fisken tl;dr: “In the sphere of databases, this terror of deleting things leads people to advocate soft deletion: instead of really deleting a record, you add a field which marks the record as deleted, and you treat any record marked in that way as if it were deleted. This is generally a bad idea, and there are a number of better ways of ensuring access to old data.”

featured in #514

Common DB Schema Change Mistakes

- Nikolay Samokhvalov tl;dr: Nikolay covers 18 mistakes, categorized into three big categories of DB schema migration mistakes: "(1) Concurrency-related mistakes. (2) Mistakes related to the correctness of steps. (3) Miscellaneous – mistakes related to the implementation of some specific database feature or the configuration of a particular database."

featured in #511

Simple Sabotage For Software

- Erik Bernhardsson tl;dr: The CIA produced a fantastic book during the peak of World War 2 called Simple Sabotage. It laid out various ways for infiltrators to ruin productivity of a company: (1)  Insist on doing everything through “channels”. Never permit short-cuts to be taken in order to expedite decisions. (2) Make “speeches”. Talk as frequently as possible and at lengths. Illustrate your “points” by long anecdotes and accounts of personal experience. Never hesitate to make a few “patriotic” comments. (3) When possible, refer all matters to committees for “further study and consideration”. Attempt to make committees as large as possible — never less than five.

featured in #474

Exceptional Exception Handling

- Yiming Sun tl;dr: Have you ever seen huge exception-handling blocks that throws an exception? Yiming shows an example and highlights the core problems: (1) It obscures the logic so unintended exceptions may be caught. (2) The code might end up catching different exceptions. (3) It rethrows a general exception, with the original exception ignored. This means that the root cause is lost - we don't know what exactly goes wrong. Yiming shows a better way to handle errors. 

featured in #471

The Ultimate Guide To Developer Counter-Productivity

- John Cutler tl;dr: John highlights 20+ specific areas where developers often lose productivity, including: (1) Reactive, unplanned work. (2) Context switching and startup costs. (3) Non-value-adding admin & compliance work. (5) Ineffective planning. (6) Dependency management overhead. (7) Ineffective meetings and communication. (8) Redundant manager briefing & orientation. (9) Consensus seeking and decision-making drag. (10) Ineffective collaboration arrangements. And more.

featured in #448

Retrospectives Antipatterns

- Aino Corry tl;dr: If you use retrospectives, or any kind of meeting where people are supposed to discuss and learn from their discussions, you will have experienced less efficient sessions from time to time. There is no wonder in that, and it happens to most people. This article offers solutions to three common, unfortunate situations: (1) Skipping generating insights. (2) Getting lost in things you can't change. (3) Being dominated by a loudmouth.

featured in #391

The Ugliest Pattern In React

- Sebastian Carlos tl;dr: "Maybe the ugliness is a virtue, since it encourages us to completely change the code to enable some of the better alternatives mentioned above — After all, “adjusting state in response to rendering” will always result in code that’s difficult to understand."

featured in #380

Falsehoods Programmers Believe About Email

tl;dr: Includes: (1) Everyone has an email address. (2) Everyone has exactly one email address. (3) An email address never changes. (4) Whenever an address does change, it’s under that user’s control. (5) Whenever an address does change, it’s because the user specifically requested it to happen. (6) Whenever an address does change, the old address will continue to work or exist. And more. 

featured in #348