Advertising in my private space on my private hardware in my private software in my private time is an invasion of my privacy. Anyone forcing ads into my domicile is invading my privacy. It’s MY space, not yours.

deleted by creator

Specialist is too thin. The specialists only know what they know and they don’t want to learn new things outside their speciality. So I had to hire a new person everytime we found a speciality gap because the specialists were like “not my job, I am an X specialist, go hire a Y specialist”. Then, they held their work tightly, no cross training, so the specialists all became their own brand of bottleneck. Different work speeds and different levels of quality meant that ego came to defend against performance complaints, and I as a manager couldn’t add more people to the problem areas because they weren’t trained in that area and the specialist could do it faster than they could train others to help.

That being said, all my full-stack team members had specialities. That’s what T-shaped means. I had frontend specialists who could work the whole stack, backend specialists who could work the whole stack. Dev tools specialists who could work the whole stack. Architects who could work the whole stack. Everyone we hired had something they were best at, and an alignment to learn the whole stack. Within a year they were able to work on all tech in the stack and anyone could bring in a new tech to solve a problem and everyone would learn it.

The idea that a single developer delivers an entire story is where your problem was situated. Stories aren’t assigned, they are owned, and they aren’t executed, they are delivered. One story can be worked on by 4 devs, all with different skills, but the story owner is the one who makes sure it gets the right people on it and is the one who makes sure the product owner sees the delivery.

Yes, I have built both types - specialist first and it was a fiasco. Cross-functional was consistently the best

Think about the alternatives - either you divide the stack into separate teams or you have non-overlapping experts in the same team. Both are horribly worse.

With the multi-team architecture, no one can deliver anything on their own. They all have to hand off their work to someone else and receive handoffs from someone else. Rework becomes huge as downstream teams with expertise not present upstream identify flaws and send work product back for revision.

With non-overlapping experts, you have a team of N with N bus factors of 1. No one can get sick or take vacation. If someone quits, dies, or wins the lottery, the whole team shuts down while they try to find a replacement. You can fix this by hiring 2 or even 3 experts per area. So now your team is full of redundant experts that fight for expert recognition. The handoff problem remains but is somewhat lessened.

A full-stack team is not a team of pure generalists. A full stack team is a cross-functional team that owns the entire value stream (design to production) and cross-trains internally. Hiring people with specialized knowledge is predicated on their willingness to learn all other areas and teach their area. Only T-shaped professionals (depth in one area, breadth across the stack) inhabit the team and only people with the humility to learn need apply.

Over time, a full stack team outperforms every other team. The team is internally redundant on all tech, so bus factors are lowest when new people are added and bus factors continuously get larger over time as people cross-train. New hires have built in training because the team is always training. New tech can be added regularly because everyone is always training and learning.

Full stack teams are the best form of software team hands down.

It means do not test HOW it is done, only test WHY it is done. Obviously you cannot test an abstract interface, only an implemented one. However, you should not be testing HOW it is implemented. Instead, you should be testing that given X input you get Y output based on the expectations set in the interface.

For example, take method F(x, y) that is designed to take in an identifier x and use it to fetch you a record from some persistence object y. Testing the interface of F(x, y) would mean testing that given the input x you get what you expect from the persistence object y. Testing the implementation would mean testing that F(x, y) issues a call to a specific method of y. For example, if y has an interface with methods getRecordById, getAllRecords, and searchRecords, testing the implementation means asserting which of these methods gets called (usually with a test using a mock object that can be interrogated in this way). Testing the interface means not caring which of these methods are called when satisfying the request for F(x, y)