|
|
|
|
|
|
by t4nkd
4792 days ago
|
|
|
Yeah, I'm not really feeling the persuasion here. I really don't know many "frontend developers" or "backend developers" to begin with. I know plenty of people struggle writing maintainable, well structured applications or who don't grasp front end concepts/technology enough to really produce anything production worthy. Those people are still "my peers" first and I typically consider their title to be "software engineer" or possibly "web developer". The individuals lacking a grasp on front end technology probably need to learn just as well as an individual with great front end skills needs to learn the rest of the stack. We're so heavily coupled now, in terms of squeezing performance out of an application and the ability to iterate rapidly, that throwing a bunch of backend logic and/or API's over the wall to "UI Developers" is probably not only a waste of time, but detrimental to the process. Throwing code over a wall is usually what happens when two distinctly different types of engineers are in the same product and avoiding it is tricky. All this opinion of course is coming from someone who has managed to develop design, UI/UX, and a programming skill set and I'm probably pretty biased when it comes to pidgin holing people into a single role. Having said that, this proposal really smells like an easy way to "be lazy" out of a responsibility in the project. Dismissing a UI issue by surrendering, "But I'm the Application Developer, I don't really do UI" sounds like the more common scenario in the roles you're proposing. The reality is, if you want to keep working on web-oriented applications, you might need to grasp a bit of both, or at least some of each and a lot more experience in either direction(e.g. learning the full stack and then taking a deep interest in hardware performance WRT application profiling). Good luck with your ambition though, I'm sure if you can make it popular the industry won't care about how I feel . |
|
|
I think if anything we're less tightly coupled than we used to be. So many projects now have a clearly defined backend API and a separate front-end project. The problem though is that these front-end projects that used to be HTML/CSS with some JavaScript are now becoming almost full-stack applications themselves, with all the nuts and bolts you'd associate with backend projects (routing, controllers, application logic, complicated event handling) now also in the frontend.
In terms of how we describe roles in software, as long as it's from a genuine specific need (e.g. "frontend JavaScript developer") and not just some mix of buzzwords, I don't really see the problem.