I'm no expert on snapchat, but one thing I can say from personal experience being at an IPOing unicorn -- until about a year into our IPO, we were a "no buy", and all of these giant companies were ostensibly going to crush us with products that didn't even compete with us. Then, one year and a couple of earnings calls in, we're suddenly a "buy" and people consider us stable and successful. What did I learn from this? Never trust the stock market, and doubly so do not trust the stock market with a new stock.
I feel like this is a terribly lacking reply. I'm not a trend-person by any mean: I'm a deep-backend developer, and my main language right now is Java[1]. However, when I have to maintain rails apps, even well-written ones, I find myself frustrated. I think ceding the advantages of a compiler is a fundamental mistake. Compilers and static checkers make for better software more easily; they don't replace tests, but they complement them and constitute compilable documentation for your code, enhancing its maintainability considerably.
[1] I write in Java because I work for a Java shop, but even if I had my choice of languages, I'd probably be using either Swift or a compile-to-JVM language.
I disagree. I'd rather getWhenPresent than orElse if the code has nothing to do with a missing value. If someone needs the value and uses orElse without isPresent, their code will break in new and unexpected ways rather than in the obvious one.
(An even better solution is SWIFT's approach to nullable types, but that boat has sailed; intellij etc could however implement a static checker for bare Optional-getting)
Playing devil's advocate here: The only way to really learn the full ruleset of a team is by undergoing a couple of code reviews in which every issue is pointed out. Once your teammates see you've understood the prevailing style, they don't have to work as hard at code reviews.
That said, I usually hate petty/nitpicky code reviews. I try to focus only on issues that I think affect readability, maintainability or functionality.
This is like people who want to repeal Obamacare and have no alternative. If you advocate blocking all ads, you should at least have a vision for how you're gonna pay for your fucking content. I block ads too (I'm ADD and moving objects in my field of vision make it hard to enjoy content), but I'm not going to be fucking self-righteous about it.
This is like people who want to repeal Obamacare and have no alternative. If you advocate blocking all ads, you should at least have a vision for how you're gonna pay for your fucking content. I block ads too (I'm ADD and moving objects in my field of vision make it hard to enjoy content), but I'm not going to be fucking self-righteous about it.
I don't entirely agree. As someone who works in a mid-to-large company, and who has worked in a 50,000 person company (admittedly for both companies not all employees were engineers), I feel it's worth noting that as companies get larger and teams more diverse, they tend to require the exact features open source projects need.
A product manager in team X who noticed a bug in product Y is not going to know what fields are necessary for that product, and as issues make their way to company-wide mailing-lists (or are linked from internal meme websites -- you know who you are), they may accumulate +1-spam if no voting system is put in place. As such, I believe GitHub's ability to move upmarket and satisfy its larger customers is actually aligned with implementing the features requested in the "Dear Github" letter.
Anecdote: I switched back from a kindle after 2 years. My kindle broke in the middle of a thrilling novel (The Magicians by Lev Grossman, highly recommended), and I decided to buy it hardback. Soon enough, I decided to not bother getting my kindle fixed -- paper books felt so much more focused, more visceral, and more engrossing.
I'm not sure it's inherent. This may be a generational thing -- I grew up on paper books. Still, one data point.
The payments team enables Square to move money. From developing infrastructure to working with external partners, we find the best ways to move money across different networks and countries in a way that is cost-effective, available, scalable, secure, and forward-looking.
As a software engineer on the Payments team, you will be responsible for designing, building, and maintaining the Payments Platform services and infrastructure that move money for Square. You will be deeply involved in the technical details of building highly available and reliable services, while also working with product teams to enable Square to rapidly build new capabilities for our merchants and buyers all over the world.
Uber and Lyft don't provide per-ride accounting for rides for this reason. I think spotify could get away with "N plays - total $X" in this case, especially since user privacy is at stake. Also the %30 cut is extremely easy to model -- a user that pays $10 with a 30% cut is like a user that pays $7 without one.