cubes's comments

Robotech, specifically Macross. I know there have been a couple attempts, but I haven't seen one that scratched the itch. I want variable controls depending on the mode of the Valkyrie/Veritech.

1. The job of an employee at a for-profit company is to create business value. This is often lost on engineers and other technically focused startup employees. Working on a project that you consider interesting or of technical merit is a waste of time if it's not creating business value.

The wrinkle here is that it's not always obvious what projects will create business value. Unfortunately, if you're not in an organization with deep pockets and a long time horizon for projects to succeed, it's almost always a better business decision to work on projects that have a direct link to creating business value.

2. Using a technology because [insert large successful company or startup here] uses it well at scale is almost always the wrong decision for a startup. What works for Google, Meta, Uber, etc. will likely not work for your startup until you reach a certain critical level of scale.

3. Headcount is vanity metric. If a company is proud that they have a large team, you should probably run. Employees cost money and employee salaries count toward OPEX vs. CAPEX. What matters is revenue per employee, but many startups are pre-revenue.

4. Scaling your organization or technical stack before you have product market fit is a waste of time. Silicon Valley history is littered with dead startups you've never heard of that burned through their runway building over-engineered systems designed to scale to meet the demand of users that never came. The same is true of startups that built out massive sales departments before they had a product that people wanted to buy.

I've used both Markdown and RST extensively. I feel RST has a steeper learning curve than Markdown, and that can be an obstacle to a successful documentation culture at an organization.

As a former colleague liked to say, "The bar to authoring documentation needs to be so low you can trip over it."

This seems reminiscent of the (in)famous R.I.P. Good Times deck that Sequoia distributed to there portfolio companies back in 2008: https://articles.sequoiacap.com/rip-good-times

I've been there.

What worked for me was talking to my manager, and arranging to unplug by taking a significant amount of time off. For me, this was two weeks initially, which I extended to three. IMO, three weeks is the minimum I would consider taking if I get into this state again.

If your manager is a good one, they will support you. If your organization is a healthy one, your team will understand and empathize.

Burnout is real, and, in my experience, it's unlikely to resolve by staying the course.

Python 2 and 3 or 3 only? I looked for this on the linked site, and it wasn't immediately obvious.

That's super helpful. I'm currently at Eventbrite, and we're probably in the same order of magnitude.

How fast does Pysa typically run? If I want to run it as part of my CI system, how much additional time might I expect it to add? Obviously this varies from code base to code base, but I'm curious what the experience at Instagram is like?

> So how do you get into the habit of creative thinking? > > Well, the best way is to just do it!

Such actionable advice! Much wow!

Congratulations Todd and team!

Wait, what? You didn't take AMT into account? Because I have colleagues that AMT has nearly bankrupted, and who spent years having their wages garnished by the IRS because of it.

Feel free to edit your post so as not to send people to the poor house.

I lean toward the 13" Air. My current work laptop is a 15" Macbook Pro, but I have an Air at home. If you don't need the larger screen, which I don't because I plug into at least one extra monitor most of the time, the Air is a nicer package. Less to lug to and from work. The other caveat is that, if you need to run multiple development virtual machines for testing, the 4GB memory max for the Air is somewhat limiting.

You're also missing the fact that joining an early phase startup carries non-trivial risk, and part of the reason early equity grants are large is to compensate for the risk one assumes by joining.

It's a potentially neat idea, but keep in mind that many people already use their email for such a purpose. Rather than a specialized app for managing and tracking pitches, consider building something that integrates into mail clients ala Rapportive?

SES is extremely easy. Unless you actually care about deliverability. Deliverability on the modern internet is hard. SES does not handle this. If Mailgun handles deliverability well, that alone is worth the price. Making it programmable is awesome.

Eventbrite is hiring in San Francisco. It's a fun place to work, and we've got lots of openings: http://www.eventbrite.com/jobs/

Email [email protected] if you're curious.

It's kind of organized ad hoc. If you're interested in putting one on, I'd suggest contacting the organizers. :)

What do you mean by large scale? The first San Francisco event featured 20 trucks. The most recent Brooklyn one, which is where it originated, had 30.

Some informative links, in case you haven't seen them already:

* http://www.quora.com/What-caused-Foursquares-downtime-on-Oct...

* http://blog.foursquare.com/2010/10/05/so-that-was-a-bummer/

* https://groups.google.com/group/mongodb-user/browse_thread/t...

Someone on this thread suggested that Foursquare's performance problem is related to the calculation of badges. I'm not sure where this idea came from. I haven't seen any mention of the issue being related to badges in first or secondhand sources.

That said, Mongo DB's map/reduce operation would not be a reasonable solution at this time. Mongo DB's map/reduce performance is, at present, somewhat lacking because it runs via the javascript engine which is currently single threaded. I know there are plans to improve performance of Mongo DB's javascript engine by switching to V8, but I don't know if V8 is multithreaded.

Often design decisions that look bad in hindsight get baked in early. By the time you realize that an alternate design would yield better performance, there may be too much data to migrate so you just have to live with it.

While luigi's statement is a little extreme, I think the gist is right. Yes outsiders can offer advice on a system, but it's really difficult to offer sound advice without specific details of the system. Perhaps outsider advice shouldn't be dismissed outright, but it ought be taken with a grain of salt.