> > 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
This in my opinion is the way forward rather than artificially setting up boundaries between roles defined by the languages they use.
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?"
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.
And then looking at it the other way, the equivalent JS is:
backgroundColor: "blue"
which as an isolated bit of code is no more or less understandable than the CSS.
The problem I've had with CSS is answering the question, "If I change this code, what will happen?" It is so easy for the answer to be "random other things break" that keeping CSS organised is really hard. At least with CSS-in-TS a "Find all references" will tell you where the style is used.
It does seem like a bit of a cherry picked example. However, for the most part, I think it's great how intuitive CSS naming conventions are. I think it's relatively easy to learn enough CSS to be dangerous.
The author is advocating for a departure from "everything is a flavor of javascript" to "it's ok to have front end designers only specialize in HTML/CSS".
I think the argument could be made that, ironically, the "everything is Javascript" is a direct result of having front end specialists that only have experience with one Turing complete language, being JS.
When Node came out, one of the biggest selling points was that front end designers would be familiar with the toolchain and backend language, and could become more full stack.
SPA frameworks came out when UX people decided page refreshes were ugly and slow, so they took HTML and turned it into a template language for JS instead of semantic markup.
Finally, in general, the trend of pushing web interfaces far past what HTML/CSS were designed to do by the front end community (who, rightly, see potential in their platform) is why more "power" is required, and why a Turing complete language is needed for an ecosystem originally intended to use forms as the only means of I/O.
> I think the argument could be made that, ironically, the "everything is Javascript" is a direct result of having front end specialists that only have experience with one Turing complete language, being JS.
Full stack devs not taking the front end seriously is definitely a thing. It's like the icing on the coding cake, and they tend to get frustrated when they find out it is a very hard thing to do, mostly because CSS is very unintuitive. You can get 80% of the way there with an afternoon of training, and then the remaining 20% takes like 5 years of experience and IE will still f you up from time to time.
But this completely jumps the shark when equating negligence of the front end to gender bias. Basically the author is pissed and vindictive, but gets to keep thinking of themselves as the good person, because the objects of wrath aren't just CS majors who know how to tree sort and don't care if the button looks flat or 3D, but are morally evil people who are the source of oppression in the world.
I have to take CSS seriously or I'm a woman-hating racist? Look man, I just like computers and building things.
They assume things are easy, because they would be if CSS was a properly engineered solution. But it isn't. Having to wait for flexbox to be able to easily vertically center stuff proves the point.
> Anything less than ‘real programming’ is now considered trivial, silly, artsy, female.
I am a very strong supporter of feminism, but this kind of reasoning needs to stop.
The idea of "as a man you're biased from your position of power, therefore your opinion is invalid/worthless" means that the opinion of any men can be shut off automatically just by finding a gender twist on any debate. It's incredibly condescending, and frustrating, since any rebuttal you might try will be dismissed as your inability to see the other side, no matter how tenuous the connection to gender is. I would even go as far as to say that it's a mirror of the old "these are men things, as a woman you wouldn't understand" that was sadly common in the past.
While I'm very happy to see women empowered and their perspective being taken into account more and more, I'm also worried about the rise of any system that leads to the opinion of a group not being listened to. That is never good, period.
And to be clear, I'm not equating the current trend of dismissing male ideas to the suffering of women under patriarchic societies. Just pointing out a worrying development.
Not surprising from Brad. Every once in a while one of his articles show up on hacker news. He's good at creating debate, mostly because what he writes is always a bunch of BS wrapped in this kind of comments that make people want to comment.
I yet have to find an article from him about engineering that makes any sense. He's able to write a few lines of jQuery this seems to make him feel like he knows so much about things he has no experience on.
He's quoting someone else though he is agreeing with them. The full quote is:
> We need to address the undervaluing of HTML and CSS for what it is: gender bias. Even though we wouldn’t have computer science without pioneering women, interloping men have claimed it for themselves. Anything less than ‘real programming’ is now considered trivial, silly, artsy, female. That attitude needs to eat a poisoned ass.
I admit I don't understand the point. I haven't experienced this perception of HTML/CSS as something "trivial, silly, artsy, female". It's possible though that this does exist? In some places? I mean people do have a tendency to think of what they're good at as superior to the things they're bad at...and loads of programmers are really bad at HTML/CSS.
Considering the other comments here, this isn't going to be a popular opinion, but we should probably being talking about the data rather than how ridiculous/insecure it seems.
What's at issue here is that coding is a combination of EQ and IQ, and when we create environments that favor "rightness" over common empathy and effective communication, we turn our backs on the people who favor thinking that way (no matter their gender) and we make worse products as a result.
We're not writing code for machines, we're writing code for people.
It seemed like a normal discussion until this random buzz topic popped up; albeit, sure we need to solve the ills of this, treat all types of people normally. ~ Wtf does Gender Bias have to do with React not being good because if you like/write css and dont know js you're fucked?
The author didn't write it, nor did he attempt to support it. I think the author made the mistake of quoting too heavily such that it's easy to mistake another author's words for his.
While I might not agree with everything he says, the gender bias lawsuit against Google revolved around women being siloed in front-end development (as well as starting at lower ranks/pay, etc.). So it doesn't seem all that far-fetched and there may be a kernel of truth there, depending on where you are and what your environment is like.
"Logic programming is considered superior to HTML/CSS even though it isn't. Just like one gender thinks that they are superior to others even though they aren't."
The thing that makes HTML and CSS different from Javascript is that they are declarative languages.
The execution engine is elsewhere and the 'code' is really configuration for the HTML/CSS engines. Same thing for SQL which is another language he mentions.
There are many advantages to this. First, of all it's much less error prone to write, and second you don't have to run any code to predict it's output.[1]
If you pull the markup languages into a procedural framework, you lose many advantages.
[1] Testing becomes a matter of seeing the results in a browser, which is not to say it's trivial. The downside of declarative languages, is that it can be hard to debug when the engine does something unexpected (remember ie6?).
Isn't the idea with full stack devs that you might have an organisation that isn't large enough to have fully specialised staff? Or that some part of the code needs some special skill eg SQL but not enough for a full time specialist?
Also it's useful to have utility players who can fill in gaps in any position.
> Also it's useful to have utility players who can fill in gaps in any position
You end up in the "width vs depth" debate if you go along these lines. It is debatable whether it is better to know 60% of all worlds or >95% of one world. (Assumption: It is extremely rare finding people who know >95% of all worlds).
However, I agree with your point that full-stack is the way to go if you are limited on resources (small orgs).
Agree with some of the insights in this article. Basically in frontend /full stack jobs generally the only interview questions are related to javascript -- kind of assuming that it's the hardest/most important part of the job. But CSS and layout stuff is its own skillset imo. Thankfully I feel more comfortable in the js coding aspect of things so this never burns me when seeking employment.
I remember reading the original article and discussing with colleagues at work. The premise just seems wrong to me:
* CSS-in JS isn't gatekeeping; there are huge benefits to breaking the global CSS model, which these articles seem to ignore, which is surprising to say the least
* the market reality is that most companies are better off with 'full-stack' people - the need adaptable people, who can get things done, albeit not always with the perfect approach
To ignore these and instead point to gender bias seems bizarre.
I agree that front end and back end should be treated as separate parts of the system (I'm not a fan of isomorphic JavaScript or server-rendered front ends).
But I think that it's possible to have really good full stack developers and there is a lot of value in having one on the team. Every project needs at least one person who understands every major part of the code; the more detailed their understanding is, the better it is for the project.
He's not a frontend developer, he's a designer, who happens to do a bit of javascript. That's fine, but it obviously colored what he thinks about full-stack developers, and frankly it's a load of bull.
First the idea that the term fullstack is somehow a capitalist conspiracy to maximize profits over the poor developer is beyond misguided. Fullstack development came to be because of the rising popularity of SPAs and the shifting of what was once strictly backend development into client side (templates, routing, etc...).
Not all code is the same, but the separation to backend and frontend is artificial - MVC in js or in C# is the same no matter what language you write it in.
I'm a proud full-stacker and would hate to work in an organization the article paints as paradise - a place where I'll have to wait for someone to write my web-services or for the DBA to add a column to a database. In fact it is that enterprise way of thinking that made me, and I think many people, prefer fullstack work.
To me full-stack is about accountability, it's about not having someone else become a bottleneck to a feature you are in charge of, it's about the ability to see a feature from start to finish and make it the way you, as the one who actually works on it, think it should be.
Honestly, I think it’s really important for people to have at least some grasp of the whole product structure even if they don’t directly work on it all the time.
If you focus only on your own thing it quickly leads to alienation from the rest of the team.
> CSS is a relatively friendly, approachable, readable language (I could ask my mailman to guess what background-color: blue does and he’d probably guess right), but by sucking styling into these complex JavaScript ecosystems we lose that approachability.
Ah, yeah. `background-color: blue` is indeed worlds more easily comprehended than `backgroundColor = 'blue'`.
ಠ_ಠ
Don't do CSS-in-JS because a linter reminding you to camelCase is intimidating? Really? I've mentored several juniors over the years and none of them have been that touchy.
I'm not a proponent of CSS-in-JS, but this article makes some "interesting" mental contortions (and even a jab at capitalism, for some reason? [Oh, right, I forgot that endorsing Communism is trendy in the US these days]) which I'm interpreting more as the author's defence against learning a little more than just HTML, CSS, and "presentational JavaScript".
I work with a number of frontend developers and designers who know HTML, CSS/Sass, and a beginner to lower-intermediate level of JavaScript (often jQuery).
As more projects start leaning towards "fullstack" apps, typically Node.js/React, I'm observing the main issue this article raises: these specifically frontend-focused people are getting separated/excluded from the development process, unless they become familiar with all-JS solutions (the "big ol' ball o' JavaScript").
The learning curve is significant (ES6~, Babel/TypeScript, React, dev/build steps), so they must choose to either:
- Become more proficient in JS to be able to contribute
- ..or focus on design/prototype using HTML and CSS as a separate phase, to be incorporated into the final product by the fullstack people
For one such project/team, I'm experimenting with a compromise: a fullstack React app that renders and composes pages/screens from folders of HTML and CSS templates that frontend people can edit freely. This is aiming toward the "best of both worlds", but it's still a bit awkward. Vue.js might be more suitable, but - at least personally - it's a compromise in the other direction..
Full-stack development and architect are roles, not skill sets. That's what I see as going missing in these discussions. Anybody can do either job. Whether they do them well depends more on their general level of software knowledge, and not so much on individual skills known.
The roles are driven by business needs. The more budget is available, the more you can afford to stratify roles into front-end, back-end, and architect. But it's up to the business to decide what roles they need, not us. The output of engineering departments is something normal people have to be able to reason about. We don't build bridges just for other engineers. We do it with taxpayer money to serve taxpayers.
As a mostly back end dev, I am always in awe of CSS/HTML wizards. I grew up in the "tables and font tags" era of the mid 90's, and CSS has never quite made sense to me...
CSS doesn't make sense to any sane person, kinda like makefiles. But everyone doing it is a little bit insane after being at the deep end for so long, that doing things any differently seems impossible.
A lot of strong, interesting opinions. I didn't agree with everything. I found this to be a very interesting perspective:
> I can see full-stack development emerging as a result of capitalistic exploitation
In my experience, I have worked with a lot of lead developers who seem to wilfully propagate this notion to their managers that we need less resources, that we can squeeze more out of what we have. I understand that part of this comes from the human desire to save your ass, especially in that kind of work culture. However, I always felt that we needed to push the opposite message, even if it wasn't necessarily true. Why have two developers working at 100% crunch-mode when you can have 3 or four working at a more relaxed pace. Simplistic, but that's my view.
Great article. I think what we're really seeing here is the end of web development as a craft. It's turning into assembly line and "inefficiencies" like having people specialize in different things is no longer (financially) viable, so it's been done away with. It's unfortunate, I miss the craft.
[+] [-] BjoernKW|7 years ago|reply
> 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
This in my opinion is the way forward rather than artificially setting up boundaries between roles defined by the languages they use.
[+] [-] Novashi|7 years ago|reply
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?"
[+] [-] tboyd47|7 years ago|reply
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.
[+] [-] captainbland|7 years ago|reply
Mind you, ask your mailman what
"div.a > .b:nth-child(3n+2) { margin: -5px -1px -5px -10px; }"
is supposed to do and you might get a different response.
[+] [-] DougBTX|7 years ago|reply
The problem I've had with CSS is answering the question, "If I change this code, what will happen?" It is so easy for the answer to be "random other things break" that keeping CSS organised is really hard. At least with CSS-in-TS a "Find all references" will tell you where the style is used.
[+] [-] ryanbrunner|7 years ago|reply
[+] [-] lewisflude|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] aristophenes|7 years ago|reply
[+] [-] fuball63|7 years ago|reply
I think the argument could be made that, ironically, the "everything is Javascript" is a direct result of having front end specialists that only have experience with one Turing complete language, being JS.
When Node came out, one of the biggest selling points was that front end designers would be familiar with the toolchain and backend language, and could become more full stack.
SPA frameworks came out when UX people decided page refreshes were ugly and slow, so they took HTML and turned it into a template language for JS instead of semantic markup.
Finally, in general, the trend of pushing web interfaces far past what HTML/CSS were designed to do by the front end community (who, rightly, see potential in their platform) is why more "power" is required, and why a Turing complete language is needed for an ecosystem originally intended to use forms as the only means of I/O.
[+] [-] lkbm|7 years ago|reply
Well, and HTML+CSS: https://github.com/elitheeli/stupid-machines/
But yeah, your point stands.
[+] [-] aristophenes|7 years ago|reply
But this completely jumps the shark when equating negligence of the front end to gender bias. Basically the author is pissed and vindictive, but gets to keep thinking of themselves as the good person, because the objects of wrath aren't just CS majors who know how to tree sort and don't care if the button looks flat or 3D, but are morally evil people who are the source of oppression in the world.
I have to take CSS seriously or I'm a woman-hating racist? Look man, I just like computers and building things.
[+] [-] dsego|7 years ago|reply
[+] [-] 321yawaworht|7 years ago|reply
> We need to address the undervaluing of HTML and CSS for what it is: gender bias.
I find it baffling how some people can make such ridiculous statements to fit their narrative and insecurities.
[+] [-] kace91|7 years ago|reply
I am a very strong supporter of feminism, but this kind of reasoning needs to stop.
The idea of "as a man you're biased from your position of power, therefore your opinion is invalid/worthless" means that the opinion of any men can be shut off automatically just by finding a gender twist on any debate. It's incredibly condescending, and frustrating, since any rebuttal you might try will be dismissed as your inability to see the other side, no matter how tenuous the connection to gender is. I would even go as far as to say that it's a mirror of the old "these are men things, as a woman you wouldn't understand" that was sadly common in the past.
While I'm very happy to see women empowered and their perspective being taken into account more and more, I'm also worried about the rise of any system that leads to the opinion of a group not being listened to. That is never good, period.
And to be clear, I'm not equating the current trend of dismissing male ideas to the suffering of women under patriarchic societies. Just pointing out a worrying development.
[+] [-] jypepin|7 years ago|reply
I yet have to find an article from him about engineering that makes any sense. He's able to write a few lines of jQuery this seems to make him feel like he knows so much about things he has no experience on.
[+] [-] scandox|7 years ago|reply
> We need to address the undervaluing of HTML and CSS for what it is: gender bias. Even though we wouldn’t have computer science without pioneering women, interloping men have claimed it for themselves. Anything less than ‘real programming’ is now considered trivial, silly, artsy, female. That attitude needs to eat a poisoned ass.
And it's from this link: http://www.heydonworks.com/article/reluctant-gatekeeping-the...
I admit I don't understand the point. I haven't experienced this perception of HTML/CSS as something "trivial, silly, artsy, female". It's possible though that this does exist? In some places? I mean people do have a tendency to think of what they're good at as superior to the things they're bad at...and loads of programmers are really bad at HTML/CSS.
[+] [-] spaceribs|7 years ago|reply
I am not proud of how male dominated frontend is, and no one should be: https://2018.stateofjs.com/demographics/gender-breakdown
As you get closer and closer to coding, you can see how this ratio gets smaller and smaller: https://www.invisionapp.com/inside-design/designer-compensat...
What's at issue here is that coding is a combination of EQ and IQ, and when we create environments that favor "rightness" over common empathy and effective communication, we turn our backs on the people who favor thinking that way (no matter their gender) and we make worse products as a result.
We're not writing code for machines, we're writing code for people.
[+] [-] blue4|7 years ago|reply
[+] [-] ppf|7 years ago|reply
2. Claim that the new prevalence of women in front-end coding is sexist
3. ??
4. Profit!
[+] [-] vinceguidry|7 years ago|reply
[+] [-] jplayer01|7 years ago|reply
https://www.forbes.com/sites/clareoconnor/2017/09/14/google-...
[+] [-] wawhal|7 years ago|reply
"Logic programming is considered superior to HTML/CSS even though it isn't. Just like one gender thinks that they are superior to others even though they aren't."
[+] [-] blahblahblogger|7 years ago|reply
[+] [-] gerbilly|7 years ago|reply
The execution engine is elsewhere and the 'code' is really configuration for the HTML/CSS engines. Same thing for SQL which is another language he mentions.
There are many advantages to this. First, of all it's much less error prone to write, and second you don't have to run any code to predict it's output.[1]
If you pull the markup languages into a procedural framework, you lose many advantages.
[1] Testing becomes a matter of seeing the results in a browser, which is not to say it's trivial. The downside of declarative languages, is that it can be hard to debug when the engine does something unexpected (remember ie6?).
[+] [-] trh88|7 years ago|reply
Well that's a conscious decision the developer makes.
You don't need to use any of this.
If, as a beginner, you just want to write an HTML doc with some styles - that still works.
However, if as a beginner you jump into a Webpack / React / CSS-in-JS setup... well you're going to have a hard time.
Complaining that "that's the way things are going" seems to pass the buck. If you don't want to go that way, then don't!
[+] [-] test1235|7 years ago|reply
You will if you want a job. Noone's hiring devs who only know html and css and don't want to learn anything else.
[+] [-] lordnacho|7 years ago|reply
Also it's useful to have utility players who can fill in gaps in any position.
[+] [-] wawhal|7 years ago|reply
You end up in the "width vs depth" debate if you go along these lines. It is debatable whether it is better to know 60% of all worlds or >95% of one world. (Assumption: It is extremely rare finding people who know >95% of all worlds).
However, I agree with your point that full-stack is the way to go if you are limited on resources (small orgs).
[+] [-] pseudalopex|7 years ago|reply
[+] [-] darepublic|7 years ago|reply
[+] [-] room271|7 years ago|reply
* CSS-in JS isn't gatekeeping; there are huge benefits to breaking the global CSS model, which these articles seem to ignore, which is surprising to say the least
* the market reality is that most companies are better off with 'full-stack' people - the need adaptable people, who can get things done, albeit not always with the perfect approach
To ignore these and instead point to gender bias seems bizarre.
[+] [-] jondubois|7 years ago|reply
But I think that it's possible to have really good full stack developers and there is a lot of value in having one on the team. Every project needs at least one person who understands every major part of the code; the more detailed their understanding is, the better it is for the project.
[+] [-] Illniyar|7 years ago|reply
First the idea that the term fullstack is somehow a capitalist conspiracy to maximize profits over the poor developer is beyond misguided. Fullstack development came to be because of the rising popularity of SPAs and the shifting of what was once strictly backend development into client side (templates, routing, etc...).
Not all code is the same, but the separation to backend and frontend is artificial - MVC in js or in C# is the same no matter what language you write it in.
I'm a proud full-stacker and would hate to work in an organization the article paints as paradise - a place where I'll have to wait for someone to write my web-services or for the DBA to add a column to a database. In fact it is that enterprise way of thinking that made me, and I think many people, prefer fullstack work.
To me full-stack is about accountability, it's about not having someone else become a bottleneck to a feature you are in charge of, it's about the ability to see a feature from start to finish and make it the way you, as the one who actually works on it, think it should be.
[+] [-] Aeolun|7 years ago|reply
If you focus only on your own thing it quickly leads to alienation from the rest of the team.
[+] [-] yakshaving_jgt|7 years ago|reply
Ah, yeah. `background-color: blue` is indeed worlds more easily comprehended than `backgroundColor = 'blue'`.
ಠ_ಠ
Don't do CSS-in-JS because a linter reminding you to camelCase is intimidating? Really? I've mentored several juniors over the years and none of them have been that touchy.
I'm not a proponent of CSS-in-JS, but this article makes some "interesting" mental contortions (and even a jab at capitalism, for some reason? [Oh, right, I forgot that endorsing Communism is trendy in the US these days]) which I'm interpreting more as the author's defence against learning a little more than just HTML, CSS, and "presentational JavaScript".
[+] [-] lioeters|7 years ago|reply
As more projects start leaning towards "fullstack" apps, typically Node.js/React, I'm observing the main issue this article raises: these specifically frontend-focused people are getting separated/excluded from the development process, unless they become familiar with all-JS solutions (the "big ol' ball o' JavaScript").
The learning curve is significant (ES6~, Babel/TypeScript, React, dev/build steps), so they must choose to either:
- Become more proficient in JS to be able to contribute
- ..or focus on design/prototype using HTML and CSS as a separate phase, to be incorporated into the final product by the fullstack people
For one such project/team, I'm experimenting with a compromise: a fullstack React app that renders and composes pages/screens from folders of HTML and CSS templates that frontend people can edit freely. This is aiming toward the "best of both worlds", but it's still a bit awkward. Vue.js might be more suitable, but - at least personally - it's a compromise in the other direction..
[+] [-] bsbechtel|7 years ago|reply
[+] [-] vinceguidry|7 years ago|reply
The roles are driven by business needs. The more budget is available, the more you can afford to stratify roles into front-end, back-end, and architect. But it's up to the business to decide what roles they need, not us. The output of engineering departments is something normal people have to be able to reason about. We don't build bridges just for other engineers. We do it with taxpayer money to serve taxpayers.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] icedchai|7 years ago|reply
[+] [-] dsego|7 years ago|reply
[+] [-] tropicalfruit|7 years ago|reply
> I can see full-stack development emerging as a result of capitalistic exploitation
In my experience, I have worked with a lot of lead developers who seem to wilfully propagate this notion to their managers that we need less resources, that we can squeeze more out of what we have. I understand that part of this comes from the human desire to save your ass, especially in that kind of work culture. However, I always felt that we needed to push the opposite message, even if it wasn't necessarily true. Why have two developers working at 100% crunch-mode when you can have 3 or four working at a more relaxed pace. Simplistic, but that's my view.
[+] [-] Touche|7 years ago|reply