Hacker News Reader

Comment by high_derivative | Hacker News Reader

This is not my reading at all.

If you have ever spent time in a FAANG research org - it can be incredibly frustrating to see so much lack of focus. Everybody does what they want. This is not an issue for most e.g. ML research (my org) because there is so much money to go around, and researchers will leave if they are too constrained.

For hardware/critical projects or customer retention, this is very much an issue. Just look at how the TF ecosystem developed API wise.

There can literally be a project with enormous importance for an ecosystem where multiple teams under one VP do the same thing slightly differently. VPs do nothing and have no opinion on the details. Internal and external users get frustrated because there is no clarity.

If you do a project where you have resources for just one shot in a given timespan, this simply won't cut it.

View on HN

I think there is a way to set a strong objective s and give freedom for the solution. Generally I’ve found that success comes from limiting objectives: one part focus, and one part humility, saying no to anything ill-defined or potentially impossible. Those are the things that the marketing engine is built on. The difference between the audience and the magician is that the magician doesn’t believe in magic. There are many more audience.

Martinis seems like a very focused leader. The problem chosen was very specific to what they knew they could do with the technology, assuming only that the theory works. He had to say no to business units asking for application value, no to easier paths to publication, no to other people trying to build their careers on a different problem, because he needed everybody’s best ideas on the one problem. But many people can’t adapt to a new problem, and many leaders can’t tell the difference between an idea for solving the problem, and an idea for solving a different problem.

The wiring thing sounds petty, but maybe it was really a divergence. I don’t know. It sounds like part of the problem is that he achieved the goal and didn’t know what to lead with next.

The wiring thing highlights the problem I think. He was the hardware manager but he didn't actually have control over the direction of the hardware team. That's a terrible position to be in.

Also, don't underestimate wiring in a quantum computer. I don't know the details of Google's system but Quantum computers uses analog RF pulses to interact with the Qubit system which are then later digitized. The design of a wiring system in a Quantum computer is similar to what you would see designing a high end phased array radar system with the need for everything to be phase matched, highly stable, and temperature controlled except that a quantum computer is also extremely susceptible to cross talk at the interfaces. Wiring a system of Google's scale can easily run into the $100k+ range in just material and manufacturing costs. If the other person didn't have any experimental experience like Martinis says, then he would almost certainly run into problems.

Yes. People usually leave jobs because their boss doesn't meet their needs. Hartmut hired Martinis to be a manager and then didn't give him authority to do his job. Martinis tells how he had several meetings with Hartmut about this problem but nothing was done. It's clear to me that Hartmut failed in his role.

Yes, we built an IC just for the wiring. I think I have a guess at what the argument was about, essentially expert heuristics versus learned optimization. It's been my experience with Google on other RF projects that they prefer naïveté versus expertise. This was explained to me as advantageous for scaling teams and minimizing technical debt, which actually makes sense.

In my experience at honours university level, which may or may not be relevant to the conversation, is that everyone does what they want if the leader figure doesn't understand the topics in depth.

In my case, I am someone who wants to do everything from first principles whereas my study leader at the time unfortunately told me "you can't understand everything". Although that statement is true, you should at least try to understand one thing really as deep as you can. But what bothered me was that if I wanted to understand something deeply, I realised I had to do it myself. So what I can say is that you don't have to be completely unfocused; it could be that your interests and objectives are different in the group.

Long story short, my HonsBSc was a basically a failure and my MSc was a success for these reasons. The funny thing is that I get satisfaction today when I do anything that would have been a great honours project in my topic (signal analysis in bioinformatics).

> Everybody does what they want.

As opposed to what? Everyone having their own personal sort of projects or splitting up in groups of two and three is natural in the academia research groups I’ve been in to.

What is wrong with that?

Because you cannot deliver experimental physics breakthroughs or hardware with teams of two deciding every week what they feel like doing.

Have you ever thought about how much work it takes to deliver hardware? How many teams and processes and planning there are involved from physics level to software stack to deliver something usable? It's insane. And normal processor hardware is something people have experience with. For a physics experiment, virtually everything is custom made and you only have budget for a few fixes or trials on each component. There is just not much room for slack.

> For a physics experiment, virtually everything is custom made and you only have budget for a few fixes or trials on each component.

I'm actually speaking from my experience in experimental physics (solid state) labs. Certainly, you can't just have teams of two entirely deciding what to do independently of the group, but the level of control and dictation Martinis is speaking about seems like a whole different level.

He got pissed just because a theorist tried to come up with an alternate way of doing this wiring and the lab leader didn't shut it down in favor of just him researching the problem.

Smart comment. I work at a large lab that does cutting-edge hardware development. The slow buildup of fabrication and fundamental-physics know-how is hard for someone who has mostly worked on software to appreciate. To realize these breakthroughs, you need to plan at the decade time scale.

TF?

TensorFlow. The API is outrageous.

I'm not quite a dev, but I have always felt there's something awful with the TF ecosystem. I thought I was the only one 'struggling' with it and that probably there was some fundamental insight I was missing.

What is awful with it?

This summed up my experience with it pretty well:

https://news.ycombinator.com/item?id=21216200

Possibly TensorFlow

Reply on news.ycombinator.com