
My biggest mistake as an F1 engineer - eloycoto
https://www.linkedin.com/pulse/what-i-learned-from-my-biggest-mistake-f1-engineer-andrew-latham
======
zwieback
Over the years I've done R&D as well as manufacturing engineering. The closer
you are to the manufacturing end the tighter the processes are nailed down,
you should still learn for your mistakes but at all times have a controlled
default. I'd say the F1 race is like that as well, if the low fuel case was
not tried before, which surprises me, it should be a wake up call for the
upstream R&D guys to better cover their process space. For the guys on race
day it's a sign that process monitoring needs to be improved. Anyway, everyone
should benefit in the end and most places I've been have had this attitude.
When it comes to learning from your mistakes individuals have a wide set of
reactions, though, and it's sometimes tough to swallow your pride and debug
the problem in front of you instead of quickly moving on and trying again.

~~~
woliveirajr
I don't read it as this wasn't tested before in R&D, but perhaps it was and
gave no advantage, so was not considered. The mistake allowed them to look for
other positive aspects that weren't considered before:taking the pole in
circuits where the first corner is complicated and messy can be a big
advantage (less risk of collision and ending the race in the same position is
something good). Also making all those companies who pay a lot of money to put
stickers on your car a little happier.

------
mickronome
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 essentially dependent on social support, and it has
been shown to improve creative problem solving. Sometimes improving
performance to such a degree that it makes it hard to believe.

~~~
koomi
> 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.

~~~
YCode
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.

------
coldcode
Or you can do what we do at BiglyCorp, have an absolute shitshow release where
250,000 customers crashed. Then act as if nothing happened and go along doing
the same things that caused the shitshow. If you don't learn from mistakes,
you've optimized for mistakes.

~~~
DanHulton
God, that's a _really good_ turn of phrase.

------
djaychela
I was expecting an error considerably larger than a fuel calculation which
ended up giving a better race strategy in terms of surviving the first corner,
and netted the same position overall as predicted! I used to prepare my own
rally car (up to WRC level), and made many mistakes much bigger than that, but
I guess that explains why he works for an F1 team and I'm currently looking
for job!

~~~
sqeaky
What did you learn from those mistakes? Did you learn how to not make them
again or possibly even something else beneficial?

I think you might have missed the point of the article. Excellence is not in
avoiding mistakes, Excellence is learning from mistakes so you can do better
next time.

------
LoSboccacc
Now I want to see an Honda F1 engineer followup

~~~
benoliver999
Would be really interesting to hear about how they passed off an engine from a
1983 Mini as a 2017 F1 car.

------
MR4D
At first glance, this might seem like "learn from your mistakes". But after
thinking about it, this article is much more.

Put simply, nothing will ever go perfectly right, and nothing will ever go
perfectly wrong. In any situation, there will be things that you want to see
happen again, and things you'd like to get rid of.

In Formula 1, that probably happens often. This is an engineer's take on what
that's like in one of the most demanding sports (business) on the planet.

------
fredley
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.

~~~
pjc50
If you don't learn _something_ from pushing a debug build to production, your
debug build isn't instrumented enough. Maybe all you learn is what the effect
of building with/without optimisation is on the real workload.

There's practically an entire genre of "here's what I learned from my
expensive mistake" stories. Usually they teach humility and caution. This one
is interesting because it's a variant of YAGNI. Imagine that you've carefully
tuned your (software/car) for a specific set of parameters, then throw one out
of whack by mistake - does this get caught by monitoring? Do you even notice?
If you hillclimb from the new status to an optimal one, do you get back to the
same local optimum?

Then of course there's the famous RISKS digest, which can be funny or
depressing depending on your mood and dependence on complex systems.

(My own personal one of these? "killall" behaves differently on Solaris than
it does on Linux ..)

~~~
lathiat
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 was
special cased at some point in Solaris 11.

Had to make that mistake 2-3 times before I finally realised what I was doing
to crash it given the slight delay.

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

~~~
ch4ck
Unlike other Unixen...

~~~
oblio
GNU CLI stuff is in terms of ease of use leagues ahead of most Unixes and even
the BSDs. The BSDs at least make it up by orderly docs.

Tiny example, GNU ls:

ls -lh bla : ok

ls bla -lh : ok

Most non-GNU lses, second form : oh-oh! :)

------
BusinessInsider
Can someone explain this to me? I'm only familiar with the current regulations
and so the logic of this paragraph doesn't make sense to me:

> Back in 2006, the regulations required teams to qualify their cars with race
> fuel-loads. The trade-offs were obvious – load the car up with fuel and
> you’d end up further down the grid, but with the benefit and flexibility of
> adjusting your strategy in the race. By contrast, qualify on petrol fumes
> and you had a good chance to be quick on Saturday, but you’d theoretically
> start the race with one hand tied behind your back.

~~~
ThrustVectoring
There's a tradeoff to be made with amount of fuel loaded into the car. If you
put more fuel in the car, it weighs more, and so will corner and accelerate
worse and have worse lap times. On the other hand, it'll have more fuel, so it
won't need to make a pit stop as soon.

Qualifying laps are structured differently from the actual race itself, in a
way that incentivizes putting less fuel in the car. Essentially, only the
qualifying lap times matter, and not the advantages from having more fuel
loaded. The obvious strategy is to put the bare minimum in the tank for
qualifying, and more during the start of the actual race.

The new regulations forbid that strategy - you're allowed no more fuel to
start the race than you had used to start the qualifying laps.

------
walshemj
Interesting the local f1 team RBR (red bull) a couple of years ago had two
DNF's from not correctly managing the fuel load.

I did do a spec job application always wondered if I would have pointed out
that as a mistake that I would have not made more than once :-) BTW my first
job was at the worlds leading rnd organisations in fluid dynamics which is
also nearby on campus at cranfield

------
pmontra
> 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.

~~~
TallGuyShort
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/](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 limits on
the car design, but on the teraflops used to design it.

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

~~~
TallGuyShort
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.

------
lisper
> 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?

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

~~~
jhpankow
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.

------
juanuys
The article is behind a sign-up page. Alternative?

------
Mithaldu
Short version: He didn't fuel Raikkonen's car up enough which forced an early
pit stop in the second-to-last lap of the race. However at the end of the race
they placed the same as they had planned, and they had for the laps before the
pit stop the advantage of having a stress-free race due to being in pole
position.

And the lesson he learned from that: Don't stick to the rules too closely, but
also try to see if breaking some rules can have positive side effects.
Experiment.

Not a fun read. Very badly written as he constantly leaves out the
consequences and details of decisions and circumstances, or only mentions them
paragraphs later.

~~~
fredley
The lesson wasn't "Don't stick to the rules", it was "Capitalise on your
mistakes". He didn't plan to underfuel the car, but when he did there were
lessons to be learned.

~~~
Mithaldu
The rules would've been "don't do it again and move on".

------
grault
Linkedin demanded me to log in to read.. I'd be happy to read this w/o logging
in / registering. Are you aware of a non-Linkedin link?

~~~
owlninja
Worked fine for me on Chrome

~~~
snowcrshd
Same on Safari, didn't have to login to read.

------
water42
why does linkedin have articles

~~~
castle-bravo
So people can self-promote (e.g. OP).

------
haydenlee
Oh F1 as in cars. I clicked thinking F1 Student Visa.

~~~
chesterc
How can a visa become an engineer, make mistakes and write about them?

~~~
TallGuyShort
F1 engineer = "engineer on an F1 visa"?

~~~
chesterc
German engineer = Engineer on a German visa?

~~~
TallGuyShort
And would you be that surprised if said engineer didn't speak English
perfectly?

------
dsfyu404ed
The story was interesting but the conclusion was basically "and that was my
long winded way of telling you to learn from your mistakes" which was pretty
meh IMO but it got me thinking.

I wonder how long it will be before AI can take common generic advice such as
"learn from your mistakes" and data about someone and generate a coherent
article like this one.

~~~
nickrivadeneira
"Learn from your mistakes" is an over simplification. Typically that means "if
you make a mistake, figure out a way to not make it again". Instead, the
lesson here is to find opportunities in the outcomes of your mistake.
Additionally, build that philosophy into your organization.

