4 ms·

Our cross-functional teams have both frontend and backend engineers working on business goals for their team. The skillsets of definitely different though and

Our cross-functional teams have both frontend and backend engineers working on business goals for their team. The skillsets of definitely different though and they both compliment each other. I'm really not a fan of having 'full stack' engineers which do everything. The truth is they are often stronger in frontend or backend, with a few unicorns that excel at both. Frontend engineers know frameworks well - angular, vue or react with other frontend concepts like cookies and frontend security. Backend engineers don't need to know about cross-site scripting, CORS and a bunch of other things that have been standardised and built into browser security. Backend engineers have used more languages outside of javascript and work with a much larger set of technologies day-to-day (databases, queues, file systems, other APIS, RPC etc). They see the client (frontend) like any other consumer hitting their system. They can't be unified because tech stacks and the web is so big and there are so many ideas and new things coming out. I'm not sure if a browser could ever do something like reading a message from a Kafka topic. A frontend dev should never have to worry about that, so why on earth would they ever need to know anything about Kafka? A backend dev might have to play with it though.

lolinder 6y ago
The article isn't advocating having everyone try to be an expert in everything, see his conclusion below. The article was prompted by an interaction with a company which didn't want to spend time improving their front end because they felt that front-end work was beneath them. The article is basically saying to change that attitude: > To be clear, I’m not saying that we all need to be experts in everything. That would be impossible. Today’s technology stack goes down a long way, so being a genuinely balanced full-stack dev is probably not the most realistic of goals — but staying open-minded is.
- nedoka 6y ago
  There's a golden balance between front-end and back-end. This article seems a bit like a he said she said, venting some kind of dispute with management on the internet.
- tedk-42 6y ago
  Yes and I agree with the writer on that. But I dislike his view that dividing frontend and backend expertise is problematic
zackify 6y ago
Funny that you say they can’t be unified, just yesterday I wrote an article about how you can write backend JS within your front end project, without even thinking about the stuff going on behind the scenes. I think things might get closer and closer together. At least in the JS community. Performance critical work will be done in Rust / wasm and we will always have people who specialize instead of generalize across all these technologies. But that doesn’t mean some projects can’t be unified more! https://zach.codes/es6-import-nodejs-on-the-frontend/ https://zach.codes/es6-import-nodejs-on-the-frontend/
enumjorge 6y ago
> Backend engineers don't need to know about cross-site scripting, CORS and a bunch of other things that have been standardised and built into browser security I agree that frontend and backend development are deep enough on their own that they require specialization for complex projects. But lacking even basic knowledge of how other parts of the stack can by an issue IMO. You mentioned CORS for example. One time I had to explain to a co-worker, who was a senior level backend dev, why the browser’s calls to his API were failing due to CORS. He couldn’t understand why the fix had to be on his end. When he tested the API with Postman the same requests were succeeding after all. It was shocking to me that someone at his level was not familiar with what was happening. Sure, it requires knowledge of browser behavior but it’s still relevant to the person writing the API. Beyond that, I find that having a little full stack knowledge helps with inter-team communication.
- tedk-42 6y ago
  While I agree that he should have some knowledge about the CORS issue, I disagree that it's a backend problem. It's the engineering/architecture problem. There's no reason why you couldn't build a proxy on the same domain as your front end app and proxy the request to the backend. It sounds like his interface (API) was built before you even started consuming it. Maybe adding such headers increased the scope of complexity for his API and tests. I don't know the circumstances, but I disagree the fix HAS to be on his end.
Chris2048 6y ago
There should be a front and a back end team, but the back-end team should know how the front-tend works in interacting with the back-end, and even be able to write JS to this end. Having one team hitting just API endpoints is fine - until you need more nuance in your approach then you need to appreciate how end-to-end works. example: what if you need to limit API calls, or stream data in a specific way? what if you need to work with the back-end to pre-fetch certain data and then cache it client-side? I'd argue these things are back-end-interacting client-side code. and they should probably be written by someone with a strong appreciation of the back-end, whether than be someone actually on the BE team, or a knowledgeable FE team member. Of course, you can always write a spec that covers all of it and bounce it between the two teams, but that doesn't always work out well, especially if FE/BE silos have developed.
- tedk-42 6y ago
  The first thing I said was advocating cross functional teams with both frontend and backend engineers
  - Chris2048 6y ago
    But what does that mean? One or two devs knows the other teams stuff? The whole team? also, what does it mean in the context of "different skillsets"? It sounds like the FE devs has some comprehension of the BE, but weaker skills than the BE devs. Then cross-functional just means not strongly siloed, but what is the advantage is that? a little knowledge can be worse than none. KT can be expensive, specialism exists for a reason, and you can end up limiting your hiring pool if your requirements are too strict. I don't think a FE team needs every member to know every detail of the back-end, a suitable abstraction can simplify how much you need to focus on the back-end detail. Instead I'd advocate having a few "specialists" that have a good knowledge of where FE meets BE. they needn't be the best BE or FE dev, but the best at integrating the two; I'd say this is usually a BE engineer who can write good JS and has a decent appreciation of the relevant protocols. They can architect the main touch points, and then abstract them (i.e. create relevant classes) for the FE, BE. These devs would be competent experts in integration, rather than the "jack of all trades, master of none" full-stack variant; a shallow but wide knowledge may be great for prototyping, but not for mature stacks.

lolinder 6y ago

The article isn't advocating having everyone try to be an expert in everything, see his conclusion below. The article was prompted by an interaction with a company which didn't want to spend time improving their front end because they felt that front-end work was beneath them. The article is basically saying to change that attitude: > To be clear, I’m not saying that we all need to be experts in everything. That would be impossible. Today’s technology stack goes down a long way, so being a genuinely balanced full-stack dev is probably not the most realistic of goals — but staying open-minded is.

nedoka 6y ago
There's a golden balance between front-end and back-end. This article seems a bit like a he said she said, venting some kind of dispute with management on the internet.
tedk-42 6y ago
Yes and I agree with the writer on that. But I dislike his view that dividing frontend and backend expertise is problematic

zackify 6y ago

Funny that you say they can’t be unified, just yesterday I wrote an article about how you can write backend JS within your front end project, without even thinking about the stuff going on behind the scenes. I think things might get closer and closer together. At least in the JS community. Performance critical work will be done in Rust / wasm and we will always have people who specialize instead of generalize across all these technologies. But that doesn’t mean some projects can’t be unified more! https://zach.codes/es6-import-nodejs-on-the-frontend/ https://zach.codes/es6-import-nodejs-on-the-frontend/

enumjorge 6y ago

> Backend engineers don't need to know about cross-site scripting, CORS and a bunch of other things that have been standardised and built into browser security I agree that frontend and backend development are deep enough on their own that they require specialization for complex projects. But lacking even basic knowledge of how other parts of the stack can by an issue IMO. You mentioned CORS for example. One time I had to explain to a co-worker, who was a senior level backend dev, why the browser’s calls to his API were failing due to CORS. He couldn’t understand why the fix had to be on his end. When he tested the API with Postman the same requests were succeeding after all. It was shocking to me that someone at his level was not familiar with what was happening. Sure, it requires knowledge of browser behavior but it’s still relevant to the person writing the API. Beyond that, I find that having a little full stack knowledge helps with inter-team communication.

tedk-42 6y ago
While I agree that he should have some knowledge about the CORS issue, I disagree that it's a backend problem. It's the engineering/architecture problem. There's no reason why you couldn't build a proxy on the same domain as your front end app and proxy the request to the backend. It sounds like his interface (API) was built before you even started consuming it. Maybe adding such headers increased the scope of complexity for his API and tests. I don't know the circumstances, but I disagree the fix HAS to be on his end.

Chris2048 6y ago

There should be a front and a back end team, but the back-end team should know how the front-tend works in interacting with the back-end, and even be able to write JS to this end. Having one team hitting just API endpoints is fine - until you need more nuance in your approach then you need to appreciate how end-to-end works. example: what if you need to limit API calls, or stream data in a specific way? what if you need to work with the back-end to pre-fetch certain data and then cache it client-side? I'd argue these things are back-end-interacting client-side code. and they should probably be written by someone with a strong appreciation of the back-end, whether than be someone actually on the BE team, or a knowledgeable FE team member. Of course, you can always write a spec that covers all of it and bounce it between the two teams, but that doesn't always work out well, especially if FE/BE silos have developed.

tedk-42 6y ago
The first thing I said was advocating cross functional teams with both frontend and backend engineers
- Chris2048 6y ago
  But what does that mean? One or two devs knows the other teams stuff? The whole team? also, what does it mean in the context of "different skillsets"? It sounds like the FE devs has some comprehension of the BE, but weaker skills than the BE devs. Then cross-functional just means not strongly siloed, but what is the advantage is that? a little knowledge can be worse than none. KT can be expensive, specialism exists for a reason, and you can end up limiting your hiring pool if your requirements are too strict. I don't think a FE team needs every member to know every detail of the back-end, a suitable abstraction can simplify how much you need to focus on the back-end detail. Instead I'd advocate having a few "specialists" that have a good knowledge of where FE meets BE. they needn't be the best BE or FE dev, but the best at integrating the two; I'd say this is usually a BE engineer who can write good JS and has a decent appreciation of the relevant protocols. They can architect the main touch points, and then abstract them (i.e. create relevant classes) for the FE, BE. These devs would be competent experts in integration, rather than the "jack of all trades, master of none" full-stack variant; a shallow but wide knowledge may be great for prototyping, but not for mature stacks.