8 ms·

> > In this symbiotic relationship, each party has a secure job with a well-defined role > Historically, different languages suggested different roles. Otherw

> > In this symbiotic relationship, each party has a secure job with a well-defined role > Historically, different languages suggested different roles. Otherwise known as silos. In my experience, front-end developers and back-end developers not working together but each "role" merely throwing their results over the wall and expecting the other side to do whatever it is they're doing is a huge problem. We supposedly have DevOps but we don't even have sufficient collaboration within the Dev part of that equation. None of these roles delivers a usable product or solution to a problem on its own. CSS-in-JS or defining styles at a component level is not a problem per se either. It can become a problem if there's a mismatch between the document structure envisioned by a designer and the component architecture devised by a developer. Component architectures aren't foreign to designers though, the perhaps most prominent example ironically being Brad's own Atomic Design paradigm. Just yesterday I saw this talk about "Angular for Designers" by Stephen Fluin, which advocates making JavaScript applications, of the Angular variety in this case, more accessible to designers: https://www.youtube.com/watch?v=LP-fNM8OITI https://www.youtube.com/watch?v=LP-fNM8OITI This in my opinion is the way forward rather than artificially setting up boundaries between roles defined by the languages they use.

Novashi 8y ago
A team of full stack devs tend towards whatever they fancy when handing out JIRAs, and the separation is still usually front or back-end. It becomes an unofficial silo anyway. The full stack advantage is for sudden departures: the project doesn't completely stop because people can fill in with mediocre code. A disadvantage is that you don't have specialists and risk more technical debt that can't be enforced by linters/testing. The reason this debate will never end is because it's never anchored to how the business sells and delivers products. Full stack is better for shorter product life cycles. Specialists are better for longer-running products and monoliths. Code quality really doesn't matter if the product disappears. The key evidence to me that full stack is mostly BS is that it only crops up in web roles. Outside of web dev, people are still silo'd -- security people and systems developers aren't pulled off-task to go work on the company website. We're completely fine accepting their responsibilities in terms of the product. If you're a front or back-end web dev though, there's this constant pressure of "why haven't you learned to full stack yet?"
- BjoernKW 8y ago
  The early days of web development up to roughly the end of the 1990s technically were full stack. It's just nobody called it that at the time. It's only by the early 2000s and the advent of architecturally complex, heavily back-end-leaning frameworks such as J2EE or JSP that front-end and back-end diverged. These frameworks had their benefit compared with the fast-and-loose way web apps often were developed before but they also introduced new problems. Apart from inherent architectural issues these frameworks introduced a new crop of developers to web development that was at least somewhat averse towards how front-end development is done on the web. To this day, I still know developers who loathe JavaScript, CSS and HTML because "they're not the proper way of doing things". Furthermore, with traditional desktop applications you also usually have a full stack attitude, although again it isn't called "full stack" in that case. Desktop application developers are typically expected to be able to write both UI code as well as business logic and database access code. Probably that's because with desktop applications there's usually only a single language you're dealing with.
  - zozbot123 8y ago
    > Furthermore, with traditional desktop applications you also usually have a full stack attitude, although again it isn't called "full stack" in that case. Desktop application developers are typically expected to be able to write both UI code as well as business logic and database access code. Many GUI applications are actually based on a client-server pattern that mirrors the "front-end" v. "back-end" distinction. Often the "server" is a separate CLI app, or even a daemon/service with no interaction with the rest of the system other than via the platform IPC (COM, DBus, whatever). Consider the traditional large-scale "pattern" of desktop apps, viz. Model-View-Controller. The Model is back-end, the View-Controller pair (which is often tightly coupled anyway) is front-end.
  - Novashi 8y ago
    Desktop and web development also got to ignore responsive design for a long time, and that revolution added serious complexity to HTML/CSS/JS and browser engines. You could slap a minimum desktop resolution on your product and call it a day.
tboyd47 8y ago
Best results come from teams of generalists working as specialists. What if my "thing they are best at and enjoy the most" is just creating new functionality, no matter what language I use? There's no place for me on a team of pure specialists.

Novashi 8y ago

A team of full stack devs tend towards whatever they fancy when handing out JIRAs, and the separation is still usually front or back-end. It becomes an unofficial silo anyway. The full stack advantage is for sudden departures: the project doesn't completely stop because people can fill in with mediocre code. A disadvantage is that you don't have specialists and risk more technical debt that can't be enforced by linters/testing. The reason this debate will never end is because it's never anchored to how the business sells and delivers products. Full stack is better for shorter product life cycles. Specialists are better for longer-running products and monoliths. Code quality really doesn't matter if the product disappears. The key evidence to me that full stack is mostly BS is that it only crops up in web roles. Outside of web dev, people are still silo'd -- security people and systems developers aren't pulled off-task to go work on the company website. We're completely fine accepting their responsibilities in terms of the product. If you're a front or back-end web dev though, there's this constant pressure of "why haven't you learned to full stack yet?"

BjoernKW 8y ago
The early days of web development up to roughly the end of the 1990s technically were full stack. It's just nobody called it that at the time. It's only by the early 2000s and the advent of architecturally complex, heavily back-end-leaning frameworks such as J2EE or JSP that front-end and back-end diverged. These frameworks had their benefit compared with the fast-and-loose way web apps often were developed before but they also introduced new problems. Apart from inherent architectural issues these frameworks introduced a new crop of developers to web development that was at least somewhat averse towards how front-end development is done on the web. To this day, I still know developers who loathe JavaScript, CSS and HTML because "they're not the proper way of doing things". Furthermore, with traditional desktop applications you also usually have a full stack attitude, although again it isn't called "full stack" in that case. Desktop application developers are typically expected to be able to write both UI code as well as business logic and database access code. Probably that's because with desktop applications there's usually only a single language you're dealing with.
- zozbot123 8y ago
  > Furthermore, with traditional desktop applications you also usually have a full stack attitude, although again it isn't called "full stack" in that case. Desktop application developers are typically expected to be able to write both UI code as well as business logic and database access code. Many GUI applications are actually based on a client-server pattern that mirrors the "front-end" v. "back-end" distinction. Often the "server" is a separate CLI app, or even a daemon/service with no interaction with the rest of the system other than via the platform IPC (COM, DBus, whatever). Consider the traditional large-scale "pattern" of desktop apps, viz. Model-View-Controller. The Model is back-end, the View-Controller pair (which is often tightly coupled anyway) is front-end.
- Novashi 8y ago
  Desktop and web development also got to ignore responsive design for a long time, and that revolution added serious complexity to HTML/CSS/JS and browser engines. You could slap a minimum desktop resolution on your product and call it a day.

tboyd47 8y ago

Best results come from teams of generalists working as specialists. What if my "thing they are best at and enjoy the most" is just creating new functionality, no matter what language I use? There's no place for me on a team of pure specialists.