joncalhoun

Have you ever tried to maintain a popular OS project on Github? Github issues feel great until you start using them at scale, and then they start to fall apart without some structure. This is especially pronounced in open source where many issues come from people who aren't familiar with what information you need in an issue to quickly resolve it.

I don't think the authors are requesting that this be made mandatory for all repos, but instead they just want the option to set up rules for repos they maintain. As someone giving up their free time to offer software for the rest of us, it seems only fair to let them set the rules about what they need before they can resolve an issue.

The biggest issue I see OSS maintainers running into is that they likely aren't the voice that Github listens to most anymore. If they can get some companies that pay for Github Enterprise to sign their letter as well that would likely help prioritize these features.

I believe this is a pretty common thing based on personal experience.

Some feedback on that regard - if you could note line numbers or anything really w/ some of these it would probably help more than just messages. Eg "Concatenated strings in HelloWorld.js#12"

My guess would be they are covering their bases legally.

I have heard several stories from small business owners who fire an employee who was stealing or committing some other crime, but they don't actively tell anyone who calls for a reference because they don't want to open themselves up to legal issues.

Even if Stripe can prove that the person did this, potential lawsuits could be incredibly distracting and expensive.

Would you pay money to exercise those options?

If you don't expect them to succeed then staying a full year for the options is pretty pointless, since they typically expire in ~90 days after you quit.

The problem with positions that pay a commission of sale price or new job offer is that they are great at convincing you that everyone is on your side when they likely are not.

For example lets assume a recruiter can only find job offers for 1 candidate at a time, and it takes on average:

- 1 week of work to find a 10% better offer

- 2 week of work to find a 40%+ better offer

It would seem like that 40% better offer is definitely worth the work, but for the recruiter it may not be.

If engineers makes say $150k, and the recruiter gets 10% of their new salary, they would make $16.5k from 1 week of work, or $21k from 2 weeks of work. If they can turn 1 candidate per week at $16.5k they will end up making more than if they spent 2 weeks per candidate, so they have little to no incentive to actually get you a better offer if it takes more work.

Not to mention recruiters are more likely to work with companies multiple times per year and an individual maybe once per year, so it is likely in their best interest to help each company get the best price on a candidate rather than help the candidate get the best offer possible.

A few potential downsides to an employee not believing:

1. If they are offered an identical position at a company they believe in, they will leave. You won't be able to do anything to keep them around, so you have less ability to retain valuable employees. Hiring and training new employees is expensive.

2. They won't push back when bad decisions are made. Would you waste your time arguing about a bad decision if you didn't give a shit about the company? You want people who will work for the best interest of the company. Granted there comes a time when you need people to accept a decision, but you want their to be a discussion around those decisions.

3. They will negotiate for more salary than equity/options, giving them less incentive to help make the company succeed.

4. They are less likely to convince their friends to join the company. Stripe built an incredibly talented engineering team through mostly referrals[1]. You lose that if you are hiring people who won't convince their friends to join.

I'm sure I am missing many others, and all startups may not need a team so dedicated that they would give up their salary, but having a team who believes in your company does have real benefits.

[1]: http://firstround.com/review/How-Stripe-built-one-of-Silicon...

> 4. Haha, I don't want to pay for Pusher right now. Will be working on a self-hosted push solution soon.

I hear great things about Faye: http://faye.jcoglan.com/

You can also get something up an running in Go very quickly that should scale pretty well and might make deploys easy since you can just compile to binaries.

eg: https://github.com/joncalhoun/sockets is a server that just allows POSTs with a message, and relays that message to all websocket subscribers. If you use any of that code be sure to change the hardcoded key here: https://github.com/joncalhoun/sockets/blob/master/main.go#L2... (I don't use this key in prod. It was just a test one.)

Nearly all YC companies that are smaller post their job postings on HN. Check here: https://news.ycombinator.com/jobs (it updates frequently, check it daily).

That said, if your goal is to become a technical cofounder, you are likely going to have a hard time. Very few YC companies are looking for a cofounder, and if they are they would likely look in their personal network first. You mention being an early architect, which is possible, but maybe not before major funding (depending on what you consider major).

Nearly all YC companies avoid hiring during YC, and instead hire after demo day. This is mostly because hiring is insanely time consuming, and during YC they focus almost exclusively on growth and getting the company in the best shape possible for demo day. Many companies also don't have the finances to hire someone until after raising, which happens after demo day.

Regardless, the HN job listings is your best bet.

A few things I would suggest to anyone learning to program:

1. Seek out peers to learn with. You don't need to go to school to find this, but it is a great place to start. Reddit, forums, local meetups, etc are all also good places to look.

The one thing I want to stress here is that you want quality over quantity. If you can find 1-3 people who you work with on a regular basis, that will have a much larger impact than meeting with 100 programmers. You generally want to find people who are around the same level as you are so that you can all learn together and teach one another. This is actually the most valuable aspect of college in my opinion - you start off with a group of peers who are (for the most part) at about the same level as you are, you make friends, and you progress at roughly the same rate. In doing that, you learn to teach one another, learn from each other, and you end up teaching each other nearly as much as the professor teaches.

If you do absolutely nothing else I mention, just do this. Find people to learn with.

2. Learn from as many sources as you can. You already read LPTHW, so now go to codecademy and try the python track, look for (and attempt to solve) more daily challenges on reddit, go to https://projecteuler.net/ and spoj.com to find problems and attempt to solve them. When you run into trouble, use those peers from (1), or if you don't have any yet, post to reddit explaining where you got stuck.

You can even try doing different things - you can try creating a website and follow tutorials on that. The point is you shouldn't read a single book, but you should read everything you can get your hands on.

3. Program constantly. Even if it seems like something you already know how to do, do it anyway. Make sure you can write that code without referencing a single book or snippet of code. If you have that, look for something else to code and see if you can do it. Tweak your code to see if you can solve the problem in another way.

My guess is if you aren't coding at least 15 hrs per week, you likely aren't coding enough. Programming isn't something you can do 1 day a week and get great at. People who get great at programming get consumed by it. Every great programmer I know spent 10+ hours every week working on side projects, learning new things, and simply coding. The bad programmers I know are the ones who only coded when they had homework or some other assignment, and the difference is astonishing.

4. Don't just program mundane things (eg formatting HTML and CSS), but try to solve new problems. This is why I mentioned spoj, project euler, and suggested learning from as many sources as you can. Solving new problems will teach you how to be a better problem solver, and you also need to practice expressing your solutions to a problem in code.

Now if you truly want to solve that problem, feel free to email me - my HN username @ gmail.com - and I will be happy to try to help you break it into smaller parts and solve it.

I suspect that if HN had been around when Google was raising we would have read the same type of comments there.

Based on the numbers in the article, they could very well be in the billions of rev within a few years if they can maintain the growth.

Do you have the source for the quote?

You don't need to exit to stop missing out on your family life. Some people may choose to focus exclusively on work, but there are plenty of founders who have a life outside of work long before an exit/ipo event.

I 100% agree with this, but just to play the hopeful optimist:

Is it possible there was a misunderstanding and the CEO meant he needs a decision from you so he can move on to their second best option if you say no?

I can understand their perspective if this was the case. They likely need to give everyone who applied quick responses, and some of those responses depend on whether you accept the offer. They also need to fill a role and it is generally assumed that someone applying for a position wants it and can decide quickly. You would be equally upset if a company listed a position they might be hiring for, but advertised it as a real opening.

Not faulting your decision making process, but have you kept track of the startups you declined offers from?

I would be curious if that paradigm changes in 10 years, not that I will remember to ask you :D

I don't know if you will see anyone openly stating how much they walked away with, but you can do some basic math to figure out that this is very plausible.

Take Stripe, valued at $3.5b[1]. $1m / $3.5 b ~= 0.029%, so any employee who vested at least 0.029% (after dilution) is a paper millionaire, and chances are their early employees have more than 0.029% equity vested.

[1]http://www.bloomberg.com/news/articles/2014-12-02/apple-pay-...

We (nomadbits.com) have been using it and everything has been great so far.

We help companies with APIs improve their developer onboarding process, which means we invoice both monthly services (like creating and maintaining high quality API libraries), as well as one-off consulting (like updating documentation and creating "Getting Started" guides), and Paid has been great for both use cases.

Do you have any specific questions?

Full Disclosure - Paid is a customer of ours as well, so we may be slightly biased :D

I would assume it is when a 500 char message is broken into 4 consecutive tweets, or something along those lines.

I'm not asking this to be snark, but because I am still not seeing a major difference.

For example, take a math textbook. Generally they are broken into subjects (eg circles) and then that topic is broken into lessons (eg circumference or area). Each lesson provides tactics & formulas for solving problems, examples of applying them, and a problem set to practice with.

In my experience this is basically what a teacher would present in the classroom, with the exception of their samples being more interactive, and teachers having the ability answer questions.

Were you thinking of another type of textbook? I can see how this may be different for history or literature textbooks, but to me that just means that said textbooks are doing a poorer job of covering everything they should. I think a textbook shouldn't just cover content, it should facilitate learning the content.

I believe this is typically called "reverse vesting", and it isn't incredibly uncommon, but I have only seen it with small (pre-series A) companies.

My (very basic) understanding is that this works fine early on, but once a company reaches a certain size & valuation it becomes hard to continue.

Sam covers this briefly with the prediction near the bottom about bitcoin.

My favorite from the source:

If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done. - Peter Ustinov

I completely agree that more shared lesson plans would be valuable, but as someone who has little experience teaching - isn't this generally what textbooks are meant to do?

I realize teachers don't just go over what is in the textbook verbatim, but I would imagine they are intended to set a pretty reasonable guideline for what material should be taught and in what order, so I guess my real question is, what are lesson plans plans to you, and how to they work alongside textbooks?

I would respect a company significantly more if this is how the negotiations started. It addresses their need to determine if their range is on par with the market rate, and it allows both parties to minimize wasted time if they aren't.

Sadly I rarely see this happen in practice. It would be nice to see studies about how this affects the average cost to recruit a new employee.

I don't think the takeaway here was meant to be "lame ideas turn out to be visionary."

If anything, I would say the takeaway is that many ideas that seem lame are dismissed without truly understanding their potential, and that PG has made it a point to spend more time exploring their potential before deciding they are indeed lame.

It's too bad Ticketfly doesn't have a bug bounty program. That payout would have been interesting.

I mentioned this in another comment, but this is why I would encourage consumers to only take a discount like this from reputable sellers.

eg I would gladly take a 2% discount with Amazon, as it would save me hundreds over time.

On the other hand, if I were trying out a new SaaS product I would start with a credit card and opt to use BTC once I trusted the company and their product, much like I wouldn't buy a 1 year subscription for a 10% discount without first using the product for a month or two.

This boiler plate code seems pretty bad to me. It is almost as if it was designed to trick candidates by giving them access to data they aren't supposed to use.

The problem clearly states "The game board is hidden from us" yet the boiler plate code gives a developer access to the size of the board as well as the current position. It is as if the interviewer asked carpenter to solve problem A then gave him boiler plate code for problem B.

First, Paypal doesn't just have a one time implementation cost. For example, refunds being limited to 60 days on Paypal will cause issues over time.

Even if the cost was fixed and upfront, a Paypal integration isn't an intelligent thing to prioritize for most startups. There are likely hundreds of other things a startup could do to increase its revenue by more than they would save in CC processing fees, so they should focus on those things first.

Eventually a Paypal integration will make sense, but likely not for a processing discount. Instead it will become useful for international payments, and even then most startups have enough headaches with Paypal that they choose to keep Stripe as the default checkout option, and use Paypal as a secondary option.

Would you do it for a percentage greater than your CC rewards if you trusted the seller?

For example, Amazon has never screwed me on a single purchase. If I have an issue they fix it, which is a large part of why I often pay 5-10% more for products on Amazon.com instead of XYZ.com. Would you use BTC for a 2% discount with sellers like this?