Hacker News new | past | comments | ask | show | jobs | submit | ible's comments login

That product name sucks for Veo the AI sports video camera company who literally makes a product called the Veo 2. (https://www.veo.co)

I tried it and it was laughably bad. The auto park was worse than it was years ago, leaving me a foot out from the curb in an easy spot. Trying to use the self driving on city streets resulted in it stuttering and stopping immediately. The only thing that worked decently was highway driving, which it does without the self driving package anyway.

Given its performance I wouldn't dare trust it with any of my daily driving even if it was free.


Even on a law and implementation effort like this with such large impact there are maybe 10,000 people in the world involved who actually understand it in any significant sense, and they all have a strong reason not to post about it on a public forum, or even a private one.

And even those people will only understand a limited aspect or perspective.

So the people commenting can only comment based on their outside impressions and emotions about generalities and how the specific implementation details seem to affect they as an end user.

I try to take anything said with that in mind. There is information in the comments about user experience but anything else is at the level of bullshitting at the bar with your friends, and not to be taken personally.


> I found it quite frustrating how teams would be legitimately actively pursuing ideas that would be good for the world, without prioritizing short-term Google interests, only to be met with cynicism in the court of public opinion.

This is part and parcel of working for a visible/impactful organization. People will constantly write things, good and bad about the organization. Most of them, good and bad, will be wrong. They'll be based on falsehoods, misinterpretations, over-simplifications, political perspectives, etc.

This becomes a problem when people in the company assume that because most of the feedback is nonsense, that all of it is nonsense. That is especially temping when the feedback is hurtful to you or critical of your team or values.

I found a bit of Neil Gaiman's MasterClass very helpful when reading such feedback. Very roughly Gaiman said that when someone is telling you something doesn't work for them, and what you should do to fix it, you should believe them that it doesn't work for them, but that the author is much better placed than the reader to know how and if to fix it.

In my context I try to understand why someone is saying something, what information I can take from it, and whether there is anything within my expertise, control, or influence that can or should be done about it.

(If you take anything from this comment, I think it should be to go listen to Neil Gaiman talk about anything!)


This is actually a great argument for a strong social democracy/welfare state.


Sort of.

If everyone does what they want - who does the jobs no one wants?


Automation and/or higher pay tends to make that not a problem.


Ah yes, the Keynes Ex Machina


automation is just going to take jobs and the higher level jobs will be unobtainable by the working class who won't have the income or childhood stability to afford obtain the education necessary for the jobs not taken by automation.

people talk about UBI (which i used to be for, but upon deeper investigation I feel is problematic) and about living wages for the lowest of jobs, but the USA is wholly captured by capital. We have two right wing parties that are controlled by industry. Neither of these things will never come unless its to hold off a violent revolution.


What an excellent demonstration of what values/norms a group really cares about.

Biggar violated the all time favourite in-group rule: Don't talk out of school. Don't talk about fight club. Don't snitch.

The other founders violated a norm against pushing yourself ahead and taking advantage of others that doesn't even seem to hold in many groups, especially upper class/wealthy ones.


Here's an analogy. You can get fired for always being late to work, but not get fired for bad behaviour (even crime) outside of work... say drunk driving.

This doesn't mean that being late to work is worse than drunk driving, or that person A is worse than person B. Not everything is a general judgement on worth or character.


I don't think that analogy applies. Both parties in this story did things in a 'work' context.

If I go on a work forum and describe my bad behaviour, behaviour that is harmful to others, and advocate for others to do it, I'm going to get in trouble, and possibly fired.

If I publicly discuss private work information, I'll definitely get fired.

If I mention the bad behaviour of someone at work publicly, without naming names, I might get a talking to, but probably won't be fired.

How a group reacts to those different things over time defines the norms and culture of the group.


Fair point.

I still think the conclusion applies though. Not everything is a judgment on overall worth or character. Most rules exist for banal reasons. Arrive on time, so we can open on time. Maintain confidentiality, so that we can have a non public forum. If heated arguments are settled by going to twitter, that's a cultural norm that negates private forums. It's not a moral norm, necessarily, but an operational one.

Very few things are absolute though. If someone brags about murder, and that confidentiality is maintained then it certainly does say something about norms and culture of a group. That said, naughtiness is an explicit part of YC culture, for better or worse.

In any case, sometimes there are choices. Civil disobedience can lead to consequences, to make another analogy. People participating in it accept that.

IDK what actually happened on the private forum, but I imagine this is an argument that spilled out from private to public. If Paul considered this a "the world must know" situation, then maybe he considers the price worth paying.


I have yet to see an actual source for this "bad behaviour, behaviour that is harmful to others, and advocate for others to do it" part.


Though based on dasickis comment, it seems there may not have been bad behaviour in the first place.


That is not a good analogy because most people's employment is "at will", meaning that they can be fired at any time for any reason other than discrimination against a protected class or retaliation for some protected activity (e.g., being a government whistleblower). If an employer wants to fire an employee who got arrested for drunk driving outside of work, that's usually not a problem.


>say drunk driving.

Unless of course, your job is driving.


Other issues aside, "A is just a complicated B, so apply the same rules to A as B" is not a formula for good decision making.

It's a common way to make bad mistakes though.


The OP has a spesific and accurate statement about danger to life and limb. A generic sounbyte does not make a convincing counterpoint


That's a terrible and misleading paraphrase of the above post, whose main point was contrasting the extreme risks inherent to auto repair to the mundane risks of computer repair. Which makes some specific arguments brought up against right to repair like battery replacement being too dangerous for independents/end users seem unconvincing. Perticularly because vehicles themselves have dangerous batteries.

Here's an allegation of that argument being brought up by Apple.

https://www.forbes.com/sites/ewanspence/2019/05/01/apple-iph...


However IMO this is a case of "A is much more complex and dangerous than B, so there is no reason to have B driven by more secretive and restrictive standards than those applied to A"


A Rectangle is just a complicated Square, so let’s just subclass. That should work out okay.

https://en.m.wikipedia.org/wiki/Circle–ellipse_problem


Trying to design for many unknown futures is expensive.

Changing in the future costs something.

Designing for future changes up front makes sense if cost(future change) > cost(future proofing)

SAAS? Do virtually no future proofing.

IOT, do some.

Space probe? Do lots.

Also, if you haven't built quite a few relatively similar systems, don't do future proofing without talking to people who have.


It must be uncomfortable being a google engineer on these products.

Having your work cancelled and thrown away is one of the most disheartening things as a developer.

It has to be back of mind for them when they are building. When it gets released they get to come see all the comments better on how long until Google kills it, and the people who won’t try it because of that risk.


Interesting. I don't think everyone shares that perspective. Certainly I think this software is sort of like an oil exploration expedition. It's going to cost a lot of work, there's a lot of stuff on-site you can't really reuse, and at the end you sometimes fail to find oil. But you built the thing to search for the oil, not to get the oil.

Shell spent billions on trying to find oil in the Chukchi Sea and there isn't enough to be worth it. But if you don't do things like that you don't find the other big finds.

That's why you don't fall in love with the software. It's there to see if the product is viable. Honestly, I like that environment.


But in Google's case they often do find oil, but then just dump it in the ocean. Lots of people used and enjoyed Inbox, Hangouts, Reader, etc, etc; but Google just discarded them anyway.

Spending years building something that thousands/millions of people end up using and liking, and then seeing it killed anyway, has to be discouraging.


Honestly, that's the dream. If you have product market fit, Google paid for the search, and now you can go make it later because it doesn't fit into their vision? Amazing. Ready-made startup.


That is hearsay, but I heard that career growth and compensation at Google is heavily tied to hitting milestones. Largest possible milestone is launching things, so there is bottom up pressure to launch products... regardless if they succeed.


Right. The point of the oil exploration expedition is not whether you find oil or not. It's that at google, running an expedition gets you a promotion, whether you found anything useful or not.


Having your work cancelled and thrown away without any change to your compensation is greatest relief you can experience as a developer.


About 6 years ago I took ownership of a very complex subsystem at work in order to fix a bunch of issues. Things started working after I fixed them, so I moved on to other things. No one else stepped to maintain it, so work done on it was minimal since then. Bugs kept appearing (the rest of the system changes a lot), and I still get emails with bug reports and/or people trying to understand the code asking me for training or even worse: patch review requests. I'm not even in the same team anymore!


Here's a magical phrase "Sorry I really don't have time to help you with this". As much as it's an asshole move, the people asking for your help are being paid to work on it and you're not, so unless you're trying to garner brownie points for mentoring, you need to be clear about your boundaries.


So... a startup?


Except, the engineers get paid adequately.


Sure, it's a trade-off in what sort of upside and control you want.


The reality is exactly the opposite, at least for less senior (< directors) engineers in Google. You get a promotion (even double) for launching the product and don't have to worry about its technical debts. This is because those less senior employees don't have a real product ownership and why they focus much more on launching a product than its growth. What Google needs to fix is this incentive structure.


if you're working on a mainline google product that gets shut down after being hyped as the next huge thing that everybody will be using then yes, that must be disheartening. Being a random developer on something like Allo would have sucked.

But my understanding is that these area 120 projects are built with more of a startup attitude, that you're taking a risk and there's a high probability of failure. It sounds really fun to me to build a "pure" product, being able to create exactly what you think the product should be without having to concede to business requirements, and just see how your vision will be accepted.


Marketing & sales make products succeed though. If it's just an engineering team chipping away, the probability that it will get mainstream traction is close to nil.


I'm in the Yaletown office, as are the positions I posted. There are definitely open positions in the off Burrard office as well.

The yaletown office has maybe 60 or 70 engineers? The other location is larger I believe (and has a better view), but don't hold that against us!


I had no idea there were so many Apple offices here.


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

Search: