14 ms·

In my experience, the developers who fall into this trap of despair almost always do so because they aren't consciously choosing what tools to use; instead they

by marrs 10y ago

In my experience, the developers who fall into this trap of despair almost always do so because they aren't consciously choosing what tools to use; instead they are letting the tools choose them. They see job descriptions demanding AngularJS or ReactJS and they think that they must learn it, or someone posts an article here and they don't want to feel left behind. Choose a library or tool because it improves your development process. If it doesn't appear to improve it, don't use it (at least not unless external forces compel you to). Especially don't use it if it appears that it will retard your performance (cough Angular cough). For example, after months (years?) of finding ever more efficient ways of enforcing object interfaces (or even basic types) at runtime, I eventually reached the limits of what JS and unit testing alone could acomplish and found myself researching Typescript, Flow, and the like. That's not to say I'm a user of either of those, but if I do choose to adopt one in a project, I will know exactly what performance gain I am expecting from it. I'm still very productive without them. In fact, I've successfully avoided a lot of fads in the industry for most of my career. It turns out that being able to explain why I don't use a tool makes me look like I know what I'm talking about and not just cargo culting. Employers quite like that. Incidentally, this isn't unique to the front-end. I've seen the same thing happen with the SQL->ORM->Mongo->Couch->SQL nonsense, or the myriad of templating engines written for PHP, a language that itself is a templating engine.

gambler 10y ago
You sound like you have not often worked with legacy code or software architecture teams who choose the "right" tools for you. In large companies you rarely choose the tools you use. Also, when you feel that you need to learn technologies simply to avoid using them something is very, very wrong. I think that is sort of the point of the article.
kraftman 10y ago
So what do you do about jobs asking for Angular/React experience? Just tell them you have none because you haven't needed to use them yet? Or avoid those jobs? (There are a lot)
- wccrawford 10y ago
  I'm not the person you replied to, but I'd recommend learning them well enough to know their strengths, and then telling the interviewer that's what you did. If you have any experience in other front end frameworks, that'll usually be enough to get you through that part of the interview anyhow.
  - k__ 10y ago
    Also, after learning a few frameworks, it simply isn't hard. I mean, if you get the right mind-set of wanting to understand "what is the intention of the framework devs" you can pretty much learn any framework. Problems mostly come if you try to force your React/Ember/Backbone knowledge into another framework. I got all my jobs without prior knowledge of the used frameworks.
  - vonmoltke 10y ago
    That's if you get the interview. This is my problem with most of this kind of advice. All the learning in the world won't help if they ignore your resume because your last job didn't us the same technologies they do.
    - marrs 10y ago
      You're presuming that's why they ignored your resume; it might not be. A good recruiter will help you improve your CV and will also ask the employer why you were rejected. It is also worth while including a covering letter that you can use to make some statements up front. Make it relevant to the job description and keep it to the point. Finally, you may not be ready for the skill level you are targeting and you may need to work out what areas you need to improve in order to be able to progress.
- glenjamin 10y ago
  I've hired multiple people onto team using React when they have no prior React experience. The learning curve for React is pretty smooth, so I'd mostly check if they had experience of building the types of apps we were doing with other approaches - and whether they'd seen any ill effects from those choices.
wccrawford 10y ago
As someone who learned Unity well enough to do game jams, then tried to switch to Unreal Engine 4 and failed to get traction for a year, I absolutely agree. I was choosing UE4 for technical reasons and completely ignoring my comfort with the system. I was completely unable to get motivated and it absolutely brought my mood down for that year. Then I recently picked Unity back up (and had to learn a year or more of what I'd missed, including the new UI stuff) and it feels so much better. I'm getting things made and my mood has improved quite a bit. I haven't completely given up on UE4, but I'm no longer trying to shoe-horn it into my development. I'll wait until it really is the right tool for the job this time.
- AtheistOfFail 10y ago
  True story, same issue. We were building on Unity 4 and kept getting awful looking details and figured 'game engine swap' and went Cryengine. Holy shit, what a bad one. Cryengine and Unreal Engine have well-thought pipelines for asset management and they work great with professional studios that use the complete professional Adobe pipeline. Remember that Unreal Engine is a professional product being shoe-horned for indies where as Unity is an indy product now being shoe-horned for professionals.
hemancuso 10y ago
How would you suggest developers actually figure out what tools to use? It is next to impossible to make an informed decision without digesting a good portion of what the OP is talking about. You need to start somewhere.
- drostie 10y ago
  This is kind of a cop-out, but I am constantly surprising coworkers with the (I thought simple!) things that I do with relatively old-school JS. I think if you're just starting out on a project -- any project, any skill level -- then your biggest obstacle is your own inertia, your tendency to evaluate options for how you might solve the problem, rather than just plunging right in and saying "I am going to code something, it may not be the right thing, but I am going to try to write this little function which does this little thing." (I once heard some conference speaker say something to the effect of "I found it very hard to floss until my dentist said 'hey, if you don't have time to floss between all of your teeth, please still try to floss just one.' Suddenly I'm at the mirror like, 'I don't wanna take that time to floss all my teeth... oh well, I'll floss just one to make my dentist happy... oh, and I might as well do another, and another..."). The hardest thing is to get started, which paradoxically can begin just about anywhere you want. You just have to choose something and do it. So a lot of this "what framework am I going to learn and use?" stuff gets in the way of this and slows you down from tackling this hardest-problem-that-should-be-a-non-issue. Just start with low-level JS and begin building, then let your pain in doing so guide your further choices. Because low-level JS sucks, of course. It sucks that the DOM specifies that each node in HTML has a property .childNodes but the object that resides in that property is not an array with a .forEach() method so you find yourself either doing `Array.prototype.slice.call(x.childNodes, 0)` (in ES5, for compatibility), or `[... x.childNodes]` (in ES6 because it's prettier and more obvious what you're going for). And it sucks that HTML tables don't come with any built-in sorting mechanisms, and it sucks to be dealing with XMLHttpRequests directly. That's why these frameworks build on top of those things. But I really think that if you're starting out, you should start out with this sucky stuff and then choose your framework based on what you learn about your pain points, rather than the other way around. If you find yourself needing to support older browsers then you will learn these cross-compilation tools; if you find yourself eventually turning it into a RESTful API written Node.js then you'll probably be OK with just ES6. Or if you find yourself writing similar sortable table widgets for the third time, you start googling "has some framework already solved this stuff?" and you eventually stumble upon the search "grid component" which will get you checking out either Vue.js, React (though you'll quickly realize that it's not native to React, there are several options there), and Ext.js, all of which have fine grid components that you might start using. Now you're doing a short research project to incorporate those things into your present workflow, which is much better than doing a long research project to decide which one of these things will be your Firm Foundation For All Things To Be Built Here. The other huge thing about knowing plain JS is that you can start by messing with other peoples' web sites; just Ctrl-Shift-J on whatever page you happen to be on, "how would I add a little button that would replace all instances of the name 'Paul Graham' on this comments thread with the phrase 'my little pony'...? I think it would be hilarious if all these techies were talking about ponies instead."
Waterluvian 10y ago
When I had no experience I was asked to define the next few years for my company's single page app. I researched all the major tools and committed to django, react, fluxxor, leaflet. As the major parts. All but leaflet (now OpenLayers) are still around and growing well. The most important thing is that I got to pick which tools felt most resilient to rapid development and lots of rookie mistakes. Even if they may have been overkill or not ideal or some thing I cant possibly know as a newcomer. In the past I did chase the dream of the one toolset to end them all and it had me never committing for any meaningful duration.
Tloewald 10y ago
I think that someone coming to the field cold is going to be sucked into the vortex of enthusiasm surrounding one or more frameworks and, eventually either become a die-hard fan of some specific stack or jaded by the phenomenon. I'm a member of the second group since, like 1995. Right now we're on the nth cycle of lemming like enthusiasm which is currently favoring React because it just tried Angular two years ago and writing a new site with React sounds a whole lot more awesome than fixing the incomprehensible pile of crap you wrote in Angular which, guess what, seemed like a great idea at the time because of the mess you made with jquery UI.
cocktailpeanuts 10y ago
In my experience, it's not the developers who fall into this trap, it's the culture--nobody wants to learn some random technology that will probably be obsolete in a year (and I'm not even joking when I say this, this really is the reality) The only situation where you are not affected is if you're a freelancer and you don't need to worry about what's going on around you. I'm not going to mention where, but I worked at a well known company which you've heard of (you probably would know it as an innovative company), and everyone who worked there was very talented, there is absolutely no doubt about that. But I got sick of what's happening around me and quit recently. Here's what happened: In the last couple of years a few people started talking about all this "cool new javascript testing/packaging/templating/single page app building" frameworks. Since it is indeed a "cool thing" to talk about these, and since they believe that potential new hires would be excited to learn that we use these hip new technologies to power our company, they started implementing EVERYTHING that the OP mentioned in the article. Of course, I'm sure it looks really cool from a recently graduated college kid's point of view when they interview. But anyway, suddenly the company culture started revolving around these hip technology advocates. I can understand why but at the same time it's really stupid because they keep switching out their stack and spend their money on useless crap instead of actually spending it on building the actual product. For example, they've transitioned from browserify to grunt to webpack in just last two years. So when I read this article I totally sympathized with the guy. If you're a web developer who works at a large company that wants to be seen as "innovative" (especially the ones that are already seen as being technically innovative), this is exactly what's going on. And you only have two choices: You either jump on the bandwagon and become one of the "in" crowd, or complain like the rest and be left behind and seen as a "laggard". When I saw these otherwise intelligent programmers moving like bunch of lemmings to adopt the latest new technology I couldn't help but feel pity for them. They grow old day by day thinking they're becoming a better programmer but all they're doing is learning some library that's designed so that the code monkeys can be managed better. They should be spending less time on those meta things and spend more time on building what a user wants instead. At least that's why I became a programmer.
- marrs 10y ago
  This is very true and cool shiny new things are hard to counter, mostly because ones instinct is to point out the deficiency in the "innovation", which is often only obvious to you. The best way I've found to counter this is to give your own demonstration showing how you achieved the same (or better) coolness with existing technology, and you did it faster, and it can be integrated into the code base today. This gives your argument real substance and people have to at least now argue against facts and data rather than hand-wavy speculation.

by marrs 10y ago

gambler 10y ago

You sound like you have not often worked with legacy code or software architecture teams who choose the "right" tools for you. In large companies you rarely choose the tools you use. Also, when you feel that you need to learn technologies simply to avoid using them something is very, very wrong. I think that is sort of the point of the article.

kraftman 10y ago

So what do you do about jobs asking for Angular/React experience? Just tell them you have none because you haven't needed to use them yet? Or avoid those jobs? (There are a lot)

wccrawford 10y ago
I'm not the person you replied to, but I'd recommend learning them well enough to know their strengths, and then telling the interviewer that's what you did. If you have any experience in other front end frameworks, that'll usually be enough to get you through that part of the interview anyhow.
- k__ 10y ago
  Also, after learning a few frameworks, it simply isn't hard. I mean, if you get the right mind-set of wanting to understand "what is the intention of the framework devs" you can pretty much learn any framework. Problems mostly come if you try to force your React/Ember/Backbone knowledge into another framework. I got all my jobs without prior knowledge of the used frameworks.
- vonmoltke 10y ago
  That's if you get the interview. This is my problem with most of this kind of advice. All the learning in the world won't help if they ignore your resume because your last job didn't us the same technologies they do.
  - marrs 10y ago
    You're presuming that's why they ignored your resume; it might not be. A good recruiter will help you improve your CV and will also ask the employer why you were rejected. It is also worth while including a covering letter that you can use to make some statements up front. Make it relevant to the job description and keep it to the point. Finally, you may not be ready for the skill level you are targeting and you may need to work out what areas you need to improve in order to be able to progress.
glenjamin 10y ago
I've hired multiple people onto team using React when they have no prior React experience. The learning curve for React is pretty smooth, so I'd mostly check if they had experience of building the types of apps we were doing with other approaches - and whether they'd seen any ill effects from those choices.

wccrawford 10y ago

As someone who learned Unity well enough to do game jams, then tried to switch to Unreal Engine 4 and failed to get traction for a year, I absolutely agree. I was choosing UE4 for technical reasons and completely ignoring my comfort with the system. I was completely unable to get motivated and it absolutely brought my mood down for that year. Then I recently picked Unity back up (and had to learn a year or more of what I'd missed, including the new UI stuff) and it feels so much better. I'm getting things made and my mood has improved quite a bit. I haven't completely given up on UE4, but I'm no longer trying to shoe-horn it into my development. I'll wait until it really is the right tool for the job this time.

AtheistOfFail 10y ago
True story, same issue. We were building on Unity 4 and kept getting awful looking details and figured 'game engine swap' and went Cryengine. Holy shit, what a bad one. Cryengine and Unreal Engine have well-thought pipelines for asset management and they work great with professional studios that use the complete professional Adobe pipeline. Remember that Unreal Engine is a professional product being shoe-horned for indies where as Unity is an indy product now being shoe-horned for professionals.

hemancuso 10y ago

How would you suggest developers actually figure out what tools to use? It is next to impossible to make an informed decision without digesting a good portion of what the OP is talking about. You need to start somewhere.

drostie 10y ago
This is kind of a cop-out, but I am constantly surprising coworkers with the (I thought simple!) things that I do with relatively old-school JS. I think if you're just starting out on a project -- any project, any skill level -- then your biggest obstacle is your own inertia, your tendency to evaluate options for how you might solve the problem, rather than just plunging right in and saying "I am going to code something, it may not be the right thing, but I am going to try to write this little function which does this little thing." (I once heard some conference speaker say something to the effect of "I found it very hard to floss until my dentist said 'hey, if you don't have time to floss between all of your teeth, please still try to floss just one.' Suddenly I'm at the mirror like, 'I don't wanna take that time to floss all my teeth... oh well, I'll floss just one to make my dentist happy... oh, and I might as well do another, and another..."). The hardest thing is to get started, which paradoxically can begin just about anywhere you want. You just have to choose something and do it. So a lot of this "what framework am I going to learn and use?" stuff gets in the way of this and slows you down from tackling this hardest-problem-that-should-be-a-non-issue. Just start with low-level JS and begin building, then let your pain in doing so guide your further choices. Because low-level JS sucks, of course. It sucks that the DOM specifies that each node in HTML has a property .childNodes but the object that resides in that property is not an array with a .forEach() method so you find yourself either doing `Array.prototype.slice.call(x.childNodes, 0)` (in ES5, for compatibility), or `[... x.childNodes]` (in ES6 because it's prettier and more obvious what you're going for). And it sucks that HTML tables don't come with any built-in sorting mechanisms, and it sucks to be dealing with XMLHttpRequests directly. That's why these frameworks build on top of those things. But I really think that if you're starting out, you should start out with this sucky stuff and then choose your framework based on what you learn about your pain points, rather than the other way around. If you find yourself needing to support older browsers then you will learn these cross-compilation tools; if you find yourself eventually turning it into a RESTful API written Node.js then you'll probably be OK with just ES6. Or if you find yourself writing similar sortable table widgets for the third time, you start googling "has some framework already solved this stuff?" and you eventually stumble upon the search "grid component" which will get you checking out either Vue.js, React (though you'll quickly realize that it's not native to React, there are several options there), and Ext.js, all of which have fine grid components that you might start using. Now you're doing a short research project to incorporate those things into your present workflow, which is much better than doing a long research project to decide which one of these things will be your Firm Foundation For All Things To Be Built Here. The other huge thing about knowing plain JS is that you can start by messing with other peoples' web sites; just Ctrl-Shift-J on whatever page you happen to be on, "how would I add a little button that would replace all instances of the name 'Paul Graham' on this comments thread with the phrase 'my little pony'...? I think it would be hilarious if all these techies were talking about ponies instead."

Waterluvian 10y ago

When I had no experience I was asked to define the next few years for my company's single page app. I researched all the major tools and committed to django, react, fluxxor, leaflet. As the major parts. All but leaflet (now OpenLayers) are still around and growing well. The most important thing is that I got to pick which tools felt most resilient to rapid development and lots of rookie mistakes. Even if they may have been overkill or not ideal or some thing I cant possibly know as a newcomer. In the past I did chase the dream of the one toolset to end them all and it had me never committing for any meaningful duration.

Tloewald 10y ago

I think that someone coming to the field cold is going to be sucked into the vortex of enthusiasm surrounding one or more frameworks and, eventually either become a die-hard fan of some specific stack or jaded by the phenomenon. I'm a member of the second group since, like 1995. Right now we're on the nth cycle of lemming like enthusiasm which is currently favoring React because it just tried Angular two years ago and writing a new site with React sounds a whole lot more awesome than fixing the incomprehensible pile of crap you wrote in Angular which, guess what, seemed like a great idea at the time because of the mess you made with jquery UI.

cocktailpeanuts 10y ago

In my experience, it's not the developers who fall into this trap, it's the culture--nobody wants to learn some random technology that will probably be obsolete in a year (and I'm not even joking when I say this, this really is the reality) The only situation where you are not affected is if you're a freelancer and you don't need to worry about what's going on around you. I'm not going to mention where, but I worked at a well known company which you've heard of (you probably would know it as an innovative company), and everyone who worked there was very talented, there is absolutely no doubt about that. But I got sick of what's happening around me and quit recently. Here's what happened: In the last couple of years a few people started talking about all this "cool new javascript testing/packaging/templating/single page app building" frameworks. Since it is indeed a "cool thing" to talk about these, and since they believe that potential new hires would be excited to learn that we use these hip new technologies to power our company, they started implementing EVERYTHING that the OP mentioned in the article. Of course, I'm sure it looks really cool from a recently graduated college kid's point of view when they interview. But anyway, suddenly the company culture started revolving around these hip technology advocates. I can understand why but at the same time it's really stupid because they keep switching out their stack and spend their money on useless crap instead of actually spending it on building the actual product. For example, they've transitioned from browserify to grunt to webpack in just last two years. So when I read this article I totally sympathized with the guy. If you're a web developer who works at a large company that wants to be seen as "innovative" (especially the ones that are already seen as being technically innovative), this is exactly what's going on. And you only have two choices: You either jump on the bandwagon and become one of the "in" crowd, or complain like the rest and be left behind and seen as a "laggard". When I saw these otherwise intelligent programmers moving like bunch of lemmings to adopt the latest new technology I couldn't help but feel pity for them. They grow old day by day thinking they're becoming a better programmer but all they're doing is learning some library that's designed so that the code monkeys can be managed better. They should be spending less time on those meta things and spend more time on building what a user wants instead. At least that's why I became a programmer.

marrs 10y ago
This is very true and cool shiny new things are hard to counter, mostly because ones instinct is to point out the deficiency in the "innovation", which is often only obvious to you. The best way I've found to counter this is to give your own demonstration showing how you achieved the same (or better) coolness with existing technology, and you did it faster, and it can be integrated into the code base today. This gives your argument real substance and people have to at least now argue against facts and data rather than hand-wavy speculation.