First posted on /r/javascript, but I think it's worth posting here too:
I was a member of the YUI team until a few months ago. I'm still at Yahoo now, just on a different team, but just wanted to give my own thoughts on this (I don't represent the company or the YUI team).
My software engineering career started with the YUI team - I actually joined as an intern at Yahoo because of a Reddit post on /r/javascript. I was pretty new to engineering in general back then, and as a biology major with no real professional experience, I didn't have an easy time getting internships. Jenny, the manager of the YUI team back then, really took a chance on me, and that really changed my entire career path.
I solved a bunch of YUI bugs, added a few features here or there, and I always tried to help other folks on #yui on IRC, the mailing list, or in-person here at Yahoo, which I really enjoyed. I learned a crazy amount of JavaScript, some pretty advanced debugging / performance profiling techniques, and even gave some talks. Eventually, a lot of people always came to me first whenever they had a question about YUI, which was pretty cool.
From the view of some people in the JavaScript community, YUI was always considered a huge, monolithic framework that was only good for widgets. I never thought that was the case - YUI pioneered a lot of the techniques that are popular in advanced JavaScript development today, like modules, dynamic loading, and creating logical view separation in your code. A lot of the influence in RequireJS / CommonJS / ES6 modules can be seen from what YUI did first, which people used to consider "over-engineering".
With a lot of new development in JavaScript though (data-binding, tooling like Grunt / Yeoman, promises and other async handling techniques), it was always hard for YUI to keep up with new features while still being able to maintain backwards compatibility with the constantly deploying products that people were building at Yahoo. We had to support product teams while also building out the framework at the same time, and making sure the user-facing products were the best was more important. Eventually, it was hard when developers who were familiar with newer JavaScript tools tried to use YUI, but ended up having to spend quite some time with the framework just to get it working with the rest of the JS ecosystem.
In the end, I wasn't involved with this decision, but I think it was the right thing to do. A lot of the YUI (now YPT) team and other front-end teams at Yahoo are now working on helping out with more cutting-edge core JavaScript work, like internationalization (https://github.com/yahoo/intl-messageformat) and ES6 modules, as well as building out components for newer frameworks like React and Ember (https://github.com/yahoo/flux-examples). Yahoo still has a lot of really strong front-end developers, and working on these more important core components is more beneficial to both Yahoo and the JS community as a whole, than continuing to maintain a framework that's a walled garden.
The one thing to take away from this is that no technology lasts forever, and in the end, what the user sees is the most important, whether it's JavaScript, Android / iOS, or holographic smartwatches.
I'll be a bit melancholy today, but I'll raise a glass to YUI tonight. RIP.
I have to give some serious props for Yahoo for taking a chance on a new dev with little experience. A lot of people go through the same frustrating thing, and many potentially talented people get looked over. Your story is inspiring (as well as a little wink to hiring managers :)
Also, super excited about the work Yahoo has been doing with React. Keep it up!
When I was a hiring manager at Yahoo, I constantly included a mix of new developers to veteran ones (perhaps a 80/20 split) for many reasons:
+ New devs can soak up a ton of knowledge quickly.
+ New devs don't come with a lot of baggage and tend to enjoy trying lots of new things.
+ New devs brought new ideas to the team that often challenged traditional ways of thinking.
+ While veteran devs acted as mentors and shared best practices.
From a recruiting standpoint, it's also easier to find new developers than veteran ones. So many companies fight for experienced talent that they overlook inexperienced talent, which meant I could assemble a good team relatively quickly.
It changed the recruiting process quite a bit though. Interviews became more about assessing potential and ability to learn than existing skills (which I think is more important anyways). It's not easy to assess for these things though.
It also changed the training process and team dynamic. The environment was one of constant learning and collaboration. New ideas were welcomed, code reviews were frequent, everyone was encouraged to hold a quick informal brownbag session on something they learned (even if others were known to be the "experts"), formal mentoring programs were established, etc.
And it made the veteran hires even more important. These devs needed to not only be strong technically, but strong with interpersonal skills too. But someone who can do this and support an inexperienced team with lots of potential is worth their weight in gold.
A lot of good developers emerged from this process. And I should add that new != young developers. There were some devs who changed careers to become devs, and shared the same energy and ability to learn as recent college graduates.
I wish I had kept a list of all the ideas you brought to the table that significantly influenced the team. From the Clarion method of code reviews to team seating arrangements to all the innovative ideas that we later saw being implemented by other startups, you were and are a font of inspiration and ideas! Your current team is extremely lucky to have you!
This is great. I got my first tech-related job (my first job ever, to be fair) because a hiring manager took a chance on me. This opened the doors for me to work at some great companies.
I was a member of the YUI team until a few months ago. I'm still at Yahoo now, just on a different team, but just wanted to give my own thoughts on this (I don't represent the company or the YUI team).
My software engineering career started with the YUI team - I actually joined as an intern at Yahoo because of a Reddit post on /r/javascript. I was pretty new to engineering in general back then, and as a biology major with no real professional experience, I didn't have an easy time getting internships. Jenny, the manager of the YUI team back then, really took a chance on me, and that really changed my entire career path. I solved a bunch of YUI bugs, added a few features here or there, and I always tried to help other folks on #yui on IRC, the mailing list, or in-person here at Yahoo, which I really enjoyed. I learned a crazy amount of JavaScript, some pretty advanced debugging / performance profiling techniques, and even gave some talks. Eventually, a lot of people always came to me first whenever they had a question about YUI, which was pretty cool.
From the view of some people in the JavaScript community, YUI was always considered a huge, monolithic framework that was only good for widgets. I never thought that was the case - YUI pioneered a lot of the techniques that are popular in advanced JavaScript development today, like modules, dynamic loading, and creating logical view separation in your code. A lot of the influence in RequireJS / CommonJS / ES6 modules can be seen from what YUI did first, which people used to consider "over-engineering".
With a lot of new development in JavaScript though (data-binding, tooling like Grunt / Yeoman, promises and other async handling techniques), it was always hard for YUI to keep up with new features while still being able to maintain backwards compatibility with the constantly deploying products that people were building at Yahoo. We had to support product teams while also building out the framework at the same time, and making sure the user-facing products were the best was more important. Eventually, it was hard when developers who were familiar with newer JavaScript tools tried to use YUI, but ended up having to spend quite some time with the framework just to get it working with the rest of the JS ecosystem.
In the end, I wasn't involved with this decision, but I think it was the right thing to do. A lot of the YUI (now YPT) team and other front-end teams at Yahoo are now working on helping out with more cutting-edge core JavaScript work, like internationalization (https://github.com/yahoo/intl-messageformat) and ES6 modules, as well as building out components for newer frameworks like React and Ember (https://github.com/yahoo/flux-examples). Yahoo still has a lot of really strong front-end developers, and working on these more important core components is more beneficial to both Yahoo and the JS community as a whole, than continuing to maintain a framework that's a walled garden.
The one thing to take away from this is that no technology lasts forever, and in the end, what the user sees is the most important, whether it's JavaScript, Android / iOS, or holographic smartwatches.
I'll be a bit melancholy today, but I'll raise a glass to YUI tonight. RIP.