Why junior developers are learning bad habits from Angular


When I wrote the other day about the fact that I won't be using Angular in my next project, one of the key points I raised was that junior developers are learning some bad habits when working with Angular. Quite a few people agreed with me - primarily because they had experienced it themselves, and that was the end of the discussion.

But on the other hand there were two more camps I noticed; the first being developers who may not have worked on Angular and genuinely want to know why I made those statements, and the second camp, those that said I was just spouting FUD because I didn't explain myself in detail, which surprised me a bit because those are developers who presumably have been working on Angular and in my opinion should already know about the pitfalls and their effect on juniors. And if they don't already know, then I thought I had linked to enough other (much better) articles explaining those pitfalls.

So either the second camp is somehow blinded and does not want to see, or they're just lazy and didn't bother reading through the linked posts. Given the links, I wasn't particularly worried about explaining myself to the nth degree, plus the fact that my article was already edging up to 2.5K words and would probably lose even more readers if it was any longer. Either way, they're probably not the ones reading here now...

This post is for those who genuinely want to know, but haven't pieced it together for themselves yet.

OK, so why single out junior developers

Well, firstly, it's because they're obviously the most likely to fall into the traps - but secondly, and most importantly, they don't know right from wrong yet. It's like telling a child not to cross the road without holding an adult's hand. They don't know about cars early on, and hopefully they'll never find out first hand just how destructive they can be. I would like to protect my junior developers in a similar fashion, and Angular isn't helping, but I'll explain why.

"Traps?!" I hear you say...

I specifically mentioned "bad habits", and I chose the term carefully, because habits are typically things you tend to learn early on in a practice, and once they're bedded in, it takes extra-ordinary effort to shake off. Senior developers in my experience tend to have been burned through this cycle once or twice already, and so are more likely to be open to better solutions when they see things just aren't right. Juniors... not so much - they just power on through hoping for a safety net.

For my first example, I'll use $scope as ~~my whipping boy~~ a way to establish a precedent for the differences between senior and junior developers. Consider the following fictitious Angular Controller;

(function () {
    var app = angular.module('jsk', []);

    function JskController($scope) {

        $scope.anonymous = function () {
            var user = !!$scope.username; //Noooooooo!!!
            return !user || $scope.username.length === 0;
        };

        $scope.displayName = function () {
            if ($scope.anonymous()) {
                return;
            }
            return $scope.name;
        };
    }
    app.controller('jskCtrl', JskController);
})();

The Controller is just a wrapper for $scope....why? What's the point in even having it if it's just a proxy? It's supposed to represent the view-model at the very least. This is also typical of developers who do not approach a problem with testing in mind, and have no issue passing $scope around thereby coupling the Controller to the data-binding, and forcing a ton of unnecessary mocking if they even bother to write unit tests in the first place.

Many would not even see the problem here, and just as children don't know cars can hurt, juniors don't know just how destructive this anti-pattern can be to performance, separation of concerns and long term code base maintenance.

This simple little anti-pattern will now pepper your code throughout if not rooted out

And now that the junior developer has done this once, they will do what every junior developer does exceedingly well - they will Copy+Paste their way into oblivion. This simple little anti-pattern will now pepper your code throughout if not rooted out, and that requires an experienced head that knows enough to spot it and provide a better way. Rinse and repeat.

Polluting other frameworks

Now take that same junior developer and move them onto another project that just happens to be written with another framework, let's pick Durandal for example. There's significantly more JavaScript™ and a heck of a lot less framework stuff that you touch daily. The same can be said for frameworks like Backbone and Ampersand. You're basically working with pure code mostly, and using the framework around the periphery where it stays out the way, but where it can be a useful time-saver.

That's how I did it on that other project

In the hands of a junior fresh out of the Angular project, all of a sudden you see application state get pulled in and passed around just like it was done with Angular. When confronted, they just shrug and say "That's how I did it on that other project" - and so starts the cycle of corrective instruction. The juniors who have never touched Angular, so far in my experience don't tend to exhibit these tendencies straight off the bat. They tend to learn from patterns being used in the code base they're working on and from the most recent, and it took me a long while to see it.

Other habits juniors learn from Angular

I'm not going to give an example for each - that was the point of my ~~whipping boy~~ example above. Suffice it to say that this post is long enough already, and that there most certainly is an example you'll be able to find if you Google for it.

Off the top of my head, the list of things juniors do includes, but is not limited to:

  • Overuse of the eventing system ($watch, $emit, $broadcast) leading to performance problems and memory leaks and not realizing it or being able to debug it
  • Writing Controllers and Directives that take the sorts of dependencies which make them nearly impossible to test.
  • Views that are heavily dosed with logic - but more on that later
  • Their first experience of DI is quite often that in Angular and it's horribly broken. Since the "patch" which fixed the minification issues, it's still really just a square peg in a round hole with woeful support for scope and lifetime and features which most DI gives you for free such as child containers. They end up hating DI and shy away from it on other projects.
  • Strange bugs that (when called over) have us all scratching our heads until one of use realizes - oh yeah, sorry we forgot to mention that pretty much everything passed around is global, and Directives etc. aren't namespaced, so I see what's happened - you've got a naming collision there
  • It's getting late, but I hope you get the idea...

Not many of these points above are exclusive to Angular of course and could be claimed are common mistakes for juniors to make in general. One of the things I look for in a framework is to guide you to towards the "pit of success", but if anything, in my experience, without constant supervision and rework, juniors are led towards the "pit of failure" instead because of the number of hoops one has to jump through to please the framework or eke out performance gains. I say "hoops", but what I really mean is "hacks"...

Hacks and other debauchery

Data-binding is broken. Some changes to Angular under the covers have made it in because of this, but having to go back and be explicit about which things should be one-way versus two-way is a big job, especially on large invested code bases with very few tests.

What's that got to do with juniors? Well, they possibly did a lot of the data-binding work up front, and will continue to do so as the app is maintained. Can you trust them to use their judgment as to which type of binding to leverage? Do you even know yourself? Are you sure?

That's the point where I start asking if it is worth it or not

I already explained why I dislike the view templating system, but I mostly dislike it because of what juniors do with it. Apart from being horribly inefficient with the DOM, terribly difficult to read or give out to design agencies, when you leave the juniors alone with them long enough, you'll find that they are exceptionally good at shoving all sorts of logic and programming in there. Maybe not something that would cross the mind of a senior developer straight away, but when you see it, you literally catch yourself saying... "wait...What?!"

You have to go through every commit with a fine toothcomb and rap them on the knuckles each time they do it. But there are so many ways in which they can make this mistake, (because they find all their damn examples on the bloody internet in blog posts like this one) which means that they end up with very red knuckles and I have all my hair torn out. That's the point where I start asking if it is worth it or not. And the answer is no, no it most certainly is not.

Conclusion

I know that a lot of the things I've mentioned above can be attributed to a simple fact that juniors make mistakes, and require guidance to get better, but I've been in this game for over 20 years now, and at no point in my career - apart from possibly working with SharePoint ;-) - have I struggled as much to get the juniors to "step away from the keyboard" and think about the crap they're writing.

I hope that this post has gone some way towards helping you understand why I personally want to keep junior developers away from Angular. I hope it hasn't come across as pure FUD, and rather measured opinion, but by all means, I'm happy to stand corrected if you feel there is a better way, so feel free to leave your comments and we can have a discussion about it!

Until next time, RobertTheGrey



4 comments

Bob Senoff
1/29/2015 2:25:35 PM
Thanks @robertthegreyfor the breakdown. I see Angular as a big hitter in the space and due to its popularity it makes it a candidate for large projects. There's a ton of guidance out there on how to do it right, but newer programmers just copy+paste their way until they can build enough confidence to write stuff themselves.

Braun Goodson ✞
4/8/2015 11:53:08 PM
@bobsenoff This. I think what the author did a great job of avoiding is that angular *isn't for juniors*. The title should really be, "why junior developers shouldn't start using angular first."

Alyssa Nicoll
1/29/2015 8:53:24 PM
As with any front-end framework, it can be difficult to enforce good conventions. Angular can be difficult to navigate and form good practices, I will admit. However, I do not feel your article explains well, why you believe this to be true. Instead of explaining in better detail *why* something is a bad practice, you passive aggressively call people desiring more of an explanation, naive children. I think this article is more of a rant against Angular and its community instead a logical discussion of what is wrong with the framework.

Robert Greyling
1/29/2015 9:09:14 PM
Thanks Alyssa for the constructive feedback – it was never my intention to come across as having a rant at Angular, and especially not the community. As I said in my last post, I actually have tremendous respect for the community that’s been able to make Angular thrive. In fact, I believe it’s entirely down to the community that it’s even still around rather than the merits of the framework itself, but I guess I made that part pretty clear in my articles. Regarding the _why_, I guess it’s hard for me to understand that you can’t see the why from my explanation, because I used examples, and these are really common examples easily Googled as well, including their recommended fixes: [for example](http://csharperimage.jeremylikness.com/2014/11/the-top-5-mistakes-angularjs-developers.html). Possibly, I think that comes from the fact that I am speaking from a place where I have all this information in my head regarding what I’ve experienced with my juniors and readers don’t, and perhaps I’m not getting enough of it out in words to bring the points across properly without sounding like a rant. Please do note however, that I never once called the “people desiring more of an explanation” naïve children. I was using naïve children as a metaphor to compare junior developers new to the world of coding in general tossed into Angular projects to sink or swim. It’s the juniors (my juniors specifically) who are naïve, not the people seeking clarification. The only aggression I showed _some_ fraction of those was to lament the fact that they were probably too lazy to read the articles I linked to – nothing more. I hope that explains some of my thinking, but thank you again for the well intentioned feedback, it will help a lot when I sit down to write again.