> Most of us will get bored without novelty. That's why the software industry has a recycling mechanism to keep things fresh and interesting for us: every once in a while a new, or different, language/framework will rise and light the path for a brighter future, overthrowing the existing standard, demanding that we learn it to be on top of the game.
IMO, new frameworks aren't that interesting in most cases. They're simply a reorganization of what we already know at worst and a watered down version of a new principle at best.
- Procedural programming
- Functional programming
- Concurrent/parallel programming
- Security
- Making apps or web apps
- Compiler construction
- Computer graphics
- Machine learning
and a few other topics, those are new things to learn IMO. When you know procedural programming, then compiler, or database construction isn't obvious at all.
However, the first moment I learned React, I felt it was quite obvious from the get go. Sure, some practice was needed to really be good at it, but the first time I created a toy compiler, I was also trying to grok it and with frameworks that has never been the case (after my first one which was Cocoa Touch).
I always felt like the software industry is like a Shepard tone [0]. Feels like it's always rising but it's actually a cycle of overlapping trends that start over and over. And the illusion is kept for both programmers and users as long as it doesn't start over with everything at once but just one bit at a time.
Like a lawn where you cut just one strip every day and you never get to see the whole lawn either too grown, or "shaved" to the ground. But it's the same lawn and it never grows taller than that last strip.
This is a fallacy of aging developers. Sure, some concepts resurface, but the same way you can't step in the same river twice, things are never the "same".
One example would be functional programming - sure, the concept was there since the 50s, but what did they use it for? What was the ecosystem? How did the functional aspect affect the tooling, the libraries? In these terms, FE itself is not revolutionary, using it in certain contexts, and with certain frameworks it is.
> Most of us will get bored without novelty. That's why the software industry has a recycling mechanism to keep things fresh and interesting for us: every once in a while a new, or different, language/framework will rise and light the path for a brighter future, overthrowing the existing standard, demanding that we learn it to be on top of the game.
This is one of worst aspects of programming to me. Instead of focusing on making the best product for the people, many feel the need to do the same thing again and again (broken) differently.
Of course, learning is fun, but can't you guys find things outside of programming to learn and let the field mature?
> Instead of focusing on making the best product for the people, many feel the need to do the same thing again and again (broken) differently.
Or, you get Resume Driven Development (RDD) where someone with a free hand says: "Hey, this LAMP stack really should be containerized, so I can slap 'Docker' on the CV!"
Haha, I'm actually working with a very strong personality who, after joining 3 months ago, has decided that the project must adopt their favourite technology stack.
Yesterday they actually said in a meeting that this was because they wanted to put it on their CV and I'm pretty sure they were serious too.
I'm a contractor and so it's not really for me say if this switch is a good or really bad idea given the projects deadlines. ;)
Not to put words into your mouth but the problem comes with when we have to choose what the one true way to do something is that we should all stick to.
Since every language, every pattern, every library is flawed in some way, this is not an easy problem to solve.
It's all trade-offs and you have to choose your poison at some point.
Agreed, it's frustrating that the article has an attention-grabbing headline and entirely fails to deliver. It's clickbait. From the article:
> So what was the worst decision of my career? I don't know.
And that's it. There's no further discussion of their career mistakes. The article should have been titled something like Complexity and change in software engineering.
If you're interested in reading about an actual career mistake and what can be learnt from it, I recommend the classic The Mythical Man-Month. From the book:
> It is a very humbling experience to make a multi-million-dollar mistake, but it is also very memorable.
IMO, new frameworks aren't that interesting in most cases. They're simply a reorganization of what we already know at worst and a watered down version of a new principle at best.
- Procedural programming
- Functional programming
- Concurrent/parallel programming
- Security
- Making apps or web apps
- Compiler construction
- Computer graphics
- Machine learning
and a few other topics, those are new things to learn IMO. When you know procedural programming, then compiler, or database construction isn't obvious at all.
However, the first moment I learned React, I felt it was quite obvious from the get go. Sure, some practice was needed to really be good at it, but the first time I created a toy compiler, I was also trying to grok it and with frameworks that has never been the case (after my first one which was Cocoa Touch).