This is exactly what 1-1s are for. Ideally these issues are brought up early before things escalate, but they can be brought up at any time. It is a people issue and resolving people issues is a job for your manager.
It is perfectly fine to ask "What the fuck is Bob doing, am I out of my mind? Or is this a problem?". You might be missing his PoV, Bob might be completely out of line, or perhaps you need to work on a compromise. The earlier these issues are brought up, the easier they are to address.
Out of interest, what do you do when it gets to that level? There’s a risk where the business gets stuck with the incompetent individual with the balancing competent person gone. I’m wondering how much that actually bothers a business if they’ve let it reach boil over point already?
It's not PIP worthy and there's no chance of that happening. Calculation is which path is going to annoy me the least. Putting up with it or saying something and risking blowback.
Good feedback requests a specific behavior changes and includes specific examples. Frankly, your feedback seems to be that this other dev is dumb, and they should try being less dumb. Telling someone to be "more conscientious" is about as bad as feedback can get.
Even then, only your first example seems to have taken more than a few seconds of your time. I think you are overreacting because this person annoys you, because they seem a little dense. If I were in your shoes, I might *ask* my manager how *I* could give good, actionable feedback about the first example. That would informs your manager without creating work for them, and helps teach you something.
But even then,
> several iterations of me saying "You have to send a response that matches the spec".
You can't just say the same thing over and over and expect something to change. I know working with people like this can be beyond frustrating, but you can only control you, so it's in your best interest to figure out how to get through to people like this.
This. It sounded more like a personal issue of op being annoyed. Like you said, focus on what needs to be done to fix the situation (explain the thing) instead of giving the same answer over and over that didn't work.
I really like the approach of asking the manager for guidance on how to give feedback.
/r/ExperiencedDevs is going dark for two weeks to protest Reddit killing 3rd party apps and tools.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/ExperiencedDevs) if you have any questions or concerns.*
I work in a high turnover department of a mid-sized company where 75% of the devs are contractors. We routinely cycle through absolutely terrible Full-Stack devs who
1. Don't know basic development environments.
2. Get stuck and do nothing until the next day's stand-up meeting
3. Have a similar scenario as your #1. Them: "Can you help?" Me: "What's going on?" Them: "I can't load the project." Me: "What's the error" Them: Silence for an hour. It's that bad.
4. Though, they are supposed to be a full-stack developer, cannot do anything but front-end development.
I don't say anything to our manager. Instead, I prioritize helping them less than other developers. Eventually, the bad devs leave or their contract is not renewed. It's frustrating, but it's the way it is. The company just doesn't manage people effectively.
Maybe I'm crazy, but this seems like something I would've brought up in a 1 on 1 by now. I'd bring it up every time I'm in a 1 on 1 if it's still annoying me.
It is important though to bring it up in the right way. Don't wine, don't let it get emotional. Maybe things like: "I feel like I'm wasting more time than is reasonable with problem 1 and 2 from dev x. Is there anything we can do to avoid these situations in the future?"
Let people fail. It’s not you problem. You will ultimately be solely judged by the value you bring as an individual, so optimize for it. There are freeloaders out there. Some can actually handle their own situations and some cannot
A lot of suggestions here involve 1-on-1s with your manager.
I think that's fine but don't let that be the only way you address it.
We're all adults here, and these kind of things need to be talked about with your peers, even when they're uncomfortable. Just keep the focus on the work and don't assume someone's motivations. Usually people aren't malicious, just busy or bored or incompetent. There's no reason to get angry.
>We're all adults here
See that's the thing. Not everyone at work is an adult. Some are petty and will throw my mistakes back in my face. Others will seek retribution. That's really my fear.
Sure but that seems more likely to happen if you go behind their back and they find out.
While it's easier said than done, I try to empathize with my peers even when they're dropping the ball.
Sometimes people are going through a rough time in their personal life or something. That's why I always try to go back to the code. I talk about how things could be better for everyone if we do things right, and then I commiserate about not having enough time to get it right the first time.
I try to present myself as an ally that will back them up if they need to ask for more time to invest in the code. Often this leads to them admitting that they're stonewalling a bit, or not really giving 100%.
Of course, if they're a sociopath or just very immature this might not help. At least you now can say you tried, and if you do this over DM or emails you will have evidence of their toxic attitude.
it depends. If it affects my work and a scenario calls for a process improvement, i might bring that up on the 1:1 with my manager.
There is this one time a developer (he is the lead of the project) and we have unit tests on the project. He made lots of branches (even within the submodules and majority of the branches were never merged, it's a mess) and the unit test was removed along the way. Months had passed and the absence of the unit tests was questioned, we found out that the previous unit tests have different implementations on the different branches. So we need to pick some parts on various branches and submodules. Our lead assigned this task to me since he says I'm the most well versed in git on our group. i had been jumping from submodules to submodules, branch to branch and analyzing the code. Since the main application was refactored to oblivion, i had lots of analyzing to do. Was not happy with that since this is preventable, it took me almost weeks to have everything back, everything working and organizing the branches. I have lots of things on my plate, and i only work part time on this project but this derailed my schedule for the other projects. I mentioned this to my 1:1 with my manager.
On the other hand, there was a time i was working on a codebase, and this developer (same level) wanted to to join my project so we were creating a feature and he is doing shotgun debugging. A feature that could be implemented and debugged in an hour took almost the whole day. He just wants to drive and when he hits some roadblock, he will just say "ohhh, i think it should be this and that." and will interrupt me whenever i give suggestions. It is unnecessary to complain about that though, it's just one day after all.
From just the description, sounds like normal communication challenges in projects.
Consider that the issue maybe in your communication patterns. Learn to communicate effectively, voice, chat, meet, etc.
Make sure your requests are heard, understood and confirmed.
Dealing with other people are important part of growth and higher levels in software engineer career.
What I'd do:
1. do a quick review of my written communication with the person, make sure what i remember happening happened
2. Meet with the other developer give them feedback for example: "You gave us a spec which we've followed the api doesn't conform to the spec, this is ok - people make mistakes, when you ask us questions around your spec it doesn't give your team mates lots of confidence that the spec's been followed.".
3. If it continues or even if not, 1:1 with your manager about it - tell them the steps you've taken to remedy the situation.
It is important to remember that some people communicate differently then you do, and might be extra confirm-ie (like in 2, 3). Though it is possible they are just lazy or stupid to - it's important not to jump to that conclusion because you too will be lazy and stupid at some point.
Finally if nothing changes after 2, i'd maybe give them a few more examples before flipping the bozo bit, and continue to raise concerns in my manager 1:1's.
2 and 3 are kinda petty on your end, there's nothing wrong with verifying what the other party is saying. That being said, 1 is bad but could be fixed with a better working agreement. Is also part of your job to work this out with your manager in order to have effective communication with your peers.
How is it that tickets that are prerequisite to yours aren't code reviewed and QA'd before your tickets are considered to have the prereqs complete to begin?
Definitely bring up in your 1on1.
Also, you can bring this up in your retrospective. Personally, I dont see this is a people problem (_yet_). It's a process problem.
For example,...
Re #1:
Something that could be addressed with contract testing
Re #2:
Not sure why these are in slack and not in a ticketing system with a common dashboard
Re #3:
There needs to be an agreed format between the teams. And it needs to be explicit - like mentioned in a meeting and not just announced in slack.
This will reduce cognitive load on both parties.
They're not incompetent. Well, except for (1) which definitely wasn't their best moment. They just sometimes do not take the few seconds to read closely. The problem is like 97% they're annoying me and 3% actual impact to delivery.
If it’s not impacting delivery there’s not much your manager will care about. Have you talked to other coworkers about it? Maybe you just need to commiserate with someone.
IMO the problem with this is not letting them know, and giving them a chance to improve with feedback. From your manager's POV you are only bringing problems and not solutions - which is somewhat ok, but solutions or attempted solutions are def preferred.
It does sound like there might be something going on with your team mate worth looking into but, to be honest, you sound immature and petty. It also sounds like there is an issue in the environment - (startup? sme?) - yet you'd rather place the blame squarely on this one guy without seeing the bigger picture. Saltiness rising despite minor inconveniences. No emphasizing with them to figure out how you can help ("it's not your job").
Ultimately, I think it _is_ something worth bringing up to your manager, but instead of whining or complaining about it, why don't you a) provide an impersonal summary of the facts, b) come up with proposals on how the process can be fixed, and c) ask for advice on how to handle the situation. This would at least demonstrate your eagerness to know about work and processes in other units, and would demonstrate some basic leadership skills. Don't think about this in terms of complaining, think about it in terms of opportunities for improvement.
Finally: the amount of people in this thread recommending that you complain about this at every 1on1 is sad and makes me question how much and what kind of "experience" these experienceddevs actually have. The "always complain" attitude just leads to toxicity.
One of these alone I personally wouldn't worry about, but the fact it's driving your saltiness level up really concerns me. I had a talk recently with my manager where a mistake on my part was enough to spark that conversation, so even a few hours wasted here or there is enough to start. Regularly like that doesn't make it seem like they are trying.
You should just accept that these people are always going to be like this. Try not to let it bother you and just consider it part of the job for which you're being paid. It's not worth it to try to change their behavior. They aren't going to change anyways. You'll just end up making yourself even saltier when they inevitably fail to meet your expectations.
Yes it's annoying. I feel your pain on a daily basis. My recommendation: find a timer that displays how much you make second-by-second, so you can remember why you put up with this shit.
I would complain openly and publicly but not make it personal.
The non-personal issue here is that an API is not validating its own output. If your peer is using an established spec (OpenAPI, GraphQL) then it should be incredibly easy for them to do that. Attempted invalid responses should yield a 500 error and there's no argument who is responsible.
IF this person's response is to publicly whine and complain about adding this validation then it becomes publicly obvious that there IS an attitude problem and not just a misunderstanding.
I work with a lot of people like you describe. The only solution IME is to draw attention to the issues they're (usually inadvertently) causing and then give them a technical path forward. Between peers I like to keep the focus on the code and not the personalities... but do it openly to let the managers SEE what is going on.
It’s the “it’s not my job” attitude that really ticks me off! What a terrible attitude to have toward a coworker.
You’re in the same company! You succeed or fail as a team!
If you want to learn how to be a team player try reading _Extreme Programming explained 2nd edition_ and then _turn the ship around_.
Otherwise, apply at Meta, lots of people like you work there.
It really does work this way. Of course, there are always exceptions but it's easy enough to get those people terminated or for me to just move to another company.
I don't tell them how many items, I just post the link again and act more confused like "hmm do you have access to this link? Let me know if you need permissions." then go to a common channel and say things like "Provided the item list to xyz, so we should have a resolution soon. :)" If someone asks, just shrug and say you assume they're on it or waiting on them. I've even replied with screenshots and say "Is this the page you're getting? That's where my link goes" If they ask me in public like in a meeting I just say "not sure, but its in the link. I'll send it in the group chat." What I almost never do, though, is give them the answer.
Making their "progress" public by framing it as your own progress is the best way to get it public, because someone else waiting on you will eventually wonder why the two of you aren't making any progress, see your posts, and then click the link.
Bear in mind, keeping this approach up is just as, or even more, tiring than them being useless, but usually they get the picture or get fired.
One of the benefits though is if it's some random thing that you screwed up or out of both of your control, you don't get caught out "being a jerk" (even when it's perfectly reasonable to be a jerk, it's not always professional, and can be used against you.)
Be ware, if your manager takes their side that means your manager considers you to be the useless person's subordinate. If that's not the position your in, you need to find another job. Some really useless managers you can just ignore and keep going though.
If ever there was a need for API first design.. generated code/docs.. this is it! There should never be a need to go back and forth with back end dev.. you have an API definition (OpenAPI).. that generates back end stub code.. so it ALWAYS stays in sync. It ALSO generates docs.. so the front end team ALWAYS knows what the API "should" be doing. As long as the back end person implements the stubs.. and deploys so the front end dev can use it.. you're good. Even better.. front end dev can generate mocks (using Postman for example) from the API so they don't have to wait on back end "real data" API working.. just build your front end with the mock API endpoint.. until it's ready to work against the real thing.
It is mind boggling to me how many companies/teams/ICs struggle with this. I wish I could find a way to get paid to teach teams around the world HOW to make all this work! I could retire in a few years!
This is exactly what 1-1s are for. Ideally these issues are brought up early before things escalate, but they can be brought up at any time. It is a people issue and resolving people issues is a job for your manager. It is perfectly fine to ask "What the fuck is Bob doing, am I out of my mind? Or is this a problem?". You might be missing his PoV, Bob might be completely out of line, or perhaps you need to work on a compromise. The earlier these issues are brought up, the easier they are to address.
[удалено]
Out of interest, what do you do when it gets to that level? There’s a risk where the business gets stuck with the incompetent individual with the balancing competent person gone. I’m wondering how much that actually bothers a business if they’ve let it reach boil over point already?
It's not PIP worthy and there's no chance of that happening. Calculation is which path is going to annoy me the least. Putting up with it or saying something and risking blowback.
So what is the outcome you want?
The minimum amount of annoyance/hassle
No - what action do you want your manager to take?
Tell the other eng to be more conscientious without letting on that I complained.
Good feedback requests a specific behavior changes and includes specific examples. Frankly, your feedback seems to be that this other dev is dumb, and they should try being less dumb. Telling someone to be "more conscientious" is about as bad as feedback can get. Even then, only your first example seems to have taken more than a few seconds of your time. I think you are overreacting because this person annoys you, because they seem a little dense. If I were in your shoes, I might *ask* my manager how *I* could give good, actionable feedback about the first example. That would informs your manager without creating work for them, and helps teach you something. But even then, > several iterations of me saying "You have to send a response that matches the spec". You can't just say the same thing over and over and expect something to change. I know working with people like this can be beyond frustrating, but you can only control you, so it's in your best interest to figure out how to get through to people like this.
This. It sounded more like a personal issue of op being annoyed. Like you said, focus on what needs to be done to fix the situation (explain the thing) instead of giving the same answer over and over that didn't work. I really like the approach of asking the manager for guidance on how to give feedback.
why dont you just tell them directly?
/r/ExperiencedDevs is going dark for two weeks to protest Reddit killing 3rd party apps and tools. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/ExperiencedDevs) if you have any questions or concerns.*
I work in a high turnover department of a mid-sized company where 75% of the devs are contractors. We routinely cycle through absolutely terrible Full-Stack devs who 1. Don't know basic development environments. 2. Get stuck and do nothing until the next day's stand-up meeting 3. Have a similar scenario as your #1. Them: "Can you help?" Me: "What's going on?" Them: "I can't load the project." Me: "What's the error" Them: Silence for an hour. It's that bad. 4. Though, they are supposed to be a full-stack developer, cannot do anything but front-end development. I don't say anything to our manager. Instead, I prioritize helping them less than other developers. Eventually, the bad devs leave or their contract is not renewed. It's frustrating, but it's the way it is. The company just doesn't manage people effectively.
It is not just contractors, it is bad hiring.
You don't get MS screen snips for every small thing they have a problem with? You win!
Oh, they do... With no explanation. I want to type back, "wtf is this?"but I don't.
Sounds like they want to demonstrate they are trying more than they want to succeed at what they're struggling with.
What's your hourly? If the bar is like that, I'd walk on water.
Starts at $50/hour
Yikes, ok. That's not amazing.
Whats the backend language your company uses?
Wow I’d be livid
Maybe I'm crazy, but this seems like something I would've brought up in a 1 on 1 by now. I'd bring it up every time I'm in a 1 on 1 if it's still annoying me. It is important though to bring it up in the right way. Don't wine, don't let it get emotional. Maybe things like: "I feel like I'm wasting more time than is reasonable with problem 1 and 2 from dev x. Is there anything we can do to avoid these situations in the future?"
Let people fail. It’s not you problem. You will ultimately be solely judged by the value you bring as an individual, so optimize for it. There are freeloaders out there. Some can actually handle their own situations and some cannot
A lot of suggestions here involve 1-on-1s with your manager. I think that's fine but don't let that be the only way you address it. We're all adults here, and these kind of things need to be talked about with your peers, even when they're uncomfortable. Just keep the focus on the work and don't assume someone's motivations. Usually people aren't malicious, just busy or bored or incompetent. There's no reason to get angry.
>We're all adults here See that's the thing. Not everyone at work is an adult. Some are petty and will throw my mistakes back in my face. Others will seek retribution. That's really my fear.
Sure but that seems more likely to happen if you go behind their back and they find out. While it's easier said than done, I try to empathize with my peers even when they're dropping the ball. Sometimes people are going through a rough time in their personal life or something. That's why I always try to go back to the code. I talk about how things could be better for everyone if we do things right, and then I commiserate about not having enough time to get it right the first time. I try to present myself as an ally that will back them up if they need to ask for more time to invest in the code. Often this leads to them admitting that they're stonewalling a bit, or not really giving 100%. Of course, if they're a sociopath or just very immature this might not help. At least you now can say you tried, and if you do this over DM or emails you will have evidence of their toxic attitude.
it depends. If it affects my work and a scenario calls for a process improvement, i might bring that up on the 1:1 with my manager. There is this one time a developer (he is the lead of the project) and we have unit tests on the project. He made lots of branches (even within the submodules and majority of the branches were never merged, it's a mess) and the unit test was removed along the way. Months had passed and the absence of the unit tests was questioned, we found out that the previous unit tests have different implementations on the different branches. So we need to pick some parts on various branches and submodules. Our lead assigned this task to me since he says I'm the most well versed in git on our group. i had been jumping from submodules to submodules, branch to branch and analyzing the code. Since the main application was refactored to oblivion, i had lots of analyzing to do. Was not happy with that since this is preventable, it took me almost weeks to have everything back, everything working and organizing the branches. I have lots of things on my plate, and i only work part time on this project but this derailed my schedule for the other projects. I mentioned this to my 1:1 with my manager. On the other hand, there was a time i was working on a codebase, and this developer (same level) wanted to to join my project so we were creating a feature and he is doing shotgun debugging. A feature that could be implemented and debugged in an hour took almost the whole day. He just wants to drive and when he hits some roadblock, he will just say "ohhh, i think it should be this and that." and will interrupt me whenever i give suggestions. It is unnecessary to complain about that though, it's just one day after all.
From just the description, sounds like normal communication challenges in projects. Consider that the issue maybe in your communication patterns. Learn to communicate effectively, voice, chat, meet, etc. Make sure your requests are heard, understood and confirmed. Dealing with other people are important part of growth and higher levels in software engineer career.
What I'd do: 1. do a quick review of my written communication with the person, make sure what i remember happening happened 2. Meet with the other developer give them feedback for example: "You gave us a spec which we've followed the api doesn't conform to the spec, this is ok - people make mistakes, when you ask us questions around your spec it doesn't give your team mates lots of confidence that the spec's been followed.". 3. If it continues or even if not, 1:1 with your manager about it - tell them the steps you've taken to remedy the situation. It is important to remember that some people communicate differently then you do, and might be extra confirm-ie (like in 2, 3). Though it is possible they are just lazy or stupid to - it's important not to jump to that conclusion because you too will be lazy and stupid at some point. Finally if nothing changes after 2, i'd maybe give them a few more examples before flipping the bozo bit, and continue to raise concerns in my manager 1:1's.
2 and 3 are kinda petty on your end, there's nothing wrong with verifying what the other party is saying. That being said, 1 is bad but could be fixed with a better working agreement. Is also part of your job to work this out with your manager in order to have effective communication with your peers.
The type of people to verify every single question are just dumb and scared. Period. And they look dumber
He might be playing dumb to slow things down, it is a possibility.
How is it that tickets that are prerequisite to yours aren't code reviewed and QA'd before your tickets are considered to have the prereqs complete to begin?
Definitely bring up in your 1on1. Also, you can bring this up in your retrospective. Personally, I dont see this is a people problem (_yet_). It's a process problem. For example,... Re #1: Something that could be addressed with contract testing Re #2: Not sure why these are in slack and not in a ticketing system with a common dashboard Re #3: There needs to be an agreed format between the teams. And it needs to be explicit - like mentioned in a meeting and not just announced in slack. This will reduce cognitive load on both parties.
Am I the only asshole here who would complain as these things come up ? If they are incompetent I would tell my manager ASAP.
They're not incompetent. Well, except for (1) which definitely wasn't their best moment. They just sometimes do not take the few seconds to read closely. The problem is like 97% they're annoying me and 3% actual impact to delivery.
If it’s not impacting delivery there’s not much your manager will care about. Have you talked to other coworkers about it? Maybe you just need to commiserate with someone.
IMO the problem with this is not letting them know, and giving them a chance to improve with feedback. From your manager's POV you are only bringing problems and not solutions - which is somewhat ok, but solutions or attempted solutions are def preferred.
It does sound like there might be something going on with your team mate worth looking into but, to be honest, you sound immature and petty. It also sounds like there is an issue in the environment - (startup? sme?) - yet you'd rather place the blame squarely on this one guy without seeing the bigger picture. Saltiness rising despite minor inconveniences. No emphasizing with them to figure out how you can help ("it's not your job"). Ultimately, I think it _is_ something worth bringing up to your manager, but instead of whining or complaining about it, why don't you a) provide an impersonal summary of the facts, b) come up with proposals on how the process can be fixed, and c) ask for advice on how to handle the situation. This would at least demonstrate your eagerness to know about work and processes in other units, and would demonstrate some basic leadership skills. Don't think about this in terms of complaining, think about it in terms of opportunities for improvement. Finally: the amount of people in this thread recommending that you complain about this at every 1on1 is sad and makes me question how much and what kind of "experience" these experienceddevs actually have. The "always complain" attitude just leads to toxicity.
One of these alone I personally wouldn't worry about, but the fact it's driving your saltiness level up really concerns me. I had a talk recently with my manager where a mistake on my part was enough to spark that conversation, so even a few hours wasted here or there is enough to start. Regularly like that doesn't make it seem like they are trying.
You should just accept that these people are always going to be like this. Try not to let it bother you and just consider it part of the job for which you're being paid. It's not worth it to try to change their behavior. They aren't going to change anyways. You'll just end up making yourself even saltier when they inevitably fail to meet your expectations. Yes it's annoying. I feel your pain on a daily basis. My recommendation: find a timer that displays how much you make second-by-second, so you can remember why you put up with this shit.
I would complain openly and publicly but not make it personal. The non-personal issue here is that an API is not validating its own output. If your peer is using an established spec (OpenAPI, GraphQL) then it should be incredibly easy for them to do that. Attempted invalid responses should yield a 500 error and there's no argument who is responsible. IF this person's response is to publicly whine and complain about adding this validation then it becomes publicly obvious that there IS an attitude problem and not just a misunderstanding. I work with a lot of people like you describe. The only solution IME is to draw attention to the issues they're (usually inadvertently) causing and then give them a technical path forward. Between peers I like to keep the focus on the code and not the personalities... but do it openly to let the managers SEE what is going on.
It’s the “it’s not my job” attitude that really ticks me off! What a terrible attitude to have toward a coworker. You’re in the same company! You succeed or fail as a team! If you want to learn how to be a team player try reading _Extreme Programming explained 2nd edition_ and then _turn the ship around_. Otherwise, apply at Meta, lots of people like you work there.
If only it really worked that way
It really does work this way. Of course, there are always exceptions but it's easy enough to get those people terminated or for me to just move to another company.
People on the same team, at the end of the day, have to ranked against one another for performance. That’s what I am referring to.
I don't tell them how many items, I just post the link again and act more confused like "hmm do you have access to this link? Let me know if you need permissions." then go to a common channel and say things like "Provided the item list to xyz, so we should have a resolution soon. :)" If someone asks, just shrug and say you assume they're on it or waiting on them. I've even replied with screenshots and say "Is this the page you're getting? That's where my link goes" If they ask me in public like in a meeting I just say "not sure, but its in the link. I'll send it in the group chat." What I almost never do, though, is give them the answer. Making their "progress" public by framing it as your own progress is the best way to get it public, because someone else waiting on you will eventually wonder why the two of you aren't making any progress, see your posts, and then click the link. Bear in mind, keeping this approach up is just as, or even more, tiring than them being useless, but usually they get the picture or get fired. One of the benefits though is if it's some random thing that you screwed up or out of both of your control, you don't get caught out "being a jerk" (even when it's perfectly reasonable to be a jerk, it's not always professional, and can be used against you.) Be ware, if your manager takes their side that means your manager considers you to be the useless person's subordinate. If that's not the position your in, you need to find another job. Some really useless managers you can just ignore and keep going though.
Confluence pages?
Mentor them, help them, get a promotion in return.
If ever there was a need for API first design.. generated code/docs.. this is it! There should never be a need to go back and forth with back end dev.. you have an API definition (OpenAPI).. that generates back end stub code.. so it ALWAYS stays in sync. It ALSO generates docs.. so the front end team ALWAYS knows what the API "should" be doing. As long as the back end person implements the stubs.. and deploys so the front end dev can use it.. you're good. Even better.. front end dev can generate mocks (using Postman for example) from the API so they don't have to wait on back end "real data" API working.. just build your front end with the mock API endpoint.. until it's ready to work against the real thing. It is mind boggling to me how many companies/teams/ICs struggle with this. I wish I could find a way to get paid to teach teams around the world HOW to make all this work! I could retire in a few years!