Recientemente comencé mi carrera como desarrollador web para una empresa mediana. Tan pronto como comencé, tuve la tarea de expandir una aplicación existente (mal codificada, desarrollada por múltiples programadores a lo largo de los años, maneja las mismas tareas de diferentes maneras, estructura cero).

Entonces, después de haber extendido con éxito esta aplicación con la funcionalidad solicitada, me dieron la tarea de mantener completamente la aplicación. Por supuesto, esto no fue un problema, o eso pensé. Pero luego escuché que no se me permitía mejorar el código existente y solo enfocarme en la corrección de errores cuando se informa un error.

Desde entonces, he tenido tres proyectos más como el anterior, que ahora también tengo que mantener. Y obtuve cuatro proyectos en los que se me permitió crear la aplicación desde cero, y también tengo que mantenerlos.

En este momento estoy empezando a volverme loco por los correos diarios de los usuarios (administradores de lectura) para cada aplicación que tengo que mantener. Esperan que maneje estos correos directamente mientras también trabajo en otros dos proyectos nuevos (y ya hay cinco proyectos más alineados después de esos). Lo triste es que todavía tengo que recibir un informe de error sobre todo lo que he codificado. Por eso, solo he recibido ocasionalmente solicitudes de cambio para hacer cosas de 180 grados diferentes.

De todos modos, ¿es esto normal? En mi opinión, estoy haciendo el trabajo equivalente a todo un equipo de desarrolladores.

¿Era un idiota cuando inicialmente esperaba que las cosas fueran diferentes?

Supongo que esta publicación se ha convertido en una gran queja, pero por favor dime que esto no es lo mismo para todos los desarrolladores.

PD: Mi salario es casi igual, si no más bajo, que el de un cajero en un supermercado.

Durante una de mis pasantías descubrí que pasaba mucho tiempo arreglando errores. Tienes que darte cuenta de que como empleado de nivel de entrada no vas a obtener el trabajo más sexy, vas a obtener el trabajo duro que nadie más quiere. Es desafortunado, pero es así en cada trabajo.

Además, debe darse cuenta de que, para una empresa, tener un código que funcione es más importante que tener un código limpio. Desde la perspectiva de su empresa, cambiar la estructura existente es una pérdida de dinero al rehacer algo que ya está hecho e introducir aún más errores. Por lo general, este tipo de empresas no son empresas de informática / software, por lo que ningún gerente lo suficientemente alto tiene la formación técnica para saber que a veces es necesario realizar estas revisiones importantes. Dicho esto, si su empresa está dirigida por personas técnicamente competentes y entienden el valor de un buen código, es posible que tenga más margen de maniobra, aunque a veces necesita elegir sus batallas (después de todo, el objetivo principal de un negocio sigue siendo ganar dinero). )

Dicho esto, no es irrazonable querer dejar su huella en el software y querer un trabajo más significativo. También es desafortunado que tengas que lidiar con tantos proyectos a la vez mientras respondes las solicitudes de tantos gerentes diferentes.

Como programador, es una realidad que pasarás más tiempo manteniendo y modificando el código de otras personas que escribiendo el tuyo desde cero. Si esto es un problema para usted, entonces quizás debería seguir desarrollándose como un pasatiempo y seguir una carrera diferente. Si está de acuerdo con mantener el código, pero siente que no se lo está utilizando de manera efectiva o se está abrumando, entonces es un tema que debe discutir con su gerente. Si sus problemas son más serios que eso o si siente que sus gerentes no saben cómo administrar eficazmente su conjunto de habilidades, sería una buena idea considerar encontrar un puesto en una empresa diferente. Dado su bajo salario declarado, este es probablemente su mejor curso de acción.

Parece que la administración tiene un problema para administrar su carga de trabajo y priorizar tareas. Debes hablar con tu gerente y hacerles entender que estás sobrecargado y que no puedes hacer un trabajo efectivo si todos siguen bombardeándote con solicitudes que quieren cumplir de inmediato.

Eso te hace saltar de una tarea y proyecto a otra, perdiendo mucho tiempo cambiando de marcha en tu mente. Para un trabajo de desarrollo de software efectivo, uno debe poder sumergirse en una tarea y concentrarse completamente en ella. Cuantas más interrupciones se obtengan, más tiempo se pierde mediante el cambio de contexto. La investigación muestra que lleva unos 15 minutos sumergirse y llegar al estado de flujo donde nuestra mente trabaja de la manera más eficiente. Si recibe interrupciones cada 15 minutos, nunca podrá fluir, lo cual es un desperdicio tremendo tanto para usted como para la empresa.

Por lo tanto, debe tratar de negociar un modo de trabajo más sensible con su gerente . Esto debería incluir priorizar las solicitudes entrantes y planificar con anticipación hasta cierto punto . Todas las solicitudes de los usuarios deben mantenerse en una lista, ordenadas por prioridades. Y las prioridades no deben ser decididas por el solicitante (ya que, naturalmente, todos piensan que su solicitud es la más importante del mundo), ni usted, sino alguien con suficiente conocimiento comercial y una visión general de toda la gama de productos que está manteniendo ( el dueño del producto ).

Idealmente, todas las solicitudes entrantes deben ingresarse en un rastreador de problemas como JIRA o Mantis . O al menos enviado por correo al propietario del producto, no a usted. Y él / ella también debe ocuparse de todas las quejas de los usuarios sobre "¿por qué mi solicitud aún no está lista?", Lo que le permite concentrarse en el trabajo de desarrollo. Si esto es inalcanzable, al menos debe negociar algunas ventanas de tiempo cuando mira las solicitudes entrantes y las trata, reservando una parte ininterrumpida de su tiempo únicamente para el desarrollo.

Si esto es posible, el siguiente paso podría ser planificar con cierta anticipación. Es decir, calcule el tiempo necesario para implementar las solicitudes de máxima prioridad, luego programe su tiempo en sprints , que pueden ser una o más semanas cada uno, y asigne suficientes tareas al próximo sprint para cubrir su tiempo.

Probablemente desee mantener una parte de su tiempo para las solicitudes de emergencia entrantes, pero el resto se puede planificar con anticipación. Y también puede preferir organizar el trabajo en diferentes proyectos en "líneas" separadas, es decir, trabajar en el proyecto A el lunes, el proyecto B los martes y miércoles, el proyecto C el jueves por la mañana y D la tarde, etc. reducir el cambio de contexto.

De esta manera, tiene una idea aproximada de lo que debe hacer en la próxima o pocas semanas. Además, esto también proporciona una hoja de ruta a sus clientes: pueden ver cuándo implementan qué solicitud. Es posible que desee o no mencionar la palabra "ágil" a su gerente aquí; esto es básicamente un desarrollo ágil , pero algunas personas se oponen a ágil sin saber realmente qué es :-)

Tenga en cuenta que incluso si su posición actual parece poco valorada por su empresa, cuantos más proyectos mantenga, más poder de negociación tendrá .

Encontrar y capacitar a un nuevo empleado para mantener todos estos proyectos lleva un tiempo considerable (= dinero) para la empresa. Y puede señalar con razón que su código es mucho mejor que las partes heredadas de estas aplicaciones, por lo que no es un hecho que puedan encontrar fácilmente un candidato con capacidades similares por la misma cantidad de dinero. Sin mencionar que si no mejoran las condiciones de trabajo, harán que el próximo tipo se hanse y renuncie tan rápido como tú ... Trata de hacerles entender que lo mejor para ti es mantenerte, y para mantenerte feliz donde estás :-) Esto puede darte algo de poder para negociar las condiciones anteriores y / o solicitar un aumento de sueldo.

Cuánto poder de negociación tiene, esa es una gran pregunta. Su gerencia puede o no estar abierta a estas ideas, y puede o no respetarlo lo suficiente como para tomar en serio sus súplicas. Pero si juegas bien tus cartas, tienes una oportunidad. Y si se niegan ... siempre puedes buscar un mejor lugar de trabajo. Esta situación no es la misma para todos los principiantes, aunque (lamentablemente) sus experiencias son bastante típicas. Pero realmente hay mejores lugares de trabajo por ahí . La calidad del lugar de trabajo solo se relaciona libremente con la ubicación geográfica, pero creo que en el norte de Europa tienes más oportunidades que el promedio. Por lo tanto, si no puede mejorar notablemente sus condiciones actuales, debe comenzar a buscar de inmediato , antes de cansarse por completo y quemarse.

Es inmensamente mejor buscar un trabajo mientras todavía tiene uno, por lo que no necesita aceptar la primera oferta solo porque necesita dinero de inmediato. Eventualmente encontrarás un lugar mejor :-)

PD: Mi salario es casi igual, si no más bajo, que el de un cajero en un supermercado.

Je, quería escribir algo sobre cómo negociar hasta que lo leyera. ¡Ahora todo lo que puedo decir es irme! Suponiendo que eso sea la mitad de lo que generalmente gana un desarrollador con un título. Y suponiendo que las cosas mejoren y que le den de inmediato un aumento del 10%, puede averiguar cuánto tiempo lleva llegar allí. También parece que no aprendes nada en el trabajo y no pareces estar rodeado de ingenieros brillantes allí, por lo que es una pérdida de tiempo.

También estaba en una situación similar, y puedo decirte que si te mantienes en esa pista, nunca termina. La gerencia seguirá pagándote, porque ... ellos pueden.

Hay algunas ideas adicionales que tengo sobre este tema.

1. Haz lo que amas. Si no lo amas, prepárate para hacer el intento de encontrar qué es lo que podrías amar.

2. Comunicación. Comunique claramente sus incapacidades para cumplir con expectativas poco realistas. En mi experiencia similar, el arquitecto (que hizo la mayor cantidad de palas) dijo: "tienes que manejar las expectativas de los demás sobre ti".

3. Burnout Si no has experimentado agotamiento, no tientes al destino. Te quita la vida y el alma de la mente. A pesar de su mejor esfuerzo, su propósito de trabajo se vuelve gris, triste y sin sentido. Imparto este consejo porque debes, a toda costa, evitar el agotamiento.

4. Formación. Aquí está el lado positivo. Su entrenamiento y experiencia, aunque frustrante y quizás mal pagado, es de hecho muy valioso para su carrera. Esta es su gracia salvadora para darse cuenta de esto porque puede absorber la mayor cantidad de aprendizaje posible y retrasar cualquier techo de vidrio inevitable.

Concéntrese en los talentos y habilidades que está creciendo ... Esto lo llevará a través de las próximas oportunidades de su carrera.

Estás lidiando con múltiples problemas aquí ... Comencemos con lo obvio ...

¿Esto es normal?

Diablos no. Pero ... ¿es común? Por desgracia sí.

Con respecto a la frustración de corrección de errores

Si bien eso no excusa el resto del desorden con el que tiene que lidiar y los múltiples proyectos con los que lo sobrecargan, solo quiero hacer una nota rápida de que el enfoque de "corrección de errores" solo es frustrante para usted como desarrollador , puede ser un enfoque perfectamente sensible para la empresa y su gestión.

Superficie para más errores y costos

Cuanto más código toque, más probabilidades tendrá de introducir errores, incluso si su intención es mejorarlo. Eso significa tiempo de desarrollo extendido, tiempo de prueba y costos. Y si se desliza a un lanzamiento de servicio con un defecto medio a alto, eso es un gran desastre para ellos.

Ruido / Niebla en sus Registros

Desde una perspectiva SCM, también tiene un poco de sentido si trabaja directamente desde la rama de una versión de servicio, ya que desea tener una visión clara de los cambios relacionados con la corrección de errores. Si hay 15 confirmaciones con miles de cambios en torno a una corrección de errores que realmente requirieron tal vez un cambio de código de 1 línea, es un poco molesto.

Por lo tanto, al ser un nuevo empleado, es aún más sensato pedirle que se abstenga de refactorizar y / o mejorar el software, y bastante bien en mi sentido para ser lo más "quirúrgico" posible con sus correcciones de errores. Simplemente mantiene a raya los dolores de cabeza.

¿Puedes hacer algo por ello?

Ahora, NO significa que habría formas de lograr tanto la cordura del código como la cordura de las mentes de las personas involucradas. Al ser junior, deben hacer que alguien revise sus cambios, especialmente las correcciones de errores, y se aseguren de que estén aprobados antes de llegar a las versiones de lanzamiento del servicio. Eso evitaría o limitaría los cambios radicales y sería más seguro.

El proyecto del infierno

Código de basura, manada de programadores, duplicación, arquitectura de basura

Una vez más, el defensor del diablo aquí, pero solo muestra que su solicitud inicial contiene algunos bits no consecuentes.

Mi punto es este: realmente realmente realmente rara vez me hice cargo de una base de código que no estaba en este estado. Y por casualidad que lo hice, recientemente se iniciaron proyectos o prototipos que habían sido iniciados por programadores bastante estelares. Pero la asombrosamente vasta mayoría de ellos parecía basura, y un número aterrador de estos eran basura real. Incluso los iniciados por buenos o grandes programadores pueden terminar siendo basura, plazos y otros compromisos que ayudan ...

¡Bienvenido a la ingeniería de software industrial de la vida real!

¿Y sabes lo que es divertido? A menudo es mucho peor en el mundo del desarrollo web. ¡Disfrutar! :)

Demasiados proyectos y solicitudes, no suficientes manos y tiempo

El problema radica aquí probablemente en:

• su administración (tal vez inconscientemente) abusando de usted ,
• tus colegas (tal vez inconscientemente) abusando de ti ,
• tu (tal vez sin saberlo) no cubres tu trasero y peleas tus batallas lo suficiente .

Sus gerentes deben saber que está trabajando en demasiados proyectos para administrar. Si no lo están, asegúrese de que estén lo antes posible. Asegúrate también de que sepan que no todo fue un piquete en el parque y que te sentiste presionado y que debe detenerse.

Trate de echar un vistazo y asegúrese de que sus colegas no desvíen más tareas y proyectos sobre usted, directamente (diciendo realmente "X será capaz de encargarse de eso") o indirectamente ("No soy la persona adecuada para esto, busca a alguien más "-> termina siendo tú).

Anécdota personal aquí: hice una pasantía hace unos años, y justo en mi último día, cuando recibí mi evaluación, mi jefe me dijo, a pesar de estar muy satisfecho con mi trabajo en general, que uno de los gerentes tenía la sensación de que yo había estado descargando algunas "tareas no tan divertidas" en otro interno cuando hubieran esperado que las recogiera. Estaba mortificado de que se sintieran decepcionados, y ante la idea de que parecería que me estaba aflojando, cuando mi intención era exactamente lo contrario: estaba tratando de tomar las tareas más difíciles y hacer que el otro interno más joven lidiara con menos cabello problemas de extracción. Poco me di cuenta de que, si hubiera estado en su posición, me habría aburrido la falta de desafío y probablemente me hubiera sentido como él. El punto es que debe comunicarse para asegurarse de que nadie haga suposiciones falsas sobre 3 cosas muy distintas:

• lo que puede hacer ,
• lo que quiere hacer ,
• y lo que estás dispuesto a hacer .

Entonces, también es en parte tu culpa por dejar que se convierta de esta manera. Pero es normal, es una lección que todos deben aprender. Se sostiene en dos letras: N - O .

Usualmente lo empleas como prefijo para una respuesta más larga pero no mucho más cargada: No, no puedo hacer esto. No, no sé cómo hacer esto. No, no estoy seguro de ser la persona adecuada para esto. No, nunca he hecho eso.

Al principio, es muy fácil sentir que puedes decir "sí, lo haré (eventualmente)", y apilar las cosas y hacerlas, tal vez poniendo algunas horas adicionales. Eso está mal. Debe comprender que su tiempo es, después de sus habilidades, su activo más valioso, para usted y para su empresa. Si se usa incorrectamente, afecta los proyectos, los plazos y los presupuestos . Tan sencillo como eso.

Además, parece un poco preocupante que tengas demasiadas personas para informar. Está bien tener varios clientes con los que tratar, y múltiples propietarios de proyectos o incluso interesados ​​principales con los que necesita comunicarse. Pero, en general, especialmente cuando es un nuevo empleado, debe informar solo a unos pocos gerentes (y muy probablemente solo a su gerente directo, y posiblemente a un desarrollador principal o principal). ¿Cómo fue de esta manera? No lo sé. Puede ser un problema de organización en su empresa, o puede ser el resultado de que usted haga un favor y luego de ser contactado directamente y no decir "no". O puede ser que su gerente directo tenga problemas con las tareas de despacho, por lo que sé (realmente lo adivino, pero el patrón es reconocible y conocido).

Te recomiendo que hagas lo siguiente con bastante rapidez: ve a hablar con tu gerente directo en persona, explícale que otros gerentes pueden ser un poco agresivos o (probablemente menos quejumbroso) que tienes demasiadas cosas acumuladas de demasiadas personas, y que necesita su opinión (y posiblemente también la de ellos) para saber cuáles priorizar.

Solicitudes de cambio de 180 grados

Estos son otro gran problema. Probablemente no sean tu culpa, pero puedes intentar ayudarlos a solucionarlo.

Las "solicitudes de cambio de 180 grados", como las llama bella y acertadamente, son una clara señal de que los requisitos son confusos desde el principio, y de que nadie se esfuerza lo suficiente para que se corten y aclaren con el tiempo.

Por lo general, es cuando alguien necesita hablar por teléfono (o mejor, ponerse de pie) y agarrar a los interesados de la mano y decirles claramente: "ahí es donde estamos, ahí es donde quieres que vayamos, ¿confirmas que estamos yendo en la dirección correcta? Está bien no obtener respuestas claras al principio, pero cuanto más tiempo pase, más claros deberían ser, o este proyecto es un desastre a la espera de que suceda.

Por lo general, diría que tome a todos los interesados ​​a su alcance, póngalos en una habitación, guíelos a través de problemas litigiosos e intente resolverlos gradualmente, y obtenga prioridades mientras lo hace. Sin embargo, en su caso, puede que esta no sea su decisión. Pero mencionas que realmente te dieron la responsabilidad de los proyectos; así que si ese es realmente el caso, entonces asume la responsabilidad y hazlo. Y NO evite decir "NO PODEMOS hacer eso" , o incluso " NO PODEMOS hacer eso" . Es realmente importante limitar el alcance de un proyecto.

Si no hay alcance, no hay requisitos claros al final de la discusión.

Sobrecarga de correo electrónico

Las personas tienden a comportarse de manera diferente según el medio de comunicación que utilizan. Personalmente, aunque soy una persona de habla suave (y he estado trabajando principalmente en países extranjeros, por lo que tampoco me gusta mucho hablar por teléfono), preferiría en orden de preferencia en función de la productividad:

• hablando con la gente cara a cara ,
• hablando con personas por teléfono,
• hablando con la gente a través de mensajería instantánea,
• hablando con la gente por correo electrónico.

Los correos electrónicos son buenos para el seguimiento, para obtener confirmaciones, para enviar notas.

Para programar, planificar y discutir puntos problemáticos, son casi inútiles. Toca la puerta del chico hasta que la abra y siéntate con un bloc de notas y una copia de tu documentación para aclarar las cosas. Una vez que haya terminado, envíe un correo electrónico y solicite confirmación. Si vuelve con una respuesta negativa o un intento ligeramente oculto de esconder algo más en el sobre, ve a hacer asediar la oficina de tu interlocutor nuevamente.

Esto es ingeniería de software. A menudo es más productivo cuando no escribe en un teclado, y en realidad puede reducir por adelantado la basura con la que tendrá que lidiar.

Hacer el trabajo de un equipo

¿Estás haciendo el equivalente al trabajo de un equipo? Tal vez.

¿Estás haciendo el equivalente al trabajo de tu equipo? Probablemente no.

Lo que quiero decir es que su equipo probablemente está ocupado trabajando y usted está sobrecargado de trabajo. Y ese es el problema: estás sobrecargado con cosas que deberían ser eliminadas de los plazos actuales del proyecto o entregadas a alguien con tiempo libre.

¿Era un idiota cuando inicialmente esperaba que las cosas fueran diferentes?

No; Solo nuevo en la fiesta. Es como una primera obsesión o relación. Lo superarás.

Supongo que esta publicación se ha convertido en una gran queja, pero por favor dime que esto no es lo mismo para todos los desarrolladores.

Esto es lo mismo para todos los desarrolladores en organizaciones caóticas, ya sean startups o gigantes bien establecidos, y sin experiencia ni confianza para hacer que las cosas se muevan un poco para inclinar sus posibilidades de supervivencia en el lado derecho de la escala.

PD: Mi salario es casi igual, si no más bajo, que el de un cajero en un supermercado.

Hice salarios decentes en trabajos que parecerían malos. No es el número en el cheque lo que cuenta, es el contexto. Lo que haces, tu edad, dónde vives y trabajas, etc.

Dicho esto, si estás muy mal pagado, trabajas demasiado y no eres del todo menor, ¡ ve a pedir ese aumento u obtén un nuevo trabajo!

Es sencillo:

• si valoran lo que haces, con gusto aceptarán un aumento,
• si no lo hacen, el futuro en esta empresa no parece muy optimista (para usted, al menos, que es lo que importa), así que no se sienta mal por irse.

Ten en cuenta que pedir un aumento es algo bueno, aunque no estarías obligado a pensarlo al principio. Demuestra que realiza un seguimiento de lo que hace y sugiere que está atento a otra opción sin dejar de estar dispuesto a permanecer a bordo. Y es bueno acostumbrarse a solicitarlos, ya que son como entrevistas de trabajo o negociaciones en general: es algo que requiere práctica, y no se caen del cielo si no los alcanzas tú mismo. Algunas compañías distribuirán aumentos regularmente sin que se lo soliciten, pero eso es solo porque son lo suficientemente inteligentes como para saber que te mantiene medio feliz y menos dispuesto a cambiar, y quieren cortar el césped bajo tu pie (la mayoría de las personas sentirían un poco incómodo por aumentar una oferta de aumento que se les ha ofrecido directamente).

Cómo proceder con esta solicitud está un poco fuera del alcance de ESTE proyecto aquí, así que no entraré en detalles. Pero le recomiendo que prepare un registro de sus ID de confirmación SCM, de sus errores y logros corregidos, y que también prepare informes comparándolos con el esfuerzo general del equipo. De esta manera:

• puedes medir por ti mismo si efectivamente hiciste mucho más que tus compañeros o no,
• puede mantenerse firme si dicen que su solicitud no está justificada.

Además de los comentarios de otras personas:

1. Sí, es normal que a un empleado de nivel de entrada se le den los trabajos que nadie más quiere hacer.

2. Debería ver esto como un componente básico para su futura carrera.

Entonces, ¿qué debería hacer? Para demostrar su valía como desarrollador profesional, debe asegurarse de que su trabajo esté estructurado y planificado, de lo contrario, puede resultarle difícil desarrollar las cosas buenas que está haciendo actualmente, por lo que debe intentar hacer cosas como las siguientes (si ya no estás)

1. Registre su trabajo con precisión, para cada proyecto. Entonces, si pasa una hora arreglando un error en el proyecto A, inicie sesión esta vez. Esto será útil para mostrarle a su gerente si desea analizar las cargas de trabajo.

2. Escribir pruebas unitarias. Menciona que algunos de los proyectos que mantiene están llenos de errores, por lo que supongo que hay pocas (si es que hay alguna) pruebas unitarias. Para cada informe de error, escriba una prueba unitaria que reproduzca el error, luego corríjalo. Esto ayudará a garantizar que no ocurran regresiones, mejorará la calidad del código y servirá como una plataforma para refactorizar el código si tiene la oportunidad (por ejemplo, podría ayudarlo a convencer a las partes interesadas de que reescribir algunas partes podría mejorar calidad sin introducir nuevos errores, debido al conjunto de pruebas unitarias).

3. Busque un nuevo trabajo: trabaja en muchos proyectos a la vez, ha escrito código desde cero y probablemente ha experimentado todo el ciclo de vida del proyecto; todas estas son buenas experiencias para aplicar en otro lugar.

Su situación es un poco nerviosa, pero aún así es normal. Pero la forma en que lo manejas es muy mala. Aquí está lo que tú necesitas hacer:

• Intenta confrontar a tu jefe. Debería tener alguna prueba (números) de cuánto tiempo cuesta realmente la base de código incorrecta. Si no entiende cosas como la deuda técnica, deja de mencionarlo. Te destrozaría la cabeza y podrías ser marcado como un tipo de "mala actitud". No es tu trabajo enseñarle a tu jefe a hacer su trabajo.

• Mantenga su propia cartera de pedidos (kanban). Cuando lleguen nuevas tareas, finalícela y diga el tiempo estimado de finalización.

• Aumente su tiempo de respuesta, revise su correo electrónico solo dos veces al día. Por lo general, antes del almuerzo y justo antes de partir. (La comprobación del correo electrónico no debe ir seguida de una codificación, ya que puede arruinarle la cabeza).

• Realice pequeñas mejoras de código como parte de cada tarea. Simplemente es su trabajo mejorar el código, las habilidades y las herramientas que está utilizando. También aumentará tu moral a largo plazo.

• Ningún cambio de proyecto durante el día. Hoy simplemente está trabajando en el proyecto X, y mañana comenzará otra tarea para Y.

• Asignar una hora por día para mantener la puerta. Significa pequeñas tareas que son triviales de hacer. Si esta tarea demora más de 10 minutos (sin importar cuál sea el motivo), entra en el trabajo atrasado y usted le notifica al gerente que se retrasará.

Ahora viene la parte difícil. Actualmente, los gerentes no se comunican entre sí, y solo asumen que terminarán su propio proyecto con la máxima prioridad. Esto trae mucho estrés en tu cabeza, porque estás en medio de discusiones. Debe obligar a los gerentes a comenzar a coordinar su trabajo. Al final, deberías tener una cartera de pedidos agradable y simple, y los gerentes deberían intimidarse mutuamente sin ti.

Así que hagamos un juego de roles simple. Hay tres gerentes y proyectos (Xavier con el proyecto X, Yvonne con el proyecto Y y Zed con el proyecto Z). Tiene un retraso de dos semanas, 5 días para X y 5 días para Y.

• Z te pide que hagas alguna tarea (1 día)
• Respondes que se hará en 11 días.
• Z responde que es una tarea simple y que no debería tomar más de un día (observe que Z aplica una pequeña presión).
• Respondes que estás trabajando actualmente para X y más tarde para Z. Puedes hacer su trabajo después de eso.
• Z responde que debes hacer su tarea inmediatamente de todos modos (aumento de la presión, violación directa del territorio X e Y).
• Respondes que hacer su tarea retrasaría el trabajo para X e Y. Él debería preguntarles primero. También CC X e Y.

Ahora hay dos extremos:

• Los gerentes comenzarán a ladrar unos a otros, muchos correos electrónicos, probablemente algunas reuniones ... Debes mantenerte alejado y dejar que el ganador te asigne una tarea.

• No pasará nada, Z te preguntará dos días después dónde está su tarea. Respondes que estás trabajando para X actualmente, y él no mencionó nada sobre el proyecto Z. Nuevamente CC X.

Ahora este tipo de comportamiento puede hacer que te despidan. Pero su situación es insostenible y, de todos modos, es probable que renuncie pronto. Esta solución solo funciona si los gerentes compiten entre sí (muy habitual). También debe mantener registros de su trabajo (trabajo atrasado), en caso de que alguien se queje, de que está aflojando.

Hace siete años, estaba haciendo un trabajo de mantenimiento al 100% durante un tiempo y escribí un artículo al respecto: The Art of Maintenance Programming . Una parte que puede encontrar útil:

1. Llegar a gustar

¿Cómo puede alguien gustarle la programación de mantenimiento? Los desarrolladores sueñan con ser arquitectos principales en sus equipos, y cuando terminan manteniendo el software existente, se siente casi como un castigo. No tiene que ser así: la programación de mantenimiento tiene su propio conjunto de desafíos y requiere mucha creatividad, adaptabilidad, paciencia, disciplina y buena comunicación. También puede ser bueno para su carrera: tener entradas rimbombantes como "Aplicación empresarial 24/7 de arquitectura n-tier" en su currículum se ve bien, pero los empleadores realmente valoran a las personas que resuelven problemas; y la programación de mantenimiento puede ser una buena oportunidad para demostrar sus habilidades para resolver problemas.

Su problema suena como algo de lo que escucha más a menudo. Parece ser un trabajo que podría encajar fácilmente en The Daily WTF .

Muchas organizaciones se centran más en las ventas o en la promoción de características que en la calidad. Lo que esas compañías no pueden ver es que hay más que cualidades externas de una pieza de software. Ward Cunningham acuñó el término deuda técnica .

Es posible que también desee leer a Steve McConnell sobre deuda técnica . Él tiene algunos puntos interesantes. En una charla técnica de Google, Ken Swaber habla sobre el desarrollo ágil de software . Una buena parte es sobre una historia similar a la tuya. Él habla sobre un proyecto de software que se ha convertido en "cerebro muerto" después de 10 años de programación por varios programadores sin tener que realizar ninguna refactorización . Creo que si ve este video, verá muchas similitudes con lo que describe.

Cualquier sistema de software se degradará en calidad cuando se expanda. De hecho, para poder sobrevivir, tendrá que hacerlo. Las Lehman Laws explican este principio bastante bien. En última instancia, se reducirá a la siguiente pregunta: "¿Cómo puedo convencer a su jefe para que realice la refactorización?" .

Cómo abordé un problema similar:

• Me enfrenté a mi jefe y le expliqué que la calidad del código se degrada cuando seguimos desarrollando ( Lehman Laws ).
• Traté de explicarle a mi jefe el concepto de deuda técnica . Y que la forma en que te deja trabajar es una forma que le costará dinero a la larga.
• Con el fin de mostrarle cuán grave era el problema, he hecho (en mi propio tiempo) un análisis de código estático. Los jefes no entienden el software, pero entienden los números. Aunque las métricas de código tienen sus defectos , es bueno tener algo medible de lo que puedas hablar. Intente averiguar cuáles son las lecturas normales para estas métricas, y se sorprenderá cuando compare esto con su propia base de código.
• Si nada ayuda y nada cambia, lo único que puede hacer es explicarle que cierta característica nueva requerirá algunas modificaciones de otras partes de su base de código. Explique que si tiene un código duplicado y ellos quieren cambiar algo, los costos de un cambio también se duplican.
• Una respuesta común al punto anterior será que nadie ha pedido y, por lo tanto, no ha pagado por esta reelaboración. Que "tal vez" este retrabajo es superfluo. Tendrá que explicar que el software siempre tendrá que cambiar. Como dicen las Lehman Laws ; tendrá que cambiar para permanecer en uso. Si no, otros programas que cambiaron siempre sobrevivirán. Son aquellos que esperan un cambio y pueden adaptarse al cambio los que sobrevivirán. De esto se trata el desarrollo ágil de software . ( Wikipedia )

Mi jefe hoy en día usa el concepto de deuda técnica para explicar a nuestros clientes que a veces necesitamos reelaborar partes del software que creamos. Solo para demostrarlo: si tienes un jefe razonable, es posible cambiar las cosas para mejor.

La situación que enfrenta es casi (si no totalmente) la misma para muchos estudiantes de primer año.

Esto sucede en las fases iniciales de una carrera. Aquí está el truco: tenemos que superar este problema y demostrar nuestro valor para la empresa (ya sea de tamaño mediano o MNC ). Deberíamos poder tomar decisiones sobre lo que las circunstancias nos exigen hacer. Por lo tanto, no hay nada de malo en poner esfuerzos en el trabajo, siempre que lo noten y se destaquen como individuos por su trabajo. Si vales, ¡la compañía lo notará! Adios y mucha suerte.

En mi opinión, no vale la pena trabajar para una empresa que prohíbe la refactorización. Refactoring es una habilidad esencial de desarrollo de software y herramientas de control de versiones hacen que sea muy fácil de desarrollar cambios de forma aislada, sin corromper el 'tronco' (en el caso de un refactor realidad hace romper algo). Como dice el tío Bob (parafraseado): "No debes pedir ser un profesional y hacer bien tu trabajo".

La programación de mantenimiento nunca debe significar perpetuar un código incorrecto.

Hace cinco años recibí este correo electrónico de uno de mis amigos.

Email body:    

Un ingeniero en formación recién incorporado le pregunta a su jefe "¿cuál es el significado de la evaluación?"

Jefe: "¿Conoces el significado de la resignación?"

Cursista: "Sí, lo hago"

Jefe: "Déjame hacerte entender lo que es una evaluación comparándola con resignación"

Comparison study: Appraisal and Resignation
|---------------------------------+----------------------------------| 
|       Appraisal                 |       Resignation                |
|---------------------------------+----------------------------------|
|     In appraisal meeting they   |    In resignation meeting they   | 
|     will speak only about your  |    will speak only about your    |
|     weakness, errors and        |    strengths, past achievements  |
|     failures.                   |    and success.                  | 
|---------------------------------+----------------------------------|
|     In appraisal you may need to|    In resignation you can easily |
|     cry and beg for even 2%     |    demand (or get even without   | 
|     hike.                       |    asking) more than 10-20% hike.|
|                                 |                                  |
|---------------------------------+----------------------------------| 
|     During appraisal, they will |    During resignation, they will |
|     deny promotion saying you   |    say you are the core member of|
|     didn't meet the expectation,|    team; you are the vision of   | 
|     you don't have leadership   |    the company how can you go,   |
|     qualities, and you had      |    you have to take the project  |
|     several drawbacks in our    |    in shoulder and lead your     | 
|     objective/goal.             |    juniors to success.           |
|---------------------------------+----------------------------------|
|     There is 90% chance for not |    There is 90% chance of getting|
|     getting any significant     |    immediate hike after you put  |
|     incentives after appraisal. |    the resignation.              |
|---------------------------------+----------------------------------|

Cursista: "Sí, jefe suficiente, ahora entendí mi futuro. ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Para ahora para una valoración tendré que renunciar ¡¡¡!!!

Si fuera usted, pasaría algunas horas después del trabajo reconstruyendo la aplicación de forma gratuita. Probablemente sea una tarea divertida. Cuando lo termines, muéstraselo a tu jefe. Si funciona y le estás haciendo mantenimiento, no debería tener nada de qué preocuparse. Esto facilitará su trabajo y abrirá los ojos de los superiores a su potencial en la empresa.

Soy un estudiante universitario a tiempo completo que trabaja en una pasantía de medio tiempo por US $ 10 por hora. Hago cosas de control de calidad que son aburridas, repetitivas y fáciles. Me considero extremadamente afortunado, porque sé que un día esto abrirá puertas a lugares más grandes y mejores.

Sí, siempre tendrá que mantener las aplicaciones, escritas tanto por usted como por otras personas. La única excepción es si escribe un programa que nunca necesita mantenimiento. Así que será mejor que te mantengas bien en el mantenimiento.

Creo que hay un indicio sutil en su pregunta de un defecto en su enfoque. Es decir, corregir errores no implica mejorar el código.

Pero luego escuché que no se me permitía mejorar el código existente y solo enfocarme en la corrección de errores cuando se informa un error.

No puedo creer que alguien te haya dicho "debes corregir los errores sin mejorar el código". Esto es a la vez difícil e imposible. Lo que no puede hacer es volver a escribir la aplicación solo porque no le gusta, o le resulta difícil de entender, el enfoque utilizado en la base de código existente.

Mi consejo es aprender a refactorizar. Cada vez que arregla un error, tiene la oportunidad de mejorar al menos parte del código. La cantidad de código base que se refactoriza depende de cuál sea el error y qué tan bueno o malo sea el código. Pero si está reparando errores y dejando a sabiendas olores de código por todas partes, entonces no está haciendo su trabajo y está acumulando deudas técnicas .

Algunos errores se corrigen simplemente refactorizando, y a veces es útil refactorizar para ayudarlo a comprender el código . Esto se debe a que la refactorización debería mejorar la mantenibilidad y la coherencia del código.

Cuando calculo una corrección de errores, generalmente tomaré una decisión sobre si un refactor principal será la mejor manera de hacerlo, y lo tendré en cuenta. Lo mismo con las pruebas unitarias. Ambas cosas deberían ser parte de la forma en que escribes el código, no algo opcional que implique tiempo extra.

Entonces, no debería preguntarse "¿puedo mejorar el código cuando soluciono el error?" Porque deberías estarlo de todos modos. No debería preguntarse "¿puedo usar la refactorización para corregir el error?" Porque si el código que está causando errores en la aplicación necesita urgentemente una refactorización, debe hacerlo de todos modos. No debería preguntarse "¿puedo escribir pruebas unitarias cuando soluciono este error?" Porque deberías escribir una prueba de regresión incluso antes de comenzar a intentar solucionar el error.

NB: Siento que algo de atribución para esta respuesta debería ir a Jeff Atwood, ya que vinculé 3 de sus artículos.

Este es todo sobre dinero. Supongo que, como titular, probablemente sea demasiado amable con los clientes que ya obtuvieron más de lo que pagaron.

Aprenda a cotizar un precio para nuevas solicitudes. Esto está lejos de ser fácil y los clientes a menudo lo probarán. Si puede, solicite la ayuda de un gerente de proyecto / producto experimentado.

Una vez que piensa en términos de dinero, la comunicación con la gerencia se vuelve mucho más fácil. Si sus clientes actuales proporcionan dinero a tiempo completo, no debe elegir nuevos proyectos. Pero comprenderá que la gerencia aún intentará intimidarlo para que los haga.

Si realmente eres valioso para la empresa, ganarás poder de negociación. Puede pedirles que contraten a más personas, obtener menos proyectos nuevos, ayudarlo a reducir la carga de mantenimiento o aumentar su salario.

No debería ser la decisión de su empleador microgestión en la medida en que se le prohíba mejorar el código existente. Usa tu propio juicio profesional. Cuando esté estimando el trabajo, tendría en cuenta el tiempo adicional para permitir cierta refactorización, si aumentará la productividad en el futuro.

De todos modos, parece que no se está comunicando efectivamente con su empleador.

1. Tiene evidencia de que la refactorización ahorrará dinero. Redacte una propuesta para un proyecto de refactorización y demuestre cuánto tiempo y dinero podría ahorrar la empresa. Describa con precisión qué cambios haría en el código y cuánto tiempo tomaría.

2. Mantenga un registro preciso para registrar la cantidad de tiempo que pasa codificando, reuniendo y respondiendo correos electrónicos. Esto lo protegerá si se atrasa.

3. Ve más despacio. Esto puede parecer un poco contrario a la intuición, pero solo se abusará de su tiempo si hace todo rápidamente. La gente respetará más tu tiempo si haces menos. Por ejemplo, solo revisaría el correo electrónico una o dos veces al día. De lo contrario, corre el riesgo de agotamiento.

4. Teniendo en cuenta su tasa de pago, no vale la pena tener dolor de cabeza. Asegúrese de salir a tiempo todos los días. No ponga horas extra sin compensación adicional. La excepción es si hay buenas opciones de avance, o si la reputación de la compañía aumentará enormemente su currículum, entonces solo tendrá que asimilarlo.

Sin saber más, solo sugeriría que intentes ser más abierto con tus gerentes. Tal vez comience a aumentar sus estimaciones de tareas. Recuérdeles constantemente qué tan ocupada está su carga de trabajo. Además, debe reunirse con su jefe y explicarle que desea un aumento salarial en los próximos seis meses, y preguntar cómo podría mejorar su desempeño para lograr este aumento salarial.

Buena suerte.

En mi experiencia, el mundo académico o los primeros 6-12 meses de una puesta en marcha orientada a la tecnología son las dos únicas áreas confiables donde encontrarás una verdadera pizarra en blanco. Ambos tienen sus propios costos, pero si te encanta codificar y a menudo te horroriza la calidad del código que descubres en la naturaleza, debes comenzar a orientar tu carrera en una de estas direcciones.

Intente hablar con sus empleadores y vea si puede resolver esto. Parece que estás muy loco en esto, y no tiene nada que ver con ser un mal programador.

Las empresas web más pequeñas tienden a tener muchos proyectos en marcha al mismo tiempo, lo que de muchas maneras te deja en un lugar difícil. Intenta sacar lo mejor de tu situación o trata de encontrar un nuevo trabajo si crees que puedes hacerlo. Prometo que hay mejores trabajos de codificación, así que no dejes que este primero te asuste.

¡Buena suerte, y espero que tanto usted como sus compañeros de trabajo entiendan la gravedad o sus esfuerzos!

Experiencia personal

Como muchos aquí, también reconozco tu situación. Básicamente obtuve mi primer trabajo de codificación con un salario bajo y tuve que mantener mucho código integrado con una estructura pobre. Al principio me pareció divertido aprender cosas nuevas, pero cuando al final tuve muchos proyectos que mantener, nuevos proyectos que hacer y una pizarra blanca que crecía más y más cada día con puntos con los que no había terminado me di cuenta de que No estaba funcionando.

Después de soportarlo durante dos años, renuncié y encontré otro trabajo de codificación un par de meses después que me queda perfectamente.

De todos modos, muchas veces no son solo sus proyectos los que podrían ser el problema. Me siento más cómodo en el lugar de trabajo cuando me reconocen y me respetan por mi trabajo. El problema con la situación en la que se encuentra es que sus empleadores solo pueden notar los errores que surgen de los proyectos creados, y no el tiempo que toma para eliminar todos los otros errores.

Salario

Si quieres más dinero, a menudo puedes conseguirlo. Logré negociar mi salario en menos de dos años con un aumento del 33%.

Básicamente, piense en el valor de su trabajo y cuánto lo necesita la empresa. Si no pueden darse el lujo de darte el salario que has ganado, entonces la compañía necesita revisar sus gastos o darse cuenta de que su negocio no está funcionando.

Y como mencionan muchos aquí, y estoy de acuerdo, eres una pieza muy valiosa del rompecabezas de la compañía. Demonios, probablemente eres el único que puede resolver ese rompecabezas. :)

Como todavía no puedo comentar porque soy un acechador en este sitio de Stack Exchange, solo agregaré la información aquí.

1. Como recién está comenzando, su salario no será estelar a menos que haya ido a trabajar para una gran empresa como Microsoft, Amazon o algo similar. ¡Pero no debería ser la de un empleado de supermercado! No aguantes eso por mucho tiempo, gana experiencia haciendo lo que estás haciendo y sigue adelante cuando surja una mejor oportunidad.

2. Para un concierto de nivel de entrada esto es algo normal. Su carga de trabajo es demasiado alta, pero se espera el tipo de trabajo. Para convertirse en un mejor desarrollador, debe aprender de los errores de los demás. Cuanto más ves, mejor te vuelves. Pero eso implica que está buscando cosas para aprender, no aprender malos hábitos ...

3. La relación entre el mantenimiento y el trabajo del proyecto debería cambiar con el tiempo. Si no es así, eso significa que la empresa para la que trabaja no se da cuenta de cómo mantener un buen desarrollador; pretenden que hagas lo mismo día tras día. Establezca una meta anual para usted en cuanto a dónde le gustaría estar, salario y expectativas laborales sabias, y muévase en consecuencia.

4) Si no eres feliz, ¡vete! La vida es demasiado corta para tratar con personas estúpidas.

Todo lo mejor.

Comienza a utilizar un rastreador de problemas para realizar un seguimiento de su lista de tareas pendientes.

Esto no solo lo ayudará a realizar un seguimiento de lo que es crítico, sino que ayudará a los usuarios y a su jefe a ver cuál es su carga de trabajo actual.

Además, si alguna vez contratan a un segundo desarrollador (o si renuncia y su reemplazo ahora ocupa su carga de trabajo), esto ayudará a administrar la carga de trabajo y podrá evitar pisar los pies de los demás.

La única forma de romper esta cadena es desarrollar nuevas infraestructuras que estén diseñadas para la flexibilidad y se prueben la unidad completa + la integración.

Si logra vender esto a la administración (inscriba a otros desarrolladores y gerentes en el concepto en reuniones 1: 1), entonces puede llegar lentamente a un estado, donde la mayoría del código de las aplicaciones está en la infraestructura y es fácil expandir y mantener, mientras que las aplicaciones reales son ligeras y se pueden escribir con bastante rapidez.

El desarrollo de la infraestructura puede permitir al principio reemplazar partes de aplicaciones existentes y después de un tiempo (puede tomar algunos años) reemplazar aplicaciones completas.

A la larga, puede reducir drásticamente el tiempo de desarrollo de nuevas aplicaciones y el tiempo de mantenimiento de futuras aplicaciones existentes.

El nuevo desarrollo requerirá al menos un 80% de dedicación (preferiblemente más) con un equipo de más de un desarrollador (algunas mentes son mejores que una). Todos los desarrolladores deberán poder pensar creativamente y romper preconceptos existentes.

Intente definir y diseñar de alto nivel una infraestructura tan nueva, luego presente la definición a sus pares y a la administración.

A partir de sus condiciones de trabajo, solicite liderar un nuevo equipo de infraestructura que se ocupe de estos problemas (en función de sus definiciones y diseño) y traiga nuevos desarrolladores para mantener las cosas viejas mientras los ayuda si es necesario (hasta 10-20% de el tiempo). Si la gerencia está de acuerdo con la idea, puede solicitar renegociar sus términos. Prepárese para encontrar otro trabajo si se niegan. (Recuerde, su trabajo requiere habilidades, conocimiento y experiencia, no es tan fácil reemplazarlo como le están pagando por creer).

¿Conoce su gerente todas estas solicitudes de cambio (solicitudes de mantenimiento)? ¿Se da cuenta de que su tiempo está ocupado analizando solicitudes que no tiene autoridad para sancionar? ¿O simplemente hace cambios cada vez que un gerente le pregunta?

Me parece que su primer puerto de escala es ponerlo todo en el escritorio de su gerente. Nadie debería venir a ti directamente. Los problemas deben surgir a través de quien sea que los envíe, generalmente un equipo de soporte. Es normal que admita su código durante un breve período de transferencia, generalmente una semana más o menos. Los cambios deben ser valorados y cobrados (cargo de transferencia) en cualquier compañía que se clasifique a sí misma como "tamaño mediano", y parece que esto se está pasando por alto (no es de extrañar que te estén inundando, eres como la puta en el baile de graduación).

Debe haber un procedimiento de solicitud adecuado tanto para plantear problemas como para solicitudes de cambio. El soporte / mantenimiento se trata de corregir errores y problemas (que se ajustan a la especificación original, pero fallan debido a un error en el código o un evento externo, como un apagado o un sistema ascendente corrupto, etc.).

Si su empresa no ofrece nada de esto y espera que usted haga frente y sea responsable de esta miríada de solicitudes aleatorias, entonces debe considerar seriamente seguir adelante. La paga siempre es pobre en el fondo: en mi primer trabajo de programación (hace casi 25 años), pasé 8 años para la misma compañía y mi paga subió poco (¡aunque siempre fue mucho más alta que un cajero!). A los 2 años de haberme ido, lo había duplicado, y dos años después me llevaba a casa más de diez veces lo que comencé (pero entonces era un contratista independiente). Como siempre, gane espuelas, aprenda su oficio y salte a un entorno más cálido.

Quizás esté en condiciones de ir a un gerente y decirle: "Mire, seré franco con usted. Mi paga es terrible, podría obtener N veces esto como programador de nivel de entrada en X.

Estoy haciendo demasiadas cosas con A, B y C. No puedo mantener esto. Honestamente, y sin ofender, voy a salir de esta habitación con esto ya sea arreglado, o con mi carta de renuncia dejada contigo. Ahora que todo esto está en el aire, ¿cómo podemos trabajar juntos para hacer esto bien? "

La respuesta es tratar de explicarlo en términos que se puedan entender;

• Es como los cambios de aceite. No son urgentes ... pero deben hacerse regularmente, no obstante
• pintar sobre óxido y se verá genial. Hasta que sangra
• construya un nuevo escritorio en el techo del techo sin soportes fuertes. Funcionará por un tiempo tal vez. Entonces colapsará y lastimará a las personas y usted será responsable.
• El aire acondicionado es genial. Una unidad de ventana es ideal para una o dos habitaciones. Intentando poner 146 aires acondicionados de ventana en un edificio de apartamentos y tendrás ... problemas.
• Enseñar a 5 niños está bien. 10 no está tan mal. Pero hay límites. Intente enseñar informalmente a 75 niños y verá esto.

Si estos no resuenan. Salir: ¡EL DÍA QUE OFRECES UNA OFERTA DE ESCRITURA, no al día siguiente! Una vez que tenga un nuevo trabajo, salga con CERO aviso. Literalmente, simplemente no vengas ese día. Pero asegúrese de tener un colega o dos que sepan lo que hizo. Esto realmente ayudará a la empresa, si la empresa puede ser ayudada, mostrándoles que su falta de respeto y arrogancia tiene un precio. Última compañía en la que estuve TRES DE LAS CUATRO TECNICAS SE DEJÓ DENTRO DE 6 MESES SIN TRABAJO A QUE IR. Al menos hizo una declaración y le dio a la persona que dejaba una buena oportunidad de decir: 'sí, qué bueno que dices todos los días, pero estás tan lleno de eso que ni siquiera te estoy dando la satisfacción de mi aviso.

Finalmente, sepa que esta situación era la norma y la norma hace 20 años antes de que agile, tdd, bdd y refactoring se convirtieran en algo más que la norma. Puede estar hablando con personas de la tercera edad que responden de inmediato "bueno, lo he hecho yo mismo y funcionó bien, bla, bla, bla". Bueno, algunos caballos y carruajes funcionaron bien hace 150 años. En las áreas tecnológicas, las técnicas de hace 20 años están tan desactualizadas como el transporte de hace 150 años. Si rechazan esta multa. Solo sepa que nunca contratarán a ningún desarrollador de tecnología actual decente que se quede. Obtendrán lo peor de lo peor y dañará terriblemente su negocio. Si dependen de la tecnología y no pueden adaptarse, fracasarán y, en última instancia, esa puede ser la mejor recompensa para usted. Eso'

Parece que su gestión fundamentalmente no lo respeta ni comprende su carga de trabajo.

No debe implementar todas las solicitudes de características que se reciban. Su gerente debe actuar como un búfer entre usted y las solicitudes entrantes (excepto quizás la más simple de las solicitudes de interrupción / reparación). Luego, él o ella deben sentarse con usted y determinar la viabilidad y prioridad de cualquier solicitud aprobada.

Además, debería estar haciendo probablemente 2 veces (al menos) lo que le están pagando.

Parece que probablemente realmente necesiten al menos 1 desarrollador más para trabajar junto a usted, pero con lo que le están pagando eso parece bastante improbable.

Si no están dispuestos a pagarle adecuadamente o ayudarlo a administrar su carga de trabajo, estaría buscando un nuevo trabajo. Desea trabajar en algún lugar donde forme parte de un equipo y donde su gerencia trabaje con usted para completar sus proyectos. Baja de ese barco que se hunde tan pronto como puedas.

Ser un héroe en un equipo de uno solo te va a quemar.

Solo soy un estudiante (todavía), pero eso es bastante normal (desde mi experiencia de pasantía). Eso es lo que obtienes cuando trabajas en soporte y aplicaciones web.

Le aconsejaría que comprenda lo que quiere el cliente (gerente) antes de comenzar a codificar. Eso podría ser complicado porque a veces no lo saben, así que trabaje con ellos hasta que se pongan de acuerdo en algo. Asegúrese de que ambos estén de acuerdo con la solución final antes de codificarla.

Además, si eres un mantenedor, puedes cambiar prácticamente cualquier cosa en el código, solo asegúrate de que no cambie el comportamiento o introduzca errores. Espero que los gerentes no 'permitan' que cambie nada porque están acostumbrados y contentos con lo que es ahora y no quieren pagar por ningún cambio nuevo.

Finalmente, no se preocupe si no puede manejar algo porque está haciendo otra cosa. Te aconsejo que le hagas saber a la gente que estás abrumado por el trabajo y su solicitud llevará tiempo. Si no lo haces, los gerentes pensarían que eres flojo. Hágales saber que ya tiene trabajo y que podrían contratar a más personas. No hay otra manera de que sepan que el trabajo es demasiado para una sola persona.

Este es un problema de gestión de proyectos. Utilice algún tipo de gestión de proyectos para decidir en qué es prioritario trabajar.

a) Necesita una acumulación de artículos para trabajar. Pones tu plan para mejorar el código en la cartera de pedidos.

b) Todos los errores entran en la cartera

c) El trabajo atrasado se prioriza.

d) Lo haces todo en orden de prioridad.

Los errores pueden ser una prioridad más alta, pero si una vez que arreglas todo eso, tienes ciclos para gastar en nuevas características o en la refactorización del diseño.

Es más fácil si solo refactoriza las mejoras de forma incremental, a medida que pasa por secciones que tienen problemas / errores que corregir. Luego puede decirle a la gerencia: "Tuve que arreglar A, pero B estaba fundamentalmente roto y tuve que hacer la solución C para arreglarlo todo de modo que D fuera más fácil / más barato en el futuro" Donde A = El error, B = El antipatrón, C = Solución, D = Ganancias futuras

Si no puede justificar el trabajo como una inversión que vale la pena, los empresarios nunca lo aceptarán.

Esto es lo de siempre. Serás explotado mientras sigas trabajando allí, parece. Es en el mejor interés de la compañía continuar con este modelo en lugar de hacerte sentir feliz con lo que estás haciendo. Cuando se trata de eso, realmente no les importa. Se trata de crear un código confiable para ellos y si eres una banda de un solo hombre, sin duda te están haciendo un banco. ¿Por qué iban a cambiar?

La buena noticia en todo esto es que eres un VIP para ellos, incluso si no lo saben. Lo que sugiero hacer es alinear algunas oportunidades más antes de saltar del barco y luego tomarlas por las bolas y exigir un salario más alto. Si no, pasar a una mejor oportunidad. En mi opinión, pronto deberías encontrar un trabajo más emocionante. Apunta tan alto como puedas. Una vez que llegue a una tienda de desarrolladores, será mucho más feliz como Google o alguna startup divertida en la que haya una cultura de desarrollo colaborativa en la que realmente se sienta feliz.

Lo que hice personalmente fue utilizar una organización contratista de cazadores de cabezas y rápidamente obtuve muchas experiencias excelentes en mi haber, moviéndome de una a otra mientras mantenía un empleo estable de mi contratista. Evita que te aburras y te desafía. Eventualmente, en mi tiempo libre construí una pequeña empresa que se convirtió en un negocio real, y luego salté del trabajo por contrato.