For plenty of already-in-shape people, the calories expended during the exercise are largely incidental, with the goal of exercise being to enhance or maintain some other property of their physical capacity.
* DevOps
* Microservices
* SOA
* ACID
* Observability
Semantic diffusion, dilution, and drift are endemic in tech because terms are so frequently co-opted by opportunists who want to find a way to sell the concept as a product.
What is interesting is that the first sentence is undermined by the second sentence, which is fairly reasonable compared to the first.
I think there's a pedagogical component too. The way that things are taught have an outsized impact in how people think things are done. This extends far beyond concepts.
For example, and I've been guilty of this too, in data science, it's common for tutorials and examples to be use ipython/jupyter notebooks. This, however, should not be mistaken for "It's a good idea to use notebooks as part of the code-to-production pipeline." It's an easy mistake to make, and implicitly part of how AI/ML is taught.
Point being: these researchers were chosen by, and paid by Mozilla to do this. The researchers have a strong incentive to be biased; to leave out details; to p-hack. Though they claim to be neutral, no human is capable of being unbiased, especially when his paycheck depends on it.
I have nothing but utmost respect for Mozilla and these researchers, but the paper needs to be read not as facts, but merely conjectures, to be verified by other more neutral parties.
> There is nothing less productive in this world than a team of developers.
First, yikes.
Also, I'm quite curious about how productivity was measured here.
For a (successful) software business, the work output of developers is highly productive because the marginal cost of selling another copy of the software is so low.
SaaS delivery models may result in somewhat higher marginal costs compared to non-SaaS distribution models, but I'd be surprised to learn that it makes developer work the least productive component of the SDLC.
They aren't saying developers are unproductive. They are saying teams of developers are unproductive. In the words of my great grandfather. "one boy is one boy, two boys is a half a boy, and 3 boys is no boy at all"
I don’t know. If someone told me “there is nothing less delicious in this world than your turkey casserole” and you came along and said “they aren’t saying your turkey casserole is undelicious,” I’d be inclined to believe you misheard something.
Team / interpersonal communication overhead, planning overhead, and dealing with less skilled members of the team can easily make 4 engineers roughly as productive as one very skilled engineer, just at 4-5x the cost once you include the increase in product/project management required by multiple people. We tolerate this generally because eg upskilling peers is important to scale a company, but pre-PMF it's a huge advantage to have just the one outstanding engineer.
the difference in productivity between 1 and 2-person teams isn't in 100%, but in maybe 50%.
The more people you add, the smaller the productivity gain.
From my own experience, my most successful products have been built by one single full-stack dev. Who did everything
> For reasons that should be obvious to anyone with a bank account, you really really want both updates to happen, or neither. This is what atomicity guarantees - that the entire transaction will either succeed or fail as a single unit.
So, I understand why this example feels particularly illustrative of the value of transactions, many-if-not-most financial "transactions" can't practically rely on this kind of atomicity for the kind of financial operation depicted.
While it may seem like a small thing, I think authors would do everyone a favor to stop using the "banking transactions, obvs" example.
I suppose this is a good example if your reader knows how banking systems work.
A better direct example in the same line of reasoning would be double-entry accounting where you would want both the credit and debit entry to either fail or succeed.
Most people probably don’t know that their bank account _is_ a double-entry account to their banking institution.
I can’t noodle a way to make the banking example more intuitive for an audience absent explaining how double-entry accounting works and that banks mostly obscure that from the customer. That’s not really knowledge you can assume from a software developer or sysadmin.
In my experience most things you want to do turn out to be impossible to achieve with RDBMS-level transactions, and you end up having to implement the behaviour that you need "by hand" with the database's transaction support mostly getting in your way. So in a subtle way banking transactions are actually a pretty good example.
We build complex systems and environments that alienate and marginalize massive groups of people and then, rather than recognizing that as a failure of the system, we frame the problem as one of individual responsibility to adjust.
But, the system probably feels like it is still working working well enough for the folks running the WSJ to continue their support of it, so we get articles like this.
RTO has benefits, just not for employees. Commercial real estate, businesses downtown, municipalities, they all benefit from this slow moving trainwreck.
Hence my choice of phrasing: "benefits to results".
There are certainly perceived benefits to management and/or related to real estate interests, including but not limited to: easier observation and suppression of employee organizing, different legal exposure profile as fewer people are casually creating business communication that may later be sifted during legal discovery, propping up commercial real estate investments, etc.
Very large household-name companies often own or otherwise control significant amounts of commercial real estate, which sit on the company's balance sheet.
If commercial real estate in general loses value, the value of these assets is also reduced, which will eventually be reflected on their balance sheets.
Even in cases where the real estate is leased rather than owned, the future rents owned are liabilities that are also a part of the companies' financial reports. If the demand for commercial real estate goes down, they won't be able to fully offset liabilities by subletting or selling their commercial real estate, which will show up as losses, write offs or write downs.
