I agree with what the author is saying, however, I think that the overall message of sticking with something, and not leaving when you encounter the first sign of monotony is applicable to software engineering more specifically than the author describes. I will provide an anecdote from my career to illustrate what I mean.
I have been working at the same company for almost 4 years. During those 4 years I have worked on the same project and haven't really switched teams. I've seen employees come and go, architecture decisions made and debated ad nauseam, and so forth. I am currently in the processing of re-implementing some functionality and architecture decisions that I made when I first started (~4 years ago).
When I made these implementation decisions I thought they were the best approach based on my experience at the time. However, having stuck around all these years and seen the product and business evolve, these decisions have turned out to be either poor choices or not the most optimal. As a consequence I've derived a lot of experience and wisdom from revisiting these past decisions, as I am now able to go back with production data and performance characteristics and see how they work or do not work. This software that I wrote way back when functioned in production and worked flawlessly without ceremony for approximately 3.5 years. Only recently and under a changing production environment has this code started to become a pain point.
Had I been part of the new every two crowd I would have never been able to see how my designs and solutions would hold up, or fall down, over the years of their life span. Furthermore, I never would have gained the wisdom and experience that comes from implementing something and having to come back and re-visit it years later.
This is really the takeaway message I understand from the author. Basically, when you only do what strikes your fancy and change your priorities with the weather, you lose out on the sort of experience and opportunity for growth that I have had in the past few weeks.
Agreed. The guy is railing against the emerging twitterati culture of folks who bounce from one gig to the next, blurting about the trendiest new Javascript library and spewing garbage code that someone else then gets to maintain.
I don't know. I've had a "new every two" experience over the last decade, and I still use "old" languages (C, C++, Fortran, even some Ada).
I'm in my mid-30s, and my view is that the kind of person you're talking about isn't restricted to any "emerging twitterati" culture. "Fad followers" exist in every age demographic.
Also, my "new every two" experiences give me a lot more breadth of experience than some poor "lifer's" years slogging away maintaining his project. It also gives me more depth in each area--because I haven't been fossilizing over the same code, in the same language, for the same project, day in and day out.
As an edit, I'll add: the (relative) ease with which (some) of the "youth" in our profession are able to switch things up so regularly ought to be viewed as a virtue. I can't stand the culture of sharing all the intimate personal details of their lives on the internet, but this is one thing which in my view they do right.
I have been working at the same company for almost 4 years. During those 4 years I have worked on the same project and haven't really switched teams. I've seen employees come and go, architecture decisions made and debated ad nauseam, and so forth. I am currently in the processing of re-implementing some functionality and architecture decisions that I made when I first started (~4 years ago).
When I made these implementation decisions I thought they were the best approach based on my experience at the time. However, having stuck around all these years and seen the product and business evolve, these decisions have turned out to be either poor choices or not the most optimal. As a consequence I've derived a lot of experience and wisdom from revisiting these past decisions, as I am now able to go back with production data and performance characteristics and see how they work or do not work. This software that I wrote way back when functioned in production and worked flawlessly without ceremony for approximately 3.5 years. Only recently and under a changing production environment has this code started to become a pain point.
Had I been part of the new every two crowd I would have never been able to see how my designs and solutions would hold up, or fall down, over the years of their life span. Furthermore, I never would have gained the wisdom and experience that comes from implementing something and having to come back and re-visit it years later.
This is really the takeaway message I understand from the author. Basically, when you only do what strikes your fancy and change your priorities with the weather, you lose out on the sort of experience and opportunity for growth that I have had in the past few weeks.