Using obscure features of a programming language
There is a coversation that I had about five years ago where I'm really disappointed with myself.
I was working at a job where we were using Rails and Angular 1. I was a front-end developer there. I was pretty comfortable with Angular and had been using directives heavily, sometimes venturing into some of the more obscure features of directives. One day my boss had a conversation with me about it.
He told me not to use them. He said that they violate the normal expectation one would have of a MVC architecture. In particular I think he was referring to the fact that in Angular you can do something like this:
<div ng-controller="MainController as main">
<fancy-directive></fancy-directive>
<h1>Page header</h1>
<p>Lorem ipsum dolor</p>
</div>
When something happens inside of <fancy-directive>, the directive can handle it. Eg if you click a button to toggle some sort of state, it can all be handled inside of the directive and never touch MainController. In fact, this was the Angular Way. However, it violates the expectation one might have that it'd be handled by MainController.
At the time, I thought it was totally crazy that he'd propose that I shouldn't use directives in Angular! Directives are like... one of the most fundamental parts of the framework. They say that the three D's of Angular are directives, dependency injection and data binding. And the reason why it's called "Angular" is because HTML elements have angular brackets − < and > − and Angular lets you create your own things with angular brackets.
Furthermore, I took an uncharitable perspective of focusing on the fact that my boss was a Ruby dev without much front end experience in general, let alone with Angular or single page apps. It felt to me like he had a huge shortcoming in his knowledge and that he wanted to take a shortcut and sidestep this shortcoming. If we're using Angular, it seems reasonable to expect that the developers know the fundamental concepts of the framework. If they don't, then we either picked the wrong developers or picked the wrong framework.
Let me give you some more context of where I was coming from. There's a stereotype about how developers go through phases with best practices over the course of time.
- In the beginning, you don't know what they are and your code suffers from this lack of knowledge.
- Then you learn what they are and start to follow them blindly.
- Then you realize that they don't apply to every situation, and start to apply them intelligently.
This is oversimplified, but I think it points at something that is roughly correct. Anyway, at the time of this directives debate, I was a little bit over a year into my career, coming from a coding bootcamp background, and I was pretty firmly in that second phase of following best practices blindly.
I didn't know that I was doing this. I just knew that I read things from all of these experts on how you should write your code. The experts seemed like really good programmers and highly trustworthy. So it just felt like I was choosing to listen to the experts instead of listening to Joe Shmoe.
I think the main place where this goes wrong isn't that the experts are wrong. If you sat down and talked about it with them, they'd usually agree that their advice is a guideline not a rule, and you have to think about whether it makes sense to apply it. But it's often hard to express such caveats when you're teaching or arguing something.
I experienced something like this in my journey as a poker player. There's a book I read called The Course. It makes a lot of generalizations about how poker players play. There's a friend I have who I discuss poker hands with, and we'd often have disagreements where he says one thing and I say, "The Course says the opposite and I trust the author more than I trust you". Then I actually met the author one day and he totally acknowledged that his advice doesn't always apply and that his book was meant to help beginners take their first steps.
I think the same thing happens in programming when experts talk about best practices. I think they know that they don't always apply, but a lot of times that caveat gets lost in translation. It was lost on me anyways at that point in my career. To me it just felt like, "Super smart experts say X, Joe Shmoe says Y, I think I'll go with the super smart experts."
Let's get back to the Angular example. I had spent a lot of time reading through all of these books and courses and stuff about Angular. So in my mind I had this repository of knowledge that all of these experts imparted on me. And my boss was telling me to violate that. It really suck out to me how much what he was telling me goes against everything I've been reading.
However, as I sit here today writing this, I disagree with my former self and agree with my former boss. In the particular situation we were in, I think it would make sense to ditch the weird directives. Or at least only use them for presenational stuff, and not keep state inside of them.
Here's the thing. On that team, I was really the only one who was an "Angular guy". We had one other guy who was an "Angular guy", but he actually didn't work in the same codebase. He mostly worked on this Django codebase. The other devs were Rails devs. Some were better with Angular than others, but in general I think that given the makeup of the team (and what we anticipate about how the team will look in the future), it'd make sense to avoid the weird parts of Angular.
There's a tradeoff with using obscure features. The benefit is that they can be powerful, make your code cleaner, whatever. The cost is that people who aren't familiar with them will have trouble understanding them. I think the job of an organization is to figure out how to navigate that tradeoff.
Maybe you want to be really careful about hiring domain experts who know all about the obscure features. Maybe you want to have non domain experts on your team, and just have them take their time learning all of the obscure features. Or maybe you just want to punt and shove all those obscure features off to the side. It depends on the situation.
If you have any thoughts, I'd love to discuss them over email: adamzerner@protonmail.com.
If you'd like to subscribe, you can do so via email or RSS feed.