My biggest mistake as an F1 engineer
linkedin.com
linkedin.com
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.
Can you give us some pointers to said research? I'd love to see the details.
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.
A business mess is one thing, but losing somebody's identity is another level of feeling shitty.
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.
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.
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 ..)
(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.
Tiny example, GNU ls:
ls -lh bla : ok
ls bla -lh : ok
Most non-GNU lses, second form : oh-oh! :)
During one test run, one input did not update, we were happily feeding stale input to algorithm, which in turn took control paths that could have caused severe damages in unsupervised environment. Lessons learned: if you rely on invariants about inputs in code (update interval in this case), guard against violations of those invariants. This helped me many times later.
Every time you use assert() somewhere you're doing just that.
I guess rather well-known real world example is systems starting to show weird behaviour when database resultset ordering changes (e.g. changes in indexing) and someone relies on correct entry being first/last.
Assumed invariant here is resultset ordering and code is written with this particular invariant in mind. If not enough ordering clauses are used, resultset ordering is not invariant, even though it worked for years already :)
What that gains us is a run with real data and a build that's instrumented with assertions - which flushes out a lot of previously unknown issues.
So yes, you learn useful things. If you ever did it accidentally, the useful thing you learn is that shipping ideally is not an on/off switch, but a carefully monitored process :)
I'm working on desktop software, and this happens to builds that are full production builds, but that don't go to stable. So a very small subset of our users - who has agreed to being guinea pigs - occasionally gets these.
It also helps that we have a clear policy that assertions can only fire in cases that truly would be a bug in the wild - you can't assert and handle the issue. Either you think it might happen, then you handle it - or you state an invariant, in which case there's no reason to handle it being false. In other words, the only price you pay is that your build is slower - any assertion that fires would've been a silent bug before anyways. And, to be as close to non-debug as possible, any assertion firing merely creates a crash dump, it doesn't actually crash the executable.
And finally, we simply need to do it in the wild because many of our bugs are simply due to the staggering number of environments desktop software encounters.
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.
> 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.
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.
However, previously, there was refueling possible during the race, which allowed for some strategy variation:
- either you start with small amount of fuel, gain advantage due to lighter car (~1s faster per lap), and refuel early in the race (probably 2 refueling stops needed in such case)
- or start with bigger amount of fuel and stay longer on the track, but only do 1 stop for refueling
Also, since you needed to start the race and qualifications with same amount of fuel, going with less-fuel-and-double-refuel strategy meant you were more likely to win a pole position due to lighter car during qualifications.
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
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.
What processing are there limits on? Is it just the wind tunnel equivalence (Were there limits on wind tunnel time back in the day?)? Is it just pre-manufacturing simulations or do they limit the sort race simulations that we're talking about here?
What is a set-up packer?
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.
Running a light fuel load in quali was a well-known strategy, and it's one they would have modeled in simulations. Likewise, avoiding first-lap (and particularly first-corner) collisions by qualifying as high up as possible is similarly a well-known strategy. Finally, they obviously know the money they get from being on pole.
The article doesn't bother explaining why the real-world outcome was different from what was modeled, so it's hard to gain any insight from it.
edit --
It's some Javascript based redirect, I can see this in curl: ... "baseRedirect":"https://www.linkedin.com/uas/login?session_redirect="}--> ...
I'm not investigating further.
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.