Quel degré de liberté un programmeur devrait-il avoir pour choisir un langage et un framework?


67

J'ai commencé à travailler dans une entreprise principalement orientée C #. Nous avons quelques personnes qui aiment Java et JRuby, mais une majorité de programmeurs ici aiment C #. J'ai été embauché parce que j'ai beaucoup d'expérience dans la construction d'applications Web et que je me tourne vers les nouvelles technologies telles que JRuby on Rails ou nodejs.

J'ai récemment commencé un projet de création d'une application Web axée sur la réalisation de nombreuses tâches en peu de temps. Le responsable logiciel a dicté que j'utilise mvc4 au lieu de rails. Cela pourrait être OK, sauf que je ne connais pas mvc4, je ne connais pas C # et que je suis le seul responsable de la création du serveur d'applications Web et de l'interface utilisateur frontale.

Ne serait-il pas judicieux d'utiliser un framework que je connais déjà extrêmement bien (Rails) au lieu d'utiliser mvc4? Le raisonnement derrière cette décision était que le responsable technique ne connaissait pas Jruby / rails et qu'il n'y aurait aucun moyen de réutiliser le code.

Contre-arguments:

  • Il ne contribuera pas au code et, franchement, il n'est pas nécessaire pour
    ce projet. Donc, peu importe qu'il connaisse ou non JRuby / rails.

  • En réalité, nous pouvons réutiliser le code car nous disposons de nombreuses applications java sur lesquelles JRuby peut extraire du code, et inversement. En fait, il a consacré certaines ressources à la conversion d'une bibliothèque Java en C #, au lieu de simplement exécuter la bibliothèque Java sur l'application JRuby on Rails. Tout ça parce qu'il n'aime pas Java ou JRuby

J'ai construit de nombreuses applications Web, mais utiliser quelque chose d'inconnu est en train de créer des difficultés et je ne parviens pas à créer une application géniale aussi rapidement que je suis habitué. Ce serait bien; L’apprentissage des nouvelles technologies est important dans ce domaine. Le problème est que, pour ce projet, nous devons accomplir beaucoup de choses rapidement.

À quel moment un développeur devrait-il être autorisé à choisir ses outils? Cela dépend-il de l'entreprise? Est-ce que mon entreprise craint ou est-ce considéré comme normal? Existe-t-il des pâturages plus verts? Est-ce que je regarde ça de la mauvaise façon?


45
"Défier les ordres" dans un domaine comme celui-ci peut constituer un obstacle à la carrière.
Dan Pichelman


39
Les entreprises préfèrent normaliser les outils car cela réduit les coûts, tant du point de vue de l'achat d'une application que de la gestion de leurs ressources. La gestion des licences prend en réalité beaucoup de temps. De plus, si chacun utilise son propre langage / outils de choix, il est beaucoup plus difficile de mélanger les gens d'un travail à l'autre. Enfin, vos plaintes concernant votre avance sur le logiciel sont identiques à la raison pour laquelle vous souhaitez utiliser l'outil de votre choix. Vous n'êtes pas familier avec mvc4 ou vous ne l'aimez pas. Sw est l’avance, c’est donc leur appel, à moins que vous ne puissiez présenter un argument qui puisse leur faire changer d’avis.
Dunk

22
Tout cela aurait dû être abordé lors de votre entretien d'embauche.
user16764

30
Êtes-vous un programmeur ou un programmeur Ruby ? Les langues doivent être comme des outils. Certains ont des forces ou des faiblesses, mais il appartient à l'artisan de les exploiter au mieux. La société a dicté un ensemble d’outils standard pour des raisons évidentes.

Réponses:


98

Je dirais que vous devez parler au chef d'équipe et dire quelque chose comme:

Je sais que vous êtes un magasin .NET, mais j'ai en fait été embauché pour mes compétences en Java / JRubyRails. Je peux construire cette nouvelle application en un temps X en utilisant ces outils que je connais déjà. Je pourrais apprendre le C # / mvc4 comme vous le souhaitez, mais cela prendra >> X fois. Qu'est-ce que vous voulez?

Cela pose la question de « compétences-vous-garous ( en supposant qu'il) -hired-pour » contre « les compétences doivent-maintenant-vous- » et montre aussi que vous êtes prêt à apprendre les nouvelles compétences, mais qu'il se prendre plus de temps pour développer la nouvelle application à mesure que vous débutez dans cet ensemble d’outils. Et vous ne voulez montrer que vous êtes prêt à apprendre de nouvelles compétences. Ne pas être ouvert à l’acquisition de nouvelles compétences est un bon moyen de garantir la cessation de votre emploi lorsque vos compétences ne sont plus nécessaires.

En ce qui concerne votre question à la fin:

À quel moment un développeur devrait-il être autorisé à choisir ses outils? Cela dépend-il de l'entreprise? Est-ce que mon entreprise craint ou est-ce considéré comme normal? Existe-t-il des pâturages plus verts? Est-ce que je regarde ça de la mauvaise façon?

Cela dépend généralement de l'entreprise. Si une entreprise achète des outils MS et normalise tout sur la plate-forme VisualStudio et le framework .NET, cela peut devenir très gênant si un développeur insiste sur l'utilisation de Linux et de C, ce qui est normal. Il peut exister des exceptions dans les cas où la société est moins pointilleuse vis-à-vis des éditeurs, par exemple en laissant les développeurs choisir Vi par rapport à Emacs, à condition que le résultat soit identique. Je sais que certaines entreprises laissent même aux développeurs le choix entre Windows et Linux, mais la langue dans laquelle elles travaillent bénéficie d'une prise en charge et d'une exécution très efficaces pour les deux systèmes d'exploitation.

Pourquoi les entreprises font-elles cela? La cohérence est une des raisons. Il peut être très difficile de déboguer des choses lorsque l’application est un patchwork de binaires construits dans les langages / framework favoris de différents développeurs, construits dans différents outils et testés sur des systèmes très différents. Si tous les développeurs travaillent principalement sur des configurations similaires, ces types de problèmes sont résolus.

Dans votre cas, il semble que vous ayez été embauché pour travailler dans une technologie non standard dans cette entreprise. Cela me semble étrange et vous voudrez peut-être parler à la personne qui vous a embauché pour savoir pourquoi elle le voulait.


31
"Je peux construire cette nouvelle application en X fois en utilisant ces outils que je connais déjà. Je pourrais apprendre le C # / mvc4 comme vous le souhaitez, mais cela prendra >> X de temps. Qu'est-ce que vous voulez?" - Très bonne réponse. Cadrez-le sous la forme d'un compromis de coût.
Christian Ternus

D'accord. Tout est question d'économie. Une fois que vous avez mis un point de vue économique sur votre point de vue, TOUT type de leader réel vous entendra et reverra leur position. Rendre le compromis explicite: Ex .: plus de temps implique que les choses vont arriver plus tard implique une échéance qui peut être manquée, ce qui implique un impact sur les revenus . Parfois, ils doivent montrer la voie à suivre pour atteindre l'objectif du «compromis».
PhD

6
+1 La seule façon dont cette réponse ne me satisfait pas, c'est qu'elle minimise légèrement l'aspect d'apprentissage. Un développeur qui est désireux d'apprendre est un atout bien plus précieux que celui qui sait tout et ne changera pas .
Corey

7
+1 J'insisterais également sur le point (implicite) selon lequel si le responsable choisit d'aller de toute façon avec MVC, OP est obligé de s'attacher et de réaliser le projet dans MVC.
Dan Lyons

"Certaines entreprises laissent même les développeurs choisir entre Windows et Linux" - et vous trouverez souvent aussi des utilisateurs de Mac dans le monde Ruby. (Mon entreprise est principalement une boutique Ruby, mais il n'y a aucune restriction sur l'éditeur ou le système d'exploitation - et nous avons actuellement des développeurs utilisant Linux et Mac, mais aucun développeur avec des machines Windows à l'heure actuelle).
Ben Lee

140

À quel moment un développeur devrait-il être autorisé à choisir ses outils?

Quand ils n'ont pas d'impact sur votre équipe.

Est-ce que je regarde ça de la mauvaise façon?

Absolument.

Oui, vous avez un délai court. Oui, vous pouvez le faire plus rapidement dans Rails. Toutefois, l’entreprise dans son ensemble doit déployer et gérer l’application. Si la société dispose d'une base de bons développeurs C #, il sera probablement moins cher (et de meilleure qualité) de disposer d'une application C # à gérer.

Vos administrateurs de base de données et vos autres administrateurs sont probablement familiarisés avec cette pile et disposent de processus pour déployer et mettre à jour cette pile. Même si vous pouvez obtenir le code plus rapidement, cela peut prendre plus de temps une fois que vous avez pris en compte tous les frais généraux nécessaires à la mise en place d'une application Web professionnelle.

N'oubliez pas que vous passerez beaucoup plus de temps à entretenir votre application qu'à l'écrire. Optimiser pour ce coût.


19
Très bonne réponse. "Meilleur" dans ce cas ne signifie pas forcément optimisation pour le développement le plus rapide , en particulier pour le programmeur initial . Du point de vue commercial, l'application passera probablement beaucoup plus de temps en mode maintenance et sera prise en charge par toute l'équipe , c'est donc ce qui devrait guider la décision du cadre.
Eric King

4
Je pense que ce sont généralement des conseils judicieux. Je ne l'ai pas choisie comme solution car, dans mon cas particulier, de nombreuses préoccupations ne s'appliquent pas. Je serai responsable de la configuration du déploiement et du déploiement de l'application. Je suis définitivement d'accord avec le maintien, c'est une préoccupation valable. Qui sait où je serai dans quelques années lorsque quelqu'un aura besoin de mettre à jour le code.
Spencer

2
La probabilité est que vous n’ayez en réalité PAS été embauché pour vos compétences dans JRuby / Rails, mais que vous ayez été embauché pour votre expérience dans la création d’applications Web et que ce qu’ils recherchent réellement est de l’utiliser dans le contexte de MVC4 et C #.
Jay Stevens

Même si vous faites valoir de bons arguments, il n’a toujours aucun sens de le faire. Pourquoi ne pas demander à l'un des gars C # de le faire? Tout ce qu'ils vont faire, c'est donner à ce gars l'impression qu'il n'a pas la propriété de ses projets, le faire se sentir épuisé et le pousser à quitter l'entreprise.
s73v3r

@ s73v3r - J'espère que le PO sait dans quoi il s'embarque. Honnêtement, si vous avez un chargement complet de développeurs C # (et de codebase), cela devrait être évident pour le responsable de Rails lors de l’entrevue. S'il
acceptait

41
  1. Vous avez apparemment été embauché en raison de votre capacité à vous adapter aux "nouvelles" technologies. C # n'est pas différent, à cet égard. Êtes-vous sûr de ne pas vouloir profiter de l'occasion pour apprendre quelque chose de nouveau?

  2. ASP.NET MVC est très similaire à Ruby on Rails, à bien des égards.

  3. Vous ne serez pas au pas d'un escargot pour toujours. Si vous connaissez déjà ROR, ASP.NET MVC sera un jeu d'enfant pour vous. L'astuce consiste à apprendre le C #.


18
+1, vous attacher à un seul langage / framework est idiot. Saisissez l'occasion d'être payé pour apprendre de nouvelles choses. Et .NET a beaucoup de développement actif et intéressant en cours.
Jozefg

Je conviens qu’elles sont semblables, mais il existe des différences importantes qui peuvent prendre beaucoup d’heures. Étant donné le nombre limité d’heures pour le projet, je pense que le rail est le choix évident. Je ne suis pas contre l'apprentissage de nouvelles choses comme je l'ai mentionné dans la question.
Spencer

L'élément n ° 1 n'est pas évident - le PO indique qu'ils ont été embauchés en raison de leur expérience en Java / JRuyb / Rails / nodejs: j'ai été embauché en raison de ma grande expérience dans la création d'applications Web et parce que je me tourne vers de nouvelles technologies telles que JRuby on Rails. ou nodejs. Le PO ne parle pas de leur adaptabilité ou que leur adaptabilité est la raison pour laquelle ils ont été embauchés.
FrustratedWithFormsDesigner

2
+1, d'accord, je n'ai jamais compris les arguments du genre "Je sais très bien faire A en langage L1 mais je ne peux absolument pas le faire en langage L2".
Shivan Dragon

2
@Spencer: lorsque vous nous demandez un conseil et que chaque personne vous donne le même conseil, vous devriez probablement l'accepter. Inutile de contester les réponses quand vous admettez, mais posez la question, vous ne savez pas quelle est la bonne réponse.
Andrew Coonce

21

Arguments pour rester avec Java / JRuby

Les chances sont, votre patron veut que vous produisiez. Ils vous ont embauché pour que vous puissiez ajouter de la valeur à l'entreprise. Assurez-vous qu'ils comprennent qu'en vous forçant à utiliser un framework avec lequel vous n'êtes pas familier, ils vous feront :

  1. Produire des résultats plus lentement
  2. Créer un code de qualité inférieure

Même les meilleurs programmeurs ont besoin de temps de préchauffage avec de nouveaux langages / frameworks.

Arguments pour l'apprentissage MVC4 et C #

Apprendre de nouvelles langues, c'est bien. Investir dans vos compétences en tant que programmeur ne constitue un risque que si le langage / la plate-forme que vous apprenez va disparaître dans un proche avenir. Avec Microsoft, je ne pense pas que ce soit un problème. C # et MVC ont eu des mises à jour récentes les améliorant tous les deux, avec encore plus de mises à jour dans le pipeline.

Faire de vous, personnellement, un développeur plus complet vous évitera de vous retrouver dans cette situation. La meilleure partie? Votre patron vous paiera pour apprendre ces choses, ce qui signifie que vous serez payé pour gagner plus d'argent.

Le résultat final

Vous pouvez finir par gagner ce combat, mais il vous restera à travailler avec des collègues mécontents. Expliquez simplement les avantages et les inconvénients de chacun à votre responsable et vous en sortirez tous les deux plus heureux.


11
+1, "ce qui signifie que vous êtes payé pour gagner plus d'argent" au bingo!
GrandmasterB

Comme le soulignent cette question (et plusieurs réponses), il existe un compromis entre la création initiale de votre temps et le déploiement / la maintenance par tous les autres. Faites un effort décent (mais respectueux) pour voir si les Pointy-Hairs sont disposés à faire ce commerce, mais sinon, respectez leur décision et appréciez être payés pour apprendre quelque chose de nouveau pendant les heures de travail.
Brichins

@ Brichins: Je pense que l'un des gros problèmes de cette réponse est qu'elle ne précise pas ce que vous dites!
Ruakh

@ruakh J'avais du mal à trouver la réponse sur laquelle laisser ce commentaire - vous avez raison, celui-ci ne traite pas de cet échange spécifique (bien qu'il indique la tension qui pourrait en résulter sur le lieu de travail). J'aurais probablement aussi dû spécifiquement dire que le PO devrait être sûr qu'il parle à tous les décideurs (sans que personne ne le oublie) pour que si / lorsque le projet ne respecte pas l'échéance, il puisse transmettre poliment "je vous ai dit peut-être pour le prochain projet nous pourrions essayer Ruby à la place? "
Brichins

18

À quel moment un développeur devrait-il être autorisé à choisir ses outils?

Lorsque ledit développeur est le logiciel en tête.

Certes, vous pouvez (et devriez) plaider en faveur de l’utilisation de la trousse à outils différente si vous êtes préoccupé par la productivité, mais préparez-vous à une réponse qui ne vous plaira pas. Il y a peut-être une bonne bonne raison pour laquelle votre chef d'entreprise souhaite que vous utilisiez une boîte à outils spécifique, que ce soit pour la compatibilité avec l'architecture actuelle, pour des problèmes de maintenance, pour des problèmes de licence, etc.

BTW, la phrase

avec un accent sur faire beaucoup de choses dans un court laps de temps

est responsable de plus de brûlures d'estomac et de chaos dans l'industrie du logiciel que n'importe quoi d'autre.


2
+1 "Quand ledit développeur est le logiciel en tête." Exactement. Parfois, lorsque vous défendez votre argument et que votre responsable n’est pas d’accord avec vous, c’est parce que votre interlocuteur a une meilleure vision de la situation dans son ensemble. C'est l'une de ces situations.
Andrew Coonce

Être en désaccord. De cette façon, vous ne conduisez vos subordonnés vers rien d’autre que des suiveurs qui oublieront comment prendre des décisions et en assumeront la responsabilité. Si tu veux ça - bien. Je pense qu'il y a des endroits où les gens seront plus intelligents que vous en tant que chef d'équipe. Mais oui, certaines personnes ont un problème avec cela, et c'est tragique.
JensG

J'ai sérieusement ri de votre réponse à "est responsable de plus de brûlures d'estomac et de chaos dans l'industrie du logiciel que n'importe quoi d'autre." ... merci! Je n'aurais pas pu mieux l'exprimer!
Alexus

11

Je remarque que vous ne dites pas que vous avez été embauché en tant que programmeur JRuby ou Java.

Voici pourquoi vous avez été embauché: "Parce que j’ai beaucoup d’expérience dans la construction d’applications Web et que je me tourne vers de nouvelles technologies telles que JRuby on Rails ou nodejs."

En d'autres termes, ils aiment votre expérience Web et votre volonté d'apprendre de nouvelles technologies.

Maintenant, ils vous demandent d'utiliser votre expérience Web et d' apprendre une nouvelle technologie.

La question est donc de savoir si vous allez le faire ou non.


9

La plus grosse dépense en logiciel est dans la maintenance de celui-ci

J'ai lu que la dépense la plus importante (80%) concerne la maintenance des logiciels. Le développement initial ne représente que 20% du coût total du développement.

J'ai lu un cas concernant un développeur qui a développé du code et des commentaires dans sa langue maternelle (pas l'anglais) et lorsque les autres membres de l'équipe sont allés améliorer et maintenir le code, c'était presque impossible car le langage (pas n'importe quel langage de programmation) était étranger pour eux.

De même, si vous développez du code dans un langage de programmation de votre choix, il sera difficile à gérer pour les autres membres de l'équipe.

Solution: Programmation par paires

Pensez à demander à vos employeurs de vous mettre en relation avec une autre personne connaissant le langage de programmation requis et pouvant travailler ensemble. Vous pouvez apprendre les uns des autres et si l'un de vous quitte la société, l'autre connaît le code.

Article Wikipedia sur "Programmation en binôme": http://en.wikipedia.org/wiki/Pair_programming


3
Si vous écrivez quelque chose que vous seul comprenez, alors vous serez bloqué pour le maintenir pour toujours.
Jwernerny

6

De nombreuses entreprises préfèrent simplement s'en tenir à ce qu'elles ont toujours fait ou à ce qui est "sûr". Il y a une raison pour laquelle Java et PHP sont toujours très populaires. Pour le moment, la recherche de "COBOL" sur Indeed.com renvoie 2144 annonces ... qui devraient vraiment parler pour lui-même. L'industrie ne se soucie pas du bon code, elle se soucie du code car elle peut traire le plus longtemps possible (cela ne veut pas dire que C # est mauvais, ce n'est vraiment pas le cas).

Pensez-y: le code va vous survivre. Il y a de bonnes chances que quelqu'un d'autre maintienne votre code et C # est un pari plus sûr que Node.js et Rails. Cela ne me surprendrait pas si, dans 5 ou 6 ans, le nombre de programmeurs Ruby diminuait de moitié, après que Perl et tout autre langage ayant été considéré à un moment donné comme étant le langage Web "it". Javascript n'est pas susceptible de disparaître, mais nous commençons déjà à le voir utilisé comme une sorte d'ASM (ou même C) du Web - un langage intermédiaire que d'autres langages peuvent compiler pour pouvoir y écrire du code côté serveur. très bien devenir obsolète.


4
Bien que cela soit vrai, il est plutôt peu pratique pour un magasin C # d'engager un développeur Ruby qui ne connaît pas C #, sans préciser clairement que le travail pour lequel il est embauché concerne principalement le développement de C #.
Carson63000

5

Mon souci principal avec les développeurs qui choisissent comment implémenter leurs objectifs, est qu'ils supposent normalement qu'ils éditeront le code. Regardez cela ainsi, 12 mois plus tard, ils pourraient avoir besoin de changements; vous n'êtes pas disponible (a quitté l'entreprise ou est vraiment occupé par une autre tâche), et un autre développeur doit convertir votre code. Si c'est un magasin C #, alors utiliser leurs outils est un bon travail d'équipe. Les nouvelles technologies devraient être étudiées et mises en œuvre, mais seulement lorsque le responsable estime que le moment est opportun, car il a pour objectif de nombreux objectifs, et pas seulement un.


3

Retournez-le, s'il vous plaît. Imaginez que vous ayez embauché un développeur Ruby et qu'ils insistent pour mettre en œuvre leur travail dans Asp.net/MVC.

Que leur diriez-vous? Ceci est notre pile, mec. Apprenez à vivre avec.

La règle d'or, ici, c'est celle qui a l'or qui établit les règles.


1
Mais pourquoi engageriez-vous quelqu'un qui insiste sur l'utilisation de .NET pour un rôle Ruby?
Bobson

3
@Bobson, parce qu’il s’agit d’un jeune et brillant programmeur qui semble être en mesure de résoudre les problèmes à l’aide de différentes technologies, de résoudre les problèmes généraux de programmation de manière satisfaisante et de postuler au poste.

2
@Bobson: Vous soutenez donc que les entreprises ne devraient pas embaucher de développeurs qui n'ont pas l'expérience du langage de leur choix. Tous les autres semblent prétendre que le nouveau langage peut être appris très rapidement, de sorte que l'entreprise ne doit pas confier un bon développeur à un simple développeur, simplement parce qu'il n'est pas un expert dans un langage particulier ... pour l'instant.
Dunk

2
" J’ai été embauché parce que j’ai beaucoup d’expérience dans la conception d’applications Web et que je m’intéresse aux nouvelles technologies telles que JRuby on Rails ou nodejs." - cela n’a pas été embauché en tant que développeur XYZ, c’est "embauché en tant que développeur Web expérimenté dans les nouvelles technologies" (pour lequel la société pourrait être intéressée par la mise à jour à venir).

3
@Bobson: Lorsque je suis embauché dans une nouvelle entreprise, non seulement je sais ce que je vais apporter à la table, mais je sais aussi sur quel projet je vais travailler et ce qu'ils attendent de moi. Si le PO ne pouvait pas être dérangé pour trouver cette information, honte à lui. Cela dit, je pense que c'est vraiment le cas de la société qui embauche quelqu'un qui, à son avis, est un bon développeur possédant des connaissances de domaine pertinentes pour venir aider l'équipe, avec l'espoir que la collecte des données mvc4 constitue un obstacle mineur. Peut-être que la compagnie n’a pas bien expliqué la situation, mais le PO n’a pas fait sa part non plus.
Dunk

2

Il y a plusieurs objectifs contradictoires et le problème est de trouver le meilleur compromis. Nous avons la date limite, nous avons un chef d’équipe qui demande un certain ensemble d’outils, et nous avons un développeur inexpérimenté avec cet ensemble d’outils, mais condamné à produire quelque chose dans un délai (évidemment court).

Il est important de comprendre que le chef d’équipe a probablement de bonnes raisons de demander exactement cet ensemble d’outils (l’un d’eux pourrait bien vous habituer à cet ensemble d’outils pour une raison que vous ignorez peut-être encore). La meilleure chose que vous puissiez faire au premier essai est de déterminer exactement quelles sont ces raisons.

Mis à votre place, j'essaierais de parler au responsable de l'équipe et d'essayer d'expliquer la situation, telle qu'elle est à votre avis, et quelles options et quels résultats (y compris les effets économiques à court et à long terme) seront générés suivant chacune de ces options. Par exemple, un autre développeur plus expérimenté pourrait être chargé de vous coacher, éventuellement avec des sessions de programmation en binôme ou similaires.

À moins que votre chef d'équipe ne soit complètement débile, vous devriez être en mesure de trouver un consensus qui ait du sens en ce qui concerne le projet et les objectifs généraux de l'entreprise.


2

Bah. Tout le monde a tort.

Devenez un meilleur développeur que les utilisateurs de la plate-forme unique et vous aurez des options beaucoup plus intéressantes que jamais. Donc, pour l'instant, apprenez le MVC. Et à votre rythme, apprenez-en davantage sur les plateformes qui vous intéressent vraiment. Développez vos compétences de nœud. Apprenez du Django. Faites attention à toutes les manœuvres Java ou pré-MVC .NET auxquelles vous êtes exposé, puis fuyez, mais apprenez-en au moins suffisamment pour pouvoir critiquer et expliquer à quel point vous avez pensé à ces préjugés inspirés par la haine, à peine dissimulés. (d'accord, peut-être que je projette là)

Et maintenant pour le conseil important. Si vous continuez à perfectionner vos spécialités tout en diversifiant votre expertise dans d'autres domaines, vous serez éventuellement dans un endroit où vous pourrez trouver du travail à tout moment de l'année en moins de deux semaines, dans n'importe quelle grande ville surtout intéressant au moins la moitié du temps. Lorsque vous vous trouvez dans cet endroit, ne vous contentez pas de ces emplois, où ils disent vouloir cela, et dès le deuxième jour, ils vous feront CELA, sans espoir de sursis à long terme. Juste expliquer poliment et présenter des excuses, mais non, vous ne vouliez vraiment pas faire CELA et vous en avez dit autant lors de votre entretien et ensuite! @ le fait qu'ils ont mal présenté la position et refusent de le reconnaître.

Mais croyez-moi, trouver un nouveau poste est toujours mieux que d'être énervé et malheureux pendant plus de 5 minutes. Mais bien sûr, vous devez d’abord payer vos cotisations pour pouvoir le faire. Certaines personnes ne le feront jamais. C'est pourquoi ils veulent tout ce qu'ils connaissent le mieux. Et bien sûr, les autres réponses ne sont pas vraiment fausses. Il est logique qu'un magasin .NET soit associé à .NET s’il doit maintenir la bêtise.

Bien entendu, ce qui n’a aucun sens est de savoir pourquoi ils se diversifieraient avec un développeur Rails / JS / UI et lui demanderaient uniquement de créer des applications MVC. Mais pour l'instant. Vous devrez peut-être le ramasser et payer votre cotisation. Et comme je l'ai dit dans les commentaires, MVC n'est vraiment pas si mal. Un très mauvais choix étant donné toutes les options mais certainement pas le pire. C'est assez simple, ne jette pas 10 000 couches d'abstraction au-dessus de tout ce qui se passe réellement, et ne se fait pas si tordu avec le côté client que vous maudriez les noms des ingénieurs MS responsables si quelqu'un pouvait être dérangé les apprendre.

Rendez-vous à cet endroit où vous pouvez partir quand vous le souhaitez si vous ne l’avez pas déjà fait et vous pourriez même vous rendre compte que vous avez un œil plus sceptique sur ce que vous aimez actuellement. Vous pourriez même vous retrouver à ne pas aimer les rails autant que moi. Non pas que Ruby a un problème (à part son interprète bien sûr).


1

Selon votre situation, il peut être dangereux de supposer que vous savez pourquoi ils vous ont embauché, et encore plus de supposer que votre supérieur hiérarchique le sait et convient qu'embaucher des personnes possédant vos compétences est une bonne idée.

Je vous demanderais de suivre les conseils ci-dessus et de vous expliquer pourquoi vous devriez utiliser JRuby au lieu de C #. Peut-être que votre argument et vos échéances signifient qu'il est logique de rompre avec les anciennes méthodes. Je ne voudrais pas simplement supposer que tout va bien, donner le responsable ou expliquer les faits et les laisser prendre la décision, c'est ce pour quoi ils sont payés, plus un peu d'ACY.


1

À mon avis, l’un des éléments qui différencient les bons développeurs des meilleurs est leur capacité à s’adapter aux nouvelles technologies. Nous vivons dans un monde en évolution rapide où la technologie de pointe d'aujourd'hui deviendra obsolète demain. Par conséquent, un développeur qui ne veut pas s'adapter est d'une utilité limitée pour l'entreprise. Ce serait bien, sinon pour un fait, il est vraiment difficile de recruter et de recruter de bonnes personnes. Quand une entreprise trouve son joyau, elle planifie à long terme.

J'ai vu des entreprises embaucher hors de leur champ technologique et elles le font pour exactement la même raison. Ils veulent avoir la main sur de grands développeurs, même si cela implique d'attendre qu'ils s'adaptent aux nouvelles technologies.

Maintenant à votre situation. En tant que nouveau membre du groupe, je ferais très attention à ce que je dis et ne le dis pas à mes supérieurs. Bien sûr, vous vous en tirerez beaucoup en partant du principe que vous êtes toujours en train de vous adapter à votre nouvel environnement. Cependant, saper l'autorité et la persévérance obstinée à l'égard de votre technologie préférée ne feront que faire croire à vos supérieurs qu'ils ont commis une erreur en vous embauchant et que vous n'êtes pas disposé à quitter votre zone de confort.

Ce que vous allez choisir dépend de vous, mais je vous suggérerais d'essayer d'apprendre de nouvelles technologies. Cela ne fera pas mal, je le promets.


1

Je vais supposer que vous avez été honnête dès le début de votre entretien concernant votre manque de connaissance de C #, car si vous ne l'étiez pas, vous pourriez vous retrouver dans une position très précaire d'un point de vue juridique.

Les bons programmeurs connaissent la programmation. Bien que personne ne puisse évidemment être au courant de toutes les langues et de tous les cadres, il existe des points communs considérables entre la plupart d'entre elles. À moins que l'on vous demande de travailler dans une langue extrêmement différente de ce qui constitue le grand public de nos jours (Lisp, par exemple), un bon programmeur devrait être capable de s'adapter.

Naturellement, il y a une courbe d'apprentissage. Si l'employeur vous a embauché, il doit avoir confiance en votre capacité à suivre cette courbe dans un délai raisonnable (encore une fois, en supposant que vous avez été honnête dès le départ en ce qui concerne l'absence de connaissance de C #). Le langage C # emprunte énormément à Java et, de manière plus générale, la plupart des langages de programmation basés sur des classes sont fondamentalement assez similaires (vous avez mentionné node.js, qui repose sur ECMAScript, un langage basé sur un prototype. à l'aise avec d'autres paradigmes de programmation.

Les bons programmeurs doivent, en plus d'être flexibles, être désireux d'apprendre de nouvelles choses. En développement logiciel, vous apprenez généralement ou vous perdez votre pertinence.

Bien entendu, votre employeur, supposant qu’il savait que vous ne connaissiez pas C #, doit vous rencontrer à mi-chemin. Si vous êtes désireux d'apprendre, ils doivent vous donner le temps et les ressources nécessaires pour le faire. Il est injuste et stressant de vous jeter au plus profond de vous. Vous devez vous asseoir et avoir une discussion calme et rationnelle avec votre supérieur. S'ils le veulent en C #, ils doivent être prêts à accepter le fait que vous travaillerez sur une courbe d'apprentissage et il serait injuste pour eux de vous imposer des délais serrés. Si les échéances ne sont pas flexibles et si elles revêtent une grande importance stratégique, elles doivent être prêtes à vous laisser une marge de manœuvre pour accomplir le travail dans les délais impartis. S'ils en ont besoin pour être dans la langue la plus utilisée dans leur bureau, vous pouvez alors demander à le mettre en œuvre maintenant dans ce que vous ' Familiarisez-vous avec le respect des délais, puis ré-implémentez-le en C # lors de votre prochain projet. Cela vous permettra de mettre le logiciel en conformité avec les exigences internes une fois que celui-ci sera conforme aux exigences externes. Comme je l'ai dit, la plupart des langages les plus couramment utilisés aujourd'hui ont beaucoup de points communs, c'est donc surtout les détails de la mise en œuvre.

Vous devez être prêt à accepter tôt ou tard votre travail dans un magasin C # et vous devez donc avoir C # sous votre ceinture.


0

Ils ne sont peut-être pas satisfaits de la manière dont tout le monde utilise MVC dans l'environnement .NET. Il pourrait y avoir trop de traitement comme des formulaires Web. Ce n'est pas différent quand une personne ayant une formation en procédures commence en POO, met tout dans une grande classe et continue comme si de rien n'était.

Ce premier projet n'est pas la situation idéale car ils veulent que cela soit fait rapidement. Familiarisez-vous autant que possible avec .NET et commencez à créer des fonctionnalités le plus rapidement possible. Vous n'allez pas aimer votre façon de faire les choses, essayez juste de garder à l'esprit que vous allez commencer à refactoriser ces choses et à appliquer vos compétences dans une autre langue.

Espérons que votre façon d’utiliser MVC4 (en supposant que tout le monde ne le fait pas correctement) dans un style plus Ruby attirera et dissipera tout le monde de la mentalité de Webforms.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.