¿Cuánta libertad debe tener un programador para elegir un lenguaje y un marco?

67

Comencé a trabajar en una empresa que está principalmente orientada a C #. Tenemos algunas personas a las que les gusta Java y JRuby, pero a la mayoría de los programadores les gusta C #. Me contrataron porque tengo mucha experiencia en la creación de aplicaciones web y porque me inclino por tecnologías más nuevas como JRuby on Rails o nodejs.

Recientemente comencé un proyecto para construir una aplicación web con el objetivo de hacer muchas cosas en poco tiempo. El líder del software ha dictado que uso mvc4 en lugar de rieles. Eso podría estar bien, excepto que no sé mvc4, no sé C # y soy el único responsable de crear el servidor de aplicaciones web y la interfaz de usuario front-end.

¿No tendría sentido usar un marco que ya conozco extremadamente bien (Rails) en lugar de usar mvc4? El razonamiento detrás de la decisión fue que el líder tecnológico no conoce Jruby / rails y que no habría forma de reutilizar el código.

Contra argumentos:

  • No contribuirá al código y, francamente, no es necesario en
    este proyecto. Entonces, realmente no importa si conoce a JRuby / rails o no.

  • De hecho, podemos reutilizar el código ya que tenemos muchas aplicaciones Java de las que JRuby puede extraer código y viceversa. De hecho, ha dedicado algunos recursos para convertir una biblioteca Java a C #, en lugar de simplemente ejecutar la biblioteca Java en la aplicación JRuby on Rails. Todo porque no le gusta Java o JRuby

He creado muchas aplicaciones web, pero el uso de algo desconocido está causando algunas revoluciones y no puedo crear una aplicación increíble en el menor tiempo posible. Esto estaría bien; Aprender nuevas tecnologías es importante en este campo. El problema es que para este proyecto necesitamos hacer mucho más rápido.

¿En qué momento se debe permitir a un desarrollador elegir sus herramientas? ¿Depende esto de la empresa? ¿Mi empresa apesta o se considera normal? ¿Existen pastos más verdes? ¿Estoy mirando esto de la manera incorrecta?

Spencer
fuente
45
"Desafiar las órdenes" en algo como esto puede ser un movimiento que limite su carrera.
Dan Pichelman
39
A las empresas les gusta estandarizar las herramientas porque reduce los costos tanto desde el punto de vista de la compra de aplicaciones como también en la administración de los recursos de la empresa. La gestión de licencias en realidad lleva bastante tiempo. Además, si todos usaron su propio idioma / herramientas de elección, entonces poder barajar a las personas entre los trabajos se vuelve mucho más difícil. Finalmente, sus quejas acerca de su liderazgo de ventas son idénticas a las razones por las que desea utilizar su herramienta de elección. No estás familiarizado con mvc4 o no te gusta. El líder sw es el líder, por lo que es su decisión a menos que pueda presentar un argumento que pueda cambiar de opinión.
Dunk
22
Todo esto debería haberse abordado durante su entrevista de trabajo.
user16764
30
¿Eres un programador o un programador Ruby ? Los idiomas deben ser como herramientas. Algunos tienen fortalezas o debilidades, pero depende del artesano hacer el mejor uso de ellos. La compañía ha dictado un conjunto de herramientas estándar por razones obvias.

Respuestas:

98

Diría que tienes que hablar con el líder del equipo y decir algo como:

Sé que ustedes son una tienda .NET, pero en realidad me contrataron por mis habilidades Java / JRubyRails. Puedo construir esta nueva aplicación en X cantidad de tiempo usando esas herramientas que ya conozco. Podría aprender C # / mvc4 como quieras, pero tomará >> X cantidad de tiempo. ¿Qué deseas?

Esto plantea la cuestión de las "habilidades-que-estaban- (presuntamente) -hired-para" frente a "habilidades-que-necesidad-ahora" y también demuestra que usted está dispuesto a aprender las nuevas habilidades, sino que va a tomar más tiempo para desarrollar la nueva aplicación, ya que eres nuevo en este conjunto de herramientas. Y quieres demostrar que estás dispuesto a aprender nuevas habilidades. No estar abierto a aprender nuevas habilidades es una buena manera de asegurar que su empleo termine cuando sus habilidades ya no sean necesarias.

En cuanto a su pregunta al final:

¿En qué momento se debe permitir a un desarrollador elegir sus herramientas? ¿Depende esto de la empresa? ¿Mi empresa apesta o se considera normal? ¿Existen pastos más verdes? ¿Estoy mirando esto de la manera incorrecta?

Por lo general, depende de la empresa. Si una empresa compra herramientas de MS y estandariza todo en la plataforma VisualStudio y .NET framework, podría ser muy incómodo si un desarrollador insiste en usar Linux y C. Eso es normal. Podrían existir excepciones cuando la compañía es menos exigente con los editores, como permitir que los desarrolladores elijan Vi vs. Emacs, siempre que el resultado sea el mismo. Sé que algunas compañías incluso permiten que los desarrolladores elijan Windows vs. Linux, pero el lenguaje en el que trabajan tiene muy buen soporte y tiempos de ejecución para ambos sistemas operativos.

¿Por qué las empresas hacen esto? La consistencia es una de las razones. Puede ser muy difícil depurar cosas cuando la aplicación es un mosaico de binarios creados en los lenguajes / marcos favoritos de varios desarrolladores, integrados en diferentes herramientas y probados en sistemas muy diferentes. Si todos los desarrolladores trabajan en configuraciones en su mayoría similares, se resuelven ese tipo de problemas.

En su caso, parece que lo contrataron para trabajar en tecnología que no es estándar en esta empresa. Esto me parece extraño, y es posible que desee hablar con la persona que lo contrató sobre por qué querían eso.

FrustratedWithFormsDesigner
fuente
31
"Puedo construir esta nueva aplicación en X cantidad de tiempo usando esas herramientas que ya conozco. Podría aprender C # / mvc4 como quieras, pero tomará >> X cantidad de tiempo. ¿Qué quieres?" - Gran respuesta. Enmarquelo en forma de una compensación de costos.
Christian Ternus
Convenido. Se trata de economía. Una vez que ponga un giro económico a su punto de vista, CUALQUIER líder que sea real, lo escuchará y reconsiderará su postura. Explique explícitamente la compensación: Ej .: Más tiempo implica que las cosas sucederán más tarde, implica una fecha límite que tal vez se pierda, lo que implica un impacto en los ingresos . A veces, necesitan mostrar el camino hacia el objetivo de la "compensación" en esencia.
PhD
66
+1. La única forma en que esta respuesta no me satisface es que desestima ligeramente el aspecto del aprendizaje. Un desarrollador con ganas de aprender es un activo mucho más valioso que uno que sabe todo sobre una cosa y no cambiará .
Corey
77
+1 También enfatizaría el punto (implícito) de que si el líder elige ir con MVC de todos modos, OP está obligado a abrocharse el cinturón y hacer el proyecto en MVC.
Dan Lyons
"Algunas compañías incluso permiten que los desarrolladores elijan Windows vs. Linux", y a menudo también encontrarás usuarios de Mac en el mundo de Ruby. (Mi empresa es principalmente una tienda Ruby, pero no hay restricciones en el editor o el sistema operativo, y tenemos desarrolladores que usan Linux y Mac en este momento, aunque actualmente no hay desarrolladores con máquinas Windows).
Ben Lee
140

¿En qué momento se debe permitir a un desarrollador elegir sus herramientas?

Cuando no impactan a tu equipo.

¿Estoy mirando esto de la manera incorrecta?

Absolutamente.

Sí, tienes un plazo corto. Sí, podrías hacerlo más rápido en Rails. Pero la compañía en su conjunto necesita implementar y mantener la aplicación. Si la empresa tiene un grupo estable de buenos desarrolladores de C #, entonces probablemente será más barato (y producirá una mejor calidad) tener una aplicación C # para mantener.

Sus DBA y otro personal administrativo probablemente estén familiarizados con esa pila y tengan procesos establecidos para implementar y actualizar esa pila. Incluso si puede hacer el código más rápido, podría llevar más tiempo una vez que tenga en cuenta todos los gastos generales necesarios para poner en funcionamiento una aplicación web profesional.

Recuerde, pasará mucho más tiempo manteniendo su aplicación que escribiendola. Optimizar para ese costo.

Telastyn
fuente
19
Gran respuesta. "Mejor" en este caso puede no significar la optimización para el desarrollo inicial más rápido , específicamente para el programador inicial . Desde la perspectiva empresarial, la aplicación probablemente pasará mucho más tiempo en modo de mantenimiento y con el apoyo de todo el equipo , por lo que eso es lo que debería impulsar la decisión del marco.
Eric King
44
Creo que este es generalmente un buen consejo. No lo seleccioné como la respuesta porque, en mi caso particular, muchas de las preocupaciones no se aplican. Seré responsable de configurar la implementación y la implementación de la aplicación. Definitivamente estoy de acuerdo con la parte de mantenimiento, es una preocupación válida. Quién sabe dónde estaré en unos años cuando alguien necesite actualizar el código.
Spencer
2
La probabilidad es que usted NO haya sido contratado por sus habilidades en JRuby / Rails, pero fue contratado por su experiencia en la creación de aplicaciones web y lo que realmente buscan es utilizarlo en el contexto de MVC4 y C #.
Jay Stevens
Si bien haces buenos puntos, aún no tiene ningún sentido tener al tipo que no tiene experiencia en esa pila, y presumiblemente no tiene interés en hacerlo. ¿Por qué no hacer que uno de los chicos de C # lo haga? Todo lo que van a hacer es hacer que este tipo sienta que no es dueño de sus proyectos, y hacer que se sienta agotado, y llevarlo a abandonar la empresa.
s73v3r
@ s73v3r: espero que el OP sepa en qué se está metiendo. Honestamente, si tienes una gran cantidad de desarrolladores de C # (y código base), eso debería ser evidente para el chico de Rails durante la entrevista. Si tomó el trabajo y luego se niega a hacer lo que le contrataron ...
Telastyn
41
  1. Aparentemente fue contratado por su capacidad de adaptarse a "nuevas" tecnologías. C # no es diferente, en ese sentido. ¿Estás seguro de que no quieres aprovechar la oportunidad para aprender algo nuevo?

  2. ASP.NET MVC es muy similar a Ruby on Rails, en muchos sentidos.

  3. No estarás a paso de tortuga para siempre. Si ya conoce ROR, ASP.NET MVC será muy fácil para usted. El truco es aprender C #.

Robert Harvey
fuente
18
+1, vincularte a un solo idioma / marco es una tontería. Aproveche la oportunidad de recibir un pago por aprender cosas nuevas. Y .NET tiene mucho desarrollo activo e interesante.
jozefg
Estoy de acuerdo en que son similares, pero hay diferencias significativas que pueden sumar muchas horas. Dado un número finito de horas para el proyecto, creo que los rieles son la opción clara. No estoy en contra de aprender cosas nuevas como mencioné en la pregunta.
Spencer el
El elemento n. ° 1 no es obvio: el OP dice que fueron contratados debido a su experiencia en Java / JRuyb / Rails / nodejs: me contrataron porque tengo mucha experiencia en la construcción de aplicaciones web y porque me inclino hacia tecnologías más nuevas como JRuby on Rails o nodejs. El OP no habla de su adaptabilidad o de que su adaptabilidad es la razón por la que fueron contratados.
FrustratedWithFormsDesigner
2
+1, de acuerdo, nunca he entendido los argumentos del género "Sé perfectamente cómo hacer A en el lenguaje L1 pero soy completamente incapaz de hacerlo en el lenguaje L2".
Shivan Dragon
2
@Spencer: Cuando nos pides consejos, y cada persona te da el mismo consejo, probablemente deberías aceptarlos. No tiene sentido argumentar en contra de las respuestas cuando admites, pero al hacer la pregunta, no sabes cuál es la respuesta correcta.
Andrew Coonce
21

Argumentos para quedarse con Java / JRuby

Lo más probable es que tu jefe quiera que produzcas. Te contrataron para que pudieras agregar valor a la empresa. Asegúrese de que entiendan que al obligarlo a usar un marco con el que no está familiarizado, lo harán :

  1. Produzca resultados a un ritmo más lento
  2. Crear código de menor calidad

Incluso los mejores programadores requieren tiempo de calentamiento con nuevos lenguajes / marcos.

Argumentos para aprender MVC4 y C #

Aprender nuevos idiomas es bueno. Invertir en tus habilidades como programador es solo un riesgo si el lenguaje / plataforma que estás aprendiendo va a desaparecer en el futuro cercano, y con Microsoft avanzando, no creo que eso sea un problema. C # y MVC han tenido actualizaciones recientes que los han mejorado a ambos, con aún más actualizaciones en proceso.

Convertirlo personalmente en un desarrollador más completo evitará que vuelva a estar en esta situación. ¿La mejor parte? Tu jefe te pagará por aprender estas cosas, lo que significa que te pagan para que valgas más dinero.

La línea de fondo

Puede terminar ganando esta pelea, pero se quedará trabajando con colegas descontentos. Simplemente explique los pros y los contras de cada uno a su gerente y luego ambos saldrán más felices.

Ampt
fuente
11
¡Bingo "1", lo que significa que te pagan para hacerte valer más dinero!
GrandmasterB
Como esto (y varias de las respuestas) señalan, existe una compensación entre la creación inicial de su tiempo y la implementación / mantenimiento por parte de todos los demás. Haga un esfuerzo decente (pero respetuoso) para ver si los Pointy-Hairs están dispuestos a hacer ese intercambio, pero si no solo respetan su decisión y disfrutan de recibir un pago por aprender algo nuevo en el tiempo de la empresa.
brichins
@brichins: ¡Creo que uno de los grandes problemas con esta respuesta es que en realidad no señala lo que usted dice que sí!
ruakh
@ruakh Estaba teniendo problemas para averiguar en qué respuesta dejar este comentario: tiene razón, esta no aborda esa compensación específica (aunque sí señala la tensión en el lugar de trabajo que podría resultar). Probablemente también debería haber dicho específicamente que el OP debería estar seguro de que ha hablado con todos los tomadores de decisiones (sin pasar por alto la cabeza de nadie) para que si / cuando el proyecto no cumpla con la fecha límite, pueda transmitir cortésmente "Te lo dije frente a lo que probablemente lo haría. ¿Quizás para el próximo proyecto podamos probar Ruby?
brichins
18

¿En qué momento se debe permitir a un desarrollador elegir sus herramientas?

Cuando dicho desarrollador es el líder del software.

Ciertamente, puede (y debe) defender el uso de diferentes herramientas si le preocupa la productividad, pero esté preparado para una respuesta que no le gustará. Puede haber una buena razón por la cual su cliente potencial quiere que use un kit de herramientas específico, ya sea compatibilidad con la arquitectura actual, preocupaciones sobre mantenimiento, problemas de licencia, etc.

Por cierto, la frase

con un enfoque en hacer muchas cosas en poco tiempo

es responsable de más acidez estomacal y caos en la industria del software que casi cualquier otra cosa.

John Bode
fuente
2
+1 "Cuando dicho desarrollador es el líder del software". Exactamente. A veces, cuando argumenta su punto y su líder no está de acuerdo con usted, es porque su líder tiene una mejor visión del panorama general. Esta es una de esas situaciones.
Andrew Coonce
Discrepar. De esa manera, llevas a tus subordinados a nada más que seguidores que olvidarán cómo tomar decisiones y responsabilizarse de ellas. Si quieres eso, bien. Creo que hay lugares donde la gente será más inteligente que tú como líder del equipo. Pero sí, algunas personas tienen un problema con eso, y eso es trágico.
JensG
Me reí seriamente de su respuesta a "es responsable de más acidez estomacal y caos en la industria del software que casi cualquier otra cosa" ... ¡gracias! ¡No podría haberlo redactado mejor!
Alexus
11

Observo que no dice que fue contratado como programador de JRuby o Java.

Esta es la razón por la que dijo que fue contratado: "[B] porque tengo mucha experiencia en la creación de aplicaciones web y porque me inclino hacia tecnologías más nuevas como JRuby on Rails o nodejs".

En otras palabras, les gusta su experiencia web y su disposición a aprender nuevas tecnologías.

Ahora te están pidiendo que uses tu experiencia web y que aprendas una nueva tecnología.

Entonces la pregunta es, ¿vas a hacer eso o no?

Kyralessa
fuente
9

El mayor gasto en software está en su mantenimiento.

Leí que el mayor gasto (80%) está en el mantenimiento del software. El desarrollo inicial es solo el 20% del costo total de desarrollo.

Leí un caso sobre un desarrollador que desarrolló código y comentarios en su idioma nativo (no inglés) y cuando los otros miembros del equipo fueron a mejorar y mantener el código, era casi imposible porque el idioma (no cualquier lenguaje de programación) era extranjero a ellos

Del mismo modo, si desarrolla código en un lenguaje de programación de su elección, sería difícil para otros miembros del equipo mantenerlo.

Solución: programación de pares

Considere pedirle a sus empleadores que lo emparejen con otra persona que conozca el lenguaje de programación requerido y puedan trabajar juntos. Pueden aprender unos de otros, y si alguno de ustedes deja la empresa, el otro conocería el código.

Artículo de Wikipedia sobre "Programación de pares": http://en.wikipedia.org/wiki/Pair_programming

Kaydell
fuente
3
Si escribes algo que solo tú entiendes, entonces estarás atrapado manteniéndolo para siempre.
jwernerny
6

Muchas compañías simplemente prefieren seguir con lo que siempre han hecho o lo que es "seguro". Hay una razón por la que Java y PHP siguen siendo muy populares. Por el momento, la búsqueda de "COBOL" en Indeed.com devuelve 2144 listados ... que realmente deberían hablar por sí mismos. A la industria no le importa el buen código, se preocupa por el código que puede extraer por el mayor tiempo posible (esto no implica que C # sea malo, realmente no lo es).

Piénsalo: el código te durará más. Existe una buena posibilidad de que alguien más mantenga su código y C # es una apuesta más segura que Node.js y Rails. No me sorprendería si en 5 o 6 años la cantidad de programadores de Ruby se redujera a la mitad, después de lo mismo le sucedió a Perl y a cualquier otro idioma que se haya considerado en algún momento como el lenguaje web "it". Es probable que Javascript no desaparezca, pero ya estamos empezando a ver que se usa como una especie de ASM (o incluso C) de la web: un lenguaje intermedio que otros lenguajes pueden compilar para escribir código del lado del servidor en él. Muy bien quedará obsoleto.

Gomi
fuente
44
Si bien esto es cierto, es una práctica de reclutamiento bastante pobre para una tienda de C # contratar a un desarrollador de Ruby que no conoce C #, sin dejar absolutamente claro que el trabajo para el que está siendo contratado implica principalmente el desarrollo de C #.
Carson63000
5

Mi principal preocupación con los desarrolladores que eligen cómo implementar sus objetivos es que normalmente asumen que solo editarán el código. Míralo de esta manera, 12 meses después pueden necesitar cambios; no está disponible (dejó la empresa o está realmente ocupado en otra tarea), y otro desarrollador tiene que abandonar su código. Si es una tienda de C #, entonces usar su conjunto de herramientas es un buen trabajo en equipo. Las nuevas tecnologías deben investigarse e implementarse, pero solo cuando el líder cree que es el momento adecuado, ya que tienen en mente muchos objetivos, no solo uno.

daveD
fuente
3

Dale la vuelta, por favor. Imagine que usted es el que contrata a un desarrollador de Ruby, e insisten en implementar su trabajo en Asp.net/MVC.

Que les dirías? Esta es nuestra pila, hombre. Aprende a vivir con ello.

La regla de oro, aquí está, la que tiene el oro hace las reglas.

Warren P
fuente
1
Pero, ¿por qué contrataría a alguien que insista en usar .NET para un rol de Ruby?
Bobson
3
@Bobson porque son un programador joven y brillante que parece ser capaz de abordar problemas con varias tecnologías diferentes, resolvió los problemas generales de programación satisfactoriamente y solicitó el trabajo.
2
@Bobson: Entonces, usted argumenta que las compañías no deberían contratar desarrolladores que no tengan experiencia en el idioma de elección de la compañía. Todos los demás parecen argumentar en la otra dirección, donde afirman que pueden aprender el nuevo idioma muy rápido, por lo que la empresa no debería transmitir un buen desarrollador simplemente porque no son expertos en un idioma en particular ... todavía.
Dunk
2
" Fui contratado porque tengo mucha experiencia en la construcción de aplicaciones web y porque me inclino por tecnologías más nuevas como JRuby on Rails o nodejs". - esto no fue contratado como desarrollador de XYZ, esto es "contratado como desarrollador web con experiencia en nuevas tecnologías" (que la compañía podría estar interesada en actualizar las cosas en el futuro).
3
@Bobson: Cuando me contratan para una nueva empresa, no solo sé lo que estoy trayendo a la mesa, sino que también sé en qué proyecto trabajaré y qué esperan que haga en ese proyecto. Si no se pudo molestar al OP para encontrar esta información, entonces lástima. Dicho esto, creo que este es realmente un caso de la compañía que contrata a alguien que cree que es un buen desarrollador con conocimiento de dominio relevante para ayudar al equipo, con la expectativa de que recoger el material mvc4 es un obstáculo menor. Quizás la compañía no lo explicó bien, pero el OP tampoco hizo su parte.
Dunk
2

Hay una serie de objetivos en conflicto y el problema es encontrar el mejor compromiso. Tenemos la fecha límite, tenemos un líder de equipo que solicita un determinado conjunto de herramientas, y tenemos un desarrollador sin experiencia con ese conjunto de herramientas pero condenado a producir algo dentro de un plazo (obviamente corto).

Es importante entender que el líder del equipo probablemente tenga algunas buenas razones por las que exige exactamente este conjunto de herramientas (una de las cuales podría ser que te acostumbres a este conjunto de herramientas por alguna razón que quizás aún no conozcas). Lo mejor que puede hacer en la primera ejecución es averiguar cuáles son exactamente estos motivos.

Puesto en su posición, trataría de hablar con el líder del equipo y tratar de explicarle la situación, como lo considera, y las opciones y el resultado (incluidos los efectos económicos a corto y largo plazo). siguiendo cada una de estas opciones. Por ejemplo, otro desarrollador más experimentado podría ser asignado para entrenarlo, tal vez con algunas sesiones de programación en pareja o similares.

A menos que el líder de su equipo sea un completo imbécil, debería poder encontrar un consenso que tenga sentido con respecto al proyecto y a los objetivos generales de la empresa.

JensG
fuente
2

Bah. Todos están equivocados.

Sé un mejor desarrollador que esas personas de una sola plataforma y tendrás muchas más opciones interesantes que nunca. Entonces, por ahora, aprenda MVC. Y en su propio tiempo, aprenda más sobre las plataformas que realmente le interesan. Desarrolla tus habilidades de Nodo. Aprende un poco de Django. Presta atención a cualquier travesura Java o MVC .NET a la que estés expuesto y luego huye, pero al menos aprende lo suficiente como para poder criticar y explicar cuánto pensamiento has puesto en tu prejuicio de odio ardiente apenas oculto de esas plataformas. (está bien, tal vez estoy proyectando allí)

Y ahora por el importante consejo. Si continúa perfeccionando sus especialidades y al mismo tiempo diversificando su experiencia en otras áreas, eventualmente estará en un lugar donde puede encontrar nuevo trabajo en cualquier época del año en menos de dos semanas en cualquier ciudad importante haciendo cosas que sean sobre todo interesante al menos la mitad del tiempo. Cuando te encuentres en este lugar, no soportes estos trabajos donde dicen que quieren esto y para el segundo día te tienen haciendo ESO sin la esperanza de un alivio previsible en el futuro a largo plazo. Simplemente explíquese y discúlpese cortésmente, pero no, realmente no quería hacer ESO y dijo tanto en su entrevista y luego! el hecho de que le han tergiversado la posición y se niegan a reconocerlo.

Pero confía en mí, encontrar un nuevo concierto siempre es mucho mejor que irritarte e infeliz seriamente por cualquier cantidad de tiempo que dure más de 5 minutos. Pero, por supuesto, primero debe pagar sus cuotas para poder hacerlo. Algunas personas nunca lo harán. Por eso quieren todo lo que mejor conocen. Y, por supuesto, otras respuestas no están realmente equivocadas. Tiene sentido que una tienda .NET vaya con .NET si tienen que mantener la tontería.

Por supuesto, lo que no tiene sentido es por qué se diversificarían con un desarrollador de Rails / JS / UI y solo lo harían hacer aplicaciones MVC. Pero por ahora. Es posible que deba recogerlo y pagar sus cuotas. Y como dije en los comentarios, MVC realmente no es tan malo. Una elección realmente mala dada todas las opciones, pero ciertamente no es la peor. Es bastante sencillo, no arroja 10,000 capas de abstracción sobre todo lo que realmente está sucediendo, y no se enreda tanto con el lado del cliente que maldeciría los nombres de los ingenieros de MS responsables si alguien pudiera molestarse para aprenderlos

Así que ve a ese lugar donde puedas irte cuando quieras si aún no lo has hecho e incluso podrías descubrir que tienes un ojo más escéptico de las cosas que te gustan actualmente. Incluso es posible que no le gusten los rieles tanto como a mí. No es que haya algo malo con Ruby (aparte de su intérprete, por supuesto).

Erik Reppen
fuente
1

Dependiendo de su situación, podría ser peligroso asumir que sabe por qué lo contrataron, y aún más asumir que su gerente lo sabe y está de acuerdo en que contratar a personas con sus habilidades es una buena idea.

Le pediría que siga los consejos anteriores y haga un caso de negocios por qué debería ir con JRuby sobre C #, tal vez su argumento y sus líneas de tiempo significan que tiene sentido romper con las viejas formas. No solo asumiría que está bien o no, dar al gerente o dirigir los hechos y dejar que tomen la decisión, es por lo que se les paga mucho dinero, además es un poco de CYA.

Scott S
fuente
1

En mi sincera opinión, una de las cosas que separa a los buenos desarrolladores de los excelentes es su capacidad de adaptarse a las nuevas tecnologías. Vivimos en un mundo acelerado donde la tecnología de punta de hoy se volverá obsoleta mañana. Por lo tanto, un desarrollador que no está dispuesto a adaptarse es de uso limitado para la empresa. Esto estaría bien, si no fuera por un pequeño hecho de que encontrar y contratar personas buenas es realmente muy difícil de hacer y cuando una empresa encuentra su joya, están planeando a largo plazo.

He visto a empresas contratando fuera de su alcance tecnológico y lo hacen exactamente por la misma razón. Quieren poner en práctica grandes desarrolladores, incluso si eso significa esperar a que se adapten a las nuevas tecnologías.

Ahora a tu situación. Como un chico nuevo en el grupo, tendría mucho cuidado con lo que digo y no digo a mis superiores. Claro, se saldrá con la suya basándose en el supuesto de que todavía está en proceso de adaptarse a su nuevo entorno. Sin embargo, socavar la autoridad y la terca perseverancia en su tecnología preferida solo hará que sus superiores piensen que cometieron un error al contratarlo y que no está dispuesto a abandonar su zona de confort.

Lo que elija dependerá de usted, pero le sugiero que intente aprender nuevas tecnologías. No dolerá, lo prometo.

Vladimir Kocjancic
fuente
1

Asumiré que fue honesto desde el principio durante su entrevista sobre su falta de conocimiento de C #, porque si no lo fuera, podría estar en una posición muy precaria desde el punto de vista legal.

Los buenos programadores saben programar. Si bien, obviamente, nadie puede estar bien versado en todos los lenguajes y marcos, existe una coincidencia considerable entre la mayoría de ellos. A menos que se le pida que trabaje en un idioma que es enormemente diferente de lo que constituye la corriente principal en estos días (Lisp, por ejemplo), entonces un buen programador debería poder adaptarse.

Naturalmente hay una curva de aprendizaje. Si el empleador lo contrató, entonces deben confiar en sus habilidades para seguir esa curva en un período de tiempo razonable (nuevamente, suponiendo que fuera honesto por adelantado con respecto a no conocer C #). El lenguaje C # se basa en gran medida en Java, y en términos más generales, la mayoría de los lenguajes de programación basados ​​en clases son fundamentalmente bastante similares (usted mencionó node.js, que se basa en ECMAScript, que es un lenguaje basado en prototipos, por lo que obviamente está cómodo con otros paradigmas de programación.

Los buenos programadores deberían, además de ser flexibles, estar ansiosos por aprender cosas nuevas. En el desarrollo de software, generalmente aprendes o te vuelves irrelevante.

Por supuesto, su empleador, suponiendo que supieran que usted no conocía C #, tiene que encontrarlo a mitad de camino. Si muestra entusiasmo por aprender, entonces tienen que darle el tiempo y los recursos para hacerlo. Lanzarlo al fondo es injusto e innecesariamente estresante. Necesita sentarse y tener una discusión tranquila y racional con su superior. Si lo quieren en C #, deben estar preparados para aceptar que estarás en una curva de aprendizaje mientras trabajas en ello y sería injusto que te impongan plazos ajustados. Si los plazos no son flexibles y son de gran importancia estratégica, entonces deben estar preparados para permitirle cierta libertad para hacer el trabajo dentro de ese plazo. Si necesitan que esté en el idioma más comúnmente utilizado en su oficina, entonces quizás pueda solicitar implementarlo ahora en lo que usted ' familiarícese con el cumplimiento de la fecha límite, y luego, como su próximo proyecto, vuelva a implementarlo en C # como un ejercicio de aprendizaje y para que el software cumpla con los requisitos internos una vez que cumpla con los externos. Como dije, la mayoría de los lenguajes más utilizados hoy en día tienen mucho en común, por lo que se reduce principalmente a los detalles de implementación.

Tiene que estar preparado para aceptar tarde o temprano que está trabajando en una tienda de C # y, por lo tanto, debe tener C # en su haber.

GordonM
fuente
0

Tal vez no estén satisfechos con la forma en que todos usan MVC en el entorno .NET. Podría haber demasiado tratándolo como formularios web. Esto no es diferente cuando alguien con antecedentes procesales comienza en OOP, pone todo en una gran clase y continúa con los negocios como de costumbre.

Este primer proyecto no es la situación ideal porque quieren que se haga tan rápido. Póngase al día en .NET tanto como sea posible y comience a desarrollar funciones lo más rápido posible. No te va a gustar la forma en que haces las cosas, solo trata de tener en cuenta que comenzarás a refactorizar estas cosas y aplicar tus habilidades en otro idioma.

Con suerte, su forma de usar MVC4 (suponiendo que todos los demás no lo estén haciendo bien) en un estilo Ruby más atrapará y separará a todos de la mentalidad de Webforms.

JeffO
fuente