I have had a very interesting train of thoughts while trying to explain to a colleague of mine why a React Developer will have it hard to just switch to node.js. She asked me this question like what's the difference between Node.js and React because as she's heard (not a tech person) that it's both JavaScript and both are using the same engine.
How would you explain such a thing?
I came up with this, very crude, way of explaining it like so: As you know, there is 50% of developers that have 5, and less, years of experience. This means that they have had to learn some framework and the basics of the programming language because it was used at work, and they have had no control over choosing which technology to use. Basically a given. Because the volatility of the market is very high, it is not uncommon for any given developer to have half a year of experience in 2 or 3 mainstream frameworks in 18 months.
Those frameworks are not hammers. They are complex tools that take some time to learn the basics, not to mention learning to write software. And this means that an adept learns to code from snippets of code from documentation of whatever thing they use. This includes the rules for naming variables (that'd be xxxService, xxxController, xxxModel, xxxInterface and so on...), what complexity of a method is acceptable... pretty much everything about programming.
But...
Documentation for React is not the book on clean code. That's a different book. Documentation for Vue.js isn't about SOLID principles - it's about Vue.js. Those are different kinds of books. Manuals. They don't teach you about programming. They teach you about using whatever they describe.
This means that if we have had a candidate that's got about 3 recent years of experience working with react and 5 years in total, it is a safe bet to say he won't know and understand OOP, SOLID principles, TDD,... They never used them. So if, all of a sudden, someone tries to encapsulate something in a set of classes, to split some bigger piece of code into manageable pieces, give those pieces some good names, maybe hide some pieces using private fields, then they freak out! It's "not the React way" I hear the most. So what is "the React way?" I ask. "Use Redux!" or "Redux sucks! Use Mobex!"... use, use, use... It's totally like crack! Totally addictive. Turns off thinking like nothing else. Why learn something else if the satisfaction from working in the IT industry is fulfilled by just "learning React"?
I don't know... I am old-fashioned. I like when I have DRY code that speaks to me when I read it some time later. I like having meaningful tests, when it makes sense, not for coverage. I don't like using frameworks, especially those that when you read the docs it looks like someone was very opinionated when designing the framework. I like using tools that fit the purpose, so if I don't need something it usually is not used. For example, I'd not use Axios now that fetch is available unless I've had a very good reason to do so then I'd abstract away Axios so that when the need for having it disappears I wouldn't be stuck with this (fantastic but) ancient utility.
That's why, under the whole umbrella of "developers", I would distinguish between "xxx developer" (React, Angular, Vue, Express.js, all the major dudes) and "software writer" where the latter is this kind of devs that when you start asking questions that require thinking you don't get an answer from React documentation.
And the most important thing: It's not wrong, bad or something else. It just is, there is nothing that we can do about it other than accept it. Just... keep it in mind the next time you'll be interviewing someone.
Top comments (0)