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?
My biggest mistake as an F1 engineer
11–20 of 70 posts
Re: My biggest mistake as an F1 engineer
#12Short 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 bre…
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.
Re: My biggest mistake as an F1 engineer
#13I'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.
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 ..)
Re: My biggest mistake as an F1 engineer
#14Short 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 bre…
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.
The rules would've been "don't do it again and move on".
Re: My biggest mistake as an F1 engineer
#15The 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.
Re: My biggest mistake as an F1 engineer
#16There 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.
Re: My biggest mistake as an F1 engineer
#17I'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.
You could learn from 'DEBUG=True' that you haven't automated your production deploy process carefully enough, including but not limited to testing failure cases. Raising the priority on that and making it part of routine work can save you from innumerable costly boneheaded mistaken deploys in the future.
Re: My biggest mistake as an F1 engineer
#18I'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.
You could learn from 'DEBUG=True' that you haven't automated your production deploy process carefully enough, including but not limited to testing failure cases. Raising the priority on that and making it part of routine work can save you from innumerable costly boneheaded mistaken deploys in the future.
I understand this, I guess what I'm trying to get at is that the learning from the article was more than just procedural (I.e how can we make sure this doesn't happen again), and more about the system itself.
Re: My biggest mistake as an F1 engineer
#19I'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.
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…
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.
Re: My biggest mistake as an F1 engineer
#20There 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…
Good luck with that when employees are treated basically like yet another raw material in the production cycle.