mattspitz

Hi! I'm the head of engineering at Vanta, and as of earlier this year, we do support long-term remote. You may have talked to us right before then.

Feel free to reach out again if you're interested and interviewing -- we're still growing quickly!

Shaking up big dairy would make big butter, no?

<Insert gratuitous joke about LibreTaxi vs. GratisTaxi here>

Yes, though the recruiting for interns in NYC goes through San Francisco for now: https://www.dropbox.com/jobs/listing/190707

DROPBOX NYC | NEW YORK CITY | ONSITE

We're a small office working on technically difficult problems across the stack that are critical to Dropbox's success. You'll have an opportunity to make an impact on both our 500+ million users and our ~60 person office and culture. We work on hard problems that matter, and we've built an excellent community here.

--

More specifically, at the moment, we're looking for:

* Product designers: https://www.dropbox.com/jobs/listing/93283

* PMs: https://www.dropbox.com/jobs/listing/485177

* Product infrastructure engineers: https://www.dropbox.com/jobs/listing/200990

* Generalist engineers: https://www.dropbox.com/jobs/listing/91340

--

It's been an incredible experience to build this office, and I hope you can join us!

Dropbox NYC | New York | Onsite

We're a small office working on technically difficult problems across the stack that are critical to Dropbox's success. You'll have an opportunity to make an impact on both our 500+ million users and our ~60 person office and culture. More specifically, at the moment, we're looking for...

...full-stack engineers interested in improving users' experiences with content in Dropbox: https://www.dropbox.com/jobs/listing/199641

...backend/infrastructure engineers interested in bringing Paper (https://paper.dropbox.com) to Dropbox's scale: https://www.dropbox.com/jobs/listing/200990 It's been an incredible experience to build this office, and I hope you can join us!

Dropbox NYC | New York | Onsite

We're a small office working on technically difficult problems across the stack that are critical to Dropbox's success. You'll have an opportunity to make an impact on both our 500+ million users and our ~60 person office and culture.

More specifically, at the moment, we're looking for...

...full-stack engineers interested in improving users' experiences with content in Dropbox: https://www.dropbox.com/jobs/listing/199641

...backend/infrastructure engineers interested in bringing Paper (https://paper.dropbox.com) to Dropbox's scale: https://www.dropbox.com/jobs/listing/200990

It's been an incredible experience to build this office, and I hope you can join us!

Dropbox NYC | New York City | Full-time / Onsite

At Dropbox NYC, we're a small, growing team making a big impact on Dropbox's products and infrastructure. We work together on wholly-owned projects in NYC ranging from web/mobile product engineering to lower-level infrastructure. For example, the infrastructure team for Dropbox Paper (https://www.dropbox.com/paper), entirely based in New York, is responsible for bringing this exciting new product to the scale and stability required for general release.

Working on challenges that only a big company faces in the setting of small office has been an incredible experience, and we've only just begun.

For more information about open positions at Dropbox NYC: https://www.dropbox.com/jobs/nyc

Dropbox NYC | New York, NY | Mobile, Web, Infrastructure | Full Time, Onsite

We're a small team working together on products and infrastructure critical to Dropbox's success. I've been here since Dropbox's first day in NYC, and I'm very excited about the caliber of our team and the impact we've made in just the last year. The adventure has been amazing thus far, and it's only just begun.

Please join us!

SWE: https://www.dropbox.com/jobs/listing/91340 SRE: https://www.dropbox.com/jobs/listing/91483

Dropbox | New York City | Software Engineer / Site Reliability Engineer | ONSITE

We're a small team building the foundation for Dropbox's first engineering office outside San Francisco. We work on impactful projects that are essential to Dropbox's success. It's a lot of fun, and we've only just begun.

- SWE: https://www.dropbox.com/jobs/listing/450

- SRE: https://www.dropbox.com/jobs/listing/761

Also hiring in...

- SF: https://www.dropbox.com/jobs/listing/143

- Seattle: https://www.dropbox.com/jobs/listing/661

- Tel Aviv: https://www.dropbox.com/jobs/listing/829

Dropbox | New York City | Software Engineer / Site Reliability Engineer | ONSITE

We're a small team building the foundation for Dropbox's first office outside San Francisco. We work on impactful projects that are essential to Dropbox's success. It's a lot of fun, and we've only just begun.

- SWE: https://www.dropbox.com/jobs/listing/450

- SRE: https://www.dropbox.com/jobs/listing/761

Also hiring in...

- SF: https://www.dropbox.com/jobs/listing/143

- Seattle: https://www.dropbox.com/jobs/listing/661

- Tel Aviv: https://www.dropbox.com/jobs/listing/829

It isn't so bad! Making bucks, getting exercise, working outside...

Dropbox | New York City | Software Engineer

We're a dozen engineers building the foundation for Dropbox's first office outside San Francisco. We work on impactful projects that are essential to Dropbox's success.

https://dropbox.nyc or email me directly, mspitz@dropbox.com.

Also hiring in SF, Seattle, and Tel Aviv.

If you can test everything manually with confidence that every incremental change breaks nothing you've ever thought about prior to the present, I suggest you work on more complicated things. Otherwise, you're mistaken.

The irony is that AngelList allegedly generates funding for real engineering teams.

DigitalOcean is fabulous. It's very nice hardware and not very expensive. No AWS services, but if all you need is root access to an OS image, I can't recommend it enough.

Well-said.

My point was more on shipping new features quickly, not shipping buggy software. It's up to your engineering process to ship solid software. The Play Store just enables your product team to figure out product/market fit ASAP.

This assumes that everyone has equal access to distribution in the app/play store, which is not the case.

Most apps grow organically at first, and at that stage, swift iteration is critical.

Also, there's a difference between shipping buggy software and quickly testing new features.

Did anyone else click this link hoping to have a sort of Star Trek-themed email address or interface?

This is incredibly misleading. Saying that the difference between iOS 4 and iOS 7 is equivalent to the difference between Android 4.1 and Android 4.4 is absurd.

The big jump in Android was from Android 2 to Android 4 (Android 3 was mostly a release for tablets). Sure, there are differences between Android point releases, but they're not as substantial as the "major versions" the chart suggests.

Good points all around.

PhoneHome home doesn't send any data that your application couldn't otherwise expose. It just provides an easier way to do it for the developer.

Regarding sensitive data, Facebook has had issues leaking user tokens in logs, and I imagine they're not alone. The typical way to handle this is to put all the sensitive information (if you have to log it at all) at a certain level and then use ProGuard to strip the calls out of the bytecode when making a production build, but between Android and remote libraries, I found that this involves a lot of whack-a-mole to get a config file that works.

But, if you've got everything through a layer of indirection (using PhoneHome), it's easy enough just to switch on the BuildConfig.DEBUG to decide whether to print to the system log.

Sure, you could route it through Sentry or whatever other logging-type backend you'd like, but the Android library takes care of the indirection and batching for you.

Never punting and always doing onside kicks is nothing new. I've been doing that in NFL blitz for years.

Always going for the 2-point conversion is the real secret.

Can you further explain why raid/replication isn't a backup? Sure, you can't backup beyond what you've replicated (locally or across a network), but for most folks, that should be fine.

Thanks for the summary. I probably should have just written that instead.

Fortunately I have no babies for you to take.

It's nice not having your fingers perched on the keyboard like a bird, right?

How much time is spent trying to install libraries on a Mac? Nothing beats aptitude/yum when it comes to installing software. Homebrew is nice, but if whatever you're looking for isn't in there (for me, pretty frequently), you're stuck either compiling stuff from source and digging through OS X's backwards filesystem layout or running a VM.

Sorry I wasn't more clear. I wasn't trying to make this a Unity debate, and I'm sorry I started one by making that point.

Thanks for the tips, but that wasn't really meant to be the point of the post. I just wanted to point out gnome-settings-daemon if you want to run something other than Unity.

Use pip, http://www.pip-installer.org/en/1.3.X/. Sorry for my assumption.

Replying to everything:

- Good catch on the subdirectories within a git repository. Currently, we'll open the file you end up on with $EDITOR, which isn't necessarily correct relative to your cwd. I'll fix that. - Re: curses cleaning up after itself, I haven't seen that in xterm or terminator. Are you sure that's completeme's fault? Perhaps it's iTerm or emacs? I've never used iTerm and don't have access to a Mac. It could have something to do with this function not getting called: https://github.com/mattspitz/completeme/blob/80328799a000180... - I originally had this writing to your bash history but removed it because it wasn't really executed by the user. This may end up being obviated by: https://github.com/mattspitz/completeme/pull/1 I'd like to have Return open your editor (with history) and something else (Tab?) dump back into your prompt. - I don't know what could cause your misbehavior in emacs with Ctrl+G. I'm using 24.3.1 and can't reproduce it.

Thanks!