> It's looking like Windows will be more of an issue here than anything in Office.
And even then, Microsoft will be happy because even if Windows were to dissappear tomorrow, people would still be buying Microsoft 365 licenses and just using the very same tech and app stack from their mac.
I've often thought this could work if the code reviewer was full-time, but rotated regularly. Just like a lot of jobs do with on-call weeks, or weeks spent as release manager - like if you have 10 engineers, and once every ten weeks it's your turn to be on call.
That would definitely solve the "code reviewer loses touch with reality" issue.
Whether it would be a net reduction in disruption, I don't know.
Doing code review as described (actually diving deep, testing etc) for 10 engineers producing code is likely not going to be feasible unless they are really slow.
In general, back in 2000s, a team I was on employed a simple rule to ensure reviews happen in a timely manner: once you ask for a review, you have an obligation to do 2 reviews (as we required 2 approvals on every change).
The biggest problem was when there wasn't stuff to review, so you carried "debt" over, and some never repaid it. But with a team of 15-30 people, it worked surprisingly well: no interrupts, quick response times.
It did require writing good change descriptions along with testing instructions. We also introduced diff size limits to encourage iterative development and small context when reviewing (as obviously not all 15-30 people had same deep knowledge of all the areas).
You could do some interesting layering strategies if you made it half time, for two people. Or maybe some staggered approach: each person does half time, full time, then half time again, with there people going through the sequence at a time. Make each commit require two sign-offs, and you could get a lot of review and maybe even induce some cooperation…
I think it's amenable if you make code review a primary responsibility, but not the only responsibility. I think this is a big thing at staff+ levels, doing more than your share of code review (and other high level concerns, of course).
Linus Torvalds is effectively a full-time code reviewer, and so are most of his "lieutenants". It's not a new idea, as you say, but it works very well.
Yes, the idea of a land value tax is to make it high enough to for banks to foreclose. The entire thing is about making sure land is used on the most socially benefiting way possible.
> The entire thing is about making sure land is used on the most socially benefiting way possible.
The idea of land value tax is to make the government effectively the universal landowner and everyone else renters, and renters paying a high enough rent that it is economically infeasible to use land for any but the most financially remunerative purpose.
Having it optimizing for social utility rather than maximizing negative externalities requires a finely optimized system of Pigovian taxes and subsidies, otherwise you are nailing the accelerator to the floor on the divergence between market incentives and social utility.
It would make sense to have those Pigouvian taxes no matter what. But having an LVT is orthogonal, and it doesn't make the bad economic incentives that much worse. Especially since most economic activity subject to pigouvian taxes will not be much affected by land value taxation.
> It would make sense to have those Pigouvian taxes no matter what. But having an LVT is orthogonal
It is absolutely not orthogonal; LVT by design makes doing things with property that are less financially remunerative unviable, it’s key selling point is eliminating “less productive” uses by that mechanism. This exacerbates any divergence between market incentives and social utility.
> People are putting their IT/dev budget into something, which means something else will be cut.
That's not how things work in normal times.
But normal times require minimally capable managers, a somewhat competitive economy, and some meritocracy in hiring. I can believe that's how things will work this time, but it's still a stupid way to do it.
I guess Peopleware couldn't get every single thing right.
A hospital model may be a good idea. One where you have a senior programmer and many junior ones doing most tasks isn't. IMO, something closer to a real hospital team, where you have experts of different disciplines, and maybe a couple of juniors composing the team has much higher chances of success.
> something closer to a real hospital team, where you have experts of different disciplines
That is not how hospitals work. The surgery departement won't have a crack team of different disciplines to teach budding surgeons everything. They'll only have veteran surgeons to guide less-experienced surgeons.
What you will have is interdepartmental cooperation / hand-off, and you'll have multi-discipline roles like surgical oncologist.
In the same way, you won't have devops seniors training front-end juniors.
A surgery team has a surgeon an anesthesiologist, a nurse specialized on material handling overseeing the material usage in the procedure, maybe a nurse specialized on equipment handling. None of those people are junior or subordinated to the others.
Yes, the most helpful things AIs do is to guide people into popular environments they don't know very well.
Or in other words, the people that get the most value from AI are junior devs, since they still don't know very well plenty of popular environments. It's also useful for seniors that are starting something in a new environment, but those only get 1 or 2 novel contexts at a time, while everything is new for a junior.
Or, in again another set of words, AI enable juniors to add more value more quickly. That makes them more valuable, not less.
It's looking like Windows will be more of an issue here than anything in Office. But either way they can only push people so far.
reply