[skydhash]

SWE is more like formula 1 where each race presents a unique combination of track, car, driver, conditions. You may have tools to build the thing, but designing the thing is the main issue. Code editor, linter, test runner, build tools are for building the thing. Understanding the requirements and the technical challenges is designing the thing.

[Waterluvian]

The other day I said something along the lines of, "be interested in the class, not the instance" and I meant to try to articulate a sense of metaprogramming and metaanalysis of a problem.

Y is causing Z and we should fix that. But if we stop and study the problem, we might discover that X causes the class of Y problem so we can fix the entire class, not just the instance. And perhaps W causes the class of X issue. I find my job more and more being about how far up this causality tree can I reason, how confident am I about my findings, and how far up does it make business sense to address right now, later, or ever?

[altmanaltman]

is it? I really fail to see the metaphor as an F1 fan. The cars do not change that much; only the setup does, based on track and conditions. The drivers are fairly consistent through the season. Once a car is built and a pecking order is established in the season, it is pretty unrealistic to expect a team with a slower car to outcompete a team with a faster car, no matter what track it is (since the conditions affect everyone equally).

Over the last 16 years, Red Bull has won 8 times, Mercedes 7 times and Mclaren 1. Which means, regardless of the change in tracks and conditions, the winners are usually the same.

So either every other team sucks at "understanding the requirements and the technical challenges" on a clinical basis or the metaphor doesn't make a lot of sense.

[skydhash]

Most projects don’t change that much either. Head over to a big open source project, and more often you will only see tweaks. To be able to do the tweaks require a very good understanding of the whole project (Naur’s theory of programming).

Also in software, we can do big refactors. F1 teams are restricted to the version they’ve put in the first race. But we do have a lot of projects that were designed well enough that they’ve never changed the initial version, just build on top of it.

[Waterluvian]

I wonder about how true this was historically. I imagine race car driving had periods of rapid, exciting innovation. But I can see how a lot of it has probably reached levels of optimization where the rules, safety, and technology change well within the realm of diminishing returns. I'm sure there's still a ridiculous about of R&D though? (I don't really know race car driving)

[altmanaltman]

Sure there is crazy levels of R&D but that mostly happens off season or if there is a change in regulations which happen every 4-5 years usually. Interestingly, this year the entire grid starts with new regs and we don't really know the pecking order yet.

But my whole point was that race to race, it really isn't that much different for the teams as the comment implied and I am still kind of lost how it fits to SWE unless you're really stretching things.

Even then, most teams dont even make their own engines etc.

[skydhash]

Do you really think that rainy Canada is the same as Jedddah, or Singapore? And what is the purpose of the free practice sessions?

You’ve got the big bet to design the car between the season (which is kinda the big architectural decisions you make at the beginning of the project). Then you got the refinement over the season, which are like bug fixings and performance tweaks. There’s the parts upgrade, which are like small features added on top of the initial software.

For the next season, you either improve on the design or start from scratch depending on what you’ve learned. In the first case, It is the new version of the software. In the second, that’s the big refactor.

I remember that the reserve drivers may do a lot of simulations to provide data to the engineers.