2 ms·

I understand the HR problem, hiring developers is hard, you want developers to be as replaceable as a bolt in a machinery. But as a developer you learn new thin

by z3t4 10y ago

I understand the HR problem, hiring developers is hard, you want developers to be as replaceable as a bolt in a machinery. But as a developer you learn new things every day and technology changes fast especially in web development. Even if the new dev knows the framework, every team does things different, and that is because different problems requires different solutions. Basically, you could just take anyone willing to learn and that person would become productive within a month or discover that programming isn't for them. Although if you want someone able to create new architecture you need someone with experience. Although developers get that experience by actually building stuff.

tomw1808 10y ago
I see you are trying to make a point here, but I simply think it is not valid and I honestly think you are making a huge mistake by writing vanilla JS for bigger projects. One thing is the HR standpoint: It is not only the reason new people are easier to find. I don't think they are replicable, but I think it is easier to get them started on projects. It is testable knowledge. It is a terrible idea to introduce "star-based" developers in bigger projects. In practice its one developer who is really good at the things he is doing and the rest of the team is suffering from the non-documented things someone was writing in the name of slightly better performance and less code-overhead. There are a bazillion frameworks out there. They all have a different purpose for different tasks and aim at different levels of abstraction. Btw React is just a view layer for me, not a whole framework. And I am definitely not a fan of React. The other thing is popularity and collaboration: It is also a fact that a popular framework incorporates hundreds, often thousands of eyes looking at bugs, improving functionality, enhancing features. How many times do we have to see developers reinventing the wheel because they don't like to work with frameworks? Routing, Authentication/Authorization, Internationalization, (API) connectivity, Security, Dataflow, Scalability, Error handling, Logging... How many times developers figure out that they did things wrong somewhere at the beginning and have to redo everything from scratch after a few months in, just because they did not go the framework- and best-practice-route? Write your small apps like ToDo lists without frameworks. The ToDo list is just the modern hello world after all. But please, write large production apps on top of frameworks and do not try to re-invent the wheel. Your future colleagues will thank you.

by z3t4 10y ago

tomw1808 10y ago

I see you are trying to make a point here, but I simply think it is not valid and I honestly think you are making a huge mistake by writing vanilla JS for bigger projects. One thing is the HR standpoint: It is not only the reason new people are easier to find. I don't think they are replicable, but I think it is easier to get them started on projects. It is testable knowledge. It is a terrible idea to introduce "star-based" developers in bigger projects. In practice its one developer who is really good at the things he is doing and the rest of the team is suffering from the non-documented things someone was writing in the name of slightly better performance and less code-overhead. There are a bazillion frameworks out there. They all have a different purpose for different tasks and aim at different levels of abstraction. Btw React is just a view layer for me, not a whole framework. And I am definitely not a fan of React. The other thing is popularity and collaboration: It is also a fact that a popular framework incorporates hundreds, often thousands of eyes looking at bugs, improving functionality, enhancing features. How many times do we have to see developers reinventing the wheel because they don't like to work with frameworks? Routing, Authentication/Authorization, Internationalization, (API) connectivity, Security, Dataflow, Scalability, Error handling, Logging... How many times developers figure out that they did things wrong somewhere at the beginning and have to redo everything from scratch after a few months in, just because they did not go the framework- and best-practice-route? Write your small apps like ToDo lists without frameworks. The ToDo list is just the modern hello world after all. But please, write large production apps on top of frameworks and do not try to re-invent the wheel. Your future colleagues will thank you.