4 ms·

(This isn't a personal attack on you or your ability, I don't know you) I think yours is a dangerous attitude, I've seen a lot of mess produced by people who c

(This isn't a personal attack on you or your ability, I don't know you) I think yours is a dangerous attitude, I've seen a lot of mess produced by people who come in to angular knowing other frameworks and their output is terrible. Part of that is because angular is different, it's not very nice and it has obscure knowledge needed to make it play nicely with unit testing. If you take an ember / backbone / whatever expert and give them a few weeks angular training they'll rock a todomvc but full apps often end up with controller-as-a-god-object. Genuine experts would be really nice to find, but it's really difficult because frameworks aren't given time to mature before the smartest people have moved on to other frameworks. You're right that employers should hire on general understanding and give time, but the required time is typically 6 months and a failed project or two. Many employers don't make and don't want to make that kind of human-capital investment anymore. The "rockstar" who knocked something up pads their resume with another project with a hot new framework, got experience with another new set of tooling and can leverage that to move somewhere else to produce more working but hard to maintain code in another hot new framework because their CV is padded with experience showing they're a quick learner, but the company left behind pays the cost in maintenance. A genuine angular expert will likely be well employed for a while come helping troubleshoot and clean up the mess left by the cool crowd. p.s. I am not an angular dev, this complaint can be leveled at a lot of hot new tech, particularly but not just the javascript front-end world, it equally applies to people who knocked up go microservices at a .Net shop, or hastily introduced mongo to replace oracle, etc., etc.

perlgeek 10y ago
> I think yours is a dangerous attitude, I've seen a lot of mess produced by people who come in to angular knowing other frameworks and their output is terrible. > > Part of that is because angular is different, it's not very nice and it has obscure knowledge needed to make it play nicely with unit testing. A possible approach is to let developers new to a framework on a prototype or toy project first, and, very important, throw away that prototype. Yes, that means you might have to wait two or three weeks longer until you get started with the real project, but the result will be so much better. But that's one of the prices you pay for using an immature technology. For a more mature one, you could read a book on successful usage pattern of the technology.
michaelchisari 10y ago
> full apps often end up with controller-as-a-god-object. Wouldn't a depth of knowledge of dev patterns (and anti-patterns) be enough? I don't have to know anything about Angular to know that's a bad idea.
acdha 10y ago
> I think yours is a dangerous attitude, I've seen a lot of mess produced by people who come in to angular knowing other frameworks and their output is terrible. Outside of a hire-an-expert consulting gig, I really would say the problem here lies almost exclusively on the engineering management, or lack thereof, and broader staffing decisions. I don't think it's necessary to have a project fail for someone to understand a tool[1] but the ability for someone to get up to speed is a function of the time invested in things like mentoring and code-review. Yes, many companies make the short-sighted decision to skimp on that investment but that needs to be recognized and fought as a management problem – any project is going to suffer in those conditions even if your entire team is staffed with experts because understanding the actual business problems is as hard as the tech stack and if you can't carve out time to think about a few controllers, there's no way that the rest of the problem doesn't have problems which are at least as bad. 1. If true, that would be a huge sign that the tool has major design failures and is not suitable for production use rather than an argument against hiring people who aren't already experts.

perlgeek 10y ago

> I think yours is a dangerous attitude, I've seen a lot of mess produced by people who come in to angular knowing other frameworks and their output is terrible. > > Part of that is because angular is different, it's not very nice and it has obscure knowledge needed to make it play nicely with unit testing. A possible approach is to let developers new to a framework on a prototype or toy project first, and, very important, throw away that prototype. Yes, that means you might have to wait two or three weeks longer until you get started with the real project, but the result will be so much better. But that's one of the prices you pay for using an immature technology. For a more mature one, you could read a book on successful usage pattern of the technology.

michaelchisari 10y ago

> full apps often end up with controller-as-a-god-object. Wouldn't a depth of knowledge of dev patterns (and anti-patterns) be enough? I don't have to know anything about Angular to know that's a bad idea.

acdha 10y ago

> I think yours is a dangerous attitude, I've seen a lot of mess produced by people who come in to angular knowing other frameworks and their output is terrible. Outside of a hire-an-expert consulting gig, I really would say the problem here lies almost exclusively on the engineering management, or lack thereof, and broader staffing decisions. I don't think it's necessary to have a project fail for someone to understand a tool[1] but the ability for someone to get up to speed is a function of the time invested in things like mentoring and code-review. Yes, many companies make the short-sighted decision to skimp on that investment but that needs to be recognized and fought as a management problem – any project is going to suffer in those conditions even if your entire team is staffed with experts because understanding the actual business problems is as hard as the tech stack and if you can't carve out time to think about a few controllers, there's no way that the rest of the problem doesn't have problems which are at least as bad. 1. If true, that would be a huge sign that the tool has major design failures and is not suitable for production use rather than an argument against hiring people who aren't already experts.