Why Make Things Complicated?

Been jumping across projects recently. Pretty normal for me, just another day at work. Actually, I kinda requested that to happen. I don't want to get stuck months at a time on one project, that's boring especially with the pace web technologies are moving. It gives me the opportunity to play with different stacks, compare technology, criticize approach, all that fun stuff. This time around, all about ending up making things so complicated.

Death by convenience

The dev branch of Ractive got updated with a PR that addresses how imports are done when dependencies are relatively very far away from the current module. In a gist, it aliases deep paths so that imports can just start with an alias and resolve from there. The fix is cool, and makes code a bit cleaner. But there's a problem.

You now have code that cannot explain itself. Just by looking at the code, you can't tell what's going with the imports. It doesn't match up with the file system and nothing immediately pops out. This will eat up at least 30 mins before figuring it out. If time wasn't enough, it also takes away productivity features. This will break code infererence, completion and lookup features of any text editor.

Giving meaning to something that's not

In most languages, null or undefined (sigh, JavaScript) signifies an absence of a value. End of story... or is it?

Nope. Someone, somewhere at some point in time will give null or undefined a different meaning other than the absence of a value. Maybe it's for convenience, or just too lazy to just stick a boolean, I don't know. null was and still is a bad idea to begin with, but someone just had to use it and make something even worse. Use Optionals, Maybes or something similar if you can. Or at least just leave null and undefined as what they are.

Over-categorizing

We once had this discussion on how to organize components of an app. Things that came up include organizing by feature, organizing by route, and all that. No one can agree on an approach because each has its downsides. For instance, organizing by feature falls apart when a feature is used in another feature. Organizing by route falls apart when a feature on a route is used in another route. Then I stepped in and said:

Just stick them in one directory.

This organization stragegy does not affect where the component is used or why it's used. Components are components, and nothing more. I just did that to one project today, shoving stuff into directories by type. The only drawback is that there will be a ton of files in the directory. But that's not a problem if they're all named consistently and if you have an editor with Quick Open (i.e. VS Code).