You know what really jizzes in my cereal?

Backend devs who do their work, as if it's only important that THEY meet the fucking deadline, while you as a frontend dev sit there like a fucking idiot, waiting for shit to happen, so you can finally do your job.

I get it that it's not always their fault, but would those who have the balls to ask me why I didn't hit the fucking deadline, despite knowing it's because they were too busy nose picking and watching granny porn, go suck an extra grimy one through their favourite glory hole?

At least the other backend developer I'm working towards another fast approaching deadline with knows their profession and has their fucking priorities straight.

To the first one: thank you, fucking cunt, and I hope you catch Hepatitis.

  • 14
    As a backend dev I have always thought about this issue... But never actually done anything about it ... Sorry :'(
  • 17
    Why do you need the backend ready to work on the FrontEnd? I'm a full stack developer, I know both sides, I've been where you're talking about but looking back I could just mock the backend as it should be before it is ready and put up my FrontEnd ready before backend is even started.
    Unless your backend developer decides the whole API and you have to wait for him to know what to mock. But even then you can decide prior to his work how you'll both structure it.

    It's all about teamwork
  • 5
    As a back-end developer I am sorry for this. But we can't do anything about shitty people can we.
  • 18
    @jowshu That won't work, if the project is sufficiently complicated and you don't even know the fucking data structure you'll have to work with upfront.

    And yeah, it's all about team work, and that's exactly what I'm ranting about here. There is no fucking teamwork, it's just everybody doing their own shit, because fuck others.
  • 14
    Jizz in yo cereal... 🤔
  • 10
    "it's because they were too busy nose picking and watching granny porn"

  • 7
    Yup, proper description of what goes in and what comes out is the way to go.
    Once you have the interfaces set up, it doesn't matter if back or front fucks up, you did your job and once the other people finish, it should all fit together nicely...if someone didn't fuck up all together and changed the scope/definition of work, that is.. which usually is the case.. but anyhow, if you have proper description/vision of what needs to be done, front & back can blissfully ignore eachother..
    And yes, idiots who do not understand that and don't know what they want can go .........
  • 4

    "if you have proper description/vision of what needs to be done, front & back can blissfully ignore eachother.."

    i wish boardroom meeting managers and all have this hardcoded into their head, like the Serial numbers hardcoded into their workstations.
  • 5
    NGL, shit like this is why I stress the importance of interfaces/whatever the equivalent is in your language. Something to enforce a contract.
  • 8
    @projektaquarius Oh, that would be fucking gorgeous, but whenever I try to push my coworkers in this direction they stare at me as if they'd just caught me mouthfucking their moms.

  • 10
    @AlexDeLarge so do you know how one would stare if you'll mouthfuck their mom? 🤔
  • 3
    @AlexDeLarge Do you have a project manager of some sorts? Usually, if there are tasks which depend on each other, they receive different dead lines. So in your case, the back end dev should have an earlier dead line for his task which allows you to hit your own.
  • 3
    @ArchLinux haha yes (:
    Garbage in garbage out.. thank god/linux/windows/chair/duck... that my boss & company owner knows that.
  • 8
    Hmm, jizzes in my cereal...
    Is this AlexDeLarge?
    Yup, it's AlexDeLarge
  • 6

    Task granularity is a must for me. Flow for me is:

    Pre-task database migrations (create table, etc)
    Review, merge and deploy DB prepmigration

    Designing & setting up class "skeleton"
    Writing TDD tests
    Writing methods
    Write post-migrations
    Document backend API
    DB & API Code Review
    Deploy API.

    Get wireframes/designs
    Plan Vue components
    Write tests
    Setup HTML/components
    Ask UI to style components
    JS code Review
    UX/spec Review
    Docker deploy for stakeholder review

    That's basically three separate deliverables, each with a deadline which gets decided upon only when the previous one is finished — although some stuff still happens in parallel.

    Each point above gets assigned separately to a person, and we track which points form the largest bottlenecks, which are then assigned more time in the future (per person & per department weighted scrum points)
  • 5
    @bittersweet Can I please work where you work?

    Seriously, how hard is is to abide to a few simple rules and agree on a general procedure?
  • 0
    Sounds like you need two separate deadlines?
  • 9
    @AlexDeLarge Lots of venture capital helps. "We need a scrum master for every team" — "OK, hired". "We need a UX tester" — "OK, hired", etc.

    I'm thinking of hiring someone to stand next to my desk, polish my monitors, and feed me chocolate. One for the office, one for at home... but my girlfriend called me "a decadent pig" when I proposed it 😣
  • 5
    @bittersweet You are a decadent pig, but a decadent pig with pretty good ideas.
  • 3
    @irene is asking all the right questions here.

    Also. Be annoying @AlexDeLarge, poke people. They will hate you but is going to work.

    Example: @paragonHex you are poked! :P
  • 0
    That's why you gotta go full stack 😉
  • 1
    @unmarked I am full stack. That's you gotta read people's rants before you start giving useless advice.
  • 0
  • 1
    @irene I really do appreciate your contribution to this rant 😂
  • 1
    I ++'ed too early
  • 1
    I knew it was your rant from the first line.
  • 1
    @cuervo So? Unplus it. Who gives a fuck?
  • 1
    You could also ask the backend dev to first mock up their API, along with its documentation. Once the mock has been finalized, you can start developing on the front on a new branch... Meanwhile the backend devs can implement the actual API, also on a new branch. If the mock API was well thought out, there should be no issues when merging
  • 2
    This is just bad management. If we have a deadline that is say 7th June, I will plan in that back end work must be complete by say 20th may (for example).

    However given that I’m now working in a pretty agile environment, we don’t hear about deadlines much.
  • 1
    @AlexDeLarge I couldn't get past the first sentence before I could ++ lol

    I'll let you keep it 😁
  • 1
    Back end are willy wonkas and front end are umpa lumpas
  • 0
  • 2
    In my previous company, the API team would simply verbally state the fields and tell us that there wouldn't be many changes. Before deadline, they would drastically change the format because they didn't think of all use cases, then claim that they met deadlines and still make changes after that.
    I left the company 😇
Add Comment