The meme above could potentially be casting shade on “full stack devs” by depicting them as a drawing of a horse but where only the backend is drawn out. If you were building a team, would you rather have that meme image above, or a developer who only knows one part of the system?
Personally, I would take that meme image in a heartbeat. I’d also take a “partial stack” dev if they are curious (described below).
I mean I get it. It’s a funny meme, but we need less walls and more bridges. All too often, managers stand behind tired ideas like “there is no full stack developer” and then force team structures that prevent good, quick conversations. Listen, our users don’t care about our architecture, they care about the code working end-to-end. I’d prefer that managers and leads invert their thinking or at least open up to the notion of a happy, autonomous team.
I think the best rationale for a “full stack dev” is that the healthiest teams are full of empathetic people who are willing to put themselves in the shoes of any member of their team (regardless of where they specialize) so they can learn about the challenges of their teammates. It’s a great way to ensure:
- team morale through empathizing
- domain knowledge transfer
- better estimates since everyone has passing familiarity with each layer of the stack
- people can help out in a pinch (if needed)
Modern web development is pushing hard for “full stack teams” not “full stack devs.” If there was an image like that of me, it would be a horse with mostly the ribs and the abdomen shaded in. I am no CSS expert, nor am I a SQL guru. Each person will always have their strengths and weaknesses, but together the team should be fully autonomous and productive. I mean it. Each member of the team is valuable.
I know that I shouldn’t be so bothered by this but I am. And if I’ve learned anything from the Buddhist scholars that I use as research for this blog... it’s that you shouldn’t cast judgement on your emotions—- you should accept them. And I’m accepting the fact that I’ve been burnt by teams before that were not truly operating like a team. I don’t want to wait 2 weeks for the backend developer to get back to me with a new API so I can finally start my UI task. Let’s just work on the API and the UI together.
What do you think? Has your company pushed too hard for split UI/Backend teams? Have they pushed too hard for full stack teams? Are there other ways to keep collaboration and empathy high?
———————————————-
If you liked this article, consider reading:
Go Home: 4 Techniques That Help You Leave Work At Work
or
How Buddhism is Agile
or
10+ Tips To Find Peace In A Loud Office
Latest comments (127)
I thought this was so elegant, as you move from left to right you see a fully developed and clearly defined "horses arse". As well as the other comments made below....
I agree with Scott's and Martin's thoughts. My first thought at seeing the graphic was "jack of all trades, master of none"; my second thought was of recruiters with outrageous requirements paired with lowball compensation.
That said, fewer walls, not less.
Sorry, but no. This is a hot-button topic for me. I've been in this industry full-time for a quarter CENTURY now, and yanno what? The more I learn, the more I realize how much I'm NOT a full-stack developer. Not for lack of knowledge, or inability... I know more about Photoshop and Sketch than many of the designers I know, more about Bash/Shell scripting than MANY of the DevOps guys I shoot pool with, and a whole helluvalot more about web development - front AND back - than the majority of the script kiddies I interview. Fact is? I'm STILL not "full-stack".
It's called "division of labor" and "separation of interests" for a REASON, folks. Rare indeed is the individual who gets off on database optimization AND color palette selection, or cryptography AND animation design.
The term "full-stack" was originally coined back in '99, around 3 years after I started developing. But upon hearing it, I tried. Gods how I tried. I've owned THREE different boutique dev shops. I've coded 80-hour weeks for longer than many of my current employees have been out of grade school. For FUN. I've written my own CMS, and SOLO'D my own CRM! Back in the 90's? Maybe. MAYBE there were a select few that were deep enough in when ASP and PHP (before JSP was even a glimmer in Sun's eye) first CAME OUT alongside the W3C's CSS1, Netscape's new-fangled "JavaScript", and that amazing Flashy stuff Macromedia had just bought from those "FutureWave" guys to punch up the new HTML3 spec microsoft was rolling for MSN 2.0, always assuming, of course you could afford a copy of that shiny new Photoshop 4 (not CC4. Not CS4. FOUR. 4.0) that was just then rolling out.
It's possible - not probable, but POSSIBLE - there were some folk that were good enough at all to have claimed "full-stack" (notwithstanding the SQL Server, Oracle, and IIS knowledge that would really have been needed then too), because the WEB WAS BUILT ON LIKE 8 TECHNOLOGIES! But now? HA!
I say this as someone who's been ACTIVELY working in JavaScript since the YEAR IT CAME OUT: I've been using this language for 8+ hours a day 6+ days a week for a QUARTER-CENTURY, and I'm STILL finding stuff I didn't know, very nearly weekly. And I'm not even TOUCHING on all the frameworks, libraries, coding styles, pre-compilers, post-compilers, de-compilers, browser-specific implementations (and I actually was one of the poor SOB's that HAD to dev for WebTV and WAP phones). And that's ONE LANGUAGE!
You show me one - ONE - legitimate "full-stack" developer, and I'll show you a reasonably-proficient bullshit-artist. When I interview people to hire nowadays? One of the first sentences I tell them is if I hear that term during the interview, or see it on their resume, better luck next time; I have no desire to hire someone who either knows jack-all about "every" layer of the dev cycle and release train or who knows a bit that's useful about several and then LIES about knowing the rest.
Specialize, folks. Find your niche and FILL that shit. Be the blogger that people turn to for integrating Couchbase and GraphQL, or the expert in using SVG animations in browser-based side-scrollers. I don't need a "universal" expert. Why? Because they don't EXIST. They're liars or suckers, or both, or worse, think I am.
I'd rather hire a dream team of 5 badasses who each rule their little kingdoms in their totality with an iron (but immanently EFFECTIVE) fist, than 5 code-bootcamp noobs who who delude themselves into believing that, because they can copy+paste from StackOverflow or npm install a 800k library with 98 dependencies (none of which they've bothered to read or understand) to solve some problem they only partially grasp (which ALREADY HAD a method NATIVE to the language available) that they are somehow "full stack."
Psssh.
"Really? You're a doctor? What kind?"
"ALL of them! I'm a FULL STACK physician"
Yeah. Have fun with that, while I'm over here with my proctologist, getting the burns from all the smoke you just tried to blow looked at.
"A lawyer!? Thank god! I'm in the middle of an IRS audit, stemming from my getting divorced from my wife without a prenup because I hit her just-yesterday-disbarred uncle-in-law's uninsured car while we'd both been drinking in the 49cc untitled Chinese scooter I'm borrowing from an out-of-town gun-collector, so he engaged in insider trading tactics to steal my company out from underneath me, then traded its pending patents to a North Korean firm for a kilogram of plutonium and a 55-gallon drum of methamphetamines, which, though they rendered him senile and demented now, it was NOT before he buried them in my back yard, where the neighbor's illegal immigrant gardener found them... by blowing himself (along with the cable company's box that straddles the sidewalk and my property line) up!
What do I do!?"
"S'cool. I GOT this."
Very interesting perspective. And I can see how coming from a world where there were so many technologies would lead you to that place. But now that there are stacks where you can just write JavaScript from the DB to the UI, it’s a little easier to make the claim that you are a generalist who specializes in JavaScript.
I would hope and encourage you to not immediately remove a candidate who says they’re “full stack” if what they really mean is that they like helping out where-ever they can.
I recognize that language is important and that I could have clarified that better in my article, however I think it’s important every team has at least one member of the team who is willing to help out where is needed. And it sounds like you have that “can do” attitude too.
In no way would I unfairly disqualify a candidate; indeed, as stated: I warn them right up front. Nor am I stating I have a problem with a can-do attitude. To whit: fully half my interview questions are logic and problem-solving puzzles in which I don't care if you get the "right" answer or not. The questions - many of which I've written or designed myself - are intended to see HOW a person thinks, not WHAT they do.
What will a candidate do when they don't know the answer, they're under pressure, and they weren't at all prepared for the issue? You tell me you need time, or need your tools to look something up? No problem. You tell me you don't know, or you "give up" or "pass"? Bye. I'll end the interview right there.
It's our JOB to PROBLEM-SOLVE. By whatever mechanism/means necessary.
I've personally been called in on Christmas Eve because someone on our QA team in Bangladesh (thank god) had noticed we abruptly were getting 5,000 uninstalls PER MINUTE (that's ~83 per SECOND) from our primary revenue generator. Took us 32 minutes to catch it, get to the office, diagnose, triage, and repair the problem, which in real-world terms, means we lost close to 160,000 users of our 9M (about 1.7%) that day.
I expect EVERYONE that works with and for me to have a "can-do" attitude. Quite aside from the fact that you'd not have survived my interview with a "can't do" attitude, it's a basic expectation. It's like a restaurant touting their food is "fresh" (Subway, I'm looking at you). If I'm at a restaurant, the very LEAST I should be able to expect is "fresh." It had BETTER be! If that's the only positive you can voice about your establishment (Subway), then you need to rethink your policy on rewarding mediocrity (still looking at you, Subway).
But this isn't about positivism or optimism. It's about spheres of influence and responsibility.
Look, I think it's a nice plus if a candidate has worked within our ecosystem (though for real: find me two companies with the same standards, best practices, deployment procedures, etc., etc.). But I'm not hiring you so you can be a graphic artist today and a Python developer tomorrow. That signifies I'M not doing MY job right (or, more probably, that I've delivered a set of reqs to someone in HR who doesn't know Java from Javascript, who in turn vocalized those to a recruiting firm, who then disseminated a memo to their headhunters, who are now trying to parrot back that we're looking for someone who drinks coffee and has pretty penmanship).
But in truth? I don't give a damn if you've used whatever bit of library esoterica du jour that one of my guys happened to have managed to successfully lobby for when this project started. I let candidates whiteboard code in their language of choice (including pseudo-code and flowcharts!). I had one guy respond in Brainfuck once (took me two weeks to figure out what the hell his answer was; I put interviews on hold until I had. I hired him, after threatening what would happen if he ever pulled a stunt like that again, rofl).
Fact is: there are back-end guys, and front-end guys. Artists and Algorithmists ("Algorithmechanics?" "Algorithmancers?" "Al Gore?"). It's not "old thinking". It's not "outdated principals". It's human nature. I too fancy myself to be one of those unicorns that straddles the divide, but if I'm honest with myself I have PREFERENCES. Build UI's or optimize Joins for a migration? Screw that; hire a database guy. I encourage my guys to expand and diversify, sure. In fact, we require it: 4 hours a week on Fridays (barring crises) you're required to code something non-work-related, then present it to the group for feedback and review. In whatever platform you want. Some of my favorite VSC and Chrome extensions came about thusly.
But when I'm losing 300,000 users an hour? I'm not calling in my jack-of-all-trades, master-of-none, so I can sit and wait for him to browse NPM or ask Reddit. I'm calling in my damn ninja, who I HIRED FOR HIS EXPERTISE. Yes, there are stacks. Yes, some even run end-to-end. But just because you can code a really slick proxy server in Node does NOT make you qualified to make an equally-slick library of GUI components that'll play nice with Opera and Edge! And it DOESN'T NEED TO.
If my Startup's budget is such that I can afford to hire ONE dev, such that I need to spend the next 18 months combing LinkedIn, Monster, and StackOverflow to FIND this $200k mythical demigod, then I'M doing it wrong. And AS a candidate, that should SCARE YOU. Because during those 18 months, I could have hired 2 $100k guys that are roaring badasses in either end of my stack and started generating enough revenue to patch the holes.
Figure out which portions of the field you LOVE. The ones you'd VOLUNTEER to work in. The ones you do for FUN. Market yourself as one of those guys and run circles around me in your interview. You'll be happier, I'll keep you 'til one of us dies, and we'll both enjoy the pride and money of putting out REAL software WE made, instead of another flashlight app.
This isn't theory. This isn't my opinion. This is real-world, practical advice from someone who's been in the trenches doing it their entire adult life, since Clinton was still in his first term. Cuz I PROMISE you: I'm way the hell more "full stack" than 99% of the guys out there. I just recognize the hubris of the idea and wouldn't be caught dead asserting it outside a discussion like this.
There's just too much to know. For ANYONE to.
To quote Kyle Simpson (author of the best-selling You Don't Know Javascript books) in his outstanding keynote at JSNation: "I don’t think anyone ever really knows JS, not completely anyway. I say this in all honesty and not to boast: I’ve forgotten more JS than most people ever learn ... I’m not a JS expert, and I definitely don’t think I deserve to be called a 'classic.'" John Resig has said much the same thing. So has Brendan Eich, for gods' sake, and he WROTE the (first version) of the damn language! Albeit, though: Douglas Crockford, when approached for comment, merely muttered, "more'n you, pussy!" then set his dogs on me.
An important part of fully autonomous teams are that they start together. It sounds like you should bring that up during a team retrospective so you can transparently state that you want to incorporate CSS best practices at the beginning of the design phase.
Of course if that’s not working and you’ve ready had enough it’s time to ask some important questions:
4 signs your job is beyond repair
Cubicle Buddha ・ Jul 10 '19 ・ 5 min read
I want to believe this so hard. I am technically “full stack” in this very sense, choosing to explore the backend as a means of greater appreciation and understanding, and to improve my own skillset.
However, developers (or rather, people) with that attitude have been sadly rare in my experience, both working with many, and also interviewing (hundreds) of “Full Stack” developers. There are diamonds, yes, but I have to sift through a LOT of cruft to find them.
I find more often than not the title comes with “ignorant arrogance”, not the humility and curiosity I hope for, and the meme feels painfully accurate to me. To clarify, most Full Stack developers I’ve interacted with were usually .NET Developers who know how to npm install Angular with Bootstrap and call themselves “Full Stack”. So the less detailed part of the horse is in essence a Backend developer choosing some automagical frontend framework just to get a project done.
And that’s not a bad thing — for prototypes, small projects and startups, maybe. But personally, I’m a UX advocate, so ignoring something like accessibility is lazy and unacceptable in a production application IMHO.
But when I have deeper conversations about the frontend, it often exposes how very little they understand and respect the responsibilities of a frontend developer, because they assume the role is simply HTML markup and “making it look nice” with CSS (funny how most FS devs I know despise or avoid CSS altogether, despite being one of the most important parts of FE Development).
Many conversations had an uncomfortable tone that suggest “That’s so easy — I can totally do your job”, yet they struggle when tasked with improving accessibility, or optimizing performance beyond minification, or explaining how a browser actually works.
Personally I’d like to do away with the term altogether, because the “stack” is becoming more and more ambiguous these days when you consider DevOps, Serverless, etc.
Thank you for sharing that perspective. I think you perfectly explained why empathy is important (regardless of the title).
Having done backend and UI about equally, I think they both have unique challenges. And like you said, if you don’t recognize or understand that CSS is hard or that state management in UI development is hard... then you probably won’t be a very compassionate coworker. So yes, I can imagine that it’s hard to scan for candidates that express that understanding or at least that desire to understand.
But hey, I think that the fact that you’re interviewing for those qualities will only help to build more empathetic teams. So thank you! :)
One additional anecdote I would like to share about the Full Stack title in general: I do worry that the title is not viable and potentially harmful to one’s career in the long run. I observed first-hand a Fortune 50 company attempt to make all their developers “full stack” with little to no success, but a TON of employee burnout, unrealistic expectations from stakeholders and managers, and a shameful amount of turnover. It’s too nebulous a term that many people have their own expectations of what it means, and then suddenly, your job description and responsibilities grow, without a clear foothold to negotiate appropriate compensation because “well, everyone is full-stack here.”
Better to specialize in one area, have a clearer career path for advancement, and a more sane work-life balance IMO! What’s the advancement path look like for a “Full Stack” developer? They risk being stuck at mid-level more so than those that specialize in an area.
Correction: It’s likely more lucrative and viable a career path for contractors who can negotiate their own rates more easily than a full-time employee could.
It’s a good counterpoint. Like it’s definitely something to consider. But this article isn’t about convincing a company about how it should run it’s business. It’s about giving developers freedom to become a generalist if that’s what they like (I know I do). Like seriously, if a company asks me to be only front-end or back-end, I refuse the position because I know that it won’t make me happy enough to stay motivated. But I understand that some developers have the opposite career goals. It takes all kinds of people, and a good company should understand that necessity to have diverse skill sets (specialist, generalist, etc). I’ve had to argue my value as a generalist many times, but once people observe what I add to a team, they start to get it: I’m someone who has enough range of knowledge that I can help bring a team together and ensure that a feature is delivered cohesively. Meanwhile, a generalist can also help remind the specialists on the team that each person’s job is hard and deserves appreciation (if they’ve forgotten).
Side note: full stack is much more possible when the whole stack is JS (ie NodeJS) backend. It’s a little unrealistic if it’s Ruby or Python on the backend and JS in the front end since they look so different. The context switching gets really tiresome (and I’ve experienced that first hand). That’s why I really admire the JS stack.
It's a pretty silly meme easily countered by its own silly memes. "Backend dev: highly detailed drawn donkey rump" "Front-end dev: highly detailed horse head" Join the two together with some duct tape.
In the past most known webmaster.
Hey I'm the guy in that photo!
I imagine the full talk will be posted soon on Smashing Conferences YouTube channel, where anyone could watch for more context here.
Here's my follow up slide, which is more of a self-portrait really:
Thank you so much Chris for making me aware of where the slide was from. I gave you a follow, you can follow me back and DM me the link when it posts. I’ll update the article then with your link and the credit. :)
Jokes aside the meme seems accurate, though. I think people mistake "fullstack developer" with "perfect developer". For me, and I realize this definition might not be accurate at large, the concept of being fullstack means I can deliver a whole application on my own if needed be; can design it and it's database, develop it back and front, then deploy it. It must be working, not perfect, you don't need to be a master in any of those, but you must at least "talk the language" of each, that way you can be part of any team or even go solo, that's how I interpret the "full" in fullstack.
For me, whilst I know my way around Vue, Bootstrap and whatnot, I definitely am not a "web designer"; my apps are always functional and have a solid backend with optimized queries and indexed tables, but they always have that crude "bootstrapy" feel, and almost no images. No one has to be perfect at anything, less yet at everything.
Thank you for your response Matheus. I love your quote about self-acceptance:
This is exactly the message I wanted to make when I started blogging. I have a couple of articles in the queue about this very important point. Thank you for highlighting it. :)
Hey man, as a guy who laughed out loud about that slide in Chris' talk and also retweeted it, I am truly sorry that you took offense in this.
BUT: my experience is quite contrary to yours and I strongly disagree with your points being made.
"All too often, managers stand behind tired ideas like “there is no full stack developer” and then force team structures that prevent good, quick conversations."
Nope. From my experience all too often companies try to hire on-guy-does-it-all solution for most of their problems. The so-called Full-Stack-Dev. And this is a more serious problem than it might seem because it changes the whole industries' notion of what matters.
That's why we have tech-bros claiming that you should "only learn JS" because the other stuff "doesn't matter" and "CSS sucks anyway" totally invalidating Front-Enders that write performant and scalable Project-Architecture with dozens of years of experience hence to not knowing enough Javascript. Or React. Or Vue. Or Typescript (Who still writes JS anymoe duh?)...
That's why many companies hire backenders (or JS-ninjas) only, because they think that HTML/CSS are easy and everyone can do it. That's why Front-End jobs get paid less. This why Semantic structures in HTML tend to be ignored more and more making the web less accessible to many users that would need it. That's why co-workers of me are being made fun of for using PHP.
And this in the end is not what "building bridges" looks like - this is gatekeeping.
Also: "team morale through empathizing, domain knowledge transfer, better estimates since everyone has passing familiarity with each layer of the stack, people helping out..." isn't a matter of everyone doing the same stuff (to some degree) but a matter of respecting each others capabilities and different skillsets and eager communication don't you think?
We have worked at different companies. All of the companies I have worked for have been hiring exclusively backend or front-end. Before I get into sharing my responses to your response, I think it’s important to state that we come from different experiences and therefore it’s totally possible that both our opinions are valid. To put it another way, the truth is probably somewhere between your opinion and mine.
I like lots of different languages, and I always encourage a team to pick what works for them. So I can say that even though I am by-design a full stack developer, I’ve never purposely tried to invalidate another developer. In fact, every couple of years I purposely ask to join a different team in a different language so I can step in someone else’s shoes for a while. I’ve already told my manager that the next team I’d like to work on is the Kotlin/Swift team at my company that builds our mobile app.
You lost me there a little bit because most JS devs have familiarity with HTML and CSS right? And most people that have tried it know how challenging it is. So I always try to evangelize at my company how important and difficult the UI work actually is. But maybe I just have a lot of empathy for UI development because I’ve done it for so long. I think that was my major point: don’t try to speak on behalf of another group of people until you’ve tried their job. I spent half a decade being a backend developer, another half decade as a front-end developer, and now I do whatever the user needs. And along the way I do my best to fight for my peers.
Yea, I have no idea why that is. Maybe managers don’t have enough experience in UI development to be able to empathize with the craft of UI development. I don’t know, but it’s silly for me to guess why the salary difference exists. I personally hope it becomes equal to backend work (or that it works like it does at my current company where it’s just “Software Engineer” with no distinction so that developers can change as their interests change).
I hear you. I ran a 2 year long a11y seminar at my last company that was designed to show any and all developer who was interested in attending about the value of markup for accessibility.
I’m sorry that they’ve made fun of you. You shouldn’t have to deal with that.
I’m not familiar with the term gatekeeping, but I will refer you to the many other comments in this thread of other people who identify as “full stack” who are desperately seeking to be seen. My article was designed to shine a light on those who like being a generalist. Ultimately, I want people of all skills and interests to be welcome to bring their skills to the table to help the user. I’m sad that this wasn’t clear in the article. Do you have any advice on how I could have made that more apparent? I’ll make sure to improve it in future articles.
Yes. I absolutely 100% agree.
So I read the word empathy being thrown somewhere on the comments, so maybe I can share a bit of an "out of the stack reason why this meme actually makes a point that is not necessarily offensive".
I'm a "Fullstack Designer" or "Product Designer" (I do UI/UX and CSS/JS daily) and at my current company anyone who can open an IDE is titled Software Engineer (their reasoning for this is expressed in this discussion). So what consequences arise from this one size fits all approach for a design team? Instead of spending time designing, I had to spend hours/days talking with dozens of people to figure out who the people that actually care about the GUI were (I still have to nag all newcomers to see if they will be doing any frontend work).
Now I work with 5 different products in my company and I actually run our Design System complete with a CSS/JS framework (it's almost as big as Bootstrap). Not only I had to waste time hunting down my allies but I also keep getting stuck explaining basic HMTL/CSS all the time (which I love but one person alone cannot do everything).
Half of our full-stacker have expressed they would rather not touch frontend with a ten foot pole, yet they still count on recruitment as people that should be doing frontend, which has made it impossible for me to recruit a real developer to work with me.
Titles are really important if you have cross team collaboration but they are just that titles, you are not forbiddden from doing database work just because you are title frontend developer, neither the opposite. And making separate back front teams would only ever make sense from a org point of view, they should still collaborate as if they were a single team if that setup exists.
To end, I do not fool myself with empirical data but I have been working for a couple years now and I have only met 1/2 actual full stack developers, the usual is that they are good at backend and wrongly think frontend is easy.
Thank you for your response. :)
Yes that’s true, but sometimes companies put arbitrary gates between the different areas. I’ve seen pull requests denied (or delayed) simply because the PR was from someone on a different team.
I wish that was the case, but if you’re two different Scrum teams, then you have two different sprint goals and therefore the UI and the backend teams are disincentivized from helping the other team... because that would take time away from the individuals goals. Sounds terrible, but I’ve seen it happen on at least 4 teams. But when you combine the teams into one team with a common backlog, then they are insensitive to help each other get items into the “Done” column. Those are just my observations though. I would not be surprised if there are some teams that have been able to successfully bridge the two teams. But so far, it’s been 4 out of 4 occasions that the two teams were essentially completely independent. I believe this is Conway’s law (but don’t trust me on that).
I hint that the real issue at hand here is that companies and devs seem to have a misguided sense that their goal is to move stories across columns in a board, versus doing a product that humans will use.
I consciously moved to specialise in an area but found it frustrating. No idea what the other guys were up to. There became an unnecessary hierarchy. It wasn't fun. Perhaps a cultural thing, but no one was open to changing the dynamic.
I moved back to full-stack at a different company and we were in it together. We all worked on different projects but could help each other out. We taught and learned from each other.
I then moved back to a specialised role, but one that requires very good knowledge of the whole stack and each part of it technically has a stack of it's own. It's been a good compromise for me.
I've yet to see the company that can make a swap from full stack to front and back end teams successfully, through choice or necessity. I've seen it as a paradigm shift based on a companies perception that you can create a better production line for software, although changed no processes to support it creating a chicken or egg scenario. I've also seen it pushed by developers that did only want to work on a part of a system after being hired as full stack. In all instances I've seen either a lack of communication or communications breakdown.
For me the frustration is that a single full stack developer can create a fully functioning feature with very little to no assistance. Splitting the teams implies you need a minimum of 2 people to deliver a feature and you gain all the complexity of the communication and the shared understanding that is required.
This site used to have interesting stuff. Now it's full of people complaining about every little thing.
Juan, if you don’t care how your team is structured, that’s cool. But programming is a team sport. If you don’t have a good mix of skills or if you don’t have healthy people on the team... then you’re not gonna produce any value for the customer. Personally, I find team organization to be pretty interesting since it can make life hell or it can make work an absolute joy.
But yes, I wish I hadn’t made such a “Buzzfeed-y” title. Live and learn, right? :)
Indeed, that matches my experience as an actual front end developer.
And most full stack developers I know are actually backend with a smattering of experience working with specific front end frameworks or UI libraries. Nowadays, of course, this type of developer often prefers tools like React, which lets them fool themselves that they're doing front end development in a more pure and highbrow way, like True Engineers.
It's not a bad tool: nothing is all bad or all good. The extent to which it's overrated, because it is, is driven by several factors including a naive reaction against pillars of the web platform, such as low barriers to entry for users, designers, and developers. Accessibility for all. Graceful degradation.
Historically, of course, client side development of web UIs WASN'T much like traditional software engineering. That was a strength as much as, admittedly, a weakness. I fear that we've gone too far in the other direction now, though.
Over the last several years, I've seen too much completely unnecessary complexity and smug exclusionary behavior. Too much sabotage of reach and user experience. Too much completely unwarranted abuse of potential mentors and peers. I suspect it won't be corrected anywhere near Silicon Valley.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.