GitHub (Actions) is simply not built to support monorepos. Square peg in a round hole and all that. We've opted for using `meta` to simulate monorepos, while being able to use GitHub Actions without too much downsides.
I've been using openapi-generator for this for quite some time. I love the principle, but find that their generators are not all top notch, and the template-based approach is very hard to contribute to.
One thing I do not see with Stainless is also using it to generate the server side of the API.
We use OpenAPI as a design doc, and generate client SDKs and Datos for the server from the same spec. This gives us pretty solid control over interoperability.
Disclaimer: I work in Norway so pension, health insurance, parental leave, etc. is already covered by the law and is not a differentiator between employers.
First and foremost: remote. Not commuting gives me 2 hours of time. Every day. That makes a profound impact on my life that goes way beyond any kind of financial compensation.
I have a friend that went of rails (schizophrenia) a couple of years back. One day he threw out all his light bulbs because they were listening devices for "the others". Or deleted all the files on his computer that contained the letter X, because it is "the unknown". Paranoia was a LARGE part of his life, in every decision he took.
My friend was experiencing a lot of stress in his life at the time, which the doctors says most likely induced the schizophrenia.
It looked a lot like what is happening with Musk now.
One thing that has really helped me is the combination of remote + pair programming. Having an extra mind to work together is amazing. Doing it remote removes the stress of commute, noise/stress from the office, and allows for relaxing breaks where I can even lay down if I want.
Using note taking frequently, small commits, TDD and drawing diagrams continuously while pairing also helps keep my mind in context and picking up the thread after breaks. Whimsical has been a fabulous tool for this.
I've been of Aubagio before, and now I'm on Tysabri. The difference is staggering. Aubagio gave me tons of side-effects like hairloss, indigestion, increased fatigue and general feeling of being sick. And it still was not able to prevent flare-ups and lesions.
With Tysabri I can't identify a single side-effect. In the three years I've been on it I've not had a single flare-up or lesion identified after MRs.
Something I also believe helps me a lot is simply living in a country with healthcare and strong welfare. Knowing that when it eventually comes to not being able to work anymore, I have public disability pension that will cover 63.5% of my current salary until I reach retirement age (where normal retirement takes over). Having this knowledge removes a lot of stress and despair, which I genuinely believe helps keeping the disease under control.
Yeah, in our case the point isn't really the code, but how you reason around it. How able are you to explain the flow of the code. And also reason about choices made.
There is a real treasure trove of things to talk about.
Questions like:
- Why is it like Y?
- What is good and bad about Y?
- Why do you think X would be better?
- Why did you end up doing Y instead of X?
- How would you approach changing it to X?
Discussions like these on both a macro and micro level is very valuable.
If you get to talking about code (usually after a quick seeding of applications and a 30 minute chat), we will always talk about the code and also give feedback on our impression. So even if you don't make the cut, we hope to provide valuable feedback on why.
I do a lot of interviews for my company. We do coding assignments OR let you bring some code. We just want to talk with you about code that you are very familiar with and confident to talk about.
Almost everyone chooses to do the small coding assignment, because they don't have code to bring.
Short story, they are shooting small plastic cubes with gas inside. The cubes are called "targets".
The "bullet" is fast enough to compress the gas inside the cube, creating fusion.
It works. But in the scenario it does work, a machine is manually opened, loaded, prepared, and then they do the shot. Whole process takes days to prepare.
For it to be viable they need to do this every five seconds.
That is a hard problem to solve. First lights business model is not to solve that problem, but rather producing the "fuel", the tiny cubes with gas inside.
They say there is many details in how they are built which increases efficiency.
But someone still has to figure out how to build a machine that can continuously reload both the fuel and the bullet.
Google+ had circles as well. I found it very hard to properly segment people properly. There are rarely such hard boundaries on relationships. If I'm snowboarding or barbecuing, it's very seldom I only wanna share that with just friends, just family, or just co-workers. It will usually be much more interest-based.
Trying to create interested-based circles was also hard, as the cardinality explodes quite fast (and you're back to square one with not knowing who you share what with).
I guess this is where Snapchat is onto something with giving a very rapid selection of who you want to share with. I usually have a small group of people in mind when I want to share something.
Defining that group, fast, almost on a per share level is the key challenge.
I think the "circles"-approach could be a way, but I think it must be much more dynamic and alive than how Google+ solved it. It must continuously evolve.
I was one of two developers on a social media network in Norway, at peak hours (from about 20:00 till 22:00) we had 60.000 unique users with activity within the last 10 minutes. This generated about 400 dynamic req/s and about 6000 static req/s. We managed this sustained traffic with a total of 12 webservers (apache + memcached), 4 databases (mysql) and 6 Varnishes.