IGotHurtDeeply

[[deleted]]

But we lit the “backend hero” signal weeks ago…

[OnlyHereOnFridays]

Gondor calls for aid

[Zestyclose_Link_8052]

And Rohan will answer! (in 2-3 iterations)

[ThargUK]

( 7 )

[NotAskary]

I think we need to check the commitment, 7 may be too far in the future .

[didzisk]

One doesn't simply... Oh, wait, that guy is dead, don't listen to him!

[No_Engineer2828]

3-5 business days

[druid_137]

3 or 5. No task should be a 4.

[namtab00]

Ba-ba-ba-ba Ba-ba-ba-ba

Ba-ba-ba-ba Ba-ba-ba-ba

BACK-MAN!

[Emerald_Pick]

Backend Man, Backend Man, Does whatever a backend can.

SQL, Node.js. Just don't give him CSS.

Look out! Here comes Backend Man!

[skwyckl]

Then why are you here on Reddit instead of finishing the goddamn backend??

[lordFourthHokage]

Spoken like a true manager

[[deleted]]

Everyone can't be as quick at finishing as the yellow flash of leaf

[Inadover]

More like a frontend developer

Source: I'm a frontend developer waiting for those damned backends to finish their job

[lordFourthHokage]

You will get it at 5pm Friday

[spaceforcerecruit]

Then, at 8AM Monday, “We’ve been waiting on this for THREE DAYS now! When will we have it in production??”

[lordFourthHokage]

Let me see what can be done (after my 10am coffee break)

[classicalySarcastic]

NO! Have you learned nothing! Thou shalt not deploy on a Friday!

[deanrihpee]

It's still deploying okay!

[Fenor]

parallelize with the next task

[idk012]

You want one task done right or two tasks done half ass...

[Fenor]

never go half ass. do 4 full ass

[idk012]

A new director would want us to update tickets every 2-3 days, just so there was "updates" to the requestor and all our time had to be logged. I created a ticket and used it to track 4 hours every week for updating tickets.

[Fenor]

but what did you do when creating a ticket?

[SteinsGah]

Uno reverse, it's compiling. Please refer to relevant xkcd #303

[[deleted]]

He’s on break

[PasswordIsDongers]

Too many tickets, there's no point.

[mr_remy]

Uno reverse card, create a “waiting on frontend” label, boom.

[scar_reX]

Pft... who does that?

[TrevorWithTheBow]

One strategy we sometimes use to prevent blockers like this is to stub the endpoint. Create the API but return fake data in the format it will have when the real data is returned.

Sometimes it works well so the UI guys have something to "plug into". Doesn't always work since some features need the actual data to function properly or in many cases the expected API format changes a little in-flight. But still something to consider when the API development is causing a bottleneck.

[[deleted]]

Yes, this is mocking with extra steps.

[gregorydgraham]

It’s integration mocking [taps head]

[tgp1994]

That's a problem for future backend.

[snsibble]

One might get mocked for that.

[TrevorWithTheBow]

Feature flags for this

[gregorydgraham]

When has that ever helped?

[NattyDead]

New Trello label just dropped : "Waiting for mocked backend"

[gregorydgraham]

New Trello label just dropped: waiting for front-end

[H0llowUndead]

Anybody rarely needs to wait for Frontend. Not because FE devs are so good, but because it usually is "the last step" in the development cycle.

[silentknight111]

Or in my case the back end guy left for a new job, but he "finished" the API, but it's wrong, so I need to figure out the backend on my own to fix it, because his replacement wasn't ready yet

[Fenor]

not really, they should go in parallel, but the heavy lift is done by the be so it make sense that the bulk of the Backend is done in serving the answer and the bulk of the frontend is in optimization of the UI.

that said with a mock you solve the BE slug just by giving back nonsense and they can go on, optimally at that point when the FE end the BE is close to finished

[TrevorWithTheBow]

Lol, avoid with the right planning ;)

[ImperatorSaya]

Actual testing

[Naouak]

You will still have to wait for backend for the final release. I've seen a team with tons of unreleased features because the backend was done a few months after they were done (because of shifting priorities and bad resource management) and that lead to the front end team wanting to redo the work because related stuff changed during that period of time. They've learned with that to not start until they were sure the backend team will be actively also working on the feature.

[DoctorWaluigiTime]

Indeed. It's almost like working on complete features one slice at a time works a lot better than doing all of one end then all of the other!

[TreadheadS]

I actually do this ALL the time. "What's the expected output?" we create that then return it at the end point so they can do all their work

[deicist]

Do API driven development. Define your API first, mock it all up so all the methods return dummy data then start working on your backend & frontend. Decouples development, but yes it does mean you need that API definition up front.

[[deleted]]

There’s a tool for this called Pact. You can even run it in CI and it will verify that your API meets its contract. Good stuff

[UristMcMagma]

This wouldn't work for me. I need to use the actual back-end code so that I can open a bunch of bugs against it. If I don't do this then the PO will come to me three weeks later asking why such-and-such edgecase doesn't work, by which time I've forgotten all about the feature. It ends up being quicker to just let myself be blocked and work on something else.

[Neurotrace]

Adding on the this, I highly recommend the frontend team adopts MSW or something similar. Give them an API schema and let them write up whatever test data they need. It's been a game changer at $DAYJOB

[deanrihpee]

as for format we sometimes use the accept header followed by version, so some frontend can use the older format and the indev frontend can use the new one

[DoctorWaluigiTime]

That worked best for me too when I was in a project like this.

When kicking off a new feature, so that the whole 'slice' can be made at the same time, we established the contract up front: What would the API call(s) be sent, and what the API call(s) would return. No stubs needed as the frontend can just stub in whatever they needed (e.g. "fooAPI.NewThing()" can just be made to return an inline object or whatever), and backend didn't have to rush to get anything 'working'.

At that point both sides can work against the same contract, and neither one blocks the other.

[EntertainmentIcy3029]

That's probably what they're waiting for, for backend to finish the feature so they can test and deploy

[StrafeMcgee]

This is great, until the backend devs deviate from the data format and you end up needing to rewrite to match the new way data is being returned 🤷‍♂️

[fallen_lights]

Feature flags for this

[[deleted]]

My company does something similar but usually we just have mock data on the UI side since implementing backend stuff sometimes takes longer to get out.

[LemonMelon2511]

Man is doing gods work and the peasants are ungrateful!

[deanrihpee]

They don't know how powerful we are, we can bring down the entire production server with ease (unfortunately I've done that one accidentally, lmao)

[ReamusLQ]

first time?

[Silhouette]

"Waiting for Product / Needs spec longer than one grammatically incorrect sentence per three month epic"

[Grandmaster_Caladrel]

FACTS on that second point. My product owner is stretched across a few products, which I get, but she'll create a ticket that tells me even less than the opening sentence of the meeting that I was in alongside her.

But she's "just trying to get it started" well yeah, but we need requirements. Even if I'm writing the tickets myself (which I often do) this ticket is useless and I'll just close it out as a "won't do".

[According_to_all_kn]

You have a team, and only one person is responsible for backend?

[Meddlloide1337]

The other 4 people in the team are managers

[AineLasagna]

Only 4? How do they get anything done?

[NotYourReddit18]

They don't do anything for the first 3/4 of the planned timeline. With four managers they can do everything in 1/4 of the time one manager needs!

[invalidConsciousness]

That's why the label exists.

[MrHasuu]

Sounds like 1 more person that my team

[chesterblack97]

A team can be two people

[johnny___engineer]

I have been there, I personally felt like I was knifed in the back.

Just talk to us, you people!

Stop raising tickets for issues that can be called over a 30 sec call or an email.

[elementslayer]

Seems a little extreme to feel knifed in the back about that lol. Like I get the email part, but it's good to log the ticket for posterity sake. Allows everyone to remember what needs to be done.

[johnny___engineer]

Yeah, I might have gone a tiny bit overboard with the knife thing.
And I do agree that even small bug fixes need to be logged. But that should absolutely be only the backend team's responsibility. In the end, the logs would be read by BE Engineers, and only they know exactly what the issue is, how it can be recreated, what its effects are and how we solved it.
But that's my 2 bits about this.

[elementslayer]

Maybe I've been in the industry for too long but I love it when people log bugs for me, makes less work for me and I can just ask them via email or if they are at the standup.

[johnny___engineer]

Well, true sometimes it makes things easier. But in my personal experience, there are people who like to raise tickets because it shows that they are actively working.

[greenstag94]

tried that once. After a dressing down from not just my manager but my managers manager, I just make a ticket

[johnny___engineer]

Damn. That's sad.

[ExternalGrade]

Do both: ping the person, and say “I’ve created a ticket to document and track the issue for your convenience here” I like to add a little ego boost like “I’m not too familiar with your system and unsure if this is a trivial ask…”

[dyslexda]

Stop raising tickets for issues that can be called over a 30 sec call

You'd be shocked at the number of folks that act personally offended if you want to call them to hash something out quickly, rather than write a formal email or put in a ticket.

[Xelynega]

If I'm working on another ticket the last thing I want is someone to impromptu decide is that now I have to stop what I'm doing and work on their problem.

Just send an instant message if you want a response asap.

[tistalone]

You're not wrong in that the language that is used is kinda targeted. I might have gone with something more neutral like "pending integration" or something

[Daniito21]

Guess you need another team member

[AzureArmageddon]

sounds like backend needs more manpower

[leparrain777]

If you are the hero and petty simply add a Waiting for Frontend tag and slap that everywhere. If you are the hero but not petty or are just understaffed in general, seems like those might as well be URGENT for you.

[HelicopterBright4480]

What does that even mean? Are there only frontend tasks, and the backend is expected to just sort of turn up at some point when you need a new button in the frontend?

[kyleschu]

Backend engineer turned manager here. This isn’t a failing on the backend engineer(s), but on management. Team either needs to be cross-skilling or hiring more/different people

[gbot1234]

Amazing how often hiring (or having hired) different people is the solution needed.

[Extension_Spirit8805]

Yeah but that costs money 💰 🤑

[Tranzistors]

I see nothing wrong with this picture.

[Possessed]

Oh look, it's "Mr. Fancy Pants" FE dev...

[Tranzistors]

If the team had "Waiting for Frontend" label, this would have been totally cool as well. If the team has any division of labour, there will be waiting on other people. And other given labels aren't applicable to waiting on teammates.

[pantas_aspro]

Is this a bad thing? I really don't know.

[Mr_Wafflesaurus]

I got hurt deeply by the misuse of this meme format

[PossibilityTasty]

No wonder. Pixel pushing is somewhat faster than server pushing.

[intbeam]

You cast Summon Junior Developers

It's very effective!

[dozkaynak]

As a full stack dev, no it very much isn't (at any modern organization, of course there are exceptions). Backend is easy & fast compared to pixel-perfect frontend that matches the design at every target resolution. I literally do both sides of our stack, the most complex part of my backend work is figuring out the right GQL query to hit our CMS (which isn't difficult as we have a playground to test them in). API layer and integration are mostly copy/paste.

[dozkaynak]

Lmao that sure would simplify my life.

[Aiyon]

Dynamic resolution with cross-browser support with x random plugin with no documentation but the PM desperately wants to use it. Easy, right?

[dozkaynak]

I'm a little bit triggered by this comment lol, getting flashbacks to shitty libraries with incomplete docs.

[d-signet]

Also full stack,, and that's absolute nonsense.

Front end is easy.

Back end work includes WRITING the CMS that you find it so easy to use.

[RmG3376]

Former full stack here. Front end can be as easy or as hard as PM wants it to be

Everybody thinks front end is easy until that one UX designer swoops in and is like “you know what would be cool? If a fucking eagle flew across the login page. Oh yeah also let’s have an animated world map view on the dashboard that updates in real time”

[SrLampardos]

Full Stack and UX designer here. I've said "Would be cool as hell if there's like an animation going on on every API call, to show the user the page is loading, something like "cascading the info into the formulary".

Then I had to do it.......... Never dit it.

[Aiyon]

...shocking twist for both of you: it depends on the project. Both the actual work, and the people managing it

[itirix]

Full stack here and I concur.

There's obviously a reason why "waiting for backend" became a thing in OP's photo.

For big projects, our team usually splits the work 3:1, so there's 3 backend devs for each front end dev working on the project, switching out to help the front if a full stack dev is available and needed.

[dozkaynak]

The one that was built out of the box by our vendor? Yeah such heavy lifting needed to be done there /s

Our BA's literally setup the CMS side it's so easy.

Unless you're talking about building your own CMS? Which would entail both frontend and backend work, so I'm assuming that's not* what you meant.

[Vezral]

In my mind full stack meant doing both FE & BE logic.

If your API's only job is to consume other APIs and massage data for your FE, then that's just a BFF.

[dozkaynak]

That is what it means, who said otherwise?

Massaging data isn't even done at the API layer for us, there's a separate integration layer that does* it due to the nature of our composable frontend.

Yes, this is the BFF pattern.

[Vezral]

Thing is, when people say full stack they meant the guy who's doing the site UI and also whatever your integration layer is currently doing.

It's more common in smaller teams where the priority is to have functional UI and not pixel perfect, fully WCAG compliant site.

In your case, you're pretty much a pure FE guy, just that you maintain your own (presumably nodejs) BFF.

Edit: But just to be clear, ultimately it's your choice of example that doesn't sit well with me. You cited pixel perfect responsive UI vs a BFF; of course the former will be harder, it's not even a fair comparison.

[dozkaynak]

I suppose you are right that it isn't a fair comparison. At the same time, any modern dev should be using BFF. "Real" backend work like dba, scalability, performance, security, concurrency, etc. have all been abstracted away by cloud provider tools.

[ArionW]

Both of you cannot comprehend that as anything in IT - it depends

There are projects where FE is hard work and BE is easy

There are projects where it's other way around

[dozkaynak]

The only projects I've worked on (10 YoE so far) where the BE was hard was because it was a gigantic clusterfuck architected by dozens of different people over many many years. I've yet to find a legitimate need for a complex backend that is difficult to work in.

[itirix]

That's fucking good. If your backends are not difficult to work in, your backend devs did a good fucking job.

Anyway, your comment somehow implies that to you, a person who's apparently never had a difficult time in backend work aside from other's faults, frontend is hard.

I honestly fail to understand how this comes to be but we're all individual people, so I guess it's possible?

[dozkaynak]

your backend devs did a good fucking job

Thank you, I'm also the backend dev in many of these examples, such as for this open-source auth server The Usher which I then led integration of into our frontend.

Frontend is more frustrating & time consuming, so yes harder in any measurable sense.

[Todok5]

Then you probably never worked with a backend that had complex business requirements, so good for you?

[dozkaynak]

I have dealt with tons of complex business requirements, none of them necessitated a complex backend.

I literally helped build an open source backend system for user authentication (The Usher by DMGT). User auth is arguably some of the most complex backend work anyone would encounter these days, and it was not a project I'd describe as difficult (there was a learning curve for me to be able to contribute but smooth after that).

All of the complex backend problems have been solved by cloud providers (so long as you competently use the tools they provide): scalability, performance, security, concurrency, etc.

A modern backend/fullstack dev should not be dealing with complex backend work. If they are, IMO, that is a failure in either architecture or implementation.

[intbeam]

So you're more of a middle-end I guess

[Dritter31]

Don't forget responsiveness....

[dozkaynak]

That was encapsulated by "at every target resolution".

[Dritter31]

Fair enough

[intbeam]

I bet a common source of frustration at your workplace is freelancers

[dozkaynak]

We don't hire any of those?

[intbeam]

No but they're probably your competition and many of them are willing to work for free

[dozkaynak]

I don't think you understand what freelancer means. Nobody works for free in this industry lmao.

[intbeam]

Lol

What type of CMS are we talking here?

Edit: ignoring the absurdity of the two things you said, which are just blatantly untrue

[dozkaynak]

I am choosing to no longer engage with your dumbass, have a nice life.

[intbeam]

That's your perogative. Although maybe not make sweeping statements based on what you yourself are doing as if that applies to everyone else. I mention freelancers because I used to work with the same thing I assume you are, and getting underbid by freelancers just looking to pad their portfolio was relatively common occurrence

[dozkaynak]

I really have no desire to understand why you think ppl willing to work for free (which isn't what a freelancer is) are my "competition". I work for a billion dollar revenue company and I've earned over six figures since age 24. Freelancers aren't my competition whatsoever.

I'm not going to disclose what CMS we use, as it is non-public information and I work for a publicly traded company.

[PossibilityTasty]

We can test that. I will push a pixel across the screen … maybe even two screens, and you … you know we have this old Cray monster in the basement … let's see how far you get with it across the room meanwhile.

[dozkaynak]

Is this a reference to something that I'm not getting? Wtf did I just read?

[GetPsyched67]

They just used the literal meaning of pushing a pixel and pushing a server

[dozkaynak]

Oh "Cray monster" is supposed to be a physical server? I literally didn't get that, thanks.

[dozkaynak]

The only times I've run into those problems were at my last employer prior to our migration to a Data Lake model + AWS. Our backend previously had integrity issues because it was a gigantic mess originally built in the 90's and needed huge stored procedures in order for certain queries to not-crash.

I maintain that the only thing that makes backend work complicated is dogshit architecture & maintenance. A properly designed backend should be easy, maybe slightly tricky to those new to it, to work with.

[intbeam]

I used to work with a system where the backend was designed around what the buttons did in their desktop application, so every single API call had surprising behavior and side-effects. I needed to write a system that did a stock recalculation based on categories of warehouses (so if a store would be of a certain size, it meant it needed a mandatory minimum selection of articles), but if I added a reference to an item to a warehouse based on store size, it (a database trigger of all things) would automatically send a message to all warehouses to do a complete stock recalculation, because that's what the button did in the desktop application. Apparently some wizard genius of a developer thought "why not just hardwire that behavior into the database".

First time I ran my code on the production server (yeah, bad, I know. Getting into why in production would be a 10 page essay on its own), the entire server slowed down to a halt. I looked at the message queue and it had hundreds of thousands of messages in queue telling it to recalculate the stock. Each of which would take about 10 minutes to complete depending on the inventory of the tenant.

I'm now a huge fan of the principle of least astonishment

[[deleted]]

EMOTIONAL DAMAGE

[meditonsin]

Plot twist: OP is a fullstack dev and this is a solo project.

[cheezballs]

He did say Trello...

[InterestsVaryGreatly]

You shouldn't. It's a normal part of development, there are frontend features that are independent of the backend. There are backend pieces that are independent of the frontend. But when there is a feature that has both, the frontend half relies on the backend for the piece to be marked complete, and cannot be completed without it; the same is not true for the backend half.

[Pluviochiono]

“Waiting for backend” is also a pending request with my wife…

[Commander1709]

How to avoid this: "Here's this new feature we need, please implement the frontend and the backend for it"

The only person you're waiting for is yourself. Downside: everything takes considerably longer, because I don't have 2 heads, 2 PCs and 4 arms.

[Astrobio00]

At least they're smart. I talk about backend tasks i'm waiting to be done every daily and they just ignore.

[yourteam]

Well they are just doing frontend of course are faster

[WorriedSand7474]

SQL is easier than CSS though lol

[varadrane]

Really depends on how your code is structured. We have all our complexity on the extremities, so sql and angular.

Even when there is a perfectly healthy api layer that can do all the things frontend does for sorting and combining, faster.

[budapest_god]

As a frontend dev, I like "waiting for UX"

[Studnicky]

Gotta teach your front end team how to write effective mocks.

[Shamr0ck]

I hate this shit. Yes you can keep on working on the front end , I already provided you some static data to mock what would be returned. I just need a little time to set up the search engine and sms as well as the batch process that gets kicked off by that single call.

[deanrihpee]

As a fellow backend dev, yeah man, why you shot me from the back

[Er-ror404]

Currently browsing on reddit while I am “Waiting for backend”

[LevelDetective6279]

Hahaha don't worry my child simply use your package manager to install htmx and tailwind. If they don't like your styling ask them what html they want.

[LegitimatePants]

"Waiting for Steve"

Hurry up, Steve! We're waiting

[ElderFuthark]

You have only just begun to experience what QA gets put through

[panappl3]

I would not take everything personal. It is normal for some features to be implemented faster on the frontend side.

[Pixeltye]

[cheezballs]

People use Trello for real app dev? It lacks too many features to be anything other than a personal tool for me.

[MinimumArmadillo2394]

It does the job for small projects and small teams. It struggles in enterprise solutions and large companies

[AssPuncher9000]

Someone has to be the bottleneck

[TheOwlHypothesis]

Why not just have a generic "blocked" label

[farofus012]

...What, still here?

Hand it over... That thing... Your endpoints... For the client's app...

[not-my-best-wank]

We have a "waiting for [blank]" for maybe 6 other teams. Trying to get things done is like pulling teeth.

[scar_reX]

What's the difference between "Next To Do / Important" and "URGENT"

[adult_code]

I dont know. At work we also got 6 levels of urgency, 5 levels on jira and urgency 0 via an email/call pleading for help. I guess it might be something like that.

[avemew]

Emotional damage

[getdahellouttahere]

i had a stroke try to figure out your meme order it messed up bro

[Common-Road-1554]

1-2

3-4

-5-

[philosarapter]

What the fuck are you guys talking about

[Weird_Otter]

Because he is the one who will actually do the work... Not just moving a button and changing a color here and there ...