I can't be the only person who thinks "full stack" translates to "master of nothing." One of the best career moves I ever made was shrug off the pressure to go full stack, and dedicate myself to backend only.
I think knowing about frontend is important for a senior or higher level engineer. I would expect someone at that level to be able to contribute where necessary, and know enough to make sane decisions and know when those decisions impact backend/frontend. But to be equally good at both isn't reasonable
A backend engineer that has adequately put in the time to operate at a senior level, will more than likely have worked closely enough with FE to check those boxes. They should be familiar with technical design and processes, which if done effectively, teach an engineer to ask those questions.
When it happens? That happened to me a long time ago. I’m still a backend developer. I can create UIs and I can spin up and manage docker CI infrastructure but I sure as hell don’t want to. A properly run company team should have separate professionals for UX, front end, back end, sysadmin, etc. Just because I am capable of doing those things does not mean I should.
Just because I am capable of doing those things does not mean I should.
This is the crux of why so many companies, especially smaller and medium sized ones, are a hot mess. capable of << good at, but of course it's cheaper to just get johnny to do everything.
My apologies. My intention wasn't a dig at engineers themselves, but rather the trend of employers seeking "full stack" engineers, and the implications of them shopping for a singular engineer willing to do the job of multiple engineers-- IE be taken advantage of, and the first to be let go, because of a lack of specialized domain knowledge, etc.
My company started with full stack devs only and we've transitioned to specialized back end and front end since we realized that 1 specialized BE Engineer and 1 specialized FE Engineer can work faster with better quality than having 2 Full Stack Engineers.
I sometimes wish my employer didn't know that I can write Python code, so that I would never be assigned front-end work. I prefer to deal with programs that take lists of numbers and return lists of other numbers.
(I'm not as bad as one guy I used to work with, because at least I accept ASCII input. His backend code only took binary-encoded configuration files for no reason I can think of except maybe to punish anyone except himself who tried to use it.)
You could do templating with jinja, or do some data visualization with bokeh. I think there's also something called dash. I don't know much about any of them though.
I mean, python has pickle and people use that to store config. It's a weird practice, and totally unsafe, but it works well enough. This wouldn't be that different.
Not understanding SQL (and in some cases NoSQL DBs) and the underlying database are a reason that so many full stack devs suck. Just because they use an ORM, they think the database work is magically solved, until they realize it’s just doing what they’re telling it to do and their lack of DB understanding has created an awful database structure. And then a DBA comes in, and then the entire ORM layer has to be scrapped because it’s trash, so on and so forth. A full stack engineer doesn’t have to be a DBA, but they sure as hell need to know what the ORM is doing to their data they are CRUDing
Frontend dev here, can confirm. Last week I had to look at some Java code and was instantly greeted by some AbstractFactoryBuilderImpl. Nightmare fuel if you ask me.
It may suggest the company doesn't want to hire the appropriate amount of engineers, with the appropriate expertise, and instead want a mule. It also may suggest that product quality is a low priority.
I love shitting on Fullstack devs as much as the next guy. However, sometimes it really just does make sense for an (often internal) product maintained by a one-person team, and it doesn't have to mean that the organization doesn't value them. I've seen it happen.
However I would not recommend it as a career path because it's essentially impossible to tell what you're getting into when you get hired. Could be what I just described, could be that you inherit the full responsibility for a 20 year-old perl+php5+xhtml+angularJS mess. I think it can only truly make sense if you work independently and get to build projects to your own quality standards, assuming you manage to find a "scope is small enough that specialization doesn't make sense" niche. This is very hard which is why in practice "full stack" tends to mean "master of none but good enough to get a product out the door cheaply".
Backend Requirements: "When x,y goes in, I want x+y to come out!" - Okay
Frontend Requirements: "Well it needs to be more user-friendly, and have this rockstar wow effect" - Yea wtf are you even talking about? You want me to add random glitter explosions, because I found a script for that, that's pretty 'wow effect' right?
Isn’t our main audience German? If you wanted non German stuff you shoulda asked for regional translations. Not only is that a change request, but you’re gonna be pushing the release window by months.
I spent years as a mobile developer and the thing that always drove me the most nuts was being handed a software design with lots of tiny buttons that were nearly impossible to tap with a finger. I generally implemented the UI by increasing the size of the tappable regions (without increasing the apparent size of the buttons) making it actually usable, but one time the designer discovered that I was doing this and went apeshit and convinced the project manager to order me to undo all this and make the tappable regions the same size as the buttons. The grounds for this was that implementing the larger tappable regions would take too much extra time - despite the fact that this had already been done and it took additional time to undo it.
I usually just do what they requested and when they come to complain I just tell them "well, you're the one who requested this" and pull up receipts. My DM to myself on Slack is filled with screenshots and links to confirmations for bullshit requests that the product team made.
Real back-end requirements: when x, y goes in (in JSON-as-an-XML-CDATA-block because historical reasons), I want you to output x+y+z+æ+the proof to P=NP.
æ will require you yo compile x+y in CSV, email it to Jenny, who will email back the answer. She doesn't quite know how to export excel sheets though so you'd better build a robust validator. No, we don't know what æ is supposed to look like, Rob from Frontend knows but he's on vacation for the next 8 months.
The request must be processed under 100 ms as the frontend team won't be able to prioritize asynchronous loading for another 10 sprints and we don't want the webpage to freeze.
And why does your API return a 400 when I send a picture of my feet? Please fix urgently, these errors are polluting my monitoring dashboard and we have KPIs on monitoring alerts.
Yea, fair enough. My point was mostly: backend requirements are usually at least objective. "Json xml comes in", "CSV goes out by email", "The request must be processed under 100 ms", "API should not return 400 on feetpics" - these are still mostly objective requirements.
Frontend requirements can be very subjective "The user should have a great user experience with the frontend"
Hahaha that's what frontend devs think, but the backend requirements are just as vague: "Just make this button work". In my example all the requirements would actually be figured out bit by bit over months, nevermind the prescience required to foresee future architecture-breaking features or scaling requirements. At least you can make a mockup and get instant feedback, flawed as it is.
On either side it takes experienced engineers to suss out actual requirements from customers/PMs. The main difference is that the backend (especially on the infra/devops side) is only accountable to itself if everything goes well, but ironically that means no-one knows or cares about the amount of engineering that goes into keeping PMs blissfully ignorant of the risks and complexity.
Hahah, well as a primarily backend developer, that's what I think as well.
“Just make this button work”
If that button doesn't work, that sounds like a frontend problem to me.. ;)
But yea, as you mentioned, it probably comes down to experience. As the meme from this post depicts. When I dabble in frontend and make a WinForm for my devtool, people just look at me and are like "Uhhh, can you make it better?"
No sir, clearly I can not. And I have no idea what you mean with "better".
Yeah if you have shitty UX people frontend will just built what they’re told. Or actually more often, you could have really talented UX people and management decisions are like “needs more buy now buttons, the 3 visible on the screen aren’t enough.” Shit flows downhill
Man, if only backend demands were algebraically tractable. Often they're related to frontend demands that may or may not make backend sense, since the frontend is all users see.
I'd suggest finding some examples or templates that are reasonably close to what you want, and working from there. It's much easier to adapt something existing with small tweaks than building it all yourself.
If you have any concrete questions, feel free to shoot me a DM :)
This is the dumbest trope. It's not the same kind of job, or even very coding-ish, but all the frontends I've made are horrifyingly ugly, and I hated making them.
Most disciplines get more specialized as they evolve. Full Stack goes against that trend, and this meme points at the problem with that. I don't think it's going to last.
Overspecialisation can also suck eggs. Interdisciplinary research is trendy in science for the that reason. Even I occasionally read a paper and can see they're missing some basic fact from another field or subfield that totally undercuts their result.
I would say I'm a fairly proficient dev overall, though on this one project I had to work the frontend. It was shit. Everything was shit.
The backend was a steaming pile of crap, and all of the implications of terrible design decisions were offloaded to the frontend. The frontend became the source of every single delay as it was where all crap started to surface. They were ignoring it, so besides frontend communication was also crap. Eventually, in line with ignoring all other issues, they sacked me.
Long story short, backend devs: treat your FE devs well.
Dr. Wesker
in reply to LinearArray • • •ImWaitingForRetcons
in reply to Dr. Wesker • • •Fal
in reply to Dr. Wesker • • •Dr. Wesker
in reply to Fal • • •Ethan
in reply to Fal • • •unalivejoy
in reply to Dr. Wesker • • •MajorHavoc
in reply to unalivejoy • • •I feel seen.
I might get that sentence embroidered on a pillow.
Ethan
in reply to unalivejoy • • •unalivejoy
in reply to Ethan • • •Ethan
in reply to unalivejoy • • •DreadPotato
in reply to Ethan • • •This is the crux of why so many companies, especially smaller and medium sized ones, are a hot mess. capable of << good at, but of course it's cheaper to just get johnny to do everything.
Prunebutt
in reply to Dr. Wesker • • •Dr. Wesker
in reply to Prunebutt • • •Prunebutt
in reply to Dr. Wesker • • •No worries. Wasn't really offended. ;)
Fuck that employer behavior, though.
Rodeo
in reply to Prunebutt • • •It just means he can't do it by himself.
Yours won't be perfect, but you can do the whole thing by yourself.
Dr. Wesker
in reply to Rodeo • • •Username
in reply to Prunebutt • • •sheogorath
in reply to Dr. Wesker • • •Simulation6
in reply to Dr. Wesker • • •ArbitraryValue
in reply to LinearArray • • •I sometimes wish my employer didn't know that I can write Python code, so that I would never be assigned front-end work. I prefer to deal with programs that take lists of numbers and return lists of other numbers.
(I'm not as bad as one guy I used to work with, because at least I accept ASCII input. His backend code only took binary-encoded configuration files for no reason I can think of except maybe to punish anyone except himself who tried to use it.)
Johanno
in reply to ArbitraryValue • • •odium
in reply to Johanno • • •DichotoDeezNutz
in reply to odium • • •odium
in reply to DichotoDeezNutz • • •Pup Biru
in reply to odium • • •muntedcrocodile
in reply to odium • • •ℍ𝕖𝕝𝕝𝕤𝕥𝕠𝕣𝕞𝕪
in reply to Johanno • • •MonkderZweite
in reply to Johanno • • •Trailblazing Braille Taser
in reply to ArbitraryValue • • •I'm terrified by this binary config file. Why?! Was he writing C and said "fuck it, memcpy"?
Edit: I suppose it would be more like "fuck it, fprintf(f, (char*)my_config_object, sizeof(my_config_object))"
Troy
in reply to Trailblazing Braille Taser • • •invertedspear
in reply to LinearArray • • •As a fullstack developer I don’t appreciate you calling me out like this. Write an efficient SQL query you framework monkeys.
But also, this is very true.
PhlubbaDubba
in reply to invertedspear • • •DROP TABLE
That seems like a pretty efficient query!
SuperDuper
in reply to PhlubbaDubba • • •astraeus
in reply to SuperDuper • • •watcher
in reply to PhlubbaDubba • • •kautau
in reply to invertedspear • • •JaxNakamura
in reply to kautau • • •I'm convinced that's a mythical being. In my 20+ years of experience I've never encountered one.
Wojwo
in reply to invertedspear • • •Sickday
in reply to LinearArray • • •eluvatar
in reply to Sickday • • •NoisyFlake
in reply to Sickday • • •NigelFrobisher
in reply to LinearArray • • •Saledovil
in reply to LinearArray • • •What I was told by a fellow student, while I was writing my thesis (paraphrased).
Dr. Wesker
in reply to Saledovil • • •Kericake🥕 (They(/It))
in reply to Dr. Wesker • • •Came here to ask if I'm the only one grossed out by the term "full stack" and its exploitative implications. Thanks for explaining why :3
Hey, maybe they make up the difference in "exposure" or something! That's a well-loved way to ask for free/underpaid work!
azertyfun
in reply to Kericake🥕 (They(/It)) • • •I love shitting on Fullstack devs as much as the next guy. However, sometimes it really just does make sense for an (often internal) product maintained by a one-person team, and it doesn't have to mean that the organization doesn't value them. I've seen it happen.
However I would not recommend it as a career path because it's essentially impossible to tell what you're getting into when you get hired. Could be what I just described, could be that you inherit the full responsibility for a 20 year-old perl+php5+xhtml+angularJS mess.
I think it can only truly make sense if you work independently and get to build projects to your own quality standards, assuming you manage to find a "scope is small enough that specialization doesn't make sense" niche. This is very hard which is why in practice "full stack" tends to mean "master of none but good enough to get a product out the door cheaply".
(des)mosthenes
in reply to LinearArray • • •RonSijm
in reply to LinearArray • • •Backend Requirements: "When x,y goes in, I want x+y to come out!" - Okay
Frontend Requirements: "Well it needs to be more user-friendly, and have this rockstar wow effect" - Yea wtf are you even talking about? You want me to add random glitter explosions, because I found a script for that, that's pretty 'wow effect' right?
KevonLooney
in reply to RonSijm • • •KairuByte
in reply to KevonLooney • • •KevonLooney
in reply to KairuByte • • •Darrell_Winfield
in reply to KevonLooney • • •NigelFrobisher
in reply to KevonLooney • • •veroxii
in reply to NigelFrobisher • • •OKRainbowKid
in reply to veroxii • • •Cwilliams
in reply to veroxii • • •ChickenLadyLovesLife
in reply to KevonLooney • • •kurwa
in reply to ChickenLadyLovesLife • • •sheogorath
in reply to kurwa • • •This is fine🔥🐶☕🔥
in reply to sheogorath • • •How good does it feel when you pull out those screenshots to say, 'no u'?
ChickenLadyLovesLife
in reply to kurwa • • •Have you ever used a mobile app? Every commercial mobile app I've ever used has tons of tiny fucking buttons.
dylanTheDeveloper
in reply to kurwa • • •Doc Avid Mornington
in reply to ChickenLadyLovesLife • • •azertyfun
in reply to RonSijm • • •Real back-end requirements: when x, y goes in (in JSON-as-an-XML-CDATA-block because historical reasons), I want you to output x+y+z+æ+the proof to P=NP.
æ will require you yo compile x+y in CSV, email it to Jenny, who will email back the answer. She doesn't quite know how to export excel sheets though so you'd better build a robust validator. No, we don't know what æ is supposed to look like, Rob from Frontend knows but he's on vacation for the next 8 months.
The request must be processed under 100 ms as the frontend team won't be able to prioritize asynchronous loading for another 10 sprints and we don't want the webpage to freeze.
And why does your API return a 400 when I send a picture of my feet? Please fix urgently, these errors are polluting my monitoring dashboard and we have KPIs on monitoring alerts.
evatronic
in reply to azertyfun • • •I'm sure there's an npm module for that.
soggy_kitty
in reply to azertyfun • • •RonSijm
in reply to azertyfun • • •Yea, fair enough. My point was mostly: backend requirements are usually at least objective. "Json xml comes in", "CSV goes out by email", "The request must be processed under 100 ms", "API should not return 400 on feetpics" - these are still mostly objective requirements.
Frontend requirements can be very subjective "The user should have a great user experience with the frontend"
azertyfun
in reply to RonSijm • • •Hahaha that's what frontend devs think, but the backend requirements are just as vague: "Just make this button work". In my example all the requirements would actually be figured out bit by bit over months, nevermind the prescience required to foresee future architecture-breaking features or scaling requirements. At least you can make a mockup and get instant feedback, flawed as it is.
On either side it takes experienced engineers to suss out actual requirements from customers/PMs. The main difference is that the backend (especially on the infra/devops side) is only accountable to itself if everything goes well, but ironically that means no-one knows or cares about the amount of engineering that goes into keeping PMs blissfully ignorant of the risks and complexity.
RonSijm
in reply to azertyfun • • •Hahah, well as a primarily backend developer, that's what I think as well.
If that button doesn't work, that sounds like a frontend problem to me.. ;)
But yea, as you mentioned, it probably comes down to experience. As the meme from this post depicts. When I dabble in frontend and make a WinForm for my devtool, people just look at me and are like "Uhhh, can you make it better?"
No sir, clearly I can not. And I have no idea what you mean with "better".
gravitas_deficiency
in reply to azertyfun • • •twitches
This is fine.
I am fine with this.
kautau
in reply to RonSijm • • •Fades
in reply to RonSijm • • •perviouslyiner
in reply to RonSijm • • •1977 narrowband radio signal from SETI
Contributors to Wikimedia projects (Wikimedia Foundation, Inc.)CanadaPlus
in reply to RonSijm • • •brettvitaz
in reply to LinearArray • • •fidodo
in reply to LinearArray • • •Fades
in reply to fidodo • • •frezik
in reply to Fades • • •CanadaPlus
in reply to frezik • • •Anders Rytter Hansen
in reply to LinearArray • •Programmer Humor reshared this.
hector
in reply to LinearArray • • •Guys I can’t do front-end! There was a time I was getting kinda good but now there’s too much CSS tricks to learn.
I’m currently making an app for the fediverse and my back-end is amazing but I need help even beginning to make something decent for the front-end!
This is a streaming app, and just developed the chat widget which looks good in OBS, that’s a start.
But the player? Responsible layout? Aaaah it seems impossible.
FooBarrington
in reply to hector • • •I'd suggest finding some examples or templates that are reasonably close to what you want, and working from there. It's much easier to adapt something existing with small tweaks than building it all yourself.
If you have any concrete questions, feel free to shoot me a DM :)
hector
in reply to FooBarrington • • •FooBarrington
in reply to hector • • •frezik
in reply to hector • • •hector
in reply to frezik • • •I don’t know the developer experience with React+Vite has been amazing for me!
Fast HMR, detailed stack traces, and typing support is so cool!
mhredox
in reply to hector • • •hector
in reply to mhredox • • •Fades
in reply to LinearArray • • •adrian783
in reply to Fades • • •CanadaPlus
in reply to adrian783 • • •ipkpjersi
in reply to LinearArray • • •frezik
in reply to LinearArray • • •CanadaPlus
in reply to frezik • • •corstian
in reply to LinearArray • • •This is me.
I would say I'm a fairly proficient dev overall, though on this one project I had to work the frontend. It was shit. Everything was shit.
The backend was a steaming pile of crap, and all of the implications of terrible design decisions were offloaded to the frontend. The frontend became the source of every single delay as it was where all crap started to surface. They were ignoring it, so besides frontend communication was also crap. Eventually, in line with ignoring all other issues, they sacked me.
Long story short, backend devs: treat your FE devs well.
Justas🇱🇹
in reply to LinearArray • • •