Not that I seek it out, but whenever I come across a Kent Beck post, I feel exactly the same. Authoritatively Pointing out the obvious with metaphors while having zero practical advice.
I don't understand how this sentiment is weird at all and I think you're reading a lot of your own biases into it. The statement talks about where the work gets done and doesn't speak to how efficiently the work gets done.
There's nothing that prevents remote work from not being efficient enough to further the goals of an organization. It also doesn't prevent one from being a leader and teaching younger folk. In fact, I've had to do this a lot and it's much nicer to get people on a video call and share my screen to teach or do team programming than it is to find a meeting/conference room in the office.
Some people don't like interruptions _precisely_ because it prevents from doing an efficient job. And it's more than slightly annoying when you're getting interrupted multiple times per hour.
Yes, _very_ few things are built solely by an individual, but _nothing_ prevents remote work from "Doing work" as you put it or collaboration between teams.
I worked for ~2 years as a contractor for a government entity in Canada. ~3500 headcount of employees. What I observed there was sickening. This was a place that had white-collar unions for all non-management employees. This union had completely hijacked the mission of this institution. It was no longer about serving the people that this entity was created to serve, but rather to protect the union and its contributors.
The software we were in charge of writing had direct, material impact on the physical and mental well beings of people in the province. Life and death. And at times I saw things like a deployment of features being delayed by weeks/months because a union member who was responsible for _manually_ deploying the changes was on vacation. To automate that deployment meant automating a union employees job and was impossible. These features directly served the needs of people that were in critical need of them.
On the other hand, I have family friends who work for UPS and other delivery services and see the brutal toll it takes on their body and mind. Pushed to absolute limits and exploited because they don't have a union.
But to me, it seems unions can and often do exploit people. After witnessing all of this I've developed a very dim view of humanity. We all just want to exploit someone.
I've worked at a company where Agile/Scrum was implemented in beautifully and we never thought to change the process.
However, I've worked more often at companies where Agile was either misunderstood, or inserted into an already flawed/toxic process of development as a magic bullet. I think there are enough places out there doing the latter that warrants discussion of this post and how we can improve things.
I think there are enough employers out there that are implementing the version of Agile/Scrum described in OP's post. I currently work at such company and can relate with pretty much everything on that post.
The sad part is I'm not really sure what is better that will be accepted by clients who now have become comfortable with Agile. From my personal experience, if you're on a team with smart motivated people, Agile won't really help you or increase your output. You will continue to deliver the quality work regardless of story points, scrums, and all the other metrics.
If you're not on such a team, clients using Agile can now point to some number and say "Hey, this number is 100 but you should be at 180. You are not performing". I do agree that it gives too many false positives and generally my attitude towards them (in cases where I have been the target) is to simply reply "If you don't think I'm performing: fire me."
They usually walk away at that point mumbling something and I go back to work.
I'm not sure. If you then go head and inline the code after, your unit tests will be worthless.
I mean it could work if you are writing a product that will be delivered and never need to be modified significantly again (how often does that happen?).
Then one of us has to go and undo the in-lining and reproduce the work :)
What if I want to test some part of the function in isolation?
At my current job I have to maintain a huge and old ASP.NET project that is full of these "god-functions".
They're written in the style that Carmack describes, and I have methods that span more than 1k lines of code.
Instead of breaking the function down to many smaller functions, they instead chose this inline approach
and actually now we are at the point where we have battle-tested logic scattered across all of these huge functions
but we need to use bits and pieces of them in the development of the new product.
Now I have to spend days and possibly weeks refactoring dozens of functions and breaking them apart in to managable services
so we can not only use them, but also extend and test them.
I'm afraid what Carmack was talking about was meant to be taken with a grain of salt and not applied as a "General Rule"
but people will anyway after reading it.
I also want to echo this sentiment. It's sad how many people here have responded with disgust and have wished bad things upon you. I come to HN to read discussions of a higher level, and instead of proposing level-headed solutions as to how to improve the app-store, you are treated with insults, and that's really sad.
As a developer you are already at the total mercy of these app stores. That doesn't seem to be a problem apparently for many people here because of the belief that the pride of the work should be completely secondary to monetary gain.
The owners of these app stores don't seem to care much either. The more people who make apps regardless of revenue expectations, the more they improve the quality of these app stores and add value to the owners, not the developers. The Apples, and Googles don't have any incentive to make the marketplace any more fair it would seem.
I can't believe someone who has 'delivered highly scalable solutions' actually managed to write this line on his blog with a straight face. How were you not able to deduce that the devs likely detected disabled javascript without the use of javascript?
His whole post is devoid of content and nothing but statements without any real substance or evidence.
I'm not sure if they actually could have sold the company to google even if they wanted to. My understanding is that you must open your books to the prospective buyer after a certain stage and it is likely that once the google accountants had a look at Groupons books the deal would have fallen through.
That could have created negative press and damaged their pump-and-dump strategy for the IPO.