¿Por qué la mayoría (o algunos) ingenieros de software odian sus trabajos? ¿Trabajar para una empresa embota tanto su mente que su amor por la programación se disipa?

Frustración.

1. Los problemas más desafiantes que resolvió fueron durante sus entrevistas.
2. Las estructuras de datos y los algoritmos que practicó durante un año para obtener este trabajo se olvidan dentro de los 3 meses de realizar el mantenimiento, asistir a las reuniones y beber la ayuda de Kool.
3. El pago es demasiado para pretender ser un geek. Un despido y eres irrelevante para el mundo. Tú lo sabes.
4. La subvención de acciones es excelente. Pero a alguien de arriba se le paga aún más para quemarlo y reemplazarlo con alguien más enérgico y más barato.
5. La idea no es innovar, hacer lo correcto de la manera correcta, servir a los clientes o hacer del mundo un lugar mejor. Esas cosas son solo parte del guión para contratar personas. La idea es salvar su trabajo a costa de otros.
6. Las reuniones están programadas para debatir por qué se negó a corregir esos 200 errores de baja prioridad presentados por el probador de estrellas en un día. El probador le prometió a su esposa que obtendría el ascenso esta vez. Nos vemos mañana. Misma habitación.
7. El jefe piensa que el desarrollo de software solo está llamando a algunas API. Por lo tanto, no verían ningún punto en aprobar su solicitud de cambio de equipo.
8. El milagro sucede. Lo absorbe y ofrece un rendimiento sobresaliente con algo de innovación. Los jefes se reúnen en una habitación para discutir cómo tomar crédito. Puedes pararte en la puerta o irte.
9. La tontería sucede. Los jefes se reúnen para lincharte en el centro de la misma sala de reuniones.
10. El corredor de bienes raíces que lo ayudó a encontrar la casa de sus sueños tiene más patrimonio neto que usted. Él tiene propiedad agrícola también. Te regala cacahuetes cultivados en su granja que parecen más pesados ​​de lo que te da tu jefe.
11. El hombre común afuera cree que eres un Einstein. Pero, usted sabe que no es más que un neumático sin cámara cuyo único propósito de existencia es mantener el aire bajo alta presión para permitir que sus jefes tengan una conducción suave.
12. El médico dice que no hay más espacio para que aumente la presión arterial. Le dices que tus órganos están en TI. Él te dice que están en SH IT.
13. La opción de dejar de fumar ya no existe. Usted está casado, tiene hijos y 2 EMI de préstamos hipotecarios. Le prometiste al mundo que le darías a tus hijos una gran vida. Como el tuyo. Ejem.

EDITAR 1: Gracias por leer, votar y comentar. La respuesta tiene mucha negatividad porque la pregunta es tal. Algunas personas preguntaron cómo prosperar en tales condiciones. Así es como lo hice: la respuesta de Imtiaz Mohammad a ¿Qué hiciste para mejorar tu carrera en software?

La mayoría de los ingenieros de software piensan que estarán trabajando en algo innovador sin tener la habilidad y la experiencia.

La mayoría de los ingenieros de software consiguen un trabajo al:

1. Aprendizaje de programación básica.
2. Aprendizaje de estructuras de datos y algoritmos.

Cuando obtienen su primer trabajo, piensan:

1. Aplicarán su conocimiento de estructuras de datos y algoritmos.
2. Implementarán nuevos algoritmos.

Pero el hecho es que:

1. La mayoría de las veces estará programando construcciones básicas como bucles, condiciones.
2. Debe utilizar sus conceptos de OOP para obtener un diseño de software mejor y modular. Aquí es donde se consume la mayor parte de la lógica y la mente.
3. En su mayoría, utilizará algoritmos estándar ya implementados compatibles con el idioma.

La mayoría de los ingenieros de software que trabajan en empresas multinacionales no están más satisfechos porque:

1. Llegan a trabajar en una parte muy pequeña de un proyecto muy grande.
2. Los empleados no pueden visualizar el impacto de su trabajo.
3. Ni siquiera llegan a desplegar su propio trabajo. Hay un equipo de implementación separado.
4. Hay demasiada jerarquía y si tiene un problema, no puede dirigirse directamente a su CEO.
5. La jerarquía inflige política.
6. La revisión del código lleva mucho tiempo: cuando la base del código se hace grande, se imponen más estándares al programador. El resultado es una lluvia de comentarios sobre los estándares y no sobre la lógica.
7. Escribir documentación: aunque la documentación es necesaria, los desarrolladores odian escribir cualquier cosa que no sea código.

Si se especializa en un dominio como aprendizaje automático, IA, visión por computadora, AR donde se crean muchos algoritmos nuevos todos los días, tendrá un mejor trabajo. Si lo contratan como ingeniero de investigación, es posible que su trabajo sea dinámico.

Pero para un ingeniero de back-end o frontend básico, la mayoría de las veces copiará y pegará código desde el desbordamiento de la pila. En ocasiones, los desarrolladores pueden sentir que están haciendo un trabajo monótono.

Si está en una startup, los puntos mencionados anteriormente pueden no ser aplicables. Hay muchos problemas como el escalado, la seguridad y la robustez que debe resolver. Eso lo hace más desafiante.

Para la mayoría de los ingenieros de software, el trabajo es bastante aburrido. Comencé a trabajar en Microsoft y me aburrí en un año. De alguna manera logró dos años allí y luego se unió a una startup. La startup se estableció dentro de un año y hubo menos problemas. Entonces, decidí trabajar con mi superior en mi propia empresa: http://www.ezdiagno.com

Ahora mi barra de calidad del trabajo ha aumentado automáticamente la construcción y la implementación de un producto desde cero. Todo se reduce a las expectativas.

En mi opinión, alguien a quien le encanta programar, desarrollar y construir realmente no odia o es indiferente a la ingeniería de software. En realidad, son las tareas aburridas y los aspectos de un trabajo los que pueden agotar incluso el alma de un programador apasionado.

Aquí hay algunas cosas que pueden hacer que un programador odie su trabajo actual:

• Mala gestión: esta es una razón muy importante por la que las empresas tienden a ignorar, y toda la carga recae en los programadores, probadores, analistas, etc. Imagínese lo que es estar inseguro de sus propias tareas y roles, que le pidan que resuelva problemas fuera de su liga en unas pocas horas, que le diga que haga una estimación de algo que ni siquiera tiene tiempo para analizar a fondo, inseguro de quién puede hablar para hacer las cosas, plazos inestables, horas extra de trabajo gratis casi todos los días, equipo estresado y tenso con baja moral y poca fe en el proyecto, tener un gerente que solo culpa y regaña, y así sucesivamente;

• Tareas aburridas y desafiantes: imagine lo que es que le digan que necesita trabajar en hojas de Excel el 90% del tiempo. O realice tareas que tienen poco que ver con su supuesto rol. O solo haga la programación de copiar y pegar. Y estás atrapado en el mismo proyecto durante años, sin aprender nada nuevo;

• Lidiar con el estrés constante: si lo anterior no se aplica a usted, es probable que tenga problemas difíciles de resolver todo el tiempo. En la programación, tenemos que resolver nuevos problemas casi todo el tiempo que no hay seguridad de que podamos resolverlo todo. ¿Y si no podemos resolverlo? ¿Qué pasaría entonces? Esto podría no ser un gran problema ya que siempre puede haber una alternativa, pero la cantidad de tiempo que se nos brinda (que depende de la gestión) determina cuán grande y manejable puede ser el estrés. Un pequeño estrés puede darle vida a la rutina, pero un gran estrés todo el tiempo puede afectarnos.

• Terrible ambiente de trabajo: ruidoso espacio abierto donde casi nadie tiene espacio. Mucha gente tiene que hablar mucho, y es mejor que te interrumpan cuando necesiten preguntar algo y no respondas en el mensajero en 30 segundos. En los peores días, alguien le gritaba a otra persona por un tiempo, haciendo que todos se pusieran tensos y que solo los que son capaces de desconectarse completamente del entorno puedan ignorar. Además, el aire acondicionado o la falta de él, lo que a menudo hace demasiado frío o calor, ya que hay algún tipo de guerra. Y tampoco hay agua, ni café, ni lugar para almorzar (y algunas personas que comen en sus escritorios hacen todos esos sonidos), incluso el uso del baño tiene algunas molestias;

Y cuando estas cosas son demasiado comunes en los trabajos disponibles en un determinado lugar donde viven, es fácil comenzar a disgustar el campo en sí e incluso querer cambiar la trayectoria profesional.

Además de la mala gestión y la monotonía del trabajo, hay una cosa muy interesante que la gente suele pasar por alto. No he trabajado más de 2 años en compañías de software (una de las 10 compañías globales más importantes y una nueva empresa), por lo que mi perspectiva puede ser limitada, aún así, aquí voy:

Falta de conocimiento

Sí, con más frecuencia que otras razones, veo que las personas que no tienen un impulso interno de hacer algo, que no hacen nada para mejorar sus habilidades, hacen la mayor parte de las quejas y odian sus trabajos.

Consideremos un ejemplo:

A nosotros, en el equipo, se nos dio una nueva característica para desarrollar. Nuevamente fue una aburrida integración UX + UI + Backend con API. Nada nuevo. Nuestro enfoque:

1. Team Lead -> Oh, dale esto a anónimo para trabajar. Pedazo de trabajo de mierda
2. Anónimo (Yo) -> Hagamos algo nuevo. Integrado mi aplicación con Java 8, introduje RxJava, escribí un procesador de anotaciones para el mismo. [El equipo ni siquiera entendió el código que escribí cuando planteé una solicitud de extracción; no tenían idea de RxJava, procesador de anotaciones, Java 8]

Entonces, ¿quién odia el trabajo? Alguien que no quiere aprender nada nuevo, experimentar con cosas, ponerse al día con los últimos desarrollos en el campo.

Otro ejemplo que me gustaría decir:

La mayoría de las personas obtienen prácticas en el campus en empresas como Infosys, TCS, Wipro, etc. (Sí, hablando de India ). Puede que sepa, puede que no, pero esos estudiantes no saben nada. En las entrevistas, esencialmente asaltan GeeksForGeeks y cosas similares, y van a la entrevista y cuentan cualquier cosa al azar y son seleccionados. Una vez en el trabajo, se enfrentan a dos situaciones:

1. Trabajo exigente: Bueno, sin conocimiento, no hacen nada y se irritan cuando la gerencia pregunta sobre el progreso. Y odian el trabajo entonces.
2. Sentado inactivo: nuevamente odian sus trabajos.

No tienen el potencial de cambiar a mejores empresas para trabajar.
Además, el asalto a GeeksForGeeks no se trata solo de esos estudiantes; incluso los estudiantes que se colocan en Amazon, etc., lo están haciendo, ya que saben que Amazon hace preguntas típicas en entrevistas de colocación. Se enfrentan al mismo problema que el anterior y odian los trabajos maravillosos.

Por último, el dinero que ganan. No ganan lo suficiente porque no saben lo suficiente. Hay miles de ofertas de trabajo para los expertos que pagan una gran cantidad de dinero. ¿Puede recordarse que Zuckerberg dijo lo mismo?
[O puede ser que sean ingenieros por casualidad :)]

El problema con la industria de desarrollo de software es que espera demasiada gente. A menudo tiene que tratar con gerentes de proyectos que no aprecian absolutamente la complejidad del código y otros obstáculos que no se hacen evidentes hasta después de que haya comenzado, que le hacen sentir que algo bueno que ha hecho no se hizo lo suficientemente rápido y no entiendo el impacto de interrumpirte mientras te concentras. Y, por supuesto, también tienden a sentirse frustrados cuando las personas se desvían del desarrollo de funciones al corregir errores, y no pueden imaginar cómo un desarrollador podría haber sido tan descuidado como para crear ese error. (Sugerencia: ¿podría ser porque estaban apurados y no podían concentrarse ?)

El resultado es a menudo horas interminables que trabajan sobre el mismo problema (debido a la presión externa en lugar de la motivación e interés intrínsecos). Los pasatiempos se olvidan, las relaciones sufren, ocurren dolores de estrés Y no importa cuánto trabaje, nunca parece ser suficiente para sentirse apreciado en el trabajo.

En serio, si la gente me deja en paz durante unos cinco segundos, me encanta programar y durante esos cinco segundos no puedo imaginar querer hacer otra cosa con mi vida. Pero agregue las interrupciones, las reuniones inútiles, los plazos innecesarios y rara vez se vaya a dormir sin preocuparse por mi carga de errores, y allí tiene una receta para la insatisfacción de la vida.

Una persona puede ser feliz en su trabajo: si eso le permite lograr algo, es decir, hacer lo que amas hacer. Se espera que un ingeniero en virtud de su título tenga una pasión extrema por construir cosas. No es una pasión extrema para ganar dinero. Tenga en cuenta este punto: el intenso impulso de construir, seguir construyendo y construir más. Esa es la definición de ingeniero. La mayoría de los ingenieros que conozco, los buenos, a menudo no les importa cuánto les pagan, si están trabajando en proyectos desafiantes, están extremadamente satisfechos al final del día. Todo lo que estos ingenieros siempre quisieron es participar durante toda su vida. A los ingenieros les encantan los problemas, cuanto más difícil es el problema, más patadas consiguen matar, lamentan resolver ese problema y piden aún más para mantenerse saciados a sí mismos y a su hambre. Si enfrentan un proyecto difícil y el siguiente es un juego de niños, se aburren y se distraen. La mayoría de los ingenieros de software adoran trabajar para nuevas empresas porque se destacan por presentar desafíos únicos para los ingenieros. Problemas que los fundadores no pudieron haber previsto cuando comenzaron la empresa. En realidad, es el mercado crudo y los clientes los que arrojan estos problemas y los ingenieros son arrojados al campo de batalla para soportar la peor parte. Un buen ingeniero amaría tales escenarios.

Ahora analicemos por qué e Ingeniero estaría extremadamente frustrado con su trabajo.

Estoy generalizando ingenieros: no separe a los ingenieros de software de los ingenieros

(1) Usted ingresa al trabajo y le dan BAU – Business As Usual, es decir, presione estos tres botones y una combinación de otros botones todos los días cuando ingresa al trabajo y regresa a casa después de esperar 8 horas.

(2) Gerentes irritantes que no tienen idea de lo que sucede con las máquinas pero quieren cumplir con los plazos dentro de los presupuestos.

(3) Las reuniones del equipo que se extienden durante dos horas a menudo y el ingeniero está involucrado porque tiene que abrir la boca durante cinco minutos, generalmente al final cuando cada miembro del equipo informa lo que sucedió, es decir, cosas técnicas, que ninguno de los otros entienden o les importa entender.

(4) Las revisiones del equipo, que son tan subjetivas que se hacen por hacerlas. Son tan mecánicos que llenan de frustración a los ingenieros.

(5) Derechos y privilegios de acceso: cada ingeniero opera dentro de un equipo. Se convierten en engranajes en una máquina: ningún ingeniero debe poder conocer el proceso completo. Si lo hace, se convierte en una pieza clave, es decir, insustituible y en la fortaleza del equipo. Cada persona en el equipo debe ser reemplazable. Todo lo que haga el ingeniero debe documentarse, capturarse y mantenerse. Debe dividirse en pasos cada vez más pequeños y ser tan triviales que un niño de clase 12 podría hacerlo sin ninguna supervisión. Es para hacer que el ingeniero sea despedible. es decir, deshacerse de lo antes posible. Por lo tanto, incluso los procesos simples a menudo fluyen a través de más de diez equipos antes de que se complete.

(6) Lea para perder su TRABAJO: hay dos chantajees continuos por parte de dos o tres gerentes, todo el equipo también está bajo presión. No están seguros de quién será despedido a continuación. ¿Quién será el próximo chivo expiatorio? Él / ella / ellos ME?

(7) La competencia – La comparación – Ellos hacen 20L Yo solo hago 10L. ¿Valgo más que eso? Esto llena a alguien de arrepentimiento y en una búsqueda continua por más: por lo tanto, mantener al ingeniero en una carrera de ratas por un mejor papel en una mejor MNC en un mejor auto en un mejor piso en un mejor – todo. Ahora es un juego de tronos. Matar, es decir, despedir a un ingeniero para el siguiente: pasar de un trono al siguiente

(8) En realidad, es solo un juego para el ingeniero más barato posible. El trabajo mental que funciona al precio más barato, siempre se trata de dinero, cómo maximizar la eficiencia para extraer las máximas ganancias. Si hay un ingeniero en Filipinas que acepta trabajar por la mitad de sus ingresos, entonces el trabajo es para él, no dudarían en despedirlo al siguiente minuto. De hecho, es consciente de que se aplicó la misma lógica cuando se despidió a un ingeniero en EE. UU. Y se le trasladó el trabajo. No eras mejor que él, eras simplemente un trabajo mental más barato.

(9) Los juegos mentales que juegan los gerentes: los gerentes son a menudo estas criaturas desempleadas que deambulan tratando de hacerse relevantes completando proyectos lo antes posible y tratando de ascender en la escala. Para hacer que este proceso suceda, a menudo hacen lo que pueden para hacer lo que esté a su disposición y eso incluye personas, es decir, ingenieros. Se les considera recursos como bancos, mesas, máquinas, etc. Para que los ingenieros se sometan a trucos psicológicos que los gerentes aprenden en sus dos largos años – Negociación – Persuasión – Manipulación – Amenazas – Chantaje – etc. hasta que puedan romper al ingeniero y secuestrar su pasión.

(10) Compañeros de trabajo: todos están dispuestos a cortarle la garganta al ingeniero sentado a su lado. Si me desempeño mejor que él, solo entonces sería elegible para la promoción el próximo año o ese aumento. Por lo tanto, es una batalla eterna por el reconocimiento y la guerra.

Entonces, el ingeniero hace todo lo posible para sobrevivir, la carrera de ratas, la política, el favoritismo, la mascota del gerente, las amenazas, los juegos psicológicos, la guerra social, la competencia en equipo y así sucesivamente. Excepto la única cosa que quería hacer, es decir, crear para construir cosas. Obtiene pura alegría al crear aplicaciones. Esa era la única cosa que se suponía que debía hacer y termina haciendo todo lo demás: comparar los tamaños de los d ** s a veces: chismes, etc.

El ambiente en una oficina corporativa está envenenado. Es extremadamente peligroso para la salud del ingeniero. Por lo tanto, comprenda que a los ingenieros de software les encanta la codificación. Simplemente odian el trabajo, es decir, los gerentes, el equipo y la oficina. No odian trabajar de hecho, muchos de ellos se desempeñarían extremadamente bien si se les permite trabajar de forma remota. También funcionarían bien si no ven a los gerentes nunca. Personalmente, sé de gerentes que aman tanto la codificación que vuelven a casa y codifican, simplemente por diversión, no para crear una nueva empresa y convertirse en millonarios. ¡Codifican algo y lo ponen en github gratis!

El problema nunca ha sido con los ingenieros.

El problema es con la estructura y el entorno de las empresas.

Las corporaciones son criaturas gigantescas como el demonio que tienen hambre de dinero: el dinero se obtiene con más ganancias, es decir, más trabajo y menos personas, o personas más baratas. Cada trimestre esperan más y más crecimiento. Por lo tanto, agotan a los ingenieros, hasta que pierden la voluntad de trabajar más.

¿Por qué algunos ingenieros de software odian sus trabajos?

1. Porque no está codificando 24/7. Escribir código ocupa muy poco de nuestro tiempo. La mayor parte se gasta en reuniones, revisiones de códigos y pruebas, lo que a la mayoría de las personas puede no gustarles.
2. Para muchos, es solo mantener el código. No trabajo de desarrollo. Necesitas una mente creativa para el desarrollo. Pero el trabajo de mantenimiento es simplemente monótono, lo que la mayoría de la gente odia.
3. Plazos estrictos para muchos. Lo rompes, va en tu revisión.
4. Es fácil frustrarse. Hay muchas maneras en que algo podría salir mal. Pueden aparecer errores. Muchos carecen de buenas habilidades de depuración. Los clientes pueden exigir una característica imposible (no vale la pena el precio).
5. ¡Muchas compañías pueden tener un código de vestimenta (que todos odiamos), horarios estrictos de trabajo, seguimiento de las horas de trabajo, sin trabajo desde casa y sin comida gratis! Si fuera por nosotros, estaría basado en resultados . ¡Y elimine todas estas BS administrativas!
6. Trabajo politico. Ya no es la supervivencia del más apto.

Estoy hablando del IIT! Sí, has escuchado bien.

TI india promedio ! (IIT)

Contestaré en la más simple de las palabras. ¡Entramos en el campo como nuevos, aprendiendo y confiando en nuestros conceptos básicos! Yeahhhhh! ¡Hagamos un traje de hombre de hierro y un JARVIS para hablar mientras lo hacemos!

¡Años en la industria, algunos de nosotros que tuvimos suerte, obtuvimos un desarrollo central en el nivel del sistema! ¡Otros tenemos una pequeña experiencia en el desarrollo de funciones! ¡La mayoría de nosotros solo tenemos experiencia en la corrección de errores, eso también está sujeto a la fecha límite o libera presión!

¡15 líneas de scripts que hicimos en casa nos dieron más placer que la mayoría de los errores que resolvimos!

Por ahora, nos hemos dado cuenta, para disfrutar de la codificación solo tenemos que seguir haciéndolo por nosotros mismos. ¡El trabajo que hace un programador promedio en la industria no tiene el potencial de proporcionar eso! ¡Lo más desafiante técnicamente fue esa entrevista que habíamos dado para ser seleccionados!

Algunos de nosotros sabemos una mierda sobre la codificación. Somos considerados basura en nuestra empresa. qué hacemos? Nosotros cambiamos Damos respuestas de plantilla en entrevistas de plantilla. Ahora tenemos gente nueva a nuestro alrededor, que sabe una mierda sobre nosotros. Y sí, ¿mencioné que ahora tenemos x% paquete adicional? Esperaremos en esta nueva compañía hasta que no se reviente la basura. Más tarde, repetiremos el mismo proceso.

Por ahora, nuestras familias piensan bien de nosotros. Somos respetados ¿Han visto nuestro trabajo? Por supuesto no. Han visto nuestro estilo de vida!

” ¡Amigo! ¡Tienes x experiencia, tu paquete debe ser mínimo 2x! ”

Nadie se da cuenta, este tipo está frustrado por dentro. Se maldice a sí mismo porque la cantidad de tiempo que pasa con Excel lo hace pensar que MS-CIT era una opción mucho más fácil que ese curso doloroso que estudió, llamado Ingeniería …

¡Salud!

Mi primer pensamiento es sobre algo que es muy difícil de aprender en cualquier carrera.

¿Cómo se encuentra una buena compañía para trabajar?

Esta es una de las muchas habilidades que no enseñan en la escuela. Es especialmente difícil de aprender como ingeniero. No porque no tengamos más oportunidades de aprender esta lección. Tiene más que ver con nuestra cultura, lo que dificulta el aprendizaje.

Por lo que puedo decir, nuestros primeros trabajos se definen principalmente por la suerte. Sin embargo, uno puede comenzar a aprender a oler si una empresa es abusiva o no si mantenemos los ojos abiertos. Especialmente si uno es flexible para moverse. Eventualmente, incluso se puede aprender a percibir las buenas empresas y no solo las malas.

Sospecho que la mayoría de la gente trabaja para compañías que los harán sentir miserables porque no saben más y tienen miedo de irse. Al principio de mi carrera aprendí esto principalmente por accidente. Viajé mucho por trabajo e hice muchos contratos. Comencé a notar patrones con compañías abusivas. Incluso después de poder reconocerlos, aún podría trabajar para ellos si pagaran una tasa lo suficientemente alta. De ahí nuestra cultura poco saludable …

En la actualidad, intento trabajar para empresas que tendrán el tipo de relación que prefiero. Tengo una relación muy feliz ahora que no planeo irme.

Esto no fue por suerte. Durante el proceso de la entrevista, me gusta obtener respuestas a un puñado de cosas que generalmente me permiten saber cómo piensan acerca de los ingenieros.

¿Qué tipo de control de fuente usan? Si no es un poco de sabor de Git, sé que no se toman en serio el desarrollo.

Cualquier empresa que admita un solo idioma estará limitada en su forma de pensar sobre la resolución de problemas. Especialmente si ese idioma es Java o .net.

Las empresas que pagan contratos de apoyo por cosas ridículas como apache u otros sin sentido deben considerarse con cuidado.

¿Los ingenieros asisten a conferencias de código abierto o, mejor aún, hablan en ellas? Si es así, ese es un signo muy positivo. ¿Existen programas de innovación o hackatones?

También me gusta hacer preguntas que evalúen la tolerancia a la calidad del código. ¿Creen que tienen algún código que no se cifra en vuelo? ¿Cuándo está bien no cifrar en reposo? ¿Conocen su cobertura de código para sus repositorios más importantes? ¿Cómo deciden cómo hacer compromisos sobre cosas como la consistencia frente a la disponibilidad? Por supuesto, algunas de estas preguntas no serían apropiadas para todos. Son una buena guía sobre qué tipo de preguntas hacer para descubrir cómo piensan. Las empresas donde estas cosas se deslizan a menudo tienen ingenieros que son golpeados emocionalmente.

Otro indicador fácil es preguntar a las personas en qué están más emocionadas de trabajar y por qué. Esmaltado sobre los ojos generalmente significa que te unirás a la fábrica de códigos si aceptas el trabajo.

Sospecho que una de las razones principales por las que la mayoría de los ingenieros no rompen 10 años es porque se conforman con relaciones abusivas donde las empresas simplemente no están tan metidas en ellas.

No odio mi trabajo

Quiero decir … no odio todo mi trabajo.

Hay aspectos que son aburridos. Hay aspectos que son molestos. Hay aspectos que son entretenidos. Hay aspectos que son agradables.

Hay aspectos de estos aspectos en casi cada momento de cada día en el trabajo.

Un ejemplo.

Escribir los requisitos sobre cómo debe comportarse una cosa es a menudo un ejercicio divertido y alucinante. Pero con mayor frecuencia es un ejercicio inútil . Impulsado por muchas opiniones diferentes. ¿Deben los requisitos indicar exactamente lo que debe hacer el código? ¿Deberían los requisitos ser vagos? ¿Cómo se probaría un requisito vago? ¿Cómo sabemos que hemos especificado lo suficiente para que Joe Schmoder pueda codificar a partir de los requisitos? ¿Cómo hacemos referencia a información suplementaria? ¿Qué constituye una revisión de estos requisitos? ¿Quién debería participar en la revisión? ¿Cómo debe llevarse a cabo la revisión? ¿Cómo resolvemos las diferencias de opinión sobre un requisito?

Escribir el código de cómo debe comportarse una cosa es a menudo un ejercicio divertido alucinante. Pero con mayor frecuencia es un ejercicio inútil . Impulsado por muchas opiniones diferentes. ¿Debería el código hacer solo lo que especifican los requisitos? ¿Qué pasa con este caso de esquina no cubierto por los requisitos? ¿Impulsamos una solicitud de cambio de requisito? ¿Esperamos mientras esperamos que el autor de los requisitos esté de acuerdo [o … que Dios nos ayude, no esté de acuerdo]? ¿Avanzamos pensando que sabemos mejor? ¿Qué pasa con la anomalía de hardware que no se conocía cuando se escribieron los requisitos que nos dicen cómo interactuar directamente con el hardware porque los requisitos se escribieron a nivel subatómico? ¿Qué pasa con el código que realmente no se puede rastrear a ningún requisito porque realmente no es nuestro código [el sistema operativo, etc.] ¿Qué pasa con el hecho de que elegimos usar un código de terceros para esta función? ¿Usamos tres espacios para pestañas o cuatro? ¿Utilizamos húngaro, camello o camello de pie?

Escribir las pruebas de cómo debe comportarse una cosa a menudo es un ejercicio divertido y alucinante. Pero con mayor frecuencia es un ejercicio inútil . Impulsado por muchas opiniones diferentes. ¿Deben las pruebas probar solo lo que especifican los requisitos? ¿Deben las pruebas abarcar todos los posibles valores de entrada? ¿Qué pasa con los enteros que podrían tener algún valor? ¿Qué pasa con … qué pasa con qué …

Descubrirá que la mayor parte de su día se consume con reuniones, soluciones de TI y problemas de proceso. Algo de eso es necesario. La mayor parte no lo es. Pero no tendrá éxito en sus desvaríos e intentará cambiar cualquier cosa. Créeme. Lo he intentado por años.

Encontrará que la mayoría de las reuniones son ofuscaciones de la realidad. Gráficos oculares, material de PowerPoint y un sinfín de “puntos de conversación” sobre nada. Las reuniones de estado se convertirán en festivales de culpa.

Encontrará que la mayoría de las acciones de TI están en contra de la productividad de la ingeniería. ¿Por qué querrías esa herramienta, cuando esta otra herramienta “desarrollada internamente” es “mucho mejor … e … interna”? Lo he visto demasiadas veces para contarlo.

Descubrirá que la mayor parte de la incertidumbre del proceso son solo personas que no han escrito una línea de código de software en años tratando de “agregar valor” al próximo proyecto mediante la inyección de procesos en la parte superior de los procesos para garantizar que los errores que cometieron no sean Hecho por cualquiera de ustedes. No importa que esos errores fueron en gran parte, si no completamente, eliminados por modernizaciones como IDEs con autocompletado, depuradores modernos, etc.

Es un trabajo divertido.

Muchos desarrolladores de software odian su trabajo porque pasan sus días encadenados a un escritorio, reparando defectos creados por el idiota que construyó el sistema, que probablemente ahora esté en la administración. Por lo tanto, no se les permite revelar la verdadera razón por la cual el sistema está teniendo tantos problemas, y es probable que se les culpe injustamente de problemas que no son su culpa.

Encontré una solución; Trabajo para mí, desde mi casa en una tranquila playa tropical. Creo pequeños sistemas para los clientes que elijo. Puedo pasar mucho tiempo con mi familia y amigos. Tengo mucha experiencia, por lo que los sistemas que construyo rara vez contienen errores graves. Los errores que se me escaparon fueron creados por mí, por lo que incluso cuando hay un problema, no siento que esté palear la basura de otra persona.

La vida es buena.

Aquí hay algunas cosas que me vienen a la mente

1. El 50% de los ingenieros no quieren hacer ingeniería. El 30% no sabe por qué lo están haciendo. La pasión es de algún lado. Las personas de TI terminan en otro lugar.
2. La mayoría de las personas que terminan en TI sin mucho interés perseguirán dinero porque no pueden perseguir nada más en este campo. Perseguir dinero es lo último que hará un hombre feliz, aunque el dinero es importante.
3. La configuración completa de los trabajos de TI está configurada de tal manera que los individuos en un equipo deben luchar entre ellos para demostrar un punto a la gerencia para obtener una buena evaluación. Invariablemente, las personas en el equipo tratarán de complicarse la vida mutuamente (no digo que las personas sean malas. Estoy diciendo que las políticas de recursos humanos pueden cambiar y hacer que el ambiente de trabajo sea agradable)
4. Esto es específico para los trabajos de TI indios. La mayoría de ellos quiero decir que más del 80% de ellos son monótonos con menos innovación y creatividad. Las personas solo se preocupan por el trabajo diario con menos importancia para: el desarrollo de la personalidad, el desarrollo de las habilidades requeridas, la mejora de los métodos de evaluación, etc. Espero que la automatización tome la mayoría de estos trabajos y libere a estas grandes mentes (aunque no se dieron cuenta de este hecho sin embargo … una vez que estén fuera de su zona de confort, llegarán a saber) hacer algo realmente importante para este mundo que realmente requiere personas creativas e inteligentes.

Por último … entonces, ¿por qué la gente lo hace?

1. Porque otros lo están haciendo.
2. Dinero
3. Porque quieren ver a su familia feliz
4. Miedo al fracaso
5. No ser consciente de sus capacidades.
6. muchas más razones no tan lógicas …

Salud…

Después de pasar 12 años en este campo, puedo garantizar los siguientes puntos:

1. Mucha gente trae esta noción a sus trabajos de que siempre se tratará de la codificación. Asumen que se les dirá que “WAP en X para imprimir la serie de Fibonacci”. El mundo real no se adhiere a ninguno de esos dos. No siempre estará haciendo codificación y no será tan sencillo.
2. Las personas no quieren entender el negocio para el que están resolviendo el problema. En realidad, muchas personas que he conocido no pueden entender el lado comercial. Recuerde que la industria del software existe para resolver un problema existente en un mundo real. Necesita comprender las empresas para resolver su problema a través del software.
3. La gente siempre quiere escribir un software revolucionario, revolucionario y universal. Gracias a la cultura de Silicon Valley. NADIE quiere resolver un problema comercial simple. Salesforce comenzó resolviendo un problema comercial muy simple cuya magnitud era enorme. Puede tener éxito al proporcionar soluciones simples a los problemas comerciales que están afectando a muchos. Este espejismo creado por uno mismo en el que cualquier cosa menos que un software devastador es aburrido y una mierda es lo que mantiene a muchos programadores infelices e insatisfechos.
4. La gente tiene miedo. Mucha gente está en trabajos aburridos que pueden absorber energía de sus almas. Pero, ellos no quieren cambiar. No tienen valor para dar el primer paso hacia el aprendizaje y asumir un papel que exige un aprendizaje exponencial.
5. Algunos codificadores engañados piensan que unirse a la tierra utópica donde todos hacen MBA proporcionará elixir a sus almas aplastantes. No lo hará. La hierba siempre es verde en el otro lado los mantiene infelices. He estado allí yo mismo.
6. Podemos aprender mucho para mantener una base de código ya escrita. ¿No me digas que no aprenderás nada sobre el mantenimiento del código de búsqueda de Google? Es solo que la gente no quiere mejorar un código existente o una pieza de software malo a menos que se le indique. Peor aún, están bajo la tutela de gerentes que dispararán armas si algo sale mal mientras mejoran las cosas. Así que no es de extrañar que no se arriesguen.
7. Los ingenieros de software están casados ​​con un idioma: el otro día conocí a un chico que está literalmente casado con Java y no puede pensar en escribir código en ningún idioma. Él piensa que la engañará (Java). Quiere hacer todo en Java. No está listo para retomar proyectos en otros lenguajes de programación disponibles. Le teme a lo desconocido. Incluso Peter Norvig ha aconsejado aprender muchos tipos de idiomas.

Aprenda al menos media docena de lenguajes de programación . Incluya un lenguaje que enfatice las abstracciones de clase (como Java o C ++), uno que enfatice la abstracción funcional (como Lisp o ML o Haskell), uno que admita la abstracción sintáctica (como Lisp), uno que admita especificaciones declarativas (como las plantillas Prolog o C ++) , y uno que enfatiza el paralelismo (como Clojure o Go).

Le dije a mi amigo que había salido con mis lenguajes de programación, algunos son mis ex y todavía salgo con muchos lenguajes de programación. No estoy casado todavía.

8. Por último, pero no menos importante, su pasión no es la programación. Son programadores de software no por elección sino porque siguieron la mentalidad de rebaño y ahora son ingenieros de software. O tomaron la ingeniería electrónica y cambiaron a un trabajo de programación cuando estaba disponible. Se aplica principalmente a los indios. Soy uno de esos. Ahora, dado que no es su pasión, hacen un mal trabajo al crear un software. No es de extrañar que el software resultante fuera una mierda y luego sean regañados por un mal trabajo. Como haces un trabajo pésimo, tu jefe no te dará acceso a proyectos importantes si tiene alguno. No avanzarás. Por lo tanto, es importante si desea avanzar para hacer su trabajo lo mejor posible. Esto le abrirá formas en el futuro, ya que es conocido por escribir nada menos que código estelar.

Me he centrado solo en los parámetros que están bajo el control de un individuo. Soy consciente de que hay muchos factores incontrolables. No me he centrado en ellos ya que no puedo cambiar factores que no están bajo nuestro control.

Amar y tener éxito en un campo de programación es como tener citas, tienes que estar abierto para coquetear, salir con muchos para entenderlos y ver sus méritos y deméritos relativos. Como la vida, no te casas con uno muy temprano. Necesitas besar muchas ranas para conocer a tu príncipe.

Sigue coqueteando. Sigue reuniéndote. Sigue codificando. Seguir aprendiendo.

Porque una gran parte del trabajo de un ingeniero de software es tedioso. Algunos ejemplos

1. Pasaste 3 horas perfeccionando un módulo eficiente y conciso. Ahora su “trabajo” es pasar 16 horas más escribiendo pruebas exhaustivas para ello.
2. Debe pasar 2 horas más analizando las reglas de negocios y descifrando los requisitos ambiguos para escribir las pruebas.
3. Debe configurar CI y automatización confiables porque sus predecesores nunca se molestaron con ellos.
4. Debe reescribir 900 casos de prueba heredados porque fallan esporádicamente.
5. 300 de los casos de prueba heredados son para reglas comerciales indocumentadas y nadie comprende por qué están allí o si pueden eliminarse.
6. Constantemente recibe preguntas de “¿Por qué el software hace esto?” No escribió el código. No hay documentación Pero tiene que aplicar ingeniería inversa a las reglas comerciales desde el código.
7. Tiene requisitos para una nueva característica que es completamente congruente con los módulos existentes y el comportamiento del sistema. Puede construirlo según lo solicitado y agregar a la deuda técnica, o debe educar al solicitante y ayudarlo a diseñar una solución más sensata.
8. Algo salió mal en la producción. Estás despierto durante 18 horas tratando de arreglarlo.

Todas estas son tareas valiosas y requieren las habilidades exclusivas del ingeniero. Pero son TRABAJOS DUROS Y TEDIOSOS.

Claramente tienes interés !!!

Permítanme arrojar algo de luz sobre el odio con mi propia experiencia:

1. Algunos estudiantes de primer año serán entrenados en un dominio particular, pero trabajan en otro dominio. # Odio
2. Una vez que ingresan al proyecto, las personas mayores impondrán su carga de trabajo y obtendrán créditos en su nombre. # Odio
3. Después de un año, no obtendrán un aumento salarial si nunca han felicitado a sus mayores por cada estupidez. #Odio
4. Sus grandes ideas nunca llegarán a sus oídos mayores. Confía en mí, soy una víctima en esto. #Odio
5. No importa qué, en su mayoría estarán en turno de noche. #Odio
6. Sufren hasta que se vuelven mayores o cambian a otra compañía. #HateEnds

Cada #Hate depende del proyecto en el que se encuentre. Hay algunos buenos proyectos y buenas personas de la tercera edad.

“No solo en TI, estas cosas tienden a suceder en casi todos los campos”.

También recibí algunos consejos:

1. Diríjase a una empresa basada en productos si le gusta la programación. Los servicios basados ​​no son para programadores.
2. Nunca des tu 100% por la compañía, simplemente no les importa, ahorra algo de tu energía para mejorarte todos los días.
3. El paciente y la perseverancia son la clave, no puedes hacer una diferencia así como así. Espera tu turno.
4. Mejore las habilidades para resolver problemas, esto lo lleva a donde quiere estar.
5. Acepta la vida como es y disfruta, simplemente no te rindas a ella.

Después de mucha investigación, incluso encontré la respuesta. Cuando te coloquen en algunas grandes empresas como Infosys, Wipro, Tcs, etc., te capacitarán básicamente en cualquier lenguaje de programación y luego en un lenguaje de script como Python, entonces estarás allí en el banco para algún tiempo (digamos de 6 a 12 meses). Luego formará parte del proyecto. Después de algún tiempo trabajando en el proyecto en estas empresas orientadas a servicios, generalmente el tipo de trabajo será de naturaleza repetitiva. así que no es un tipo de trabajo de ciencia espacial. Cualquier persona que tenga conocimientos básicos de inglés puede ser perfecto en cualquier lenguaje de programación en solo 6 meses. Así que mi sugerencia para usted si desea seguir su carrera en TI que planear ir a empresas basadas en productos . Entonces, al menos, no odiarás tu trabajo durante 15 a 20 años.

Sé por qué los ingenieros de software odian sus trabajos, yo también soy uno de ellos.

1. Eres perfecto en una tecnología, pero estás obligado a trabajar con algunas tecnologías diferentes que no te gustan.
2. Presión de trabajo, algunas veces necesitas trabajar en fin de semana.
3. Menos trabajo de desarrollo, más trabajo de mantenimiento.
4. Menos codificación, más formalidades, como pruebas, revisión de código,
5. Con frecuencia cambio de requisitos del cliente.
6. Tienes que trabajar bajo alguien, siempre habrá plazos para los entregables.

Lo que creo es que ” un fotógrafo no puede odiar su pasión por la fotografía, pero puede odiar el trabajo de fotografía debido al empleador ”

Similar,

“ Un ingeniero de software apasionado no odia su pasión por crear la propia aplicación, si odia el trabajo. Definitivamente podría deberse a la empresa o al cambio de estilo de vida debido al trabajo ”

Si está de acuerdo con esto, entonces …

Existen otros Mitos sobre empleados de TI que también serían aplicables a los empleados de Software.

Ellos dicen…

1. Salir a tiempo es un crimen
2. Revertir correos sin TL es una mala práctica
3. Cuando un empleado solicita licencia por más tiempo, es LOP. Cuando el gerente se va por más tiempo, es VACACIONES.
4. Cuando cuidas de tu propia familia, estás nostálgico. Cuando trabaja para la familia de su gerente, su responsabilidad queda demostrada para el próximo proyecto. Jajaja

Y aquí hay más razones que podrían ser aplicables: 10 mitos sobre los empleados de TI que se dieron cuenta en el momento de la evaluación 🙂

Para empezar, soy un aprendiz graduado en una empresa de software. Me colocaron en las prácticas universitarias. La compañía, cuando visitó inicialmente nuestro campus universitario, fue venerada por nuestro gerente de colocación porque nos ofrecía un paquete soñado.

Hice la entrevista muy bien y estaba más que seguro de que me seleccionarían. ¡Y sucedió! Yo junto con mis amigos que fueron colocados estaban extáticos. Tuvimos un entrenamiento de la compañía en nuestra propia universidad. Nos enseñaron C, C ++, Core Java, java avanzado, sql, plsql, unix, todo desde cero (conocíamos solo a C y Java durante la entrevista, ya que provenimos de una rama que no es de TI). Todo salió bien hasta que terminó la capacitación. Aprendimos todo lo que nos enseñaron con la mayor dedicación y no podíamos esperar para unirnos a la empresa.

Finalmente, una buena mañana fuimos invitados a unirnos a nuestros trabajos. Fuimos y completamos los trámites iniciales. Alrededor de la tarde, tuvimos una pequeña reunión con nuestro gerente. Estábamos entusiasmados de haber sido seleccionados para el desarrollo. Ahora nos dimos cuenta al día siguiente de que la tecnología utilizada por nuestro equipo es AS400, de la que nunca había oído hablar. Estaba terriblemente decepcionado cuando investigué en línea y descubrí que era casi obsoleto. Sin embargo, me consolé que las técnicas de desarrollo en cualquier idioma serían las mismas. Así que me concentré en la capacitación durante 2 meses y me asignaron a un proyecto. Han pasado 4 meses y no tienen ningún trabajo de desarrollo concreto que podamos hacer. Nos dan algunos programas para depurar y sucedió durante semanas. No sé por qué nos pusieron en el equipo en particular si no nos requerían. Además, me llamo desarrollador, pero no he aprendido nada aparte de redactar correos electrónicos y depurar.