Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My biggest mistake as an F1 engineer

linkedin.com

Post reply on HN
Print view View original

41–50 of 70 posts

Re: My biggest mistake as an F1 engineer

#41

Post by jecel »

TallGuyShort wrote: post #33
pmontra wrote: post #24

> before the race weekend, all our simulations, which had been firmly plotted around a more conventional qualifying strategy, had told us we were likely to finish third. That was 2006. Do anybody have information about to the software racing teams use to simulate race strategies and how many GPs they test? Thanks.

Big Monte Carlo simulations, and I'd expect them to test every GP. Based on where they qualify they have pre-computed decisions about when to pit / change tire types, etc. under various conditions, like a safety car on lap 10, etc. See: http://www.canopysimulations.com/ . Not sure how many of the teams use that specific software, but the computing side of F1 is actually a big deal: the rules place not only place limi…

Monte Carlo simulations are particularly important for the Monaco GP ;-)

Re: My biggest mistake as an F1 engineer

#43

Post by TallGuyShort »

jecel wrote: post #41
TallGuyShort wrote: post #33

Earlier quoted context omitted.

Big Monte Carlo simulations, and I'd expect them to test every GP. Based on where they qualify they have pre-computed decisions about when to pit / change tire types, etc. under various conditions, like a safety car on lap 10, etc. See: http://www.canopysimulations.com/ . Not sure how many of the teams use that specific software, but the computing side of F1 is actually a big deal: the rules place not only place limi…

Monte Carlo simulations are particularly important for the Monaco GP ;-)

Which is actually true! The next best thing you can do at that track besides getting pole is to time the stops perfectly to maximize off-track passing, and that's what the simulations generally focus on.

Re: My biggest mistake as an F1 engineer

#44

Post by lmm »

fredley wrote: post #10

I'd be interested if anyone has any anecdotes that compare from software engineering. Sending a car out with suspension thingamies still attached seems like the equivalent of pushing a build to production with `DEBUG = True`, and I'm not sure much useful can be learned by you in that situation.

We broke one API for 2 months, and thereby discovered that no-one was actually using it and so removed it.

We left some database healthchecks running on every request for a while, making load times a factor of 10 longer than they needed to be. Learnt our stuff was really fast and we didn't need to worry about performance much, I guess.

Re: My biggest mistake as an F1 engineer

#45

Post by ch4ck »

oblio wrote: post #23
lathiat wrote: post #19

Earlier quoted context omitted.

I'd also strongly suggest not typing "exit" into kdb, the Solaris debugger when it is in write mode. It sets the global pointer for exit (the libc function) to NULL and the whole system will crash a few seconds to minutes later when the next process exits. (It's not uncommon to use this tool to reconfigure some configuration values at runtime) At least not on Solaris 10 or any of the open source derivatives. Seems it…

Solaris, the system were ease of use is an enemy.

Unlike other Unixen...

Re: My biggest mistake as an F1 engineer

#46

Post by YCode »

koomi wrote: post #30
mickronome wrote: post #16

There is quite a bit of research that implies that the most influential action you can take to make a software team more productive in terms of both quality and quantity is to build a culture that is a close sibling to what he describes. Add in a little more of a socially supportive environment into the professional mindset depicted in the article to adapt it to software develop ent. Psychosocial well-being is essent…

> There is quite a bit of research that implies that the most influential action you can take to make a software team more productive in terms of both quality and quantity is to build a culture that is a close sibling to what he describes. Can you give us some pointers to said research? I'd love to see the details.

Google's Project Aristotle came to similar conclusions, you might look into that.

The rough TL;DR is good teams have all members speak up when necessary and good psychological safety, defined as the feeling that you can be wrong and you wont be rejected, punished or embarrassed for it.

Re: My biggest mistake as an F1 engineer

#47

Post by jhpankow »

iDemonix wrote: post #42
lisper wrote: post #40

> one of the mechanics mistakenly left a set-up packer in the suspension system of one of our grand prix cars What is a set-up packer?

I believe it 'packs out' the suspension to essentially disable it if they're doing any maintenance that requires it.

Yes it locks it in place so the car doesn't move during transport. F1 cars derive so much of their suspension movement from the flexing of the tyre wall that the car is still drivable.
Post reply on HN