MalcolmDiggs

* San Francisco Public Library has fast wifi, private meeting rooms, etc. I worked there for months after I got sick of giving Regus all my money.

* WorkShop Cafe (http://www.workshopcafe.com/) is awesome, and charges you 2 - 3 bucks an hour to work from their space.

* There are lots of free cafes, hotel lobbies, bookstores, parks with free-wifi, and other places to work.

If none of those work for you, check out WeWork, RocketSpace, NextSpace, Sandbox Suites, etc. There are so many co-working spaces available, that I'm sure you'll be able to find one. They typically have a waiting list for private offices, but there's enough turnover on the open-desk areas that you can normally squeeze in.

* Introduction to Algorithms, by Cormen et al (aka "CLRS")

* Any of Robert Sedgewick's books on Algorithms ("Algorithms is C++", "Algorithms in Java", etc)

* The Art of Computer Programming by Knuth.

* If you want a more math-focused approach, Knuth has another book called "Concrete Mathematics" which might be worth your time.

* If you want something fun and accessible check out "9 Algorithms that Changed the Future" by MacCormick

2. Square for Triangles

3. Tinder for Forests

4. Uber for Poop

1. Old money. In California, the VCs and Angels I met were mostly self-made; they had cashed-out of the dotcom boom, or recently been apart of an IPO. They were all 20 - 40 somethings. NY is very different. I had never been exposed to the "country club" / "summer house in Nantucket" / "trust fund" scene before. It definitely feels like a different planet sometimes. So if you're raising money, be prepared to have conversations with the type of people you might have thought didn't exist anymore.

2. No echo-chamber. For the best and brightest in NYC, tech is often NOT the obvious choice. In many circles, going to the tech scene, (let alone the startup scene), is seen as odd. ("Why didn't you go into finance?" "Why didn't you go into law?" "Why aren't you a doctor yet?"). The greatest minds of the generation are becoming MOTUs (Masters of the Universe) at hedge funds and big banks. They're making a ridiculous amount of money, and really have no interest in this little tech thing we're doing. Talking about your startup in NYC feels odd sometimes. You're not praised or catered-to like you are in SF. Nobody really cares what you're doing, and nobody takes you that seriously until your run-rate is the hundreds of millions per year. It's a nice change in context actually. The SV echo chamber is gone.

Besides that (and NYC's insane weather), things are pretty much the same. Lots of talent, but it's expensive to hire. Lots of businesses, some good, some bad. Lots of VCs and Angels. Terrible rent, good food, etc.

Is it worth the move? Yes. Simply because when you move to NYC you may be seated at a cramped restaurant shoulder-to-shoulder with your next investor; and in SF you might see @sama walking down Market street. That kind of "right place at the right time" moments are more rare outside of those cities. Which coast you choose is entirely up to you; either way you're making a good move.

Pick 2 hosting solutions you like (I'd recommend checking out AWS, Linode, Rackspace, and GCP), and build your systems redundantly on both. If they don't share infrastructure/datacenters, the odds of them both failing at the same time are small enough that it's not worth worrying about.

If it's an issue of finding clients, that, in my experience, has little to do with the technology choice. I freelanced in PHP for over 5 years, and I rarely (if ever) talked "tech" with clients. I kept discussions much more high-level than that. They didn't care how exactly I was building their projects.

Definitely check out RFP's (requests for proposals). Government agencies, universities, etc put them out. Start replying to them, and you should find plenty of work.

1. If you'd simply read the link (which you clearly have not done), you'd understand that a k-value of 2.0 means that each customer referred an average of 2 new customers. I never said "probability". You did. Yes, probability above 1 is impossible, which is why I never used that word. You clearly conflated the two, which is your error, not mine.

Here's why I said "likelyhood" (likelihood) instead of "probability": http://stats.stackexchange.com/a/2645

"...the likelihood function does not obey the laws of probability (for example, it's not bound to the [0, 1] interval). "

2. Reading-comprehension. It's not that hard.

2. Nobody said it "has to be" paid. The OP asked how "you" market your startups, and I told him what the companies I've worked with have done, in my experience.

I'm disappointed guys...

They'd need a reason to do it. So clearly the pitch above failed to give them a reason.

1. Initial external paid marketing (in the form of Adwords campaigns, email blasts, facebook ads, affiliate programs, etc).

2. Reworking the product until the "viral coefficient" is higher than 1.0. The viral coefficient(aka "k-factor" or "k value"), is basically just the likelyhood that one existing customer will refer another customer. So if your k-factor is above 1.1 for a given period, your initial userbase will grow over each period with no additional marketing needed.

In practice however, few startups ever reach a k-value of 1, so many rely on a combination of virality and traditional paid marketing in perpetuity.

[1] https://en.wikipedia.org/wiki/K-factor_(marketing)

It's a bit like perceived scarcity. Building a flashy portfolio website really only says two things: "I have free time on my hands", and "My demand is so low I have to put effort into advertising". Sure, if you're just getting started, that might be the brand you wanna build. But as you gain momentum, having less of a public brand is often better for business than having more.

It's counter-intuitive, I know; and maybe my experience was colored by the freelancers I happened to know at the time. But it convinced me enough that I took down my website while I was freelancing full time, I only put it back up after I quit, (to use as a resume to get full time job.) Removing my online presence did wonders for my business, and that's why I recommend it.

Yes they can really help you organize larger projects easily. With variables, you only have to write things once. If you change your "black" from #000 to #1a1a1a, for example, that's one change instead of dozens. Nesting is another useful feature that helps you separate one page/module from another, and keep everything contained. Mixins and functions are super-useful if you find yourself re-writing the same stuff over and over. Also, the preprocesing itself is a great way to "lint" your styles (in a surface-level way). If there's a syntax error, the preprocessor will just fail, exposing an issue that might have gone unnoticed if you were using plain css.

But no, they don't help you write the most efficient CSS. So if performance is your goal, you can probably write better/faster CSS if you target each element manually, rather than letting the preprocessor target based on your nesting.

And no, they don't help you alleviate cross-browser issues; that's what auto-prefixers and shims are for. Those are different tools, also useful.

And no, they don't help you keep your css tiny, that's what a concatenators, minifiers, and utilities like "UnCss" are for. Also great tools, but separate ones.

If you want to get all the benefits you can, your CSS build tool will need to include many different phases. Preprocessing is only one phase; but may be an important one, depending on what you're looking for.

Also,if you want to get started, just rename your .css to .less or .scss instead, and preprocess it. Both less and scss are supersets of css, (so all valid css is also valid less and scss). You can write vanilla css inside a less file with no issues. That way, if the urge strikes you to experiment with the features of the preprocessor, you can do so immediately.

Yes, this is correct.

"Is it reasonable to expect the company to give me access to the full cap table?"

No.

But, it IS reasonable for your contract to state what percentage of the fully-diluted capitalization of the company your stock options are granting you the right to purchase (at the time of the writing, or at a predetermined time in the future, like at the end of an round).

All that being said: All early employees are going to get diluted eventually (in most cases), and nobody has any way to predict how much dilution you're going to experience over time.

So, while it may make you feel better to know exactly what your options would be worth today, it's kind of irrelevant to what they'll be worth once you pass your vesting cliff.

The best protection, in that regard, is to only work with people you trust. If you're worried about being screwed-over by these people, and you haven't even started working there yet, that might be a bad sign.

It's not black and white, and no library is going to solve all the issues. A pragmatic JS engineer is going to have to use many different tools in their toolbelt on a routine basis, it's just a matter of choosing the right tool for the job (which includes taking into account the environment you're working in and the code that already exists).

But in general, in my experience, callback hell is often a sign of an upstream design-pattern issue. If the procedure you're writing needs to call a series of 20 functions, in sequence, (and wait for them all to callback one after the other) you can probably implement it in a clean way that doesn't require your code to move evermore to the right. Frameworks like Express (which passes around "next"), and Mocha (which passes around "done") set great precedent of alternative ways to conceptualize those kind of issues. Achieving this in practice often means writing a combination of promises, callbacks, and other things.

Each hiring manager should be able to quickly scan through your CV and check the mental boxes in their head, so that they can move your candidacy on to the next phase. That's really all the resume needs to do. So streamline each resume you submit to make that process as quick and painless for the hiring manager as possible.

Later on, when you're getting to know the company (and they're getting to know you), that's when you can bring in your multitude of experiences that aren't directly related to the job. But there's no reason for that initial submission to be an exhaustive list of all your great qualities.

AWS is great to the tune of $15,000 https://aws.amazon.com/activate/

GCE is great to the tune of $100,000 https://cloud.google.com/developers/startups/

I'd recommend doing both options. Burn through your credits on both platforms first, then make a decision about which one you like best... or choose none of the above!

I don't work with friends, and I don't make friends at work. I keep those two areas of my life completely separate.

The benefits are: you can make whatever business-decisions are prudent without worrying about upsetting a friendship, and you can make whatever friendship decisions you want without worrying about how it effects your business.

I have a similar mantra for business & family, never mixing the two.