7 ms·

>FAANG culture is becoming so slow and ineffective that I'm not surprised they are cutting tens of thousands of employees. In my experience it wasn't the exces

>FAANG culture is becoming so slow and ineffective that I'm not surprised they are cutting tens of thousands of employees. In my experience it wasn't the excess employees (everyone seemed to be busy) but that processes in the org didn't match the size and leadership from the top down couldn't see the problem. So no efforts were made to make teams work better together and align their incentives. A great example was API teams would ship incomplete and untested work as "done" because they were overworked and on an insane timeline. My front-end team tested the APIs for implementation and discovered all the missing parts, and then we had to document all of it and ask the team to fix it. The API team would then push back claiming we were wrong. My devs would have to spend hours on calls with them going over each missing piece and the API devs played dumb every time. I would have to escalate to my manager and he felt pushing back on the other leads would burn political capital he didn't have. This wasn't just one API team, it was seven. Somehow the culture of the org caused them all to follow the same strategy to push their QA to other teams and delay completion. It was so crazy that they would get defensive saying "we have the best developers in the world, that is not possible." A true organizational illness.

Yoric 4y ago
Is that Microsoft?
- criddell 4y ago
  Sounds like ESRI to me.
ecshafer 4y ago
I've never liked having an API team / Front End Team distinction. I don't think it makes good software in most cases, it creates that combative element between the teams due to different priorities that you saw. A team with a product, needs to have the freedom and ability to work at any level of the stack to get that product out, sure that rarely happens 100% and there is coordination between teams, but Vertical slice teams do it better than Horizontal slice teams in my experience.
- mixmastamyk 4y ago
  That's a major reason why graphql was invented, to my knowledge.
- sibit 4y ago
  I agree with this take. I work on a small team (2 backend devs, 2 frontend). The we are always arguing about the API. The frontend devs want the data for their components pre-formatted in 1 API call. The backend team wants to run a SQL query and return the entire record as JSON.
  - keyle 4y ago
    FWIW here: The backend guys are wrong.
    - operatingthetan 4y ago
      The test is to ask ask a full stack developer responsible for both sides what they would do! (And of course, accommodating the data needs of the UI is the answer.)
      - sibit 4y ago
        Exactly. My understanding is the API accommodates the frontend data which accommodates the design which accommodates the users needs.
      - wruza 4y ago
        What a fullstack guy would do is irrelevant here, because if their requirements changed, they’d just redo it. It’s not about who does the job, but about where we end up at when the format becomes obsolete. Likely scenario: backend formats data and moves on / gets busy elsewhere. Frontend changes, so that data is now required in a different format. Frontend decides to just reformat it at their side because of schedules. Now it’s a mess and nobody knows why. The root of the problem is this stupid frontend/backend team division when it’s actually a single program. That’s where the idea of “let’s ask fullstack” comes from. But there’s no good answer this guy could give you, apart from “stop drawing stupid dividers across the whole”.
andruby 4y ago
This is one of the reason I dislike separating API and frontend into different teams. Find people who can do both, or create cross-functional teams that can ship things somewhat independently
jiggawatts 4y ago
Happens everywhere. I just advised a dev team manager not to push a code base to the test team while it was very visibly broken. You don’t need a tester to tell you it’s obviously broken, and any testing they do will just have to be redone anyway once the basic issues are sorted. Nope. “We have to show progress!”
- operatingthetan 4y ago
  It happens much less in organizations where leadership set dates based on following basic scrum estimation and an earnest conversation rather than some manager throwing a dart at the calendar and using that random date as a lever against the teams driving artificial velocity. Other parts of the org like UX and product need to fulfill their obligations as well or it won't work. I've found a lot of teams deep into a death march who never bothered to push product on incomplete requirements.
- gymbeaux 4y ago
  “Leadership” is always getting in their own way with meaningless reporting and honestly it ruins software development for me. I want it to just be a hobby, but to start over from a career (and salary) perspective would be devastating financially. Whenever United Airlines decides to do something about the pilot shortage by paying for flight school (not just 10% of it) I’m down…
deleted 4y ago
[deleted]
Stratoscope 4y ago
A few years ago, a recruiter reached out to me about a role at a company that sold a data analysis product which included geospatial mapping, and they needed an API developer. They had a Python API, but it was complicated and difficult to use and no one liked it. They wanted something simpler and easier for outside developers to work with. I wrote them a cover letter that began: - - - When I design an API, I start with the apps. An API has no value on its own; its value comes from what you can build with it. There may be an existing app that needs a new API feature, but I like to write a self-contained sample app for quick iteration on the API design and to include in the SDK. An API also needs full test coverage, of course, but that comes after this initial step. Instead of test driven development, you might call it app driven development. An SDK developer is also in a customer support role: they should write solid reference documentation and tutorials and sample apps, and interact directly with the users of the SDK. It’s not a job for someone who likes to just sit quietly and code. One of my hobbies has always been to assist other developers in various online forums. Most recently this has been on Stack Overflow where I’ve posted over 600 quality answers. Previously I was known for my advice on the original jQuery mailing list and Windows programming forums. - - - I went on to list some of the APIs I've built. The cover letter must have resonated with them, because they brought me in for interviews the next day, and made an offer the day after that. This looked like my dream job! I love building APIs, working with the developers who use those APIs, and especially anything to do with geospatial data. The team that hired me had been a startup that was acquired by a larger company in another state. Things looked great at first. I was writing sample apps and imagining what APIs would make it easy to develop those apps. And then a team of Architects from the larger company swooped in and decided that they should be the ones to design the new API. They liked to design with UML charts of boxes and arrows, and thought the API should reflect the inner workings of their system. I thought the API should be simple and easy to use for outside Python developers, and I tried to put myself in the shoes of those developers to understand what would make their jobs easier. At one point my manager asked, "can't you just implement what the Architects have specified?" I gave it my best, but by that time I was demoralized and unproductive. The company wanted me to do the exact opposite of what I was good at and what they hired me for. I was fired after three months.
- sibit 4y ago
sumedh 4y ago
> The API team would then push back claiming we were wrong. Wasn't there some design document which had some of the acceptance criteria or the requirements?
gymbeaux 4y ago
This was at a FAANG? What a joke. I can’t believe I used to want to work at Google.

Yoric 4y ago

Is that Microsoft?

criddell 4y ago
Sounds like ESRI to me.

ecshafer 4y ago

I've never liked having an API team / Front End Team distinction. I don't think it makes good software in most cases, it creates that combative element between the teams due to different priorities that you saw. A team with a product, needs to have the freedom and ability to work at any level of the stack to get that product out, sure that rarely happens 100% and there is coordination between teams, but Vertical slice teams do it better than Horizontal slice teams in my experience.

mixmastamyk 4y ago
That's a major reason why graphql was invented, to my knowledge.
sibit 4y ago
I agree with this take. I work on a small team (2 backend devs, 2 frontend). The we are always arguing about the API. The frontend devs want the data for their components pre-formatted in 1 API call. The backend team wants to run a SQL query and return the entire record as JSON.
- keyle 4y ago
  FWIW here: The backend guys are wrong.
  - operatingthetan 4y ago
    The test is to ask ask a full stack developer responsible for both sides what they would do! (And of course, accommodating the data needs of the UI is the answer.)
    - sibit 4y ago
      Exactly. My understanding is the API accommodates the frontend data which accommodates the design which accommodates the users needs.
    - wruza 4y ago
      What a fullstack guy would do is irrelevant here, because if their requirements changed, they’d just redo it. It’s not about who does the job, but about where we end up at when the format becomes obsolete. Likely scenario: backend formats data and moves on / gets busy elsewhere. Frontend changes, so that data is now required in a different format. Frontend decides to just reformat it at their side because of schedules. Now it’s a mess and nobody knows why. The root of the problem is this stupid frontend/backend team division when it’s actually a single program. That’s where the idea of “let’s ask fullstack” comes from. But there’s no good answer this guy could give you, apart from “stop drawing stupid dividers across the whole”.

andruby 4y ago

This is one of the reason I dislike separating API and frontend into different teams. Find people who can do both, or create cross-functional teams that can ship things somewhat independently

jiggawatts 4y ago

Happens everywhere. I just advised a dev team manager not to push a code base to the test team while it was very visibly broken. You don’t need a tester to tell you it’s obviously broken, and any testing they do will just have to be redone anyway once the basic issues are sorted. Nope. “We have to show progress!”

operatingthetan 4y ago
It happens much less in organizations where leadership set dates based on following basic scrum estimation and an earnest conversation rather than some manager throwing a dart at the calendar and using that random date as a lever against the teams driving artificial velocity. Other parts of the org like UX and product need to fulfill their obligations as well or it won't work. I've found a lot of teams deep into a death march who never bothered to push product on incomplete requirements.
gymbeaux 4y ago
“Leadership” is always getting in their own way with meaningless reporting and honestly it ruins software development for me. I want it to just be a hobby, but to start over from a career (and salary) perspective would be devastating financially. Whenever United Airlines decides to do something about the pilot shortage by paying for flight school (not just 10% of it) I’m down…

deleted 4y ago

[deleted]

Stratoscope 4y ago

A few years ago, a recruiter reached out to me about a role at a company that sold a data analysis product which included geospatial mapping, and they needed an API developer. They had a Python API, but it was complicated and difficult to use and no one liked it. They wanted something simpler and easier for outside developers to work with. I wrote them a cover letter that began: - - - When I design an API, I start with the apps. An API has no value on its own; its value comes from what you can build with it. There may be an existing app that needs a new API feature, but I like to write a self-contained sample app for quick iteration on the API design and to include in the SDK. An API also needs full test coverage, of course, but that comes after this initial step. Instead of test driven development, you might call it app driven development. An SDK developer is also in a customer support role: they should write solid reference documentation and tutorials and sample apps, and interact directly with the users of the SDK. It’s not a job for someone who likes to just sit quietly and code. One of my hobbies has always been to assist other developers in various online forums. Most recently this has been on Stack Overflow where I’ve posted over 600 quality answers. Previously I was known for my advice on the original jQuery mailing list and Windows programming forums. - - - I went on to list some of the APIs I've built. The cover letter must have resonated with them, because they brought me in for interviews the next day, and made an offer the day after that. This looked like my dream job! I love building APIs, working with the developers who use those APIs, and especially anything to do with geospatial data. The team that hired me had been a startup that was acquired by a larger company in another state. Things looked great at first. I was writing sample apps and imagining what APIs would make it easy to develop those apps. And then a team of Architects from the larger company swooped in and decided that they should be the ones to design the new API. They liked to design with UML charts of boxes and arrows, and thought the API should reflect the inner workings of their system. I thought the API should be simple and easy to use for outside Python developers, and I tried to put myself in the shoes of those developers to understand what would make their jobs easier. At one point my manager asked, "can't you just implement what the Architects have specified?" I gave it my best, but by that time I was demoralized and unproductive. The company wanted me to do the exact opposite of what I was good at and what they hired me for. I was fired after three months.

sibit 4y ago

sumedh 4y ago

> The API team would then push back claiming we were wrong. Wasn't there some design document which had some of the acceptance criteria or the requirements?

gymbeaux 4y ago

This was at a FAANG? What a joke. I can’t believe I used to want to work at Google.