681 karma · joined November 13, 2012
How would you know this without doing your research? You've proved my point.
Why are you interviewing somewhere when you don't know anything about it? Sounds like a great way to line up jobs you don't even want, which is a waste of both your time and everyone at the company whom you spoke with.
https://www.cnbc.com/2019/04/03/why-amazon-paid-no-federal-i...
There's specific credits/exemptions in the tax code that they are able to exploit (and perhaps they can only exploit some of them _because_ they are a big company), but it really isn't about their size.
https://w3techs.com/technologies/details/pl-php claims ~79% of websites whose backend is known use PHP.
https://w3techs.com/technologies/details/pl-ruby shows Ruby has grown from 2.5-3.5% over the last year.
Why treat internal 'customers' any differently than forward facing ones? Building great internal tools can dramatically improve your teams' workflows and solve meaningful business problems.
Original tweet: https://twitter.com/cory_foy/status/1251705040873689088
It's also quite clear he takes issue with the Trump administration and Marc's attempts to downplay their role in the current crisis and our preparedness.
> The IRS? Turns out they're actually racist for requiring a bank account to transfer money to.
Cory didn't say the IRS is racist for requiring bank accounts, he's saying racist/classist policies prevented people from getting them in the first place.
You're intentionally misrepresenting his response to claim everything is about the current crisis — it is obviously not. Nor is Marc's original article.
Let the epidemiologists guiding global responses to the pandemic provide guidance and everyone else should call out anyone trying to peddle their own made up conclusions.
The idea being that some tricks are "too perfect", so the only way to do it is obvious, or the solution the audience arrives at is one which makes it look easy, and thus they don't give you (the magician) any credit for it.
You can easily find counter-examples if you look for them.
If leaked Russian documents surface and Wikileaks refuses to publish them... that's a different story.
https://www.privateinternetaccess.com/blog/2019/11/bellum-om...
I didn't lose trust in PIA because of Kape, I lost it because your blog post was poorly written and inadequately communicated some very important news. You bury mentions of a merger in the 7th paragraph, wtf?
I can't trust PIA if you can't be trusted to clearly communicate such important information.
* An API to request files/upload files
* Authentication/encryption (how do we ensure DB employees aren't arbitrarily reading data on servers?)
* Service that shards data and handles multi-region replication
* That entails multiple datacenters (how much code does it take to keep a DC running?)
* Automated backups to cold storage
* Automated restoration + testing of cold storage volumes
* Soft + hard deletion (deleting hot/warm/cold storage volumes reliably)
* Error handling (retries, host errors, network failures, filesystem corruption, finding data when a host dies)
* Fail-safes like blocking requests when hosts can't handle them, shedding load, etc.
I'd also add that at this scale, very few libraries start handling the types of problems you have. For example, there might be a memcache library that makes writing queries easy. However, when you have thousands of memcache servers globally you can't just hardcode IP addresses anymore. You know have to write your own custom 'service-service' that lets you look up what host you should talk to for something.Once you have extensive knowledge of how a system works, you can more easily spot incorrect code and are less likely to write it yourself. You should always treat any debugging session as "learning more about the system". If you can't explain to another person _why_ a bug occurred, then you won't be able to convince them that the problem is truly fixed.
The approach you take to learn how the system works is not important, and will vary from person to person. Experienced developers can read code, think about it, and understand what it does. Some people understand control flow through print statements. Some people can fly through with a debugger. Saying someone else's method of study is "wrong" is just silly if in the end they understand how it works.
This article is especially wrong because it makes the assumption that you must step through a program line by line when you use a debugger, which you don't have to do. You can just put breakpoints at the same places where you would have put an equivalent print statement, except now you can inspect _everything_, instead of the one or two things you bothered to print out.
Numbers probably aren't including housing, which in Silicon Valley puts a ~$7500 monthly salary roughly up to $10k.