To me this looks like better plan. Instead of unpredictable mechanism on when the messages disappear from you history, it's now predictable and you can act according to it.
I've used python typing heavily at work and was really useful to detect bugs and helped with developement.
> as evidenced by only 15% of repos passing mypy
That is no evidence. Of course, if you don't have mypy in CI (or pre-commit hooks or whatever), your repo will not pass mypy. But if you have it in CI, then you can rely on them being correct.
> tools like pytype or mypy will never capture all the complicated hacks possible
But they can either enforce everything being correctly typed (if you go to really strict settings), or yes, you will have some code untyped, so you will be careful around that part. It's not like all or nothing.
But for wast majority of pull request branches, people are not checking them out. And if so, they are not modifying it, so dropping local branch and checking fresh one is 20s additional work.
Additionally, technically speaking --force does not overwrite history, it just moves the branch pointer. Old commits are there.
First, never use --force, but use --force-with-lease -- this will fail to push in case someone make remote changes. Useful if you are collaborating on branches (or develop from more than 1 computers).
> It can't pause when a conflict occurs, so you have to fix the conflict and (somehow) re-run it from the point it stopped at, which is fiddly at best.
There is better way:
1. I use `git rebase -i` from the top of the stack -- it opens a vim with list of changes it's going to do.
2. I have script (https://github.com/mic47/git-tools/blob/master/GitStackTodo.... ) that process this and inserts commands to backup branch and move branch to new location to TODO list. At this point, I can even modify the TODO list to rip out commits I don't want, or squash commits i want. Or you can reorder commits (I usually do code review fix at top of the stack and then reorder commits -- at least if I am reasonably sure there won't be conflicts for this fixes).
3. At this point, you can insert more things, like run tests after each branch, or commit (and pause rebase in case of failure, so you can fix it).
4. When I close this file, rebase starts. In case of conflict, rebase pauses, let you fix it, and when you continue rebase, it will finish the TODO file.
5. After, I have script that removes backup branches.
6. I have script that runs command on each branch, so at the end, I do this to push my changes `git stack-foreach master git push --force-with-lease `
What if you can't resolve conflict and you are in the middle of the rebase? You can run `git rebase --abort` and it will restore top of your commit. Only drawback is that branches that were rebased are not restored, but hence my script also create backup branches so I can fix that manually and move branches back.
Depends on how her/his skills apply to such company / role.
I.e. at FB, you could be E7 by just technical work, but you had to be really good and be able to pick important problems and solve them (say that you are able to design and implement core systems for example). But it's easier to get above E5 by going TL way.
I worked for FB (left in 2018), and you are right. He started as E4, which means that he was not new grad (new grads starts as E3). So he was either phd, or had industry experience before.
His first year: "Because of the 3 launches and building a 4 people team, I was promoted to E5" -- looks like he should have been E5 when started (given that he was able to build team in the first year), and they quickly corrected for that.
Depends on how you provide feedback. If you get it back from the recruiter, there will be information loss. If it's written by engineers, or given you by engineer (or eng manager, who understand the feedback) personally, it end up much better -- because it's easier to mitigate any misunderstanding.
They will not cut ads off. They will try to consolidate ads and use ad budget more efficiently. Most likely, google, facebook ads are more likely more effective than non-targeted ads like TV, so while total ads budget goes down, targeted ads budget don't.
Yes. I imagine, we would have hashtags, and algorithmic hashtags (in case your uncle stops using #rightWingConsiracy hashtab because everybody is filtering it?) and ability to filter by hashtags (with ability to selectively pick whether you block algorithmic hashtags, or normal hashtags). The problem I see is that your uncle might get offended that FB is marking his posts #rightWingConspiracy).