I think that when you split a task among multiple people, important context gets lost, and you run the risk of making a bad product. Everyone can do well individually, but taken as a whole, the work product falls short. Having a detailed understanding of the problem and solution space is crucial to making something good, and getting that understanding is expensive. Individual output in a very small area isn't a good metric for productivity, the results of that output are what's important.

For that reason, I think it's important for individuals to own things from idea to implementation to maintenance. You know how best to test your software. You know why you're getting paged for it breaking. You should handle that.

I think the loss of quality when splitting up projects among multiple teams (or even individuals) is why startups produce so much more than huge corporations. (My personal view is that output scales logarithmically with the number of people involved -- to do a project that's 4x more complicated than what one person could do alone, you'll need 2^4 = 16 people. Part of that is all the communication required to hand ideas over from product to engineering, hand software from engineering over to QA, hand maintenance over to SREs, etc. You can skip all that and do more with less.)

A couple years back the team I was on was behind schedule on a project. We needed to complete the project in 2 months and we expected we had 6 months of work to do. So we worked nights and weekends, we had 12 hour calls in which the managers were constantly checking in on. Crunch time.

During that time we all worked as one. Focus on one workflow, get it down, move to the next one. We finished on time, and the knowledge sharing that occurred during those 2 months were more than years of knowledge sharing than I had previously.

Once we completed the project, we went back to the old style. Productivity dropped like a rock. But during CO-VID we have had glimpses of that crunch style that come when everyone is on a call. Completing a story is so much better when the team completes that story.

Where do you work, so that I can make sure to never work there?

I think a developer doing their own QA is far better than them not doing it. How are they not just throwing over garbage if it hasn't been exercised meaningfully (typically an automated test won't be as good as a manual test but maybe it can be). In the bigger picture, going "slower" is probably better than being worried with "speed of delivery" which then takes longer to actually be done with the level of quality that would make the product "good".

The article says the engineer should go out and find another person to use it in front of them!

A quick local build and cursory click through can be okay but should they be doing the above for every contribution?