/Antipattern

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

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

Manager Antipatterns

- Ted Neward tl;dr: “There's a whole host of mistakes that companies often fall prey to with respect to those they have leading teams, and I thought it a good idea to collect them into one place, under the umbrella heading of "manager antipatterns”.”

featured in #545

Manager Antipatterns

- Ted Neward tl;dr: “There's a whole host of mistakes that companies often fall prey to with respect to those they have leading teams, and I thought it a good idea to collect them into one place, under the umbrella heading of "manager antipatterns”.”

featured in #544

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