For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | adeebshihadeh's commentsregister

"Open source has always worked on a system of trust and verify"

Not sure about the trust part. Ideally, you can evaluate the change on its own.

In my experience, I immediately know whether I want to close or merge a PR within a few seconds, and the hard part is writing the response to close it such that they don't come back again with the same stuff.

(I review a lot of PRs for openpilot - https://github.com/commaai/openpilot)


Cool to see you here on HN! I just discovered the openpilot repository a few days ago and am having a great time digging through the codebase to learn how it all works. Msgq/cereal, Params, visionipc, the whole log message system in general. Some very interesting stuff in there.


When there's time, you review, when there isn't you trust...


That's the issue here.

Even if I trust you, I still need to review your work before merging it.

Good people still make mistakes.


What is the definition of trust if you still have to verify? How does "trust" differ from "untrust" in that scenario?


trust resudes the verification I suppose. Getting a PR from a trusted contributor would probably have me do a quick scan for obvious mistakes. And they'd know to keep the PR's small and on the right branch to help facilitate a scan.

a new person with a big idea on the slightly wrong (but reasonable) channel would have more work in verification.


What's the rush? Building good things takes time.


deadlines, money, attention. The usual things in industry.


> In my experience, I immediately know whether I want to close or merge a PR within a few seconds

Not sure this is what I want to hear about a system that people entrust their lives to on the highway…


Why? I don't appreciate comments that cast doubt on decent technical contributors without any substance to back it up. It's a cheap shot from anonymity.


I'm not the parent but if you know you want to merge a PR "within a few seconds" then you're likely to be merging in bad changes.

If you had left it at know you want to reject a PR within a few seconds, that'd be fine.

Although with safety critical systems I'd probably want each contributor to have some experience in the field too.


Sounds like you misunderstood. They didn't say they are merging PRs after a few seconds. Just that the difference between a good one and a bad is often obvious after a few seconds. Edit: typos


Exactly, every PR starts with:

1. What’s the goal of this PR and how does it further our project’s goals?

2. Is this vaguely the correct implementation?

Evaluating those two takes a few seconds. Beyond that, yes it takes a while to review and merge even a few line diff.


I'm not sure there are many ways to interpret "I know whether I want to merge a PR within a few seconds".


Yet I also agree with GP.


"*WANT* to close or *WANT* to merge". Not WILL close or WILL merge.

You look at the PR and you know just by looking at it for a few seconds if it looks off or not.

Looks off -> "Want to close"

Write a polite response and close the issue.

Doesn't look off -> "Want to merge"

If we want to merge it, then of course you look at it more closely. Or label it and move on with the triage.


What kind of things would you like to hear? The default is you hear nothing. Most black boxes work this way. And you similarly have no say in the matter.


you can have fun while solving real problems. it might even be a requirement


comma four, baby!!

glad you're enjoying it :)


we hire through https://comma.ai/leaderboard and i think our interviews are relatively chill

never heard of anyone asking for anything like that


This was back around 2017-19 (can't remember the exact year), but it was definetly pre-Covid and left a bad taste in my mouth, just like Jane Street and FTX at the time - especially given that your then competitor Deepscale didn't have that style of interview.


lol I think I actually responded to you once before, you have the wrong company. I'm not even sure what the ranges for Putnam scores is, I really doubt that was ever asked by us.


hey, CPO of comma here.

happy to answer questions about the four :)


roughly speaking, the latest policy models trained in it are indistinguishable from openpilot release on 15-30 mins of driving, but you start to notice the subtle issues (e.g. turn cutting) on a few hours of driving.

we'll definitely do some good writeups and/or talks once it's shipped.


correct, we’re a little over 20k total


comma.ai | Software + Hardware Engineers | San Diego, CA | ONSITE

Our mission is to solve self driving cars while delivering shippable intermediaries. We build and sell the comma 3X to a growing fleet of users and get back 3M minutes of driving data every week for training openpilot.

Some background on what we're hiring for: https://blog.comma.ai/refactoring-for-growth/

https://comma.ai/jobs

- Systems Software Engineer

- Full Stack Software Engineer

- Electronics / Hardware Engineer

- Controls Engineer

- Designer


comma.ai | SW/HW Engineers, Designer | Full-time | On-site| San Diego, CA | https://comma.ai/jobs

We're the Android of self-driving cars.

-> Second largest fleet after Tesla, 54% miles engaged

-> Open source, profitable, and lots of cool problems to work on

-> 21 people, mostly engineers: https://blog.comma.ai/refactoring-for-growth

Our hiring process:

* programming challenge or bounty

* quick technical phone call

* paid, on-site micro-internship

Try our programming challenges -- https://comma.ai/leaderboard


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You