83% of development is pointlessly renaming things

So you’re creating a (SQL) database table named car. Each car record has to have an indexed identifier, so you give it a column named id.

BAM! You’ve created endless unnecessary work for the project! Congratulations, you’ve done your part in ensuring developers stay in high demand.

Wait, what?

DB queries

Because you’re adhering to the “best practice” of naming the column id, now anytime you run a database query with ids from multiple tables, you’ll have to alias them to distinguish between them:

select car.id as car_id, user.id as user_id .....

Join statements also become more work. Instead of this:

select * from car join user
  using (car_id);

You now have to do this:

select * from car join user
  on car.id = user.car_id;

Mapping query results in your code

Say you have the following query:

select car.id as car_id, user.id as user_id .....

In your code, you’ll have to know car_id will be returned by the query, instead of just id.

But if you run this query:

select id from car;

Then your code will have to know id will be returned, instead of car_id.

Combining mapped query results with other code

So it turns out you only need to get the car its id, so you decide to query the database like this:

select id from car where [...] limit 1;

In your code, you’ve got your id. But you need to combine it with some other data. For example: your application is a RESTful API, and the DB query result needs to be added to the JSON object you received in an endpoint call. Let’s say the incoming JSON object looks like this:

{
  "user_id": 1
}

If you merge that with your DB query result, you get something like:

{
  "user_id": 1,
  "id": 3
}

That may make sense if the object you’re constructing is a car. But if you’re constructing something else, the id needs to be renamed to car_id for it to make sense.

Instead of using select id from car in your query, you could have queried select id as car_id from car. That still counts as pointless renaming, because you could have just named the column unambiguously, during the creation of the table.

api call responses

Since you’re happily renaming things left and right, obviously the right thing to do when responding to an incoming API call is to name the object keys of your result differently from what they are called in the database.

So whoever is querying your API will get a response like this:

{
  "user": 1,
  "userCarId": 3
}

Here, user is actually the id column of your user table, which you cleverly named something else than user_id. This way, you ensure they will also have to do unnecessary renaming. Remember: we’re all in this together. We cannot ensure job safety for everyone if we just give others the chance to do work without unnecessary renaming things.

api input validation

Obviously we need to validate the data that we receive in API calls. If we made sure that data was named the same as our database columns, we could automate a lot of this work. That would be horrible, because we need to keep our jobs. So no, we’re not adding a middleware to our router that checks if the incoming JSON keys match a database column name. And we won’t automate the validating/coercing of that data by looking at the database schema.

Instead, let’s give the keys of the incoming JSON objects random names. This way, we ensure we manually have to write a bunch of validation logic. Profit!

Conclusion

As if the inflation and probably an incoming recession weren’t enough, big companies are starting to fire their employees. Those are, like, really smart people, who can actually solve Hackerrank problems and have the motivation and stamina to pass like 20 interview stages. Yikes!

Luckily, we have a secret weapon: renaming stuff. As long as we pointlessly rename a bunch of stuff, we can create as much work for ourselves as we like, as well as for those who consume our APIs.


willfennel.com   |   posts   |   RSS feed