/Antipattern

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


Linguistic Antipatterns

tl;dr: "This website is dedicated to cataloguing types of linguistic antipatterns and discussing the deeper reasons they cause problems and how to fix them."

featured in #343


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 #320


How I Accidentally Deleted 7TB Of Videos Before Going To Production

- Nikita Brancatisano tl;dr: "The bad news is that this was on Friday, and we needed to have the videos back up at most for Tuesday morning. We had to upload ~8TB of data with a 30MB/s connection. Not ideal, and I had to think about something fast."

featured in #314


Eight Points For One Team Is Two Points For Another Team

- Lloyd Atkinson tl;dr: "In my ongoing quest to explore the problems that are endemic to modern software development, I decided to focus in particular on estimation and the disaster that is “story pointing.”" Lloyd discusses the antipatterns experienced when estimating, including failing to realize story points are an estimate, coercing developers into choosing a lower number, discounting high or low numbers, and more.

featured in #309