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

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?

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 sí 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.

¿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.

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 #.

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.

¿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.

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?

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

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.

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.

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.

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.

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).

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.

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.

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.

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.