So the answer for me was to research frameworks in my spare time. Then if they were promising, look for opportunities to introduce them into work. If I am not allowed to decide that, I convince or demo it for people who are. Still no dice? See if the company has other projects where you can explore those interests. Still no? You make a decision on what is more important to you. Stay if there is compelling reason, or look for another job.
However, I would not recommend moving on just to learn new frameworks. I have learned a number of them over the years, and they will all disappoint you. They are rehashes of the same ideas (usually components), except you have to learn to code against the framework's specific opinion. Then when you change to a different framework you have to learn a new opinion with different gotchas, and the same maintenance burden. (Granted, some frameworks are significantly worse than others, but all of them are fundamentally bad at maintenance.) The more important thing to focus on is Separation of Concerns in whatever framework you use. And conforming your mindset to solving the business problem over the technical one is most important of all. (Sometimes we make the solution more complex than is needed by focusing on the technical, when the solution to the business problem would have been much simpler.)
I am a large fan of the MVU pattern and functional languages like Elm for front-end. It is harder to get started and requires a shift in thinking. But maintenance and refactoring is fairly low-risk. Whereas component-based is more familiar and easy to get started but (in my experience) builds up a lot of accidental complexity over time. Plus with MVU, the application is almost entirely my own functions and data structures and the patterns I setup with them. It is a refreshing change from having to (memorize and) conform to whatever abstractions a framework decides are important. Under MVU, I find that bad design can be felt more directly. If the solution is painfully complicated, then it probably is not a good design. And since it is easy to refactor, early mistakes can be corrected later. Whereas frameworks try to identify pain and apply a numbing agent so you can ignore it, potentially masking bad design. The downside to Elm -- aside from the initial mental shift of functional programming -- is fighting with the compiler and "type tetris", but these trade-offs seem worthwhile for the benefits.
I'm not thinking of switching jobs because of the new Frameworks learning :). The project I'm working in my current job is great, it has taught me a lot (it's OOP project BTW haha). I'm more interested in switching jobs because of two main reasons:
Number one, an opportunity to lead and learn from the people who have been working on different frameworks, I have been working for more than 3 years with the same team in the same project, and sometimes is good to hear different opinions and different ways of thinking to improve. Unfortunately looking for another project inside the company is not an option due to all the company's projects (99% for FE) are under that internal Framework. Doing a demo using a different Framework to stakeholders is not an option, the project might have +6 years of development with 60+ people involved, it's huge and highly coupled :( not an option to introduce a section with a new Framework.
Number two, I'm interested on living in another country and learn from other culture, not an option to ask for a transfer in my current job.
I agree with you on learning new frameworks: "learn different opinion, better than others in some things, etc." I have been following FE Frameworks since 5 years now, and yikes there are lots of them.
A couple of weeks ago I first watched a conference about Elm and turns out that it's very interesting, and as you mentioned looks really easy to refactor. I'm going to give it a try and give it 1 hour a week to get familiar with it. :)
Another thing that I'm going to try is to have more participation on Open Source Projects. Hopefully this is considered as work experience and I will be a step forward to get there.
Thanks!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
So the answer for me was to research frameworks in my spare time. Then if they were promising, look for opportunities to introduce them into work. If I am not allowed to decide that, I convince or demo it for people who are. Still no dice? See if the company has other projects where you can explore those interests. Still no? You make a decision on what is more important to you. Stay if there is compelling reason, or look for another job.
However, I would not recommend moving on just to learn new frameworks. I have learned a number of them over the years, and they will all disappoint you. They are rehashes of the same ideas (usually components), except you have to learn to code against the framework's specific opinion. Then when you change to a different framework you have to learn a new opinion with different gotchas, and the same maintenance burden. (Granted, some frameworks are significantly worse than others, but all of them are fundamentally bad at maintenance.) The more important thing to focus on is Separation of Concerns in whatever framework you use. And conforming your mindset to solving the business problem over the technical one is most important of all. (Sometimes we make the solution more complex than is needed by focusing on the technical, when the solution to the business problem would have been much simpler.)
I am a large fan of the MVU pattern and functional languages like Elm for front-end. It is harder to get started and requires a shift in thinking. But maintenance and refactoring is fairly low-risk. Whereas component-based is more familiar and easy to get started but (in my experience) builds up a lot of accidental complexity over time. Plus with MVU, the application is almost entirely my own functions and data structures and the patterns I setup with them. It is a refreshing change from having to (memorize and) conform to whatever abstractions a framework decides are important. Under MVU, I find that bad design can be felt more directly. If the solution is painfully complicated, then it probably is not a good design. And since it is easy to refactor, early mistakes can be corrected later. Whereas frameworks try to identify pain and apply a numbing agent so you can ignore it, potentially masking bad design. The downside to Elm -- aside from the initial mental shift of functional programming -- is fighting with the compiler and "type tetris", but these trade-offs seem worthwhile for the benefits.
First of all, thanks a lot for your reply Kasey.
I'm not thinking of switching jobs because of the new Frameworks learning :). The project I'm working in my current job is great, it has taught me a lot (it's OOP project BTW haha). I'm more interested in switching jobs because of two main reasons:
Number one, an opportunity to lead and learn from the people who have been working on different frameworks, I have been working for more than 3 years with the same team in the same project, and sometimes is good to hear different opinions and different ways of thinking to improve. Unfortunately looking for another project inside the company is not an option due to all the company's projects (99% for FE) are under that internal Framework. Doing a demo using a different Framework to stakeholders is not an option, the project might have +6 years of development with 60+ people involved, it's huge and highly coupled :( not an option to introduce a section with a new Framework.
Number two, I'm interested on living in another country and learn from other culture, not an option to ask for a transfer in my current job.
I agree with you on learning new frameworks: "learn different opinion, better than others in some things, etc." I have been following FE Frameworks since 5 years now, and yikes there are lots of them.
A couple of weeks ago I first watched a conference about Elm and turns out that it's very interesting, and as you mentioned looks really easy to refactor. I'm going to give it a try and give it 1 hour a week to get familiar with it. :)
Another thing that I'm going to try is to have more participation on Open Source Projects. Hopefully this is considered as work experience and I will be a step forward to get there.
Thanks!