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!)
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.
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.
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.
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.
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"
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.
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.
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 don't know what 'cortical representations' are exactly, but it seems generally true that experts in a domain build up gradually higher level pattern recognition in their area of expertise. Whether it is driving a car, playing a sport or game, or writing software.
As a beginning programmer I had to consciously think about fundamental concepts all the time, or grapple with my limited knowledge of a programming language, instead of thinking about the problem.
As an experienced programmer I think in higher level concepts and abstractions, and the fine code details happen without me consciously thinking about them particularly.
This actually makes learning a new programming language or IDE more painful now than it was when I was new. It probably takes me less time to get to an equal level of skill in language X than a beginner, but getting to the level of fluency where the low level details don't require conscious thought takes time and practice. Being slowed down so much while getting to that point is deeply frustrating.
For me I've noticed that over time I've stopped worrying about the code and now mostly care about the data. How it's stored, how it's transformed etc. The code comes from how the data is managed.
As a new programmer, you certainly spend more time thinking about the details and minutae of the code itself.
Changing languages within the same group tends to come pretty easy, a C-like is mostly similar to other C-likes, flipping from python to ruby isn't all the terrible (or vice versa).
Moving between language groups is harder though, still struggling to wrap my head around lisp and haskell for example. Probably due to my skewed upbringing, BASIC to 6502 to 68k to C to python.
> Moving between language groups is harder though, still struggling to wrap my head around lisp and haskell for example
I played around with CL and Scheme before coming to Clojure. I did not have much success with the first two but with Clojure it finallly clicked because at least on a superficial level Clojure seems to have more syntax than the other lisps (because of vector and hash-map literals). And eventually I understood why "code is data" in lisp. But I think that the visual distinction for the different collection types really helped me understand the concepts behind lisp better.
FYI: I haven't used Racket yet (if that should be relevant).
Took the words right out of my mouth! I feel a little guilty when I'm reminded that "the language is just a tool," meanwhile I am loathe to switch unless truly necessary. Honestly, I don't think I have the memory space to be deeply fluent in more than a few languages, and so when presented with the option of learning/using a new one, I weigh that against proficiency lost in other areas. I know it's not zero-sum, but context switches have a cost. Especially in industry, languages are often so similar that it's hard to justify. I used to feel differently, and be more enthusiastically polyglot (I've got production code currently running somewhere in the world in about 8 languages). It wasn't until I found a language that clicked with me that I even had the motivation to become really fluent.
well, "cortical representations" is just a fancy way of describing modern day phrenology. I.e. you stick a programmer in the fMRI scanner, the signal gives more blobbiness in the brain cortex (i.e. the outer layer of noodles) in a certain pattern vs. an aged match nonprogrammer control.
If you actually get inside the skull and attach electrodes, you then can maybe measure the oscillatory dynamics and properties of say a bunch of neurons in a specific part of the cortex and claim there's tuning because some paramater - phase coupling, firing frequency, etc etc etc appears different than a group of aged matched controls. But I'm sure no programmer voluntarily agreed to non-medically necessary brain surgery...
I called this building consciousness. If you are pouring lot of code daily and moving between many projects, you will start writing comments automatically. Once you build enough consciousness about anything, learning become very second nature. And this is the reason 10000 hours rule work imo.
On side note, the biggest mistake people do is they can't think straight. If you want to learn coding, start coding first. Don't read theory or watch youtube videos. If you want to learn public speaking, start giving speeches. Don't read motivation books. This is how child learn. Fail and improve. Sadly many kids want to become hacker by watching hollywood movies and youtube videos.
Given its performance I wouldn't dare trust it with any of my daily driving even if it was free.