Side-project Ideas That Could Get Big | Hacker News Reader

Side-project Ideas That Could Get Big

pioneer.app

61 pointsdanicgross10 comments

> Reply-to-sheet > You often send emails to lots of people where the replies ("yes I can make it!") are collected into a spreadsheet. With your service, you can simply CC XXX@your-website.com and have the replies collected into a Google Sheet. Make it frictionless to get started. No sign-up should be required to create the sheet.

I'm really surprised that evite hasn't done this.

I'm really curious how many people win each pioneer round. I haven't been able to find that information. That's actually the only thing keeping me from participating again (I did the first one and I enjoyed it).

Also your terms of service don't say users are limited to a single account, so could someone create an account for each of their projects?

1. We'll be releasing more info about our first cohort of Pioneers soon!

2. Sure! Just don't do anything you wouldn't do if you were running Pioneer :)

very cool. I'm going to get my application submitted this weekend. I'm looking forward to learning more about the first cohort. My original guess was that you'd select ~10-20 people.

Feedback to the pioneer team :

- remove the country and age columns in the leaderboard page. There's no need for it to be public...privacy.

- we still don't know what the experience of going through the program will be like, maybe have a few people write about their experience?

Questions : - how's the security of the backend used to collect all the info? A simple page going over what you do to secure applicant data will be reassuring.

- how many people applied and how many did you fund?

While these may not seem important to the general public, I'm pretty sure the average HN user cares about it. As some anecdata : this is basically why I have not put in an application.

Thanks

Another point : the privacy policy could be improved. Specifically, sharing of applicant data with 3rd parties. I don't want that at all. When I submit an application, I expect only Pioneer will have access to it. If you want to send marketing emails to applicants that's fine, but sharing applicant info with 3rd parties is not cool. Keep it simple like YC's no bs approach. Thanks.

Why are they against Gmail Auth? What’s wrong with it? I love Gmail Auth. I trust it far above Facebook and Twitter Auth.

There are a lot of personal CRMs already -- I use busycontacts instead of the default Apple contacts and that is one of its functions. Look up a contact and you get the messages and calendar entries about them; you can add notes, etc.

One nice part is it uses standards instead of requiring something proprietary like gmail.

Yes, I always knew that is just a simple side project to reliably measure software engineering productivity. It is probably as simple as counting the lines of code produced in a given day. /s

I think the "side project" framing actually makes this problem more solvable, because you don't have to completely solve every aspect of the problem. It seems likely that developing an easy to measure metric would start to help the issue, which is what Pioneer may be looking for.

E.G., measure the productivity of repo owners (managers/leads) by their lag in accepting pull requests. Measure the quality of submitted code by comparing how often my code is accepted compared to someone else's (w/in the organization/language/community).

From there you could build more of a productivity measurement suite, e.g. maybe connect test coverage and bug reports to specific commits and start to score a coder.

Basically, look at currently-existing data points about coders that a specific team culture believes are important to productivity. Then baseline that against a comparable group, and present reports.

Another trick is to simply measure stuff over time. (This is a bit trickier, due to what you hinted at w/ LOC... but still measures change over time, which is really useful for managers.)

The final thought I have is that it is useful to connect events over time that are related to the same code/feature/branch. If my team's workflow is design/develop/test/commit....gap....deploy to users, then bugs are temporally disconnected from development efforts. Connect things over time in an easy to use report, that has value.

Reply on news.ycombinator.com