I had a very similar setup for a while and it worked okay. We had one meeting day each week. It was mostly about whiteboarding and building social cohesion. We still communicated quite a lot on other days (mostly through text, rarely VC).
I wonder to what extent the issues described are fundamental and to what extent this is just a matter of adjustment / investment / development of new practices.
The organizations spend a huge amount of resources on shared offices. Contrast that with a lockdown remote setup when even having a decent internet connection and mic is not obvious for many people... What if some non-trivial fraction of office budget was allocated to remote setups?
The best practices and social norms for remote work are not the same as in-person. If remote work becomes more mainstream, I expect that we'll collectively get better at this. Anecdotally, remote-first approach with self-selected people works better than "retrofitting" remote work in an in-person organization.
Hmmm... yeah, but you could have made it in other ways, which might or might not be possible to offset, e.g.:
I previously assumed that you can only offset capital losses against past capital gains.
BTW if you allow offsetting against any kind of income then you get another issue – all of the people who are really bad at investing consistently decrease their tax bills by their capital gains losses. Not sure how big a deal is that. Or perhaps that's a feature?
We should significantly increase capital gains taxes by taxing it at the same rate as ordinary income.If an investor makes money one year then loses it later, we should give them their taxes back.
I wonder how progression would interact with the giving back. I.e. if you had gains while being a high-maginal-rate taxpayer and then losses at a lower rate or vice versa.
If an investor makes money one year then loses it later, we should give them their taxes back.
If we don't allow carrying forward losses this puts people who are just starting to invest at a serious disadvantage.
If you can immediately offset all your losses such tax basically feels like the government de-levereging you (taking a percentage of all gains and losses). I.e. you can get the same outcome as without the tax by investing 11−taxrate times more.
If, on the other hand you lose before you have gains (and we don't allow carry-forward) you lose 100% of what you lost.
Could you explain where P(I swing election) = 1/sqrt(nVoters) is coming from?
Note: the math and the picture didn't transfer. I may try to fix it in future, but for now you might want to just read it at the original site.
Could you add a link?
I found pair programming pretty useful when starting a new project from scratch, when changes are likely to be interdependent. It is then better to work with, let's say, 1.5x the performance of a single developer on one thing a time, than to work separately and then try to reconcile the changes. Knowledge transfer is also very important at this stage (you get more people with the same vision of the fundamentals).
This generalizes to other cases when there is a "narrow front" - when few things can be worked on in parallel without stepping on each other's toes.
Even more generally, it seems there are three kinds of clear benefits:
1) Less change synchronization (fewer changes worked on at the time).
2) Knowledge transfer (see @FeepingCreature's answer).
3) Immediate, detailed review - probably fewer defects.
There is also a matter of raw throughput (or how much time is required to make a specific change, while the rest of the code is assumed to stay the same, ignoring the cost of syncing with any changes done in parallel). A naive baseline is that a pair has a throughput of a single developer (since they're working on one change at a time). Fortunately, it can be way better, because one person can just focus on the details on the code and the other on the slightly bigger picture and next steps, look up the relevant facts from the documentation etc. This eliminates a lot of context switching and limits the number of things that each developer needs to keep in working memory. Also a lot of typos and other simple problems get caught immediately, so there is less debugging to do. It's not so clear, what all of this stuff adds up to.
I was able to find some studies about the topic, including a meta-analysis by Hannay et al. TL;DR: it depends on the situation, including how experienced are the developers and how complex is the task). It's clearly not a silver bullet and generally it still seems to be a trade-off between person-hours spent and the quality of the produced software.
doubling the size of a tax quadruples its social cost
Could you explain that in more detail? Why is that?