joncooper

Both. And low portfolio concentration.

I remember back in the day /dev/audio had bad default permissions on, I think, SunOS, and you could just cat it to a file to record.

Or to do a streaming parse with json.Decoder.

OT, but, I have a 2001 (996) 911 which I bought used for ~$20k in 2009. It's been hassle-free since then and the largest expense has been tires.

Lawyer up. It's worth the $10k it will probably take you to paper this correctly. Since it will be difficult to estimate damages should this not work out, consider writing a liquidated damages clause with clearly spelled out triggers.

John Ratey wrote several good books on ADD/ADHD as well as this one: _Spark: The Revolutionary New Science of Exercise and the Brain_ http://www.amazon.com/Spark-Revolutionary-Science-Exercise-B... - it is pretty good.

Tips for the prospective founding CTO working from a clean slate with a non-technical cofounder:

* Get it in writing, and sooner rather than later.

* Do not work for free. A business cofounder should be in charge of finding money. If they can't get enough to pay you to build a PoC, you shouldn't work with them.

* Work together to set near-term goals for the non-technical party, and assess whether they can deliver. If they can't: beware.

* Do not accept less than a 50/50 split unless the other party has decades of experience in a vertical, glowing references, and an astounding Rolodex. A few years at McKinsey or Bain followed by an MBA isn't worth more than the work you put in to get here. (Although it is meaningful.)

* Check references on the other person and do background work. It's amazing how little folks put into this compared with, say, the amount they put into their first hire. This is a source of much pain.

* Qualitatively, you MUST feel a sense of respect for the other person, and it helps if you find them outright impressive. Again, a source of major pain.

We use Duo at work and it is awesome. Bravo.

Effectively they issue a bond bundled with a bunch of options that may be exercised in exchange for giving up ownership of the bond, "converting" it to equity.

This isn't necessarily driven by a view on the equity valuation. It's more often driven by high realized volatility in the equity, which increases the value of the equity optionality. Correspondingly this decreases the value of the fixed income aspect of the bond, which from the issuer's (Twitter) perspective means they pay less in interest.

Note that "Twitter expects to enter into privately negotiated convertible note hedge transactions". This means that they will buy call spreads to help manage the EPS impact of increasing the fully-diluted share count. Realized volatility and the pricing across strikes of the option chain will be affected.

If you're interested in this, definitely read the book _Suicide_ by the sociologist Emile Durkheim. (Published in 1897). It's an incredibly incisive analysis of several of the flavors of depressive thoughts that smart folks have. One of the top 3 books I've ever read.

http://en.wikipedia.org/wiki/Suicide_(book)

Yes.

I'd love to hear about your startup and/or beta test.

Out of curiosity, does "burner & co" mean the same thing it'd mean in the SF Bay Area, i.e. the Burning Man scene? Or something else?

> My biggest issue with Swift is that there often seem to be too many ways to do things.

This is my biggest issue with the Apple libraries in general. It's an artifact of the software's bloodline running back to the 80s.

Talent != IQ. And I'd argue "smart" != IQ.

How did you identify the vertical that you've successfully targeted?

My understanding is that the Go team isn't opposed to generics, and in fact is quite aware of their value, but that:

- it isn't a priority

- it is a tricky thing to get right in the context of Go

- there haven't been any satisfactory proposals thus far

If this isn't quite right I'd love to be corrected.

Pretty sure most people thought that was a joke.

Another +1 for godep.

Exactly. In either case there's nearly 30 years of libraries to learn to be effective on Apple platforms. (Significant traces of work done at NeXT remain, which started in the mid-80s, I believe.) The language itself is the least of your worries.

That said, I am excited about Swift because the hardest part of teaching new developers to work on Apple platforms is the fact that you need to understand C to write Objective-C.

This is what regulation is for.

Agreed. As you work with the libraries you run across many different ways of doing things, and folks often just use the last one they saw instead of working to understand the options and making a choice on purpose. I'm thinking especially of messaging patterns, event handling (especially gestures), working with the view hierarchy, etc.

Count me in the "happy to not have exceptions" camp.

I am going to require job candidates to read one of these and discuss it with me.

That alone would be helpful. Thanks!

Do any of y'all have an opinion on which of the tools mentioned here is the most robust to junky input?

As an aside, anyone got recommendations on learning the skills scottm01 mentions? "people skills, budgeting, planning, and politics"

I'm working on the Coursera compilers class right now, which is excellent: https://class.coursera.org/compilers-004

The code generation portion of the class covers this material from the other end, i.e. at the point where the AST is transformed into assembly code, and it has been super interesting.

This is obvious in retrospect but wasn't to me beforehand: if you're interested in reverse engineering, it's very helpful to study how the assembly was written in the first place.

Ansible Tower.

A related Quora answer I wrote a while ago:

http://www.quora.com/Investment-Banking/Why-are-there-so-man...