Czy Programista C# w projektach WPF musi posiadać biegłą znajomość XAML'a?

Cześć wszystkim,

Ostatnio nasunęło mi się takie pytanie. Otóż na początku był WinForms, gdzie nie było jakiegoś specjalnego podziału na "backend i frontend". Natomiast potem powstał WPF, doszedł wtedy XAML, który rozbudował możliwości graficzne. Znacząco pozwoliło to oddzielić "backend i frontend", bynajmniej tak to nazwijmy. I teraz takie pytanie

1. Czy ten podział powstał ze względu na to, aby móc się lepiej odnaleźć w pisaniu kodu + nazwijmy to większa elastyczność?
2. Czy może raczej ktoś się zajmuje wyglądem (Xaml), a programista (C#) code-behind?

Zmierzam tym wszystkim do tego ile programista, który odpowiada za logikę aplikacji musi znać składni xaml'a, na ile to mu się przyda w codziennej pracy? I jak to ewentualnie u Was wygląda?

Pytam, bo nie wiem na ile muszę umieć xaml'a (znać składnie ≠ umieć go używać i pisać własne okna itd.), aby zostać programistą C# i odnaleźć się przy projektach WPF.
Porównuje to do korzystania z bibliotek, wtedy głównie czytamy dokumentację, a nie kod źródłowy (chyba, że mamy ważną rzecz do sprawdzenia to wgłębiamy się w kodzik), bo interesuje nas wynik, a nie co się dzieje, że dostajemy wynik.

dziękuję ślicznie i pozdrawiam

To wszystko zależy jaka firma. Jak jest czysto backendowy, to nie powinno go interesować, co się dzieje na froncie niezależnie czy to XAMl czy JS czy cokolwiek innego. Jeśli jest "full stack" no to wówczas mus znać to, w czym jest napisany front, ale dalej nie powinno to mieć wpływu na backed.

Ten podział powstał po to żeby móc testować jednostkowo logikę zawartą w viewmodelach. Szczerze powiedziawszy to się jeszcze nigdy nie spotkałem z podziałem na front/backend jeśli chodzi o aplikacje desktopowe w wpf, zawsze to był fullstack.

Jak piszesz w codebehind w wpf to zapomnij o tym że ktoś inny będzie robił xamle, tylko przy użyciu mvvm jest to możliwe by ktoś inny robił xamle, aczkolwiek nie spotkałem się jeszcze z tym w praktyce.