### Some of the biases I have when considering code:

_This list is particularly targeted at Ruby code, since that's what I have the most experience with_

**Delegation**: Spent multiple days working on a bug without realizing it was delegated in the place it was occuring. I think it started out not delegated and became so later on, so tests weren't catching it, and delegation overrode one of the methods? In general, I feel like any time spent figuring out what something actually is, if it seems to be one thing in the code but is actually a different thing, is wasted time.

**Single Responsibility Principle**: Bike Index bike creation bug hunts. Any new service has to be compared against the Bike Index bike creation process - where when there is a bug, I have to trace it through a series of files. I feel like this tracery is a waste of time. Unless multiple other files need access to the same thing, I'm generally opposed to creating extra files.

**Hand written sql**: You can extend things that are Active Record collections. Pretty much every time I have written something that returned an array I have had to, at some point down the line, refactor it to return an active record collection so it could be extended. Also, when writing sql, you have to protect against injection attacks and from what I've seen, to do that you have to be cleverer than everyone on the internet, which is difficult.

**Database constraints**: I have been bitten by weird data (that is actually acceptable) breaking and not throwing errors in the place you expect, by performance slow downs, by them making loading bulk data in difficult and by them making deleting data difficult. In my experience, the more complex the constraint the more likely it is to cause me problems.

**Duplicating foreign keys in multiple places in your database**: It's pretty easy to duplicate stuff effectively across tables, using Rails. If it's difficult to do a join, duplicating a foreign key on the relevant table has ended up being more performant and less error prone for me (and easier to migrate away from when refactoring into a better solution later). Calling this "caching" has made this more palatable to people.

**Modifying the state of an object in a process, rather than using the output of functions**: When I find a bug, I try to replicate it with tests. Often, if there is a lot of set up to get to the place where the bug occurs, I'm too lazy to do a good job. If the only thing that matters for a method is accepting input and returning output, it's much easier to test, so I generally do a better job.

---

This list is not complete, I'm creating new biases every day!

When I'm considering a code solution, these are frequently part of my perspective. I ignore all of these regularly (except delegation, I avoid that pretty aggressively), these are just something that I'm considering when thinking about code.