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

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

  

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

Esto plantea el problema de "habilidades que estabas" (supuestamente) "contratadas para" frente a "habilidades que necesitas ahora" y también muestra que estás dispuesto a aprender las nuevas habilidades, pero eso tardará en desarrollar la nueva aplicación, ya que usted es nuevo en este conjunto de herramientas. Y do quiere mostrar que está dispuesto a aprender nuevas habilidades. No estar abierto a aprender nuevas habilidades es una buena manera de asegurar que su empleo finalice cuando ya no se necesitan.

En cuanto a tu pregunta al final:

  

¿En qué momento se debe permitir que un desarrollador elija sus herramientas? ¿Depende esto de la empresa? ¿Mi empresa apesta o esto se considera normal? ¿Existen pastos más verdes? ¿Estoy viendo esto de forma incorrecta?

Por lo general depende de la empresa. Si una empresa compra herramientas de MS y estandariza todo en la plataforma VisualStudio y el framework .NET, podría ser muy incómodo si un desarrollador insiste en usar Linux y C. Eso es normal. Es posible que existan excepciones cuando la empresa es menos exigente con los editores, como permitir que los desarrolladores elijan Vi vs. Emacs, siempre y cuando la salida sea la misma. Sé que algunas compañías incluso permiten que los desarrolladores elijan Windows en lugar de 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 las cosas cuando la aplicación es un mosaico de binarios integrados en los lenguajes / marcos de trabajo favoritos de varios desarrolladores, integrados en diferentes herramientas y probados en sistemas muy diferentes. Si todos los desarrolladores trabajan en en su mayoría configuraciones similares, ese tipo de problemas se resuelven.

En su caso, parece que fue contratado 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é ellos querían eso.

  

¿En qué momento se debe permitir que un desarrollador elija sus herramientas?

Cuando no impactan a tu equipo.

  

¿Estoy viendo esto de forma 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 compañía tiene un buen número de buenos desarrolladores de C #, entonces probablemente será más barato (y proporcionará una mejor calidad) tener una aplicación de C # para mantener.

Sus DBA y otro personal de administración probablemente estén familiarizados con esa pila y tienen procesos implementados para implementar y actualizar esa pila. Incluso si puede hacer que el código se haga más rápido, puede llevarle más tiempo una vez que tenga en cuenta todos los gastos generales necesarios para que una aplicación web profesional esté en funcionamiento.

Recuerda, vas a pasar mucho más tiempo manteniendo tu aplicación que escribiéndola. Optimizar por ese costo.

1. Aparentemente fue contratado debido a su capacidad para adaptarse a las "nuevas" tecnologías. C # no es diferente, en ese sentido. ¿Estás seguro de que no quieres aprovechar la oportunidad de aprender algo nuevo?

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

3. No estarás al ritmo de un caracol para siempre. Si ya sabe ROR, ASP.NET MVC será muy fácil para usted. El truco es aprender C #.

Argumentos para quedarse con Java / JRuby

Es probable que su jefe quiera que produzca. Te contrataron para que pudieras agregar valor a la empresa. Asegúrate de que entiendan que al forzarte a utilizar un marco con el que no estás familiarizado, te hará que:

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

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 sus habilidades como programador es solo un riesgo si el lenguaje / plataforma que está aprendiendo va a desaparecer en un futuro próximo, y con Microsoft a su lado, no creo que eso sea un problema. C # y MVC han tenido actualizaciones recientes que los han mejorado, con aún más actualizaciones en trámite.

Hacerte, personalmente, un desarrollador más completo evitará que te pongas en esta situación nunca más. ¿La mejor parte? Tu jefe te pagará para que aprendas estas cosas, lo que significa que te pagan para que valgas más dinero.

La línea inferior

Puedes terminar ganando esta pelea, pero te dejarán trabajar con colegas descontentos. Simplemente explique los pros y los contras de cada uno a su gerente y luego ambos saldrán más felices del otro lado.

  

¿En qué momento se debe permitir que un desarrollador elija sus herramientas?

Cuando dicho desarrollador es el líder del software.

Ciertamente, puede (y debería) defender el uso de diferentes herramientas si le preocupa la productividad, pero esté preparado para una respuesta que no le guste. Puede haber una buena razón por la que su cliente potencial quiere que use un conjunto de herramientas específico, ya sea compatible con la arquitectura actual, con preocupaciones sobre mantenimiento, problemas de licencias, 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 cualquier otra cosa.

Observo que no dices que fuiste contratado como programador de JRuby o Java.

He aquí por qué dijo que fue contratado: "[B] 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".

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

Ahora le piden que utilice su experiencia web y que aprenda una nueva tecnología.

La pregunta es, ¿vas a hacer eso o no?

El gasto más grande en software está en el mantenimiento del mismo

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

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

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

Solución: Programación por pares

Considere pedirle a sus empleadores que lo emparejen con alguien que sepa 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 sabría el código.

Artículo de Wikipedia sobre "Programación de pares": enlace

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

Piénsalo acerca de esto: el código va a durar más que tú. Hay una buena probabilidad 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 que en 5 o 6 años el número de programadores de Ruby se redujera a la mitad, después de todo lo mismo le sucedió a Perl y a cualquier otro idioma que se haya considerado en algún momento el lenguaje web "it". Es poco probable que Javascript desaparezca, pero ya estamos empezando a verlo como un tipo de ASM (o incluso C) de la web, un lenguaje intermedio que otros idiomas pueden compilar para escribir código del lado del servidor. muy bien se vuelven obsoletos.

Mi principal preocupación con los desarrolladores que deciden 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 batir su código. Si es una tienda de C #, usar su conjunto de herramientas es un buen trabajo de 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.

Da la vuelta, por favor. Imagina que fuiste tú quien contrató a un desarrollador de Ruby e insisten en implementar su trabajo en Asp.net/MVC.

¿Qué les dirías a ellos? Esta es nuestra pila, hombre. Aprende a vivir con ello.

La regla de oro, aquí está, quien 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 que no tiene experiencia con ese conjunto de herramientas, pero está condenado a producir algo dentro de un plazo (obviamente corto).

Es importante comprender que el líder del equipo tiene probablemente algunas buenas razones por las que exige exactamente este conjunto de herramientas (una de las cuales podría ser, de hecho, acostumbrarte 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 estas razones.

En su posición, trataría de hablar con el líder del equipo y tratar de explicar la situación, tal como está en su opinión, y las opciones y el resultado (incluidos los efectos económicos a corto y largo plazo) Se generará siguiendo cada una de estas opciones. Por ejemplo, se podría asignar otro desarrollador más experimentado para que lo guíe, tal vez con algunas sesiones de programación en pareja o similares.

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

Bah. Todos están equivocados.

Sea un desarrollador mejor que esas personas de una sola plataforma y tendrá muchas más opciones interesantes que nunca. Así que, por ahora, aprende MVC. Y en su propio tiempo, aprenda más sobre las plataformas que realmente le interesan. Construye tus habilidades de Nodo. Aprende un poco de Django. Preste atención a los chanchullos Java o pre MVC a los que esté expuesto y luego huya, pero al menos aprenda lo suficiente como para poder criticar y explicar la cantidad de pensamiento que ha puesto en su odiado odio de esas plataformas. (bueno, tal vez estoy proyectando allí)

Y ahora para el consejo importante. Si continúa perfeccionando sus especialidades y al mismo tiempo diversifica su experiencia en otras áreas, eventualmente se encontrará en un lugar donde puede encontrar trabajo nuevo en cualquier momento del año en menos de dos semanas en cualquier ciudad importante que realice En su mayoría interesantes al menos la mitad del tiempo. Cuando te encuentres en este lugar, no toleres estos trabajos donde dicen que quieren esto y en el segundo día te hacen hacer ESO sin ninguna esperanza de un rescate previsible en el futuro a largo plazo. Simplemente explique educadamente y pida disculpas, pero no, realmente no quería hacer ESTO y lo dijo en su entrevista y luego! # # Ing. Renuncie y siga adelante cuando pasen un par de semanas e inevitablemente no hayan hecho nada para adaptarse. el hecho de que tergiversaron el puesto y se niegan a reconocerlo.

Pero confía en mí, encontrar un nuevo concierto siempre es mucho mejor que enojarse gravemente e infeliz por cualquier período de tiempo que dure más de 5 minutos. Pero, por supuesto, primero tiene que pagar sus cuotas para poder hacerlo. Algunas personas nunca lo harán. Es por eso que quieren todo lo que mejor saben. Y, por supuesto, otras respuestas no son realmente incorrectas. Tiene sentido que una tienda .NET vaya con .NET si tiene 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 tendrían que hacer aplicaciones MVC. Pero por ahora. Puede que tenga que recogerlo y pagar sus cuotas. Y como dije en los comentarios, MVC realmente no es tan malo. Una elección realmente mala teniendo en cuenta todas las opciones, pero ciertamente no la peor. Es bastante sencillo, no arroja 10.000 capas de abstracción por encima de todo lo que realmente está sucediendo, y no está tan retorcido con el lado del cliente que maldeciría los nombres de los ingenieros de MS responsables si alguien pudiera ser molestado para aprenderlos.

Vaya a ese lugar donde puede irse cuando quiera, si aún no lo ha hecho, e incluso podría descubrir que tiene un ojo más escéptico de las cosas que le gustan actualmente. Incluso podrías encontrarte a ti mismo rechazando los rieles tanto como yo. No es que haya algo malo con Ruby (aparte de su intérprete, por supuesto).

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

Le pediría que tome el consejo anterior y haga un caso de negocios por qué debería elegir JRuby sobre C #, tal vez sus argumentos y líneas de tiempo signifiquen que romper con las viejas formas tiene sentido. No solo asumo que está bien o no, dale al gerente o dirija los hechos y les dejo que tomen una decisión, es por lo que se les está pagando mucho dinero, además es un poco de CYA.

En mi opinión honesta, una de las cosas que separa a los buenos desarrolladores de una buena es su capacidad para adaptarse a las nuevas tecnologías. Vivimos en un mundo acelerado donde la tecnología más avanzada de hoy se volverá obsoleta mañana. Por lo tanto, un desarrollador que no esté dispuesto a adaptarse tiene un 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 difícil de hacer y cuando una compañía encuentra su joya, están planeando para el largo plazo.

He visto empresas que contratan fuera de su ámbito tecnológico y lo hacen por la misma razón. Quieren obtener grandes desarrolladores, incluso si eso significa esperar a que se adapten a la nueva tecnología.

Ahora a tu situación. Como un chico nuevo en el grupo, tendría mucho cuidado con lo que digo y no le digo a mis superiores. Claro, se saldrá con la suya basándose en la suposición de que todavía se encuentra en un proceso de adaptación a su nuevo entorno. Sin embargo, socavar la autoridad y la perseverancia obstinada 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 escogerás depende de ti, pero te sugiero que intentes aprender nuevas tecnologías. No dolerá, lo prometo.

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

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

Naturalmente hay una curva de aprendizaje. Si el empleador lo contrató, debe confiar en sus habilidades para seguir esa curva en un tiempo razonable (nuevamente, suponiendo que usted fue honesto desde el principio con respecto a no saber C #). El lenguaje C # toma mucho de Java, y en general, la mayoría de los lenguajes de programación basados en clases son bastante similares (usted mencionó node.js, que se basa en ECMAScript, que es un lenguaje basado en prototipos, por lo que obviamente 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 estás aprendiendo o te estás volviendo irrelevante.

Por supuesto, su empleador, asumiendo que sabía que no sabía C #, tiene que reunirse con usted a mitad de camino. Si se muestra ansioso por aprender, tienen que darle el tiempo y los recursos para hacerlo. Lanzarte al final profundo es injusto y innecesariamente estresante. Necesitas sentarte y tener una discusión calmada y racional con tu superior. Si lo quieren en C #, entonces 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 si tienen una 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 de uso más común en su oficina, entonces quizás pueda solicitar implementarlo ahora en lo que está familiarizado para cumplir con la fecha límite, y luego, a medida que su próximo proyecto vuelva a implementarlo en C # como 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 de uso más común en la actualidad tienen mucho en común, por lo que principalmente se trata de detalles de implementación.

Tienes que estar preparado para aceptar, tarde o temprano, que estás trabajando en una tienda de C # y, por lo tanto, necesitas tener C # bajo tu cinturón.

Tal vez no estén satisfechos con la forma en que todos usan MVC en el entorno .NET. Podría haber demasiado tratarlo como formularios web. Esto no es diferente cuando alguien con antecedentes en procedimientos comienza en OOP, pone todo en una gran clase y continúa con su trabajo como siempre.

Este primer proyecto no es la situación ideal porque quieren que esto se haga tan rápido. Póngase al día con .NET lo más posible y comience a activar las características lo más rápido que pueda. No le va a gustar la forma en que hace las cosas, solo trate de tener en cuenta que comenzará a refactorizar estas cosas y aplicará sus habilidades en otro idioma.

Con suerte, tu forma de usar MVC4 (suponiendo que todos los demás no lo están haciendo del todo bien) de una manera más Ruby-Style logrará que todos se alejen de la mentalidad de los formularios web.