1,052 karma · joined May 21, 2015
Although the math in the book is relatively basic I enjoyed it tremendously because it gives the historical development for everything and even describes the characters of different mathematicians, etc. The historical context helps so much with understanding.
I will look into Lean that is mentioned here.
It teaches the basics and then how to build a MIPS processor.
I know that's only part of what nand 2 tetris aims for. But still good.
It has solutions for many exercises.
Same works in Japan. Saved me a few hundred bucks on my TV.
Anyway, how is Mozilla to work for? I always thought it must be great, but recently reading about the firings and project cancellations it doesn't seem so rosy anymore.
PRs are expensive. So when you think 'this is a self contained change, but I need it to continue development' you are unlikely to send a PR for it. You will just pile on more code.
Because if you make another PR based on that first PR and someone finally does code review and tells you to fix something then you suddenly need to propagate these changes to all follow up PRs which is quite some work.
And while I think I might just miss something obvious it seems many people miss it that's why we have blog posts about 'stacked PRs'. (On HN a day ago or so)
In the end we moved to Gerrit and never looked back. We are not super experienced yet but I'd say our commit quality went up by quite a bit.
This is a good introduction to the differences of stacked diffs vs PRs: https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/
I've never worked in silicon valley so I thought there must be some magic that makes everything better.
But from talking to people in open source related slack groups, on conferences, and to great senior engineers I came to understand that all I was missing was the courage to follow through with whatever ideas I had. No magic solutions. Just hard thinking.
If people tried both and have opinions please share. So far I am ok with commit messages even if they tend to be long.
Another thing. How do you people think ADRs compare to design docs? IMO design docs are for gathering feedback and ADRs are for documenting decided things, there is some overlap.
Also from the article: "You can’t take your old organization based on feature teams, roadmaps and passive managers, then overlay a technique from a radically different culture, and expect that will work or change anything."
1. yes you might get a house at this price but it's either 1-2 hours out of the city center (which is fine, just saying Tokyo is large.) Or alternatively it's in bad neighborhoods. (bad is relative if you are from the US)
2. your house will most likely look like this: https://www.ii-ie2.net/dat/5ba1164d.jpg
Sayonara sunlight, hello neighbor.
here are listings: https://www.homes.co.jp/smp/kodate/shinchiku/tokyo/list/
there are nice ones in the list. I am just saying that this is the eastern country side of Tokyo (check the map) when the title probably makes everyone think something different.