Sounds like the setup at WeWork offices. Granted, it's a co-working space instead of a single company's office, but I found it to be a good mix when my company worked out of WeWork Golden Gate last year.
>If he's willing to do that, then he'll have to exercise what he already has vested.
Not necessarily. It depends on the terms of his or her options grant. Many companies give employees a 10 year exercise period after they leave (advocated by Sam Altman: http://blog.samaltman.com/employee-equity).
From reading the post it seems like her dad made this decision for her, which feels a bit off to me. While the school may not have been serving her needs intellectually, I can see a strong argument for sticking it out socially. Then again, if she was already isolated or had strong friendships outside of school, maybe it's not such a big deal. Would enjoy hearing Katya's side of the story.
As an outsider to scaling issues, what strikes me about SoundCloud's struggles with shedding their Rails past is how similar their problems sound to Twitter's problems. Granted, a microblogging service has a different set of concerns than an audio delivery service, but the pain is the same.
Going out on a limb, perhaps this similarity contributes to the reasoning for the Twitter/SoundCloud acquisition rumors: more exciting problems for Twitter engineers to solve now that they've tamed their own beast? Or to put the theory in a business light, Twitter engineering leadership may have confidence they can architect SoundCloud better than the SoundCloud team has done.
You're making a big assumption, which is that all those good engineers love to live in Silicon Valley and want nothing more than to stay in the area their entire lives. For each one of the engineers who feel that way, there's someone who worked here for awhile but now dislikes the area for one reason or another. Enticing good people to spend a few years in Berlin working for a company like Soundcloud might be easier than you think.
A well-articulated point, but I disagree with ruling out the concept on this basis. Affordances could be made to make this sort of concept more usable. For example, the pinch could work when the user is approximately within the icon dimensions (e.g. only one finger is actually on the icon, the other is close to it) rather than the "strict" implementation requiring both fingers to be within the icon's dimensions.
I'm familiar with a couple of vendor solutions but this is the first platform-agnostic one I've come across. Looks promising, excited to check it out.
We used UserVoice's iOS SDK for awhile, then decided to drop it when we started receiving crash reports for the SDK. It worked well when it didn't crash, though. :)
Right now we use a plain old email form, with some meta information prefilled in the body of the message. It's admittedly a bit old school, but it works.
We also looked at the ZenDesk iOS SDK since we're in the process of switching to ZenDesk. However we were turned off by the lack of activity in that repository.
FTA, "To make matters worse, the government won't disclose its reasoning for requesting the gag, effectively shutting the public out of the courthouse without any explanation."
It's idealistic to think that no information should be able to be quashed by the government, but it's not idealistic to think that their motives for doing so should be made public.
Not sure it should be obvious you don't. Pull requests are especially well-suited for a team environment, but using PRs in a solo project can still give a higher level of structure to the progression of your code. Gives you an opportunity to explain why you're doing what you're doing.
Depends on whether or not quality of the product is a factor in your cost calculations. It should be, and for many startups and solo developers, it absolutely is.
> You have 0 control over distribution though, which is pretty important to me.
Simply having to wait a week to get approved for the iOS App Store (and less on Android) doesn't constitute 0 control over distribution. You can still release the app to the store when you want, if you plan ahead, and pull it whenever you like. Less control, yes, but not zero.
Also, how is this different from writing a non-native app? The same rules apply to distributing web apps if you want them to be in the store. True that you can release it as a website whenever you want, but that's not really the same thing.
I agree that you must put in time to get better, but I think the difference with programming is that more hours does not necessarily result in getting better. Actually, now that I think about it, maybe that's no different than the examples you provided. If you practice violin 14 hours a day, will you really be better than you would if you practiced 8 hours a day and spent the other 6 doing other things?
When programmers get beyond a critical daily/weekly threshold, putting in more hours hurts more than it helps. The brain gets tired of solving problems, and when that happens, pushing yourself further is not the answer. The answer is to do something else, especially something involving physical activity, to allow your brain time to recover.
I believe that many programmers fundamentally do not understand this concept, thus they drive themselves crazy trying to push harder and harder. Yes, you may write more lines of code that way, but at what cost?
No, they are crazy. Reverting someone else's changes without explaining why is crazy. No one is telling these people they can't explain their actions.
If any of these people has a disagreement with a co-worker over the co-worker's changes, it's their duty as a fellow employee to explain to the co-worker why they disagree, or at least explain to the manager why they disagree with the change, so that the manager can explain it to the co-worker. But just making the change and then threatening to quit... that is most definitely crazy.
I'm not sure surprised is the word I'd use to describe their sentiment. I'd guess rather that they originally planned to back down at the first sign of legal threats. Popcorn Time has been circulated as an experiment, not a business, and in that sense it was a success. Also, the code isn't going anywhere, so it's not as if all this work was for nothing.
Yes, and the fact that the state lies within a country now notorious for having a dysfunctional Congress, the same body that pulled the rug out from under SSC's original proposal in the 90s.