¿Qué es lo más frustrante de ser un programador de computadoras?

Answer 1

Creo que una de las partes más frustrantes de ser un programador de computadoras son los pequeños errores que ocurren una y otra vez. En ese momento no se sentía tan importante y era solo un pequeño error que se solucionó fácilmente, pero luego hubo otro y otro y simplemente continúa. Al final del día, estás realmente molesto porque todos estos pequeños errores se acumularon y te volvieron loco.

Otro problema que creo que puede ser muy frustrante es la API de terceros. A veces confías mucho en ellos y luego notas un problema o necesitas una nueva función, pero esa API en particular no te proporciona ninguna fuente para solucionar el problema, por lo que debes preguntarle al autor de la API y esperar. por lo mejor.

El desarrollo multiplataforma puede ser algo muy frustrante porque requiere que usted aprenda X (dependiendo de cuántas plataformas admita) diferentes formas de hacer exactamente lo mismo la mayoría del tiempo. Eso puede ser muy frustrante. Además de eso, la compilación cruzada también puede darte dolores de cabeza molestos.

Usar el programa equivocado para administrar su enorme pila de código, como subversión, etc. Puede ser muy frustrante cuando elige el programa incorrecto para su solución y observa que a mitad del desarrollo este programa causa más problemas que la documentación faltante.

Desarrolle su solución alrededor de una versión de una API de terceros solo para ver que se lanzó una actualización impresionante que no es compatible con versiones anteriores, por lo que tiene que volver a escribir la mitad de la solución solo porque le gusta la API limpia o incluso el rendimiento aumentar.

Las opciones de diseño falsas que significaron buenas, pero son absolutamente problemáticas durante el desarrollo y porque se gastó demasiado tiempo en realizar estos diseños, ya no se pueden revertir.

No tener un servidor de compilación y olvidarse de compilar su proyecto en todos los perfiles, terminando con errores que son muy difíciles de rastrear porque ha habido una docena de cambios antes de que se compilara algo para ver si funciona.

Documentación falsa: esto se aplica especialmente si el programador que creó la solución no la documentó y otro programador tuvo que hacer una documentación para la solución.

Los programadores confían casi infinitamente en goto, usándolo en todos los lugares posibles y haciendo así imposible el seguimiento del código.

Hinchar un solo archivo con cantidades de código insanas, especialmente clases, lo que hace que no sea humanamente posible hacer un seguimiento de lo que se supone que la clase debe hacer en absoluto.

Lenguajes de programación a los que ni siquiera les importa la sintaxis. Esto se aplica especialmente a PHP para mí, puede ser muy frustrante leer el código de las personas cuando la sintaxis es simplemente imposible para usted.

Su jefe tiene expectativas muy altas de usted y de sus colegas, pero no tiene suficiente tiempo / recursos para siquiera acercarse a estas expectativas.

Su patrocinador acelera su desarrollo y le impide completar el software inicial de la manera que desea.

Estas son algunas de las cosas frustrantes de las que salgo cuando soy programador. Supongo que realmente depende de lo que la gente considere frustrante.

Answer 2

Hay muchas cosas que me molestan como programador y sospecho que también molesta a los demás:

1. Cambiar un requisito a mitad de su desarrollo, lo que requiere cambiar casi todo el algoritmo responsable de crear esa función.

2. Un desprecio completo del final del cliente para comprender el back-end de un sistema. El famoso “no puedo verlo, rebotar y bailar en el sitio web o una aplicación que no funciona”. En serio, chicos. Hacer que las cosas reboten y bailen es la parte más fácil del trabajo.

3. git conflictos. No puedo enfatizar esto lo suficiente pero son un gran dolor.

4. Cuando un cliente hace hincapié en un truco de una solución en lugar de uno real porque les ahorra una hora. A pesar de que nos avergonzamos de emplear el parche de un truco, tenemos que hacerlo porque el cliente es el jefe, ¿verdad?

5. El antiguo dejemos de agregar más desarrolladores en el proyecto para hacerlo más rápido. Lea la ley de Brooks [Wikipedia]. Clientes / PM: nueve mujeres no pueden tener un bebé en un mes.

6. Hacer cumplir “esto parece fácil, ¿por qué lleva tanto tiempo” sin tener una idea de lo que se necesita para desarrollar una característica de la manera correcta? la hermosa manera

7. Reuniones. No puedo enfatizar este punto lo suficiente: las reuniones son asesinos de productividad. Esto se aplica no solo a los desarrolladores, sino también a las personas que pertenecen a otra profesión. Hay una gran charla en TED sobre este tema, véala ( https://www.ted.com/talks/jason_ …)

Answer 3

Al ser un programador informático, la gente espera que usted sea un “hombre milagroso”, se espera que cree esta IU de aspecto maravilloso, la conecte con los componentes de lógica de negocios, la aloje en un marco de trabajo, interactúe con la base de datos y finalmente la implemente. Y si eso no es suficiente, también debe seguir revisando su código en busca de estándares de calidad y revisarlo también.

La peor parte de las expectativas es que debe entregar su producto en cualquier momento. Dígale a su jefe que este es un problema para cumplir con los requisitos del cliente, y la respuesta es rápida: “Pero usted es un programador, debería poder hacerlo correctamente”. Parte del problema se debe al hecho de que la mayoría de las veces, durante las conversaciones con los clientes, los programadores rara vez participan en ellos. Entonces, 8 de cada 10 veces, el programador aprende lo que quiere el cliente a través del Analista de Negocios o Programador, y generalmente no traducen lo que quiere exactamente el cliente.

El gráfico de Usuario de Quora resume exactamente lo que sucede con la mayoría de los proyectos. Los programadores y los clientes deberían estar durmiendo juntos, pero en la mayoría de los casos ni siquiera están a una distancia de contacto y, en algunos casos, ni siquiera se conocen entre sí.

Por supuesto, la peor parte es tener que revisar otro código, resolverlo, depurarlo, modificarlo. Y es aún peor, si la persona antes de que usted abandonó la compañía, y realmente nunca tuvo ninguna transferencia de conocimiento de la misma. Todavía recuerdo, en los primeros años de mi carrera, donde estaba trabajando en un módulo particularmente complejo, tuve que llenar para un colega mío, que estaba de permiso. Él hizo la transferencia de conocimientos por mí, pero incluso entonces tuve un tiempo tórrido, resolviendo una pieza de código particularmente compleja.

Trabajar contra plazos ajustados es otro dolor, y nuevamente por la misma razón, a los programadores nunca se les permite expresar su opinión. Los gerentes de proyecto o los analistas de negocios prometen la luna al cliente, y los programadores tienen que hacerlo, pase lo que pase. Imagínese esto, si hubiera dado un requisito para un automóvil “que volaría, viajaría bajo el agua, dispararía misiles”, y luego el gerente le pide a su equipo que construya dicho automóvil en solo 1 mes. Estoy seguro de que se echaría a reír, de hecho, su idea sería rechazada de primera mano. Pero como programadores, no solo se supone que debemos construir un automóvil que “vuela, viaja bajo el agua, dispara misiles” en menos de un mes, sino que incluso garantiza que no tenga defectos.

Todavía me encanta escribir código, y no creo que deje de hacerlo durante bastante tiempo. En cuanto a los problemas que planteé, no deberían existir idealmente hablando, pero tampoco vivimos en un mundo ideal.

Answer 4

Cuando su parte del código deja de funcionar porque alguien más cambió su parte del código. A menudo sus funciones toman más argumentos que antes. A veces se eliminan por completo o se colocan en un archivo diferente.

También me disgustan las combinaciones porque es como si quisieras cambiar el código de esta manera, quiero cambiar el código de esa manera, entonces, ¿cómo deberíamos cambiar el código? Siempre he sido capaz de encontrar una manera de incorporar nuestros dos cambios, pero si hubiera un conflicto real, sería un proceso incómodo.

Answer 5

En el trabajo:

1. Interrupción del flujo (psicología);
2. Oficinas abiertas con todo el ruido;
3. Requisitos / especificaciones / tareas poco claros;
4. Cambio de requisitos / especificaciones a mitad de camino;
5. Horrible API o librerías sin la documentación adecuada. En absoluto;
6. Herramientas lentas y computadoras lentas para el desarrollo. ¡Eso mata cualquier flujo!
7. Mantener códigos de pesadilla donde el autor hace mucho que no está en el proyecto;
8. La gerencia viene con promesas locas durante la reunión con el cliente.

Expectativas y estereotipos sobre los programadores:

1. Medición de la productividad con la cantidad de código producida;
2. Medir el talento con la cantidad de proyectos paralelos que hacen los programadores (también conocido como la codificación sin vida, de lo contrario no somos programadores reales);
3. Medir la dedicación por la disposición que tenemos de trabajar horas extras gratis: si la administración hace un trabajo decente, no debería haber plazos locos y tanta carga para los programadores;
4. Suponiendo que los programadores son personas aburridas sin vida y son solo una máquina que convierte la pizza y el café en código.

Answer 6

Para enumerar algunos:

1. La gente viene y los molesta para decirles hola cuando están fluyendo.
2. Los gerentes de productos les piden que agreguen una opción más que será utilizada exclusivamente por estos 2 o 3 clientes, lo que causa la “muerte por preferencias” en el producto.
3. Límites del equipo que no les permiten depurar o mejorar libremente un producto
4. conflictos svn tree merge
5. jenkins más lento construye

Answer 7

Estar encerrado en un espacio de cabeza de codificación cuando el resto del mundo no lo está.

Las reuniones innecesariamente largas y sin sentido pasan de ser aburridas al infierno. Estaré en una llamada y el tío paseará por 35 malditos minutos sobre cosas al azar sin tomar un segundo para respirar. Finalmente, tan lejos, lo interrumpiré y le haré dos preguntas. Luego se va a joder por otros 10 minutos y, finalmente, básicamente dice “No sé”. Toda la cosa podría haber terminado en 5 minutos, pero solo perdió 40 minutos extra yendo completamente al azar.

Si estuviera en un espacio de cabeza social normal, no me hubiera importado. Habría jugado algún juego en mi teléfono o revisado los correos electrónicos mientras escuchaba la llamada, y habría esperado a que finalmente llegara a su punto. Pero en un espacio de código, me enojo mucho por la redundancia y el desperdicio, y solo quiero profundizar y salir sin charlas ni trámites.

Las personas que intentan venir a charlar también se convierten en un infierno. Por ejemplo, durante los primeros 2-5 minutos soy un imbécil y casi no puedo recordar cómo hablar en voz baja. Es como si mi memoria estuviera totalmente llena de un programa cargado y tuviera que volcarlo. Luego cargué la mentalidad de conversación y puedo chatear. Pero luego, cuando se van después de su charla a menudo sin sentido, me lleva otros 15 minutos recargar el espacio de cabeza de codificación. Apesta

Especialmente porque la gente no se da cuenta, y se ofenderá si usted se muestra cortante o simplemente se ha desvanecido. No es que te odie, es solo que ahora estás destruyendo mi maldito cerebro.

Por otro lado, sin embargo, estar en un espacio de cabeza de codificación puede ser algo genial a veces. Solo veo el mundo de manera diferente.

Me detendré en un semáforo y veré autos alineados en tres carriles a una cantidad diferente de pies de la línea y simplemente dibujaré algunas similitudes abstractas entre el algoritmo requerido para determinar un año en el que la mayoría de un grupo de científicos estaba vivo en y el camino que tendría que tomar una bala para golpear a la mayoría de los autos y / o matar a la mayoría de las personas. En realidad, existe una similitud sistémica bastante interesante, ya que las dos tienen longitudes diferentes y superpuestas, y ambas requieren una sola línea para atravesar … bla bla bla.

O veré un estacionamiento casi vacío e inmediatamente comenzaré a imaginar un mapa de calor que muestre los espacios de estacionamiento más utilizados. Probablemente se rellenarán con espacios, porque la gente probablemente se salteará un lugar si es posible, luego rellenarían los extras. Esto me recuerda a los cubos en las tablas hash. En general los delanteros se llenarán más rápido. Probablemente podría encontrar una función para el mapa de calor dado un vector desde la entrada que se extiende hasta el punto más cercano de la carretera. Puede que no sea perpendicular al pavimento, podría estar en un ángulo no ortogonal, lo que haría una función interesante para determinar los colores.

Los colores cambiarían con el tiempo, por lo que sería un mapa de 4 dimensiones. Podría visualizarlo como colores cambiantes, o como una gama montañosa de valores que sube y baja en diferentes áreas a lo largo del tiempo. bla, bla, bla.

Es una especie de mentalidad compulsiva que no puedo deshacerme de las primeras 1 o 2 horas después de salir del trabajo.

De todos modos, me dejé llevar … TL; DR: el espacio de cabeza de codificación es una bendición y una maldición fuera de la codificación.

Answer 8

Compatibilidad hacia atrás, pensamiento a corto plazo y el culto de “peor es mejor”.

Quiero hacer las cosas bien , pero en cambio hay mucha presión para hacer las cosas de manera rápida y familiar . A veces está justificado, pero parece que la cultura actual de programación / negocios se ha movido demasiado en esa dirección.

Tiene sentido, supongo, psicológicamente. La gente parece mucho más preocupada por los grandes costos iniciales que los pequeños persistentes. Un pequeño lastre en la productividad puede tener un impacto absoluto mucho mayor que un costo importante por adelantado, pero no se siente tan mal. En todo caso, hace que las personas se sientan ocupadas y productivas.

Y así, en lugar de resolver problemas interesantes o fundamentales, termino de pasar meses hackeando algo feo juntos sobre protocolos de espantamiento absolutamente horribles como IMAP, que fueron diseñados, pobremente, para abordar las inquietudes específicas de los ingenieros particulares que formaban el equipo relevante. Comité hace casi 30 años. ¿Ya son relevantes esas concesiones? Jajaja. Decir ah.

Luego, en lugar de arreglar esto (porque hacer que la gente adopte cosas nuevas es difícil), las empresas simplemente dejaron de apoyar partes y agregaron sus propias capas. Ahora tenemos un protocolo con el mismo diseño pobre y obsoleto en su núcleo, pero que carece incluso de la menor gracia de estar estandarizado de manera significativa.

No es que alguna vez se haya estandarizado de manera significativa: ¡los RFC reales están muy lejos del tipo de formalismo claro e inequívoco que me gustaría! Están escritas en un lenguaje natural ambiguo similar a los legales, con toda la claridad que eso implica. Y lo que es más importante, formalizar el estándar por completo los habría obligado a simplificarlo radicalmente en lugar de repasar cada idea y característica arbitraria que pudieran inventar.

¿La lógica que estaba implementando? Podría ser descrito en una pantalla llena de pseudocódigo. Lo que hinchó a páginas y páginas y páginas de código real, tratando con todo este crucero. Se reúnen en su mayoría con esperanza.

Me alegra no saber nada de ingeniería civil porque, de lo contrario, temería caminar por las calles.

Por supuesto, también simpatizo totalmente con las personas que hacen esto. Yo mismo hago los mismos tipos de diseños. Solo hay mucha presión para eso, y es más fácil hackear algo juntos que poner un pensamiento o diseño real en él. Pero el hecho de que lo haga yo mismo, a pesar de estar profundamente preocupado por la tendencia, solo lo empeora.

Más o menos la única cosa con la que no simpatizo es con la idea de que esto es algo bueno o una buena ingeniería.

Aún así, es divertido despotricar sobre eso.

Answer 9

Al aire libre
Lo más molesto de ser un programador es trabajar con personas no técnicas (gerentes) que no saben nada sobre lo doloroso que puede ser el proceso, pero suponen que es un proceso muy simple.

Te encuentras a ti mismo trabajando como un único desarrollador en una startup que quiere construir ” el próximo facebook “. Primero pretenden, todo lo que necesitan son características básicas.

Quieren que se complete en un mes y que se lancen la próxima semana. Está tomando pedidos de todos los cofundadores, en secuencia aleatoria. No hay absolutamente nada en el papel, como plan de trabajo.

Dos semanas después del proyecto, quieren la mayoría de las funciones actuales en Facebook. Pocos días después, uno de ellos ya había tomado prestadas algunas funciones de Twitter que desea incluir sin ningún tipo de discusión previa con sus socios.

Luego de tres semanas de iniciado el proyecto, se dan cuenta de que algunas características de Facebook ya no son necesarias para el proyecto; se le solicita que lo descarte. La compañía ya está dando a conocer al mundo que lanzan dentro de una semana. Usted ingenuamente trabaja día a día, no ha completado el 40% de su requisito “no bien definido”. Para la cuarta semana, todos los cuerpos están en su cuello, martillando en el lanzamiento.

Intenta explicar por qué no será posible lanzar, considerando:

• características incompletas
• loco
• preocupación de seguridad
• Costo de desarrollo continuo en una plataforma en vivo.

Entonces, todos los cuerpos te miran como un fracaso, una alegría mortal. Luego sigues ingenuamente sus comentarios e instrucciones, y lanzas el siguiente facebook .

—El problema acaba de empezar—

Answer 10

Con los auriculares enchufados y estando en la zona, tecleando el código más rápido que los Dioses del teclado, entonces … Alguien viene y te toca en el hombro para decir / preguntar algo y de repente has salido de tu programación de Nirvana.

Una vez que quien haya hecho el acto impío se vaya, tomará otros 30 a 60 minutos para volver a ese estado productivo.

Eso muele mis engranajes.

Answer 11

Constantemente te sientes inadecuado , sin educación y / o poco inteligente .

Hay tantas cosas que muchas otras personas saben o hacen, de las que tienes poca o ninguna idea, y que a veces no puedes evitar sentirte como un completo tonto.

Sientes que estás aprendiendo y creciendo todo el tiempo y, sin embargo, sientes que siempre estás atrasado.

No sé de los demás; este es probablemente el caso en todas las profesiones humanas y probablemente depende más de tu personalidad que de cualquier otra cosa, pero eso es lo que encuentro, el ganador absoluto, número uno, en la lista de Cosas que me frustran como programador.

Si te sientes así, no estás solo. Al parecer, algunos El 90% de los estudiantes del MIT sienten que están en la mitad inferior de su clase.

Answer 12

• La gente espera que seas Neo de la película The Matrix. Cuando te vean con tu computadora portátil trabajando en el editor de texto Sublime o algo similar a la imagen que se muestra, te verán como si estuvieras decodificando el Enigma allí mismo.

• Desde el control remoto de la TV hasta el Nokia 1600, puedes reparar todo. Casi todo, hasta que les expliques que no debes hacerlo. Pero no te atrevas a hacer eso. Es como perder todo el grado en la universidad.
• Cuando estás en una multinacional y tu colega de una oficina internacional te pregunta sobre en qué idioma te sientes cómodo. Dirás accidentalmente a C ++ solo para que luego te arrepientas de lo idiota que has sido. Sí, eres fluido en inglés también.
• La gente te sigue preguntando que tan geniales son tus oficinas. Las describe en detalle sobre la mesa de Snooker y la sala de descanso y las cafeterías temáticas y se da cuenta internamente de que la carga de trabajo de los proyectos nunca le ha permitido pasar tiempo de calidad en esas áreas.
• Asesoramiento gratuito. Sí, obtendrías eso en abundancia. Los amigos de otras sucursales te darían una docena de ideas por semana, ya que una de ellas podría hacer maravillas una vez que dejes tu trabajo y trabajes como CTO para la startup. Incluso podrían convencerte de que podrías ser el próximo Zukerberg o Steve Jobs. Tuyo ‘podría ser el próximo Uber o el próximo Netflix.

¡Ser programador no es fácil!

Answer 13

Cuando comencé mi carrera en la década de 1990, había 3 aspectos bastante frustrantes, y he llegado a enfrentarlos en mayor o menor medida:

1. Trabajando por el bote de basura.
2. Comunicación entre desarrolladores y empresarios.
3. Discusiones entre desarrolladores sobre detalles estéticos o funcionales.

1.
Muy pronto, descubrí que gran parte del trabajo que realizo, sin importar cuán sofisticado, bien hecho, orientado hacia el futuro, mantenible, quedaría fuera de uso bastante rápido, solo por las decisiones políticas del lado del cliente, las nuevas tecnologías. , las nuevas estructuras de la empresa, los procesos se están volviendo obsoletos, etc. Y también fue frustrante ver, en contraste, el pequeño código de código que hice desde 1992 que aún funciona hoy en día.
Hoy, he llegado a una calma zen cuando hago un proyecto, sabiendo que nada está hecho para durar, que abarca un cambio constante en cada aspecto de un sistema, que se enfoca menos en hacer que las cosas estén “preparadas para el futuro”, que se centre menos en lo genérico. Soluciones extensibles, pero haciéndolas de manera que los programadores puedan mantenerlas y ampliarlas en el nivel de origen. Hoy en día, evito deliberadamente soluciones excesivamente “geniales” o “elegantes” o “genéricas”, no hago grandes marcos que estén diseñados para durar los requisitos de las próximas dos décadas, pero trato de hacer que la fuente sea tan simple y comprensible como sea posible.

2.
Realmente, esto es sobre personas. Se trata de la empatía, de poder escuchar antes de juzgar, de poder sentir lo que necesita su cliente, incluso si no pueden expresarlo por sí mismos. Me frustré muchas veces, acudir al departamento de TI de la empresa cliente por primera vez, y no me encontré con ninguna pista sobre lo que realmente debería hacer el “nuevo sistema”, pero aprendiendo que la gente está absolutamente comprometida con que el sistema debe ejecutarse en Oracle DB 9.0 y estar abierto para el negocio exactamente dentro de 8 semanas.
La forma en que podía superar la frustración causada por esto era hacer las cosas de manera iterativa. En lugar de una larga fase inicial de escritura de documentos de requisitos comerciales, los BRD se pueden escribir de forma iterativa (por ejemplo, SCRUM), y la codificación puede comenzar bastante temprano, presentando algo que al menos de alguna manera funciona en una etapa temprana, y luego refinándola junto con la documentación de requisitos que la acompaña. Pero tenga cuidado: el extremo opuesto, que no tiene ningún documento de requisitos, es igual o más peligroso. Es absolutamente necesario que sus requisitos estén escritos en lenguaje humano lo más claramente posible, revisados, acordados y firmados, y necesita aclarar frases ambiguas desde el principio, o de lo contrario, le afectará mucho más adelante.

3.
Pasamos muchas horas largas o incluso días entre desarrolladores discutiendo la “mejor” manera de hacer algo. Los paradigmas cambian, y las personas tienen diferentes preferencias. A un desarrollador le puede gustar seguir patrones de modelado muy simples, pero esto aumenta el número de clases en su modelo. Es posible que otro desee no tener ningún modelo de dominio, sino solo objetos de datos simples. En estos días, a las personas les gusta discutir sobre la solución “correcta de conformidad con REST” a un problema, y ​​a menudo resulta que si hay 10 desarrolladores en una sala hay 11 opiniones sobre lo que realmente es “conformidad de REST”.
Se pierde un tiempo precioso de esa manera, y la mayoría de las veces esto se convierte en un juego que todos quieren ganar. Hace que aquellos cuyas opiniones han sido rechazadas se sientan mal, frustrados y desmotivados.
Si los desarrolladores junior actúan de esa manera, realmente ayuda tener un jefe de desarrollo con experiencia que tenga la autoridad para simplemente ordenar “¡Hágalo así!”.
A menudo, sin embargo, hay científicos informáticos experimentados que argumentan de esa manera. Si eres uno de estos, recuerda una cosa: la humildad es tu mejor guardia contra la humillación. Entre en el momento adecuado, y tal vez a veces haga las cosas de una manera que considere subóptima, y ​​le ahorrará algo de frustración. Junto con 1.), piense que nada está hecho para durar y que el argumento que tiene hoy sobre este tema específico puede quedar completamente obsoleto mañana.

Answer 14

* Depuración de cosas que alguien más escribió hace 5 años.
* Peor aún si la persona ya ha dejado la empresa.
* Además, el código se escribió cuando la empresa aún estaba en marcha, así que no hay documentación y no entiendes por qué las cosas están escritas de esa manera y todo parece estar copiado y arreglado. Ah, y no hay prueba de unidad o integración.
* punto extra si ese código es un sistema de infraestructura que está siendo utilizado por el 80% de la empresa.
* punto extra si su CEO sigue molestándolo para que lo arregle (o al menos a su gerente se le está presionando el jefe de su jefe, etc.)
* punto de bonificación adicional si * justo ahora * le dijeron que su equipo realmente “era dueño” de ese sistema debido a algunas reorganizaciones y nunca se dio cuenta de eso (por lo que nunca tiene tiempo de leer el código) y se encontró el error en Viernes a las 7 de la tarde cuando estás a punto de dejar el cargo.

Answer 15

Las personas piensan que necesitan comunicarse con usted de “maneras especiales”, especialmente cuando se trata de relaciones.

Aquí hay unos ejemplos:
¿Cómo puedo impresionar a un programador de computadoras en una cita?
¿Cómo impresiono a una chica técnica como en desarrollador / programador?
¿Cuáles son las cosas que debes saber antes de salir con un programador?
¿Cómo es salir con un programador súper inteligente que también es muy verbal?
¿Cómo se siente ser el otro significativo de un programador?
¿Cómo es salir con un programador?

Answer 16

Todas las cosas mencionadas por otros que he visto hasta ahora son cosas que me irritan o me frustran, pero puedo reírme de ellas como las cosas con las que todos se enfrentan y lo superamos juntos. No son problemas enormes que se repiten a menudo en el lugar donde trabajo (con un grupo bastante experimentado y articulado). Solo se me ocurre una cosa que me pone a gritos de puñetazos enojado (cuando estoy solo) y que trata de corregir el mismo error más de 20 veces seguidas y todavía veo que el mismo problema muestra que es una cabeza fea, especialmente cuando mi código Aparece (ya menudo está) haciendo todo correctamente y “por el libro”. Esto a menudo resulta de software de terceros que está defectuoso y / o está mal documentado y que no proporciona el código fuente.

Answer 17

Trabajaba en Indonesia, mientras que mi carrera temprana como programador me llevó a una depresión severa:

1. Espera convertirse en un mago . Algunos todavía piensan que una ocupación relacionada con el programador / SE / IT puede resolver cualquier problema relacionado con la tecnología. Y es muy inútil explicar por qué. Por ejemplo, arreglando la impresora hasta “hackear una contraseña de facebook”.
2. Pagado barato Cuando la mayoría de la gente cree que trabajar en el campo de TI es una minería de oro, en mi país me sentí tan privado, en comparación con otro amigo mío cuyo trabajo relacionado con su campo de ingeniería, la brecha salarial base puede ser muy amplia. Soy miembro de Cari Freelancer Indonesia & Pekerjaan Freelance Online | Rekber (Rekening Bersama), donde puede encontrar personas, ofrece trabajos relacionados con TI y software. Por ejemplo, las aplicaciones móviles que se pueden proyectar pueden tener un precio de alrededor de 500 a 700 usd. Es por eso que muchos golpean y ejecutan proyectos en mi país. El problema no proviene del sitio web en sí, sino del mercado que desconoce el precio y el esfuerzo para crear un software decente.

Answer 18

http: // … 1. No hay suficiente comunicación entre los miembros del equipo.
2. Demasiada comunicación de los gerentes, p. Ej., Gerentes de proyecto, CC casi en cada interacción.
3. Reuniones sin un objetivo claro y / o agenda.
4. Ambiente de trabajo deficiente, por ejemplo, demasiado ruidoso, demasiado ocupado, demasiadas interrupciones.
5. Equipo defectuoso o obsoleto: computadora, accesorios, escritorio, etc.
6. Se le pide un nuevo enfoque para resolver un problema y luego se le dice que resuelva ese problema a la manera antigua.
7. “No hay suficiente tiempo para hacerlo de la manera correcta”.
8. Ser retenido por otros programadores que no aprenderán cosas nuevas ni se adaptarán y cambiarán, porque “no me importa lo que hagan otras compañías”.

Answer 19

Depende de la perspectiva desde la cual te estés acercando.

Desde la perspectiva de un miembro del equipo de desarrollo:

• Otros desarrolladores no prueban su código después de integrarse con el tuyo
• Cambios de patrón y cambios de estilo que no se publican adecuadamente en toda la organización
• Vendedores que se comprometen a cumplir plazos para nuevas funcionalidades.
• Líderes de desarrollo que no priorizan las motivaciones de su equipo.
• Organizaciones de tecnología que tratan a sus desarrolladores como un centro de costos, en lugar de la fuente de sus ingresos
• Mayores que compran herramientas y toman decisiones basadas en finanzas y publicidad en lugar de méritos técnicos
• Otros desarrolladores introduciendo cambios de última hora en el repositorio de código principal

Como desarrollador:

• Problemas de la biblioteca oscura para los que no existe ninguna solución en la web
• Problemas claros de la biblioteca para los que existe una solución, pero todo lo que puede encontrar al buscar dicha solución es “NVM, solucionado”
• Código que de repente funciona sin razón aparente
• Código que no funciona sin razón aparente
• Código que no funciona por una razón clara pero difícil de encontrar, como una pequeña nota en un documento de especificación de API
• Herramientas que se estrellan frecuentemente sin ninguna razón.

Como solicitante de empleo / nuevo empleado:

• Tener que luchar contra la guerra de control de fuente de nuevo en cada nueva posición
• Tener que ser deshumanizado y ser tratado con desconfianza y falta de respeto (relativo) como candidato de trabajo
• Tener que deshumanizar y desconfiar de los solicitantes para su puesto abierto debido a que demasiadas personas intentan pasar por alto
• Tener que leer artículos sobre cómo ser un mejor programador y, como resultado, sentirse inferior.
• Tener que calificar lo que realmente es un “buen programador”
• Leer las definiciones de “buen programador” de otras personas y, como resultado, sentirse inferior.
• Lucha contra el síndrome del impostor.
• Luchando contra la arrogancia excesiva.
• Reconociendo que no todos hablan en código.

Probablemente podría seguir por más tiempo.

Answer 20

Actualmente estoy trabajando en un equipo de desarrolladores web y lo que experimenté aquí hasta ahora es notable de manera negativa. Su aplicación web está mal documentada y tiene muchos errores.

Lo más frustrante es ser contratado para trabajar en un software mal documentado. Hace las cosas difíciles para quienes se encargan del proyecto. Falta de comentarios y una semántica mal escrita, especialmente cuando el programador anterior deja un montón de errores y errores. Para colmo, el cliente no quiere que el software se reescriba, solo quiere que se modifique.

En mi situación, el cliente no quiere que el sitio web se rediseñe como sugerí. Quiere que sea compatible con el móvil. Necesito editar el css mal documentado al mismo tiempo que agrego mi propio código a la página web, lo que lo hace más grande en términos de tamaño de archivo, que debería ser más pequeño si lo rediseñé desde cero. El desarrollador anterior dejó miles de líneas de CSS mal escritas que se superponen y afectan mi diseño, por eso tengo que escribir reglas css muy específicas. Al final, logré solucionar el problema, pero el tamaño del archivo creció y el tiempo de carga de la página sufrió.