Pie eyed opinion

[LesterBoffo]

The problem with Thorstens latest pie chart is that it explains why FG has such a low team working ethos.

He see's little to no value in communication within the community as it's a direct drain on implementation time.

Whereas I'm different.... I know for a fact that 90% of my time is me talking to myself about the design problems I'm facing and how to solve them.... the implementing of the solutions once I've determined them is matter of minutes...

I then review the results and argue with myself if they're good enough, if they're fit for purpose, if they meet my objective or even could i do it better more elegantly, and then I rewrite.

Now I'd love to be able to use the forum as a sounding board, to get others opinions or maybe even to collaborate with others solving similar problems, but every time I've tried Thorsten has gone out of his way (in topics that he's no practical skill in, just academic knowledge) to stymie conversation..

People like D-echo and Lester by refusing to stand up against it give tacit approval for these actions and leave me with no choice but to have to argue my corner... and then they come out with comments like "you're just a person that trolls the forum seeking arguments"..... Trust me I'm not, I like only to post in the flight model forum about flight modeling and unfortunately for others in opposition to bullying wherever I see it.

If Thorsten, Horray, Curt and others concentrated more on coding than on telling people how Flightgear should be run, and in what direction it must go in the forum itself would be a lot healthier.

Tacit approval? No, I don't. I've been critical of Thorsten's 'style' for a quite a while, and have been on the receiving end of his arrogant superiority more than a few times. I just refuse to engage him any further, something about wrestling with pigs.

[SHM]

He gets it back fair and square!!

[KL-666]

Whereas I'm different.... I know for a fact that 90% of my time is me talking to myself about the design problems I'm facing and how to solve them.... the implementing of the solutions once I've determined them is matter of minutes...

Exactly. The final programming is almost merely translating to programming language. Relatively quick.

I am aware of how programmers hate to document. Therefore i always tell programmers who are also involved in the design: I am not going to tell you to document. What you should do is make a good document in the design phase, which will help you get to agreement with others you have to talk with. When you are done programming, then the documentation is already almost complete. Just a few amendments following the actual programming, and you are done.

The programmers always see the usefulness of the design document, and start making use of them. The filling in afterwards often does not happen. But hey, we do have almost perfect documentation now. So we can look back at the reasons why our source is coded in certain ways, which interfaces we have and where the dependencies are. This speeds up developing new modules or modifying old ones more than enough.

Kind regards, Vincent

[SHM]

Dont we already have the git submodule approach?

[KL-666]

Good to see everyone talking chill again. Life is so much more fun with a bit of humor. Curt made the best 3D pie chart ever.

https://forum.flightgear.org/viewtopic.php?f=3&t=30648&p=297137#p297132

Let's keep up the good going and not hate so much. As i always say, the one who hates, hurts himself most.

Kind regards, Vincent