Discussion :

[L33tige]

C'est étrange, je suis lead-tech et spécialiste backend. Mais je sais faire et fait à l’occasion du frontend et de l'intégration devops, je me considère donc fullstack avec une spécialité sur le backend et je n'envisage plus d'embaucher des gens qui ne sont pas un minimum fullstack.

Ça me semble vraiment waterfall (ou très année 2000) d'embaucher des spécialistes, voir même pénible pour un projet. Dans une équipe agile, si j'ai une priorité sur mon frontend pour ma satisfaction client et que mon backend (qui se résument à des API REST la majorité du temps), je fais quoi ? j'accepte de ne pas mettre 100% de la capacité de mon équipe de réalisation sur ce qui a vraiment de la valeur pour mon client ou me permet de terminer la livraison ?

Nan mais l'api rest ok c'est simple, mais le traitement avant pas forcément, on n’envoie pas que des résultats de SELECT * pour afficher une liste dans un tableau hein...

[micka132]

Edit : comme le dit, dfiad77pro

ps: à la lecture de ce topic, le front , c'est pas que JS, y'a aussi encore pas mal de WPF (C#), winforms, de QT, sans compter les applications Mobiles.

Pourquoi le Front-end c'est forcément du Web?
Dans les clients lourds, on fait bien de l'affichage pour l'utilisateur.
Idem pour les applications natives mobiles.

La différence que je fais c'est qu'en appli client lourd (moins vrai pour les mobiles), on est normalement "full stack" avec des problématiques de back-end puisqu'on est souvent en accès direct à la BDD et accès réseau intranet

[VBurel]

Je ne savais pas qu'il pouvait y avoir des développeurs full stack en entreprise.
doivent se faire chier ou etre traités comme des esclaves...

oups, j'ai oublié de mettre un smiley :-)

[GreatDeveloperOnizuka]

Edit : comme le dit, dfiad77pro



Pourquoi le Front-end c'est forcément du Web?
Dans les clients lourds, on fait bien de l'affichage pour l'utilisateur.
Idem pour les applications natives mobiles.

La différence que je fais c'est qu'en appli client lourd (moins vrai pour les mobiles), on est normalement "full stack" avec des problématiques de back-end puisqu'on est souvent en accès direct à la BDD et accès réseau intranet

En client lourd, tu peux être plus être "fullstack". Si tu fais du WPF par exemple, t'as "seulement" le C# à maîtriser alors que tu dois connaitre normalement un autre framework en JS sur le web la plupart du temps (pas tout le temps évidemment).

[CS FS]

Je suis toujours épaté par les salaires mis en avant dans ce genre de graphiques.
--

Au-delà du fait que j’ai déjà été confronté à des backends catastrophiques, gérés par des "spécialistes" qui ne connaissent même pas la notion d’indexes. Je me dis qu’un profil full-stack est souvent ce qu’il y a de plus viable pour un employeur, de par sa flexibilité et sa vision globale des contraintes d’un projet.

De mon point de vue, nous ne vivons pas dans un monde où le spécialiste back ou front est systématiquement plus doué qu’un développeur full-stack. Ce que je veux dire par là, c’est qu’on peut facilement confronter un développeur full-stack qui ponce la même pile technologique depuis plus de 12 ans (par exemple WPF/Asp.net MVC), et un spécialiste back ou front qui, dans un même laps de temps, va avoir fait tourner plus de technos que de handspinner.

Partant de là, c’est sur ses compétences qu’un dév devrait être évalué, et non sur son profil.

[GreatDeveloperOnizuka]

Je suis toujours épaté par les salaires mis en avant dans ce genre de graphiques.
--

Au-delà du fait que j’ai déjà été confronté à des backends catastrophiques, gérés par des "spécialistes" qui ne connaissent même pas la notion d’indexes. Je me dis qu’un profil full-stack est souvent ce qu’il y a de plus viable pour un employeur, de par sa flexibilité et sa vision globale des contraintes d’un projet.

De mon point de vue, nous ne vivons pas dans un monde où le spécialiste back ou front est systématiquement plus doué qu’un développeur full-stack. Ce que je veux dire par là, c’est qu’on peut facilement confronter un développeur full-stack qui ponce la même pile technologique depuis plus de 12 ans (par exemple WPF/Asp.net MVC), et un spécialiste back ou front qui, dans un même laps de temps, va avoir fait tourner plus de technos que de handspinner.

Partant de là, c’est sur ses compétences qu’un dév devrait être évalué, et non sur son profil.

Niveau maintenance, est-ce vraiment une bonne idée de foutre 350 technos Trouver ensuite des ressources pour maintenir et faire évoluer ça par exemple. Le mec qui fait tourner un truc qui marche bien sur asp.net MVC depuis 12 ans, tu devrais trouver plus facilement des mecs poru maintenir ça. Sans parler de la compatibilité des composants trop hétérogène. Perso j'espère que Blazor va tuer JS un de ces jours côté dev .NET par ex

[CS FS]

Niveau maintenance, est-ce vraiment une bonne idée de foutre 350 technos Trouver ensuite des ressources pour maintenir et faire évoluer ça par exemple.

En grossissant un peu le trait, c’est un peu ce qu’il se passe dans le monde du Web. Aujourd’hui un développeur Web qui bosse comme il bossait il y a 12 ans, ça se fait rare (un développeur WPF par contre...).

Au-delà de ça je n’ai pas dit qu’il fallait embaucher tel ou tel profil, j’ai simplement confronté deux extrêmes, en soulignant le fait que l’assertion "spécialiste > full-stack" n’était pas forcément pertinente.

[micka132]

En client lourd, tu peux être plus être "fullstack". Si tu fais du WPF par exemple, t'as "seulement" le C# à maîtriser alors que tu dois connaitre normalement un autre framework en JS sur le web la plupart du temps (pas tout le temps évidemment).

Oui mais non! WPF n'a par exemple rien strictement à voir avec Winform, même si tout deux sont utilisables avec c# (ou VBNet, et même c++), il s'agit de 2 Frameworks avec toute une logique à appréhender. Ca revient au même que de dire NodeJS c'est du JS, donc faire du React c'est la même chose. D'ailleurs tu peux entièrement faire ton site sans aucun Framework, ce qui en c# sans Framework graphiques (Wpf, Winform, Uwp, Xamarin, Gtk#,MonoMac,Qml.Net, QTSharp,...…. ) ne sera pas possible, tu seras limité à des applications consoles (souvent synonyme de backend).
Tu noteras aussi qu'avec Unity, tu fais également du c#, mais c'est bien encore un autre univers que de maitriser cet outil !

[micka132]

e depuis plus de 12 ans (par exemple WPF/Asp.net MVC)

Pour le coup Asp.Net (MVC ou non) est plus proche de Php (ou de NodeJS), c'est plutôt la partie back-end. Ton front tu vas pouvoir le faire avec n'importe quel framework web.

[GreatDeveloperOnizuka]

Oui mais non! WPF n'a par exemple rien strictement à voir avec Winform, même si tout deux sont utilisables avec c# (ou VBNet, et même c++), il s'agit de 2 Frameworks avec toute une logique à appréhender. Ca revient au même que de dire NodeJS c'est du JS, donc faire du React c'est la même chose. D'ailleurs tu peux entièrement faire ton site sans aucun Framework, ce qui en c# sans Framework graphiques (Wpf, Winform, Uwp, Xamarin, Gtk#,MonoMac,Qml.Net, QTSharp,...…. ) ne sera pas possible, tu seras limité à des applications consoles (souvent synonyme de backend).
Tu noteras aussi qu'avec Unity, tu fais également du c#, mais c'est bien encore un autre univers que de maitriser cet outil !

1) Euh c'est bien plus facile d'apprendre WPF en venant de Winforms et C# que d'apprendre ReactJS en venant de Winforms/C# donc dire que Winforms et WPF n'ont rien à voir... L'inverse est vrai un mec qui fait du ReactJS si tu le fous sur un projet Winforms sans connaissance du C# ça va lui prendre plus de temps.

2) Pourquoi je pourrais pas faire de site avec que du C#? C'est juste que ça va te prendre un max de temps. Rien ne m'empêche de renvoyer un doc html en full string par exemple non ?

[micka132]

1) Euh c'est bien plus facile d'apprendre WPF en venant de Winforms et C# que d'apprendre ReactJS en venant de Winforms/C# donc dire que Winforms et WPF n'ont rien à voir... L'inverse est vrai un mec qui fait du ReactJS si tu le fous sur un projet Winforms sans connaissance du C# ça va lui prendre plus de temps.

Il faut comparer ce qui est comparable, là tu changes de langage et d'environnement. Compare plutôt le passage de React vers Vue et Winform vers WPF. Pour "survoler" le truc (c'est à dire faire un truc qui tourne sans jamais sortir des sentiers battus) c'est comparable, pour le maitriser à mon avis il y a bien plus d'écart du coté wpf/winform. Pour UWP/WPF là par exemple on est beaucoup plus proche.

2) Pourquoi je pourrais pas faire de site avec que du C#? C'est juste que ça va te prendre un max de temps. Rien ne m'empêche de renvoyer un doc html en full string par exemple non ?

Oui tu peux, en assembleur aussi, mais là tu parles de serveur http. Ton rendu ne sera qu'un fichier texte. Tu vas mettre des balises (html) et éventuellement du JS, ca ne fera que "polluer" le texte. C'est le rôle d'un autre logiciel (le navigateur bien souvent) d’interpréter le HTML et le JS. C# n'a rien à voir la dedans!

[Glutinus]

56000€ > 59000€ d'après le graphique mid-level

J'étais tombé sur un article il y a deux ans sur l'art de faire raconter n'importe quoi à une dataviz, notamment en ne prenant pas des échelles orthonormées...

[MarieKisSlaJoue]

C'est étrange, je suis lead-tech et spécialiste backend. Mais je sais faire et fait à l’occasion du frontend et de l'intégration devops, je me considère donc fullstack avec une spécialité sur le backend et je n'envisage plus d'embaucher des gens qui ne sont pas un minimum fullstack.

Ça me semble vraiment waterfall (ou très année 2000) d'embaucher des spécialistes, voir même pénible pour un projet. Dans une équipe agile, si j'ai une priorité sur mon frontend pour ma satisfaction client et que mon backend (qui se résument à des API REST la majorité du temps), je fais quoi ? j'accepte de ne pas mettre 100% de la capacité de mon équipe de réalisation sur ce qui a vraiment de la valeur pour mon client ou me permet de terminer la livraison ?

meme si dans le fond je suis d'accord avec toi, il faut aussi noter que maintenant savoir toucher du front, n'est pas juste faire un peu de html/css/js. Il faut maintenant savoir se retrouver dans des Framework entier qui n'ont rien de facile a apprehender. Donc demander a un specialiste du back d'aller rajouter des component Angular dans du front ca peut tres vite devenir compliquer, et avec la multiplication des techno tu peux vite avoir un back qui n'est pas techno-compatible avec ton front.

Donc oui il faudrait (et je pense qu'on l'est tous plus ou moins) full stack avec a chaque fois une grosse (voir tres grosse) specialiste en back ou en front. Mais si tu veux un peu de polyvalence dans ta team et ton contexte, ca va demander a ton entreprise du temps de formation et d'avoir l'occasion de pratique de facon assez frequente pour ne pas tous oublier 2 semaine apres la formation. Et ca qui est pret a le payer ?

[GreatDeveloperOnizuka]

Il faut comparer ce qui est comparable, là tu changes de langage et d'environnement. Compare plutôt le passage de React vers Vue et Winform vers WPF. Pour "survoler" le truc (c'est à dire faire un truc qui tourne sans jamais sortir des sentiers battus) c'est comparable, pour le maitriser à mon avis il y a bien plus d'écart du coté wpf/winform. Pour UWP/WPF là par exemple on est beaucoup plus proche.

Oui tu peux, en assembleur aussi, mais là tu parles de serveur http. Ton rendu ne sera qu'un fichier texte. Tu vas mettre des balises (html) et éventuellement du JS, ca ne fera que "polluer" le texte. C'est le rôle d'un autre logiciel (le navigateur bien souvent) d’interpréter le HTML et le JS. C# n'a rien à voir la dedans!

Si on part de là, du coup tu peux pas faire des sites avec tout le reste stricto en fait (Java, Php, etc.).

Sinon oui, je parle de se débrouiller avec pas de maitriser le truc (totalement inutile dans 95% du temps vu les changements rapidos qu'on subit).

[Alexcouter]

J'étais tombé sur un article il y a deux ans sur l'art de faire raconter n'importe quoi à une dataviz, notamment en ne prenant pas des échelles orthonormées...

L'échelle est, je pense, surtout "Parigonormée" ! talent.io doit fonctionner en majorité sur la région parisienne (en tout cas à l'époque peu de postes en Bretagne). En plus, vu leur stratégie de comm' ils ciblent déjà le haut du panier et fait de la pub pour des postes dans de grosses sociétés qui serait donc peut-être le reflet du salaire des postes auditionnés.

Oui historiquement le back est (injustement) mieux payé que le front. Mais les chiffres avancés par cette société me semblent un peu élevés (à moins que ça soit le coût BRUT destiné aux employeurs).

[Invité]

J'étais tombé sur un article il y a deux ans sur l'art de faire raconter n'importe quoi à une dataviz, notamment en ne prenant pas des échelles orthonormées...

Petit cours d'autodéfense intellectuelle de Normand Baillargeon ?

[micka132]

Si on part de là, du coup tu peux pas faire des sites avec tout le reste stricto en fait (Java, Php, etc.).

C'est parce que C# n'est qu'un langage, alors que lorsque l'on parle de Java ou de Php il s'agit également d'un framework (un ensemble de librairie). En C# tu peux utiliser le sous framework .Net web qui est Asp.net (WebForms ou MVC), mais il faut tout de même le coupler avec du HTML/JS/CSS pour pouvoir gérer ton affichage. Ce n'est donc pas vraiment avec du C#(ni java/php) que tu fais du front Web.
Note que c'était le cas avec Silverlight, ou bien les applets en Java: tu ecris du c#/java et tu peux piloter les éléments de ton interface.

[Pierre Fauconnier]

[...]

Oui historiquement le back est (injustement) mieux payé que le front. Mais les chiffres avancés par cette société me semblent un peu élevés (à moins que ça soit le coût BRUT destiné aux employeurs).

Je rappelle qu'au départ, le sujet de l'article, c'est Fullstack vs Back, et pas Front vs Back... Cela dit, je te rejoins: il est injuste que le Front soit moins bien payé que le back.

[GreatDeveloperOnizuka]

C'est parce que C# n'est qu'un langage, alors que lorsque l'on parle de Java ou de Php il s'agit également d'un framework (un ensemble de librairie). En C# tu peux utiliser le sous framework .Net web qui est Asp.net (WebForms ou MVC), mais il faut tout de même le coupler avec du HTML/JS/CSS pour pouvoir gérer ton affichage. Ce n'est donc pas vraiment avec du C#(ni java/php) que tu fais du front Web.
Note que c'était le cas avec Silverlight, ou bien les applets en Java: tu ecris du c#/java et tu peux piloter les éléments de ton interface.

C'est ce que je dis oui, tu fais pas du front avec du java php.

[Mingolito]

C'est normal que le back end soit mieux payé que le front end, le back end c'est le noyaux de l'application avec toute la partie importante, la conception de la base de données, et très peu de développeurs sont bons en bases de données, un développeur bon en base de données ça vaux de l'or. S'il a fait un bon schéma et de bonne requêtes SQL l'application sera saine et performante, si son schéma est merdique ainsi que ses requêtes l'application sera lente voir buguée. Parfois dans une fournée de nouveaux développeurs à peine un sur 10 sait faire un schéma de données correct, c'est celui la qu'il faut payer à prix d'or et les autres c'est du menu fretin, des grouillots HTML, ça mérite à peine le Smic.
Un bon développeur Back end ça peu être formé parfois en 5 ans, Master, ingénieur, donc des formations avec de vrais modules de bases de données, d'algo, de modélisation, et de méthodes.
Comparativement un webmaster front end c'est jamais plus qu'une espèce de secrétaire html avancée, c'est ça que les bootcamp forment en 3 à 6 mois.

Donc le full stack en fait il sera en PME le plus souvent, ou en web agency qui travaille pour les pme, alors que le back end il sera dans un groupe de travail plus grand, dans une grande entreprise ou une grosse SSII qui à pour client de grandes (et riches) entreprises, donc mieux payé. Tout cela est logique.