johnksawers

I think the scrum team size is determined in part because communication overhead is exponential, getting beyond 6-8 people means the whole team has to spend a lot of extra time coordinating. This is true regardless of whether you're dong scrum or not. It's true some teams may be correctly sized at 20, but I would suspect that breaking that into 2-3 other teams would be a benefit most times.

Story Points represent effort and uncertainty, not business/customer value - those are Business Value Points. Devs are only committing to X story points per sprint. If refactoring is needed, it's built into the story points, or added as it's own task. And as others have said if the Product Owners don't take engineering input on paying down tech debt/infrastructure/internal tooling, then you have a broken company no matter what process you're following.

Whether we can run the tests ourselves, and whether we want to spend the engineering time to build and/or maintain an in-house CI system are two very different questions.

Whether a developer (or business person) made a business decision to outsource CI has nothing to do with technical competence.

Using SaaS for any business data has a risk, but usually it's worth it. I'm sure you use slack, slack could be breached, and I'm sure no one at your company has ever slacked a password to someone else.

That's a good article - a nice overview. I have a conference talk I give on the same topic called Your Emotional API: https://johnksawers.wistia.com/medias/wnlr918xe7

You've hit on what I think the core problem is: since forever (as far as I know) computers have been regarded as "magical and incomprehensible" - that is, non-technical people think they will never be able to understand what you just did with the proxy settings. So even if you show them and explain what you did, they never even consider that they could use that knowledge again in the future.

I think this is a failure of education. As the author points out, learning MS Office shouldn't be the first step, learning the principles of technical problem solving should be. That most computers operate the same way regardless of what they look like, and that you can draw inferences about what's wrong, and where to make changes. It seems like drilling in 'try a few things and then google for it' (as we all do) would help a lot.

Certainly unwillingness to teach can be a problem, but I think often it's born from the experience of solving the same problem for the same person many times over, and seeing their unwillingness to learn. </huge_generalization>

Many of these arguments assume that in (say) 50 years, all the janitorial/toilet cleaning/fruit picking jobs (i.e. shitty) jobs won't have been replaced by robots. I think this will happen whether it puts people out of work or not, so maybe we stop people from needing these jobs in the first place. Sure there will be some manual labor left to do, but it'll be highly paid so you can do it 5 hrs a week instead of 50 for some extra cash for your house party.