Fatigue & Identity

05. April 2016 Uncategorized 1

One of the trends in development recently has been to talk about fatigue. As far as I know, it started with JavaScript fatigue. The idea being that JS is changing so much and so often that people can become exhausted trying to keep up.  A mere 2.5 years ago, when I started at my current job, Backbone and Marionette were pretty cutting edge here in the mid-west. There weren’t a lot of people doing them, and even fewer doing them on production applications.  In that time, I’ve seen Marionette, Angular, some Knockout, Dart, and Typescript. Now we’re seeing things like Elm and React. All of this to be able to have a rich UI on the web. And those are just the languages. That’s not even talking about things like Grunt, Gulp, Webpack, Browserfy, RequireJS, etc.

The fatigue sets in when developers try to figure out how to stay up to date with technology. Just when you think you’re getting good at Marionette, Angular comes out. You have a grasp on Angular, and they overhaul it with Angular 2. The thought is, “How can I have time to learn the next framework before it’s obsolete.”  This typically then leads to developers longing for the days of when libraries only changed once a year or so (or less, if you were waiting to upgrade from .Net 2 to .Net 3.)

I personally haven’t felt much fatigue. I might even be described as JavaScript apathetic. (Or possibly as having fatigue fatigue…I’m tired of being tired.) And I really enjoy writing JavaScript.

So I started thinking recently, why don’t I suffer from JavaScript fatigue? Is it because I’m far superior to all these developers who experience JavaScript fatigue? I seriously doubt that. Is it because I’m too old to care? That’s possible, but while I might be nearing ancient in the JavaScript world, I’m not that old.

Then I started thinking of something I started learning around 10 years ago, and that is, what is my identity?

If my main identity is a developer, I might experience some fatigue as I see how quickly the industry is changing. If I identify primarily as a JavaScript developer, I probably have more fatigue than just being a developer. If I find my identity in being an Angular developer, then I’m probably freaking out and suffering a lot of fatigue because I don’t know if I should learn Angular 2 or React next. Has everything I’ve done the last two years been a lie?

But my ultimate identity is not in any of these things. Yes, I’ve just wrapped up an app that was written using Angular. I’ve been doing JavaScript applications for about 2.5 years, and I’ve been a professional developer for almost 16 years. But that’s not who I am.

So who am I? Where do I find my core identity? My identity is wrapped up in being a child of God. When I’m anxious, I remind myself of Romans 8.33 “Who shall bring any charge against God’s elect? It is God who justifies” (ESV).  If I’m a child of God then everything else comes in a distant second place. What JavaScript library I’m going to be using next week is one of the least of my worries.

This was one of the biggest & most important things I learned during my time in seminary. My identity impacts so much of what concerns me and how I’m able to handle things like JavaScript fatigue.


1 thought on “Fatigue & Identity”

  • 1
    Nicholas Tuck on April 5, 2016 Reply

    Interesting thoughts on identity fatigue. I imagine their is many people this can apply to. Living through the transition from the death of flash/flex to html5, there was a huge identity crisis in that community.
    For me fatigue is less so identity toward a tool/library and more so a lack of forward progress. New tech is popping up and being “adopted” (somehow we tell ourselves that because it was at a conference and used it) faster than many real projects can make it into production. It’s really hard to utilize experience and make forward progress when you have a new tool every 3 months that we have to try and must use because it will solve all the old problems we did figure out how to manage but will add new problems we don’t know how to manage. Learning curves can be quite steep, and costly, to the point only a couple people understand that technology on the team, because their next project in a few months will use new tech with new problems so why bother.
    I was once asked in an interview “You are young to be an expert in X technologies, what do you think counts as being an expert, reading blog posts and trying it out once or twice?” It wasn’t a great question but a big part of my reaction to that question was: building something with the tool, taking it to production and maintaining it. Then can we really know what worked and didn’t work. It often feels like we barely even think about production before picking the next new tool.

Leave a Reply

Your email address will not be published. Required fields are marked *