>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."
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.
In combative environments that's solved with a BFF maintained by the frontend team, and the backend gets away with exposing broad and generic API the frontend team reprocesses on their layer.
In sensible work environments, that's solved by aligning incentives at project level. If your frontend team crucially needs something done, but the backend can't give a shit, the problems run deeper than area of responsibility IMHO. Either what the frontend works on doesn't matter, or the backend team wants to sink the ship, or there's way too many fires to put out and the ship is already sinking.
Having mega teams or filling them with jack-of-all-trades types also has critical downsides.
backend for frontend. It's usually another layer between the frontend and the "real backend". So frontend calls BFF (usually a node server), and BFF calls the backend.
I've never liked having an API team / Front End Team distinction.
If there is only one front end that talks to the back end, then yes I agree. If there are 20 different front ends from 20 different teams, some of them external, that are expected to talk to the same API, then it makes a lot more sense.
In the case of 20 frontends to 1 backend, it might make more sense to organize it as 19 frontends to 1 front/backend.
In other words, have a team with front and back-end devs working together, with a frontend acting as a sensible default interaction to an API. This can be something as simple as a widget or component.
This front end is expected to have a full suite of tests running through the API (or an api test device -- this test device can also be used to better communicate the requirements to backend devs), and be well documented in how and why it's doing something.
That acts as an example for any other frontends. When they have questions or issues with the api, it also provides an immediate source of truth to show how to properly do something. And it provides confidence that the API is behaving in the expected fashion for the user experience being provided for.
The most successful APIs I've worked with have been done this way.
In one project we were rebuilding an old outdated UI. We started with being very strict about literally only implementing what was needed for frontend, for example not even a GET /widgets/{id} until there was a UI that needed it. We also explicitly built new models for this, separate from our database models, so it wasn't just "return everything in the table": if the UI only displayed half the fields, that's what was returned. A big benefit of this mindset was when we needed a list of things from joining multiple tables, there was no thought of pushing this to the front-end; we just made a viewmodel, did the work server-side and returned it.
Also, pretty early on we implemented Swagger (OpenAPI) and built in docs to our code. This helped establish it as a part of dev and the coding style that any new devs quickly bought into, as opposed to an afterthought everyone sees as a chore.
After we had a a dozen or so APIs done, we started opening it to customers. We'd add new things they'd request (but our UI didn't need), but strictly kept the use-case-first mindset, as well as continuing the UI port (page-by-page, effectively). Even a few years later, the feedback from our developer users was overwhelmingly positive, along the lines of "this is the best API I've ever used".
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.
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.)
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”.
I agree. Sometimes it's easier to just return the record. It starts to suck when you get an array back and you have to loop through all n+1 results to query each additional record instead of just getting what you need in 1 request.
I've been called a conspiracy theorist before, but I believe this is why many frontend developers make their tooling and stack so complicated - to carve out their own niche to remain relevant. Just compare how simple and easy Java is to get up and running.
Ehhh... Java didn't start out that way. It felt like confusing hell and I wasn't sure what I was doing for a good reason and what I did because that's just what you did. EJB, Glassfish, Apache, WAL, something something Enterprise. Java the language is quite nice, the tooling can be quite insane. Yeah, don't forget the custom convoluted setup at some companies which only work with Eclipse, which suddenly slows down for no reason until you restart it. Then, you throw in some plugins and 50% of your screen real estate is gone.
Don't get me wrong, I quite like Java and the good tooling, but I'm more exposed to C# these days and Java feels like 90% the same, so I'm never compelled to go back.
Or you are maybe sarcastic, impossible to tell in text...
Side-edit: from the very beginning, Java was simple, when it was released. But in 2010 it felt super confusing to me.
I never had thought that in my life I'd have people longing for how easy java is lmao.
That coming from experience of managing various shit turborchargers like tomcat or jboss that just added tons of unnecesary complexity and zero benefits to 90% of apps that used them
There’s a special spot in hell reserved for the most vile systems managers. Their punishment is to repeatedly deploy WAR files to WebSphere. And each time it doesn’t work, and of course it never works, they have load up NetBeans to hand edit some XML config file and try again.
>Just compare how simple and easy Java is to get up and running.
Is it? I come from a very different background and I'm trying to get a small Java back-end up and running (Quarkus) and wow, it's so painful! There's a huge amount of buy in, to me, in the framework. I found Node, Go and Python to be easier in simply delivering a HTTP(S) server. I've gotta do it in Java for reasons.
You're probably referring to Spring boot, which I haven't used but I presume is fine.
However, the Spring framework in the 2000s was a horrible mess of "aspect oriented programming" and obscure XML configuration files. Till this day I had no idea what it was trying to achieve with that architecture (except maybe trying to avoid writing code by writing lots of XML configuration files instead)
The most popular "complex" front end stack these days is something like Next.js and it's a single button push to have a dev server that instantly responds and updates to saving a change in the code, and it's another single button to deploy. Just because you don't have familiarity with something doesn't make it complicated. It would be more or at least equally as complicated to write the majority of web applications using nothing but the browser provided abstractions directly.
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.
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.
“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…
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 hope its okay that I take a chance at digging into this a little bit because I think its a pretty interesting thing you encountered here. I myself have been part of acquisitions, both good and bad, and worked at 2 monolithic organizations (university system and Apple, respectively) and 5 varying sized startups back to a monolithic organization via acquisition.
What strikes me as interesting here is the interference levels. The big question I have here is my initial thought upon reading this is: When the parent corps software architects came in to lay claim to the new frontiers of their acquisition, a few common scenarios come to mind [0][1]:
The first is that its entirely possible that the architects saw a greenfield way to grow their career by treating the acquisition as a chance to grow their stature. Therefore, its important for them to have their names all over things and for some understandable version of what gets done to mirror things others will understand, presumably so they have the easiest path to explain their OKRs (or similar). If this was the case, then the best thing you could have done in my view was to express early about collaborating and learning their process, and try to insert yourself into the discussions and appeal to them as an authority, while selling your idea as if it was their idea[2]. The metric for them is visibility, familiarity and career ascension, and thats the hidden goal in this scenario you have to play into.
Another scenario is that the team had already largely sold this upstairs (or it came as a top down directive) and they were simply under the thumb of need to make this follow the same uniform structure that the team had been following without any real room to make exceptions. It'd help if people just said this, but I have found often they don't, it comes out in other ways. A key thing I like to do when I interact with a team and they present me with something before I'ved asked for it in detail is ask if they already started or got some kind of sign off on it. If they did, you can appeal for changes, accept the design as is, or appeal to the higher stakeholder involved. In these situations, I've had the best luck drilling down into the surrounding circumstances and figuring out who it is that I need to build a relationship with to change the circumstances for the better, whenver possible. These are more political in nature and really will reveal alot about culture, so its important to use a deft hand. I've been in situations like this, and I've usually pitched something to the effect of
you don't want this acquired tech to go south, perhaps we should re think this before it becomes a larger problem (though decidedly not worded in this direct manner, again, use a deft hand)
Lastly, the last scenario that comes to mind for me is that its entirely possible that the team was generically tasked with taking on architectural responsibilities post acquisition and they simply had different culture / methodology for handling this, and only an appeal to a higher authority or diving into their existing process would help at all. I find generally its best to see if you can get into their process and start to form things around how they're already working that move the needle rather than trying to wholesale push back against whatever it is they're trying to achieve, that usually ends up being a losing proposition unless you have higher authorities vested in your success and outcomes over theirs, basically.
[0]: They're hypothetical and based on what I've seen and learned from others, but not representative of every situation, and may not be related at all to yours.
[1]: The advice I may lay out here, is hypothetical in that I can't speak to any specific situation, only pattern match. Sometimes, politics kills any good intent and attempts at proper compromise. That's when it becomes a red flag, depending on how, what, why, who and how often. can't win them all, unfortunately
[2]: I realize this is one of the tenants from books like How To make Friends And Influence People but its easier than you might think, if you haven't done it repeatedly it might sound sneaky but it boils down to agreeableness to a big degree.
> try to insert yourself into the discussions and appeal to them as an authority, while selling your idea as if it was their idea[2]. The metric for them is visibility, familiarity and career ascension, and thats the hidden goal in this scenario you have to play into.
Very difficult in practice, does anyone have stories on accomplishing this in a developer job?
I've had some success with this by working solo on an idea until it's ready to present. Then I'll talk in general terms about the idea with someone who has authority/political backing. It's important to talk high-level without showing them any of your work. I ask a few questions and I let them play with the idea. I try to spend most of the time listening. If I find that we are mostly on the same page I wait until the next day and show them my work saying something like "I threw this together based on what you were saying yesterday". This has worked well so far in my career. As the people who want to grind the corporate ladder ascend/move to bigger companies, they call me within a few months asking if I'd like to join them/their new team.
If I need to insert myself into a discussion I play dumb by asking a lot of questions even if I have knowledge/experience with the subject. To present alternative ideas I'll ask things like "Why wouldn't X work here?" or "What are the benefits of doing {current thing} instead of {what I want}?". Since I'll already have knowledge of the subject I can mostly tell when their responses don't make sense and I'll continue asking to follow-up questions trying to get them to see things from my perspective. I've done this a lot and it seems like it's a 50/50 shot that they'll be open to trying your ideas.
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.