¿Qué odian los programadores?

Answer 1

Aparte de las frecuentes interrupciones

1. Gerentes no programadores – arriba de la lista
2. Que ‘The Art of Computer Programming’ está acumulando polvo en la estantería.
3. Reuniones
4. El cliente es el rey
5. Escribiendo especificaciones de diseño – seguido por especificaciones de prueba
6. La infraestructura de prueba es una lucha interminable entre tu intuición y el hoyo baboso
7. Nadie entiende el modelo de seguridad. La gente ni siquiera sabe cómo funciona SSL. Así que explicar la seguridad es una yegua nocturna.
8. Se pierde tanto tiempo en escritura, despliegue la depuración que ocurre el cambio de contexto. Y así es como llegué a 1M de visitas en Quora. Simplemente durante el tiempo compilaciones de SQL
9. Un amigo que ha abierto una startup, es miserable, pero luce.
10. Cuando RH comienza a hablar: ‘¿Cuántas horas hombre?’
11. Por mucho que odio a Veg Biryani, creo que los MBA en la industria de la computación están perdidos todo el tiempo. Los gerentes de TI y Veg Biryani son los mismos. Existen mas como parias. Ningún administrador en el planeta sabe nada acerca de cómo manejar a este grupo de geeks individualistas y este magnífico código que funciona, pero si elimino este comentario, deja de funcionar.
12. Esa caja negra, que hay que reformular.
13. Código de comentarios por el bien de ello
14. Probadores manuales
15. Revisión de código nits = arreglarlos termina causando un error
16. Defectos de los que tiene que atender una llamada, si vale la pena corregirlos.

Answer 2

En primer lugar, hay algo que debo confesar: no soy un programador . ¡Pero trabajo con programadores! Y vivo con un programador, y curiosamente, la mayoría de mis amigos son programadores. Por lo tanto, creo que mi perspectiva en este tema es lo suficientemente profunda como para emprender esta pregunta. ¡Vamos, entonces! Aquí están mis 10 mejores (el orden es aleatorio):

1. Que se le diga qué hacer (o no hacer) . Esto se aplica tanto a “Soltar este problema, está tardando demasiado” y “Por favor, lave los platos”.

2. Que se le diga cuándo hacer cosas (o cuándo no hacer). Lo que nuevamente se aplica a “Está bien, nos quedaremos con lo que tenemos, nos iremos a casa y lo haremos el otro día” y “¿Podrías lavar estos platos ahora?”.

3. Ser interrumpido. Para el observador externo, el flujo parece ser una de las cosas más importantes en el trabajo de un programador. Cuando se los interrumpe, es posible que no reaccionen en absoluto o se enojen porque alguien tuvo las bolas para hacerlo.

4. Programación (que, por supuesto, también puede ir a la lista de lo que les gusta a los programadores). Lo sabes, ¿verdad? “¡Odio la programación! ¡Odio la programación! ¡Odio la programación! … Oh, funciona. ¡Me encanta la programación!

5. Tecnologías que no utilizan. Los argumentos de los desarrolladores que trabajan en diferentes tecnologías son absolutamente divertidos de ver. De hecho, me recuerda el momento en el que participé en un grupo de investigación de mercadeo de grupo focal y 7 mujeres discutían sobre cuál champú es el mejor. Nunca esperé que alguien pudiera tener sentimientos tan negativos por mí solo porque me gusta un champú diferente. Ver a los programadores hablar sobre tecnologías es casi lo mismo.

6. No entender las cosas. Que se le diga qué hacer (o que no debe hacer) sin que se le diga por qué se necesita hacer. O (no) saber por qué algo funciona. En Internet, hay un meme perfecto que lo ilustra: una persona sentada desconcertada frente a una computadora y pensando “No funciona … ¿por qué?” Seguida de la persona sentada desconcertada frente a la computadora y pensando “Funciona … ¿por qué?”.

Honestamente, no puedo pensar en ningún otro grupo con tanta falta de comprensión del mundo.

7. Tareas aburridas. Incluyendo cosas repetibles, componentes o funciones de escritura que son en realidad muy similares a lo que han estado haciendo para otro cliente, y tareas que no les permiten usar todo su potencial. Me parece algo bueno, en realidad. Demuestra cuán creativos son.

8. Rastreadores de tiempo. Creo que está relacionado con su propio sentido de libertad y privacidad. El tiempo de seguimiento de cuánto tiempo trabajan en cada proyecto les da la sensación de estar bajo vigilancia.

9. Las personas de recursos humanos. Especialmente aquellos que los envían a LinkedIn. Cuanto más lo pienso, creo que se aplica a todas las personas no técnicas con las que necesitan trabajar. Gestores de ventas, marketing, proyectos no técnicos.

10. Tratándolos como los “chicos de la computadora”. Has estado allí, ¿verdad?
– Amigo, me dijeron que eres programador, ¿verdad?
– si
– ¡Es genial! Porque mi impresora no funciona …
– Hombre, ¿qué parte del ‘programador’ te perdiste?
Mientras que para algunas partes de la sociedad, ser programador significa pasar mucho tiempo con las computadoras y conocerlas bien, para los programadores es como no ver la diferencia entre un cantante y alguien que repara las radios rotas.

_____________

ACTUALIZACIÓN: Recientemente he escrito un artículo sobre la base de esta respuesta. El artículo contiene imágenes que tuve que eliminar de mi respuesta en Quora debido a la política de imágenes, y algunas pautas básicas sobre cómo encontrar un hilo de entendimiento con los programadores. Lo puedes encontrar aquí: ¿Qué odian los programadores? 10 cosas que debes evitar al trabajar con desarrolladores

Answer 3

Prefiero publicar esto como anónimo, ya que, en parte, estoy criticando a la compañía en la que trabajo actualmente. Tengo mucha experiencia (más de 25 años) en cosas integradas en tiempo real, así como una variedad de roles, desde ingeniero de construcción hasta arquitecto de software.

1. Como dice todo el mundo, ser interrumpido mientras se encuentra en “la zona”. Hubo una persona que finalmente tuve que decirle a F * off por interrumpirme constantemente sin preguntar. (No me importa si la gente pregunta, otros monos de código entienden cuando dices “No ahora, vendré a verte más tarde a …”)
2. Mi próximo odio es la documentación inútil. No son las cosas que realmente importan, el diseño de software, las guías de usuario y los procedimientos de prueba, etc., sino los interminables documentos estúpidos que llevan semanas o meses de esfuerzo para hacerlo bien, y solo los lee el revisor y quien hace el control de calidad. El cliente puede simplemente mirarlos. La compañía para la que trabajo tiene un conjunto estricto de cosas que debemos producir independientemente de la relevancia del documento. Parecen más preocupados por obtener la fuente correcta en el pie de página de los documentos en lugar de producir un producto de calidad que funcione para el cliente.
3. Pretendiendo ser Lean, cuando somos muy FAT. Los Scrum sin sentido que no logran mucho, aparte de perder el tiempo de todos. Solo porque la gerencia puede decir que somos “Lean”. El Scrum es la ÚNICA parte de Lean que realmente hacemos.
4. Gestión de las modas que van y vienen. Cada uno es visto como una bala de oro que arreglará todo. Creo que la mayoría de las veces, la moda podría ayudar si se implementara correctamente, pero todos siguen la moda hasta que finalmente desaparece.
5. La falta de personal de soporte de software, como los artistas gráficos y los redactores de documentos técnicos. Lo admito, soy una mierda en las interfaces de usuario, puedo hacer todo lo que está en el back-end pero no necesito la ayuda de alguien que dicta cómo debe verse una pantalla, colores, fuentes, etc., lo mismo para los documentos que el cliente realmente quiere, necesita el toque de alguien (no de los monos del código) que sabe escribir y puede eliminar la jerga del software del documento. Esa no es mi habilidad, estoy seguro de que haré el draft lo mejor que pueda, pero alguien debe asumir el control en esa etapa.

Answer 4

Cosas que los programadores odian.

1. Instrucciones que intentan articular cómo hacer las cosas pero no por qué.
   Odiamos cuando los no programadores dicen cosas como “Necesito que cree un nuevo interruptor en el código y lo use para escribir los datos en la base de datos”, en lugar de “necesitamos hacer una copia de seguridad selectiva de la información antigua”. En estos días, cualquier persona que haya usado Facebook cree que son arquitectos de software calificados y que generen conversaciones con términos técnicos que han escuchado. Pero úsalos en todos los lugares equivocados.
2. Interrupciones
   Esto es generalmente irritante para todos, pero especialmente para los programadores; los que no son programadores invariablemente no entienden por qué esto es así y sospechan que es solo un plan de trabajo, pero créanme que es real. Existe el hecho de estar en la “zona”, esto significa que en el estado mental correcto para ser productivo para la programación, este estado tarda un tiempo en llegar, sin embargo, una vez que esté en funcionamiento, la productividad suele ser buena, como una especie de Locomotora contra un Ferrari. Piense en ello como en soñar, se necesita un tiempo para que se desarrolle un sueño y para que usted pueda meterse en él, luego, si alguien lo despierta de repente, es muy difícil volver a ese punto en el sueño (si no es imposible).
3. Alcance de arrastramiento
   Esto es algo que sucede con cualquier tipo de proyecto, desde construir una casa hasta diseñar un folleto, pero es particularmente común con los productos de software, ya que la mayoría de las personas no pueden articular lo que quieren hasta que ven algo que no quieren.
4. Gestión que no entiende la programación.
   La administración es difícil, la gente generalmente apesta, sin embargo, eso no significa que los gerentes deban poder escapar sin tener un entendimiento básico de lo que están haciendo sus subordinados. Cuando la administración no puede captar la naturaleza básica y las heurísticas de los proyectos de trabajo terminan con un alcance limitado, plazos poco realistas y frustración general en ambos lados de la valla.
5. Documentando lo que hacemos
   Los programadores odian la documentación, punto final, la única vez que estamos interesados ​​en la documentación es cuando intentamos utilizar el software de otras personas, y no, la ironía de eso no se pierde en nosotros.
6. Márketing
   Programadores y geeks en general odian el marketing; “El departamento de colorear” como se lo conoce cariñosamente. Esta es otra dicotomía, ya que los geeks en sus millones se caen sobre sí mismos para comprar cosas como iPads y netbooks, triunfos de la forma sobre la función. La tensión siempre está alrededor de lo que es más importante, cómo se ve o qué hace, la respuesta depende de qué lado de las pistas te sientas más cómodo.
7. Hardware
   Cualquier programador al que alguna vez se le haya pedido que corrija una extraña falla en el servidor de la base de datos o por qué las unidades RAID no funcionan correctamente sabe que los problemas de hardware son una molestia. Parece que hay un error común entre las personas no técnicas de que, dado que los programadores trabajan con computadoras, debemos saber cómo solucionarlos; Esto es un poco como asumir que Jenson Button sabe cómo desmontar y volver a montar una caja de engranajes de carreras porque él también sabe cómo conducir un auto de F1.
8. Imprecisión
   “El sitio web está roto”. “La característica X no está funcionando correctamente”. Las solicitudes vagas son un dolor para tratar. Siempre me sorprende cómo los no programadores exasperados tienden a sentirse cuando se les pide que reproduzcan un problema para un programador. Parece que no entienden que “está roto, ¡arréglalo!” No es suficiente para que hagamos algo útil.
9. Otros programadores
   Los programadores no siempre se llevan bien con otros programadores. Sorprendente, pero cierto. Esta podría ser fácilmente su propia lista de los 10 principales, así que solo voy a enumerar algunos de los rasgos comunes que los programadores tienen para molestar a sus compañeros programadores y guardar detalles para una publicación aparte:
   • Ser gruñón hasta el punto de ser hostil (¡podría escribir un libro completo sobre esto!)
   • No entender que hay un momento para debatir sobre la arquitectura del sistema y un momento para hacer las cosas.
   • Incapacidad para comunicarse de manera efectiva y confusa terminología.
   • Pensamiento unidimensional, sin apreciar los “factores humanos”.
   • Falta de peso propio.
   • Ser apático hacia el código base, el proyecto y la fecha límite.

Y por último, pero no menos importante, la cosa número 1 que molesta a los programadores …

1. Nuestro propio código (6 meses después).
   ¿Alguna vez has visto algo de tu antiguo código y muecas de dolor? ¡Qué estúpido eras! ¿Cómo pudiste, que sabes tanto ahora, haber escrito eso? ¡Quémalo! ¡Quemalo con fuego!

Bueno, buenas noticias. No estas solo.

La verdad es que el mundo de la programación está cambiando constantemente. Lo que consideramos como una mejor práctica hoy puede quedar obsoleto mañana. Simplemente no es posible escribir el código perfecto porque los estándares sobre los cuales se juzga nuestro código están evolucionando cada día. Es difícil lidiar con el hecho de que su trabajo, por más hermoso que sea ahora, probablemente será ridiculizado más adelante. Es frustrante porque no importa la cantidad de investigación que realicemos sobre las últimas y mejores herramientas, diseños, marcos y mejores prácticas, siempre existe la sensación de que lo que realmente estamos buscando está algo fuera de nuestro alcance. Para mí, esto es lo más molesto de ser un programador y, al mismo tiempo, también lo que también hace que valga la pena.

Answer 5

Sí, lo que ustedes dijeron, más

• Cuando los gerentes quieren que los desarrolladores asuman el riesgo de la programación: la programación es predecir el futuro . Nadie es bueno en eso. Así que odio que el jefe espere que trabajes tarde porque no predijiste correctamente los futuros meses de anticipación. Esto significa que, en lugar de aceptar que predecir el futuro es intrínsecamente difícil, y aceptar el riesgo (que es casi seguro) que podría llegar a retrasar, la compañía pone el riesgo en los hombros de los desarrolladores. Me pregunto si el gerente del jefe le pide que le reembolse a la compañía si supera el presupuesto.
• Proyectos con financiación insuficiente: cuando programa 10 años hombre, y su gerente cree que su equipo de cinco hombres aún puede terminar en un año. Ah, sí, comienzan el proceso de contratación tres meses después, y al final del año han contratado a dos tipos más, pero eso es solo tal vez seis años de trabajo, así que, ¿es de extrañar que llegue tarde? Lo mismo cuando se supone que la ayuda proviene de otro departamento, pero de repente están demasiado ocupados para ayudar durante un mes, y luego se retrasa porque hubo un montón de trabajo que no se realizó, o tuvo que burlarse de toda la contribución del otro departamento para avanzar, tiempo que no calculó, tiempo que no estaba gastando en su propio código.
• Deuda técnica: cuando contrata un proyecto que lleva dos años ejecutándose, tiene solo seis páginas de documentación y ningún caso de prueba, y piensan que debería poder ponerse al día en un par de semanas. Y la mitad del código fue escrito por un genio autodenominado que ya no trabaja allí, y WTF hace esta clase exactamente? Nadie lo sabe. Ellos siempre trabajaron alrededor de eso.
• Cuando todo es importante: cuando el departamento de ventas ejecuta el proceso de desarrollo, le indica que se concentre en la función X el lunes (porque un cliente les gritó sobre la función X el lunes) y luego dice que no, que la función Y es la más importante el miércoles (porque una característica solicitada por el cliente Y el miércoles). Luego, el viernes, dicen que necesitas trabajar todo el fin de semana en la función Z porque un cliente cuenta absolutamente con eso (lo que descubrieron el viernes). Luego, el próximo lunes se preguntarán por qué no has terminado con la característica X todavía.

Me gustan las otras respuestas, y podría seguir para siempre. Esto tendrá que hacer.

Answer 6

1. Un aspirante a soñar despierto, Steve Jobs, diciéndonos, si solo pudiera conseguir uno o dos programadores, interrumpiría todo el mercado.
2. Los grandes cambios de última hora se rechazan como pequeños ajustes introducidos en la línea de tiempo.
   ‘ Oh, me olvidé de decirte … puedes agregar un pequeño cambio … ‘.
3. La mayoría de los programadores backend odian CSS . Ellos absolutamente odian CSS . Odian que simplemente no funcione como piensan que debería. Se mantienen alejados. Toman un papel muy específico y no lo tocan.
4. Odiamos las configuraciones . Odiamos cuando no podemos empezar. Instala esto. Instala eso, luego actualiza esto, luego instala eso, luego configura esto …
   ‘ Ughhh … ¿Cuándo puedo escribir el effing básico – Hello World ”?
5. Pruebas unitarias de escritura. Cuando está escribiendo un código de aplicación crítico, la única manera de estar seguro de la corrección de los cambios que realiza a lo largo del tiempo son las pruebas unitarias. Pero entonces nunca lo aceptas de todo corazón hasta que sufras y después de eso también escribes pruebas por miedo y no por amor. El instinto natural de un programador es resolver un problema, crear algo, a pesar de su importancia, en el fondo, la mayoría de los programadores odian las pruebas de escritura.
6. Actualización de tickets a medida que funcionan. Nuevamente, con el tiempo podríamos aprender la importancia de rastrear el progreso en una herramienta, pero odiamos hacer entradas en ella.
7. Redacción de documentación. De nuevo una de esas cosas que son importantes. Pero vamos, si eres un programador, sabes que no te gusta esta mierda tanto como te gusta escribir código, de hecho, si tienes que pasar todo un día haciendo esto, ¡te sofocarás!
8. Compañero programador que les dice que su elección de lenguaje de programación, paradigma de programación, Editor de código, marco o estilo de formato de código Es mejor que el de ellos. Esto a menudo conduce a la violencia y al derramamiento de sangre.

   Consejo profesional : nunca le digas a un amante de Emacs que vim es mejor o viceversa

9. Largas reuniones aburridas. A los programadores no les gustan las reuniones. Período.
10. Plazos
11. Ofertas de trabajo que ofrecen horarios de trabajo flexibles y buscan ninjas de código de pila completa .

Answer 7

Esto detesto

1. Después de presentar el cambio final a la comercialización, obtienes la temida larga pausa en la sala ahora muy tranquila … y luego “Hmmm … y si …”.
2. … luego, después de perder la discusión y seguir adelante y hacer lo que ellos exigieron que hagas porque es una “buena UX” … 1 semana después, la misma escena … la habitación en silencio … se miran entre sí … y: “Hmmm … supongo que tenías razón … no parece equilibrado … OK … hagámoslo a tu manera. Cuando se puede hacer Estamos atrasados ​​en esto ”.
3. Hacer que el personal de marketing hable con el cliente y le prometa a la luna, las estrellas a la mitad de la galaxia, y luego, sin la participación de nadie técnico, elaborará una “especificación” del producto que aterrice en su escritorio el lunes.
4. Hacer que el personal de marketing hable con el cliente y le prometa a la luna, las estrellas a la mitad de la galaxia, y luego, sin la intervención de nadie, elaborará una “especificación” del producto que aterrice en su escritorio el lunes con una fecha límite de 2 semanas … usted dice que es imposible, el marketing dice que el cliente lo quiere en 2 semanas, ya estamos comprometidos
5. El vendedor dice: “Tienes que usar [alguna biblioteca oscura que nunca hayas usado y NO quieres” porque los desarrolladores de la última empresa en la que trabajé usaron eso.
6. Conversaciones que van así:
   Programador: Sí, le acabo de enviar un correo electrónico para avisarle que el sistema no está enviando clientes potenciales. Aunque estoy en eso … investigando.
   Gerente no técnico: ¿Qué pasó?
   Programador: No estoy seguro todavía. Voy a ir
   Gerente no técnico: ¿QUÉ SIGNIFICA QUE NO ESTÁ SEGURO? ¿CÓMO PUEDE PASAR ESTO?
   Programador: Uhm … Necesito verificar primero todas las llamadas entrantes de los 300 nodos—-
   Gerente no técnico: ¿QUÉ? 300? ¿Cuánto tiempo va a tomar para arreglar esto?
   Programador: Todavía no lo sé porque no sé cuál es el problema, por lo que primero necesito …
   Gerente no técnico: ¿No lo sabes? ¿Que sabes? No me estas dando soluciones solo problemas.
   Programador: Bueno, eso es lo que estoy tratando de explicar:
   Gerente no técnico: no quiero excusas, arréglalo. Te llamo en 5 minutos.

   Inspirado en hechos reales. Algunos desarrolladores se vieron perjudicados en la producción de ese script.

7. Gerente de proyecto: Necesito que me des una fecha límite que pueda alcanzar.
   Desarrollador: Hmmm, [murmura algunos cálculos para sí mismo] … 3 semanas
   Project Manager: What No. Eso es demasiado … necesitamos líneas de tiempo realistas.
   Desarrollador: Bueno, primero necesito hacer una copia de seguridad de toda la base de datos de 600TB en un servidor fuera de línea, luego necesito reestructurar la base de datos vacía … luego escribir guiones de importación que además deben calcular xey … [explicación larga] … por lo que 3 semanas A las 8 horas los días es apenas suficiente.
   Gerente de Proyecto: No… ¡el MD se volverá loco! Esto tiene que estar fuera la próxima semana
8. Esta declaración de una persona no técnica: “No es tan difícil … es solo copiar y pegar, ¿no?”.
9. Cliente: “Le pedí a mi amigo que mirara tu código y él dijo que no deberías usar …”.
10. Absolutamente odio pasar por cientos de páginas de un tutorial … dándome una palmadita por un trabajo bien hecho … solo para descubrir que la versión [cualquiera que sea la versión que estudié] ya no es compatible o el 80% está en desuso. Mirándote AngularJS!
11. Reuniones interminables para discutir cosas sin sentido a expensas del progreso.
12. El pajarito en su hombro que regresa cada 5 minutos para preguntar “¿Está arreglado?”
13. Las personas no técnicas que toman decisiones para técnicos altamente cualificados se sorprenden cuando las cosas se desmoronan.
14. Este es mi favorito [¡NO!]: “No funciona. ¡¡¡Nada está funcionando !! ”… Odio esto en particular porque“ nada ”significa literalmente“ nada del trabajo arduo que has realizado en los últimos x meses ha significado nada que funcione ”. En cambio, tenía que enseñar a la gente a decir: “Cuando hago X, esperando que suceda Y, no es eso”. Esto es más útil para mí y no destruye el valor de mi esfuerzo y es mucho más útil para que ambos identifiquemos y resolvamos el problema rápidamente … sin juntar los 45.
15. Cliente: Quiero que el sitio aparezca “pop” …

Es muy fácil volverse cansado y cínico. Me he reunido con programadores que se han convertido en monstruos adecuados después de años de “tomarlo” de personas que creen que saben de lo que están hablando pero que solo se están interponiendo en el camino del programador, que, si se le da la oportunidad, puede solucionar muchos problemas. cosas.

Edit: He visto hace años …

Answer 8

• Tengo una idea para una aplicación …

OK, ok sé el trato. Hacemos la próxima Snapchat / Instagram, ¿la compramos por miles de millones y dividimos 50/50?

• Mi computadora está lenta…

Esto se debe a que tu ** “*” antivirus está comprobando cada enlace sangriento cuando navegas.

• Deberías ser muy rico …

El momento de duda de un codificador.

Mmh Mas o menos. En realidad, ahorro más porque los videojuegos cuestan menos que ir al estadio para ver fútbol.

• ¿Cómo es que el desarrollo de software es tan caro? ¡No usas ningún material!

Necesito computadora, licencias, servidores, y mucho tiempo. Tiempo que debería ser recompensado lo suficiente como para motivarme a no ir al extranjero o para hacer otra profesión.

Dado que pocas personas pueden hacer el desarrollo de software, esto aumenta los precios.

• [Preguntas de entrevista]

Preguntas que nunca debes hacerle a un programador en una entrevista.

Las preguntas que hace en una entrevista hablan mucho sobre si debo unirme o no.

• ¿Por qué codificas también en el fin de semana?

Graficas Gráficos por todas partes

Es muy diferente codificar:

• Para fuente abierta
• Sin puntos muertos
• No hay pautas estrictas
• Con claros objetivos útiles.
• En un sofa

Que codificar:

• Para un software propietario de gestión de back-end.
• Listo para ayer
• Con nombres de variables que deberían ser como myCustomVariableInt_p
• Para corregir un error en el ticket # 7671 urgente “no se puede conectar. Resuelve lo antes posible, usuario profesional ”
• En un cubículo o un espacio abierto lleno de teclas y personas murmurando.
• Pfft, los programadores realmente no tienen responsabilidades

Software por valor de miles de millones …

Software por valor de miles de millones …

Los ingenieros de software con código moral laxo pueden costarle mucho más a su empresa.

• ¡Hagamos una demostración con los clientes, incluso si aún no está listo!

Una pesadilla de codificador

Empujar: lanzar el sitio web a un servidor.

Prod: nombre habitual del servidor web que aloja el sitio web que los usuarios verán

¿Por qué es tan terrible? Eso significa que si surge un error durante el fin de semana, usted es responsable, y debe solucionarlo incluso si planeaba ir de campamento, de lo contrario, su trabajo está en juego.

• ¿Podemos programar una reunión para fijar la fecha límite, ya que se omitió la última vez?

Sugerencia de sala de juntas Coder

Realmente vamos a escribir código en lugar de perder horas.

• Los programadores quedarán obsoletos por AI pronto …

Una especificación muy completa y precisa.

Luego los programadores escribirán especificaciones para la IA.

¡La programación ya es la tarea más automatizada!
El “Imprimir” hola mundo “;” de hecho usa un programa para crear un código de máquina que es esencialmente “abrir la salida en serie, escribir ‘h’, escribir ‘e’, ​​…” que luego se traduce al código que realmente se usa para abra el terminal, descifre los caracteres en bytes, abra el flujo, … luego se traduce en códigos de CPU … que abren y cierran conexiones electrónicas, luego se compone una imagen en el búfer de video y el controlador del monitor lo muestra.

¡Es una cantidad de trabajo alucinante que se debe hacer a mano!

---

Muchas gracias a CommitStrip! Ir a su sitio para obtener otros chistes frescos sobre la programación.

SANJAY:)

Answer 9

Interrupciones – como lo mencionan otros.

Opciones tecnológicas para las víctimas de la moda : tener la obligación de usar algo que está mal para el trabajo o malo, porque es moderno, o porque una gran empresa lo usa (por ejemplo: MySQL: un tinkertoy como una base de datos real, pero “usa Facebook “Sí, sacan el extremo frontal de SQL y lo usan como un disco duro gigante distribuido. Funciona porque no usan la mayor parte del mismo). Y luego soplando un montón de tiempo de desarrollo resolviendo sus problemas.

Aceptación no crítica de “mejores prácticas” : una vez eliminé un servidor de clase 170 a 13 clases pequeñas y claras que hacían lo mismo. Las otras 157 clases eran clases de Java sin lógica para modelar datos, y todo lo que se usaba era tomar los resultados de una base de datos y convertirlos en JSON. Entonces serialicé los conjuntos de resultados SQL directamente a JSON. Desde la perspectiva del costo de mantenimiento, ese tipo de reducción de tamaño de código es siempre una ganancia.

Cuando era adolescente, tenía un gato que pedía beicon de la mesa del desayuno, unos cuantos maullidos y un poco de beicon. Ella tenía un gatito, que imitaba a su madre, maullando continuamente, sin parar, durante el desayuno. Cuando tomó un poco de tocino, continuó haciendo gorgullos mientras trataba de comérselo; no entendía que el comportamiento de maullar fuera por un propósito, o saber cuándo se cumplía ese propósito. No seas el gatito que no sabe por qué está maullando; si escuchas una forma particular de hacer las cosas es bueno, no lo uses hasta que comprendas profundamente por qué y para qué sirve exactamente.

Metodología locura : si tienes un equipo que se ha consolidado, hay pocas cosas que puedes hacer que sean más destructivas que forzar una “metodología” enlatada en sus gargantas, porque alguien tiene religión al respecto. He escrito sobre uno de estos aquí: ¿Un sustituto para tener una arquitectura? – estas cosas son como Amway: cuando fallan, es culpa del individuo y cuando tienen éxito es el éxito de la metodología. Usted sabe que está en presencia de una creencia religiosa no racional cuando la prescripción cuando la metodología falla es más de lo mismo: “usted no oró lo suficiente”.

No hay una talla única para todo esto. Si puede permitirse el lujo de hacerlo, lo mejor es contratar a personas inteligentes y dejar que descubran cómo trabajar mejor juntos, con algunos empujones y tal vez una o dos ideas de un conjunto de metodologías diferentes si las cosas no funcionan bien. Lo que está bien depende enormemente de qué tipo de cosas esté construyendo y de la distribución de los niveles de experiencia en el equipo. Tomará decisiones muy diferentes si está creando un sistema de control de tráfico aéreo que si está creando una interfaz de usuario web.

Clunky bug tracking systems : un desarrollador en un equipo con un producto maduro pasa gran parte de su día en uno. Si no puede archivar errores rápida y fácilmente, vea sus errores y cierre errores, su productividad se verá afectada. Los rastreadores de errores siempre son blancos de “no es solo una cera para el piso, ¡es una cobertura de postre!” la expansión del estilo – particularmente aquellas dirigidas a audiencias “empresariales” o que se supone que apoyan alguna metodología particular. La antigua Bugzilla, tan larga en el diente como es, es decente para la productividad. El rastreador de errores de Github es mi estándar de oro personal: se dieron cuenta de que la mayoría de las funciones de los rastreadores de errores son inútiles. JIRA es menos sabia de lo que era antes, pero aún así quiere mover sus zarcillos en todas las direcciones (¿no quieres una wiki con eso?) – y este tipo de herramientas integradas terminan impidiéndote el uso de herramientas simples y buenas de otras proveedores que hacen lo que usted necesita (github está lleno de otros gratuitos), en favor de una extravagancia de basura empresarial. Las suites de productos a menudo se construyen alrededor de una que es realmente buena. Esta es la web, y la “integración” suele ser poco más que hipervínculos.

La idea de que las marchas de la muerte mejoran la productividad , no lo hacen. Hay una ilusión perniciosa de que las personas miserables hacen más cosas.

Equipos grandes : nunca he visto un equipo realmente asombroso para construir algo nuevo o reescribir algo más grande que 5 personas, y he estado haciendo esto por más de 30 años. Más grande que eso, necesitas dividir las cosas en equipos más pequeños. De lo contrario la comunicación general y la política inundan la productividad.

La palabra “cascada” : en realidad, nadie hizo cascada, y nadie quiere. Es un hombre de paja inventado como una forma de denigrar todo lo que vino antes del sabor de la semana.

Answer 10

Interrupciones Específicamente, interrumpiendo a un programador mientras se encuentra en la zona.

Interrumpir a un programador mientras está en BitLand puede ser catastrófico para él. Detendrás su tren de pensamiento muerto en sus vías. Los pequeños detalles que jugaba en su memoria a corto plazo se han ido. Incluso podría perderse en el algoritmo de búsqueda que estaba implementando. Tiene que seguir mirando estos pequeños detalles (como los nombres de variables locales y el lugar donde se encontraba en un algoritmo) en algún lugar de su código que lo frena hasta que recupera la velocidad.

Es fácil molestar a un programador y luego pasar por esto:

a esto:

Entrar en la zona es un proceso largo. En promedio, toma hasta 15 minutos o más dependiendo de la persona para comenzar a trabajar con la máxima productividad. Antes de ingresar a la zona, puede estar revisando sus correos electrónicos, leyendo artículos de Hacker News, viendo videos de Youtube de PewDiePie o Jacksepticeye, o incluso jugando un juego competitivo de Counter-Strike: Global Offensive (Silver III 🙁), especialmente cuando se siente Has hecho suficiente trabajo creativo o te sientes cansado.

Quitarse fuera de la zona es fácil . Las simples interrupciones, como hacerle preguntas a un programador, hacer ruido, salir a almorzar o hacer que un amigo te haga ping a Slack o Skype pueden sacarte de la zona, como cómo Márquez noqueó a Pacquiao en su cuarta pelea. Una vez que estás fuera, tu productividad está seriamente en problemas. ¡Puede tardar media hora en volver a la zona!

Para simplificar las cosas, he aquí una analogía. Haga que alguien cuente de 0 a un número muy grande. A mitad de camino, grítale: “¡Mira! ¡Ardilla!”.

Fuentes:

• Experiencia personal (puedes visitarme en GitHub o en mi sitio web)
• ¿De dónde obtienen estas personas sus ideas (no originales)?
• ¿Cómo explicar a un laico por qué un desarrollador no debería ser interrumpido mientras codifica hasta el cuello?

Answer 11

Estoy seguro de que la mayoría de los programadores estarán de acuerdo conmigo … (aunque podría haber una excepción).

Como los programadores también son seres humanos, odiamos todo lo que la gente normal odia. Jaja

• En el lugar de trabajo:

1. Política : odiamos la política en el lugar de trabajo. Pero cuando se trata de política sucia es abominable. Muy pocos programadores pacíficos pueden sobrevivir a la política.
2. Burlas: La gente que habla contra nosotros siempre parece burlarse de nosotros, pellizcando nuestros sentimientos, humillándonos indirectamente, pellizcando.
3. Configuración de problemas: Si el desarrollador env. no está bien, realmente duele. Tenemos que configurar, configurar etc por mucho tiempo . Sabes que ? Es mucho tiempo

1. Subestimación de la calidad del código: si tiene que seguir un determinado patrón, debe codificar de acuerdo con las reglas de la oficina. Si bien hizo un buen código que realmente puede equiparse con el código de producción, debe escuchar a su gerente / líder. Un montón de regaños, hay que escuchar.
2. Omitir el código de producción: si se omite su código, es realmente doloroso. No hay crédito existido.

• En Implementación:

1. Lista enlazada: es una estructura de datos bien conocida para crear asignaciones de memoria dinámicas. Pero es realmente difícil de implementar.
2. Programación dinámica: un verdadero amigo en la conjetura de la pesadilla. Es realmente doloroso de implementar.
3. Entrada de datos: hay muchos proyectos que requieren datos. a veces tienes que hacerlo tú mismo para probar PROPÓSITO. Realmente duele.

Estas son todas mis opiniones personales. Pero hay una visión mínima de los problemas comunes.

Answer 12

1. La gente piensa que solo porque soy un programador, puedo arreglar su computadora.

1. Por casualidad sé cómo arreglar computadoras. No porque sea programador.

La gente piensa que porque soy programador, también debo ser un hacker.

La gente piensa que solo porque mi trabajo consiste en escribir / mirar fijamente las pantallas de las computadoras, no tengo una razón válida para tener una muerte cerebral cuando llegue a casa.

Lenguajes de programación basados ​​en sangría.

Visual Basic para Aplicaciones

Cuando mi oficina se queda sin azúcar para la máquina de café.

Haciéndome perder mi tiempo (probablemente no distinto de los programadores, pero me molesta mucho)

Cuando la gente insiste en hablar contigo cuando llegas al trabajo. ¿Por qué? ¿Solo porque?

No, no quiero ayudarlo a construir su nueva aplicación “increíble”.

Agregar un montón de requisitos a un boleto sin cambiar la fecha límite. Especialmente molesto si el boleto tuvo que enviarse semanas antes y luego, cuando ya casi termine y tenga algo más que necesito para terminar en mi expediente, descargue otras 100 cosas en este boleto. Vete a la mierda

Tener que usar sistemas de basura . ¿Por qué esta página tarda 15 segundos en cargarse? ¡No hay nada en ello!

Tener que hacer un seguimiento de mi tiempo: me siento como un niño que tiene que registrar sus horas de educación física en la escuela. Pensé que éramos adultos?

La frase “es sólo un par de pequeños cambios …” – Es un par de pequeños cambios en 150 páginas. NO ES POCO.

Answer 13

La lista es larga

• Clientes que quieren jugar programador y decirle qué hacer.
• Muerte por patrones de diseño. Estoy completamente cansado de escuchar acerca de la necesidad de insertar un patrón de diseño xyz en algún código. No necesito un código que tenga muchos patrones de diseño. Necesito un código que resuelva los problemas de los clientes. Y no me des esta BS sobre “si tuvieras este patrón de diseño, tu código funcionaría mágicamente”.
• Algunos programadores que deciden el código al que fue expuesto por primera vez durante el fin de semana deben ser la base de nuestro producto en el futuro. Estoy tan harto de esto. Una vez más, los clientes no necesitan el código que acaba de leer. Los clientes necesitan un código que funcione, resuelva problemas comerciales y genere valor. Todo lo demás es solo BS.
• La idea de que al leer algo en internet, deberíamos implementarlo.
• Experiencia en gestión. El proceso de desarrollo de software en una startup no está relacionado con el proceso de desarrollo / gestión en una empresa establecida. No hagas software en una startup como lo harías en una empresa.
• Valor de negocio. ¿Es mejor el software que proporciona una mejora del 5% a 1k usuarios que el software que proporciona una mejora del 50% a 4 personas en el proceso de operaciones del software? Las organizaciones de TI en una empresa optimizarán la mejora del 50% para las 4 personas de operaciones. Tan equivocado.
• Mover a la gente y / o dejar ir a las personas equivocadas. Estas personas son propiedad intelectual. Dejarlos ir por la razón equivocada es una pesadilla. Normalmente la razón equivocada es el dinero. Si alguien más piensa que alguien vale más dinero, probablemente lo sea.
• Siendo una ducha. Si tus contratos son douchey, eres juzgado por eso.
• No confiando en mi entrada. En algún momento, tienes que confiar en mi entrada. Si no lo haces, no vamos a estar juntos mucho tiempo.
• A los clientes les encanta culpar a los desarrolladores por las cosas que llegan tarde. Y los clientes nunca llegan en el último segundo con nuevas solicitudes de características que van a cambiar muchas cosas que ya se han hecho.
• Otros desarrolladores utilizan la biblioteca equivocada porque quieren verse geniales, nuevos, diferentes. Había varias personas que querían usar varias bibliotecas porque otras bibliotecas eran demasiado populares. ¿Qué tal si resuelves los problemas primero? Ese es uno grande para su currículum, “creó millones en valor para el cliente”.
• No uses las cosas nuevas más geniales. Está muy bien que haya nuevas bibliotecas, productos, etc., geniales. Por favor, no creas que todo funcionará perfectamente el primer día. Mejor aún, no conviertas estas herramientas en la piedra angular de tus planes el primer día.
• No entendiendo que podría ser atropellado por un autobús hoy. Alguien más podría tener que tomar tu código mañana. Debería escribir su código de manera que alguien más pueda intervenir. Es difícil hacer esto, hay mucho conocimiento arraigado en un producto, pero los desarrolladores deben tratar de entender esto.
• Pensando que usted es más inteligente que los expertos en las principales corporaciones de software que han estudiado y construido sistemas que son escalables para millones de personas.
• Plataformas que cambian continuamente y son incompatibles entre sí. Por ejemplo, .net core es en su mayoría incompatible con el código en el que he estado trabajando durante los últimos 2.5 años. Utilicé todas las cosas que Msft me dijo que usara, sin embargo, después de tener aproximadamente 15k o más líneas de c # con reglas de negocio muy ajustadas basadas en el marco de la entidad, descubro que debería haber estado usando el código primero para generar mi acceso a los datos. . Como inicio, no tengo tiempo para volver a escribir ese código, así que ahora me siento atascado. Esto no es sólo un problema con Microsoft. Sería genial si hubiera menos dolor en hacer avanzar las cosas. Microsoft no es el único que hace esto, por lo que no es solo un problema contra ellos.
• “¿Puedes venir a mi casa y ayudarme a reparar mi computadora?” No lo lleves a BestBuy ni a que el escuadrón friki lo arregle en tu Dime.
• Tratando de venderme en patrones de diseño, deuda técnica y otras palabras de comadreja. Estoy seguro de que te encantan estos términos, pero son palabras de comadreja.

• Patrones de diseño. Algo de entrenamiento intenta venderte para justificar sus servicios de entrenamiento.
• Deuda técnica. Un término usado para hacer que las personas suenen importantes. La realidad es que te importa el código que funciona y resuelve problemas de negocios. La razón por la que tiene que volver a escribir es porque el individuo que escribió algún código ya no está. Alguien más, en lugar de aprender el código, usa el argumento técnico de la deuda.
• Si está fuera de una empresa, utiliza el término deuda técnica para sembrar Miedo, Incertidumbre y Duda.

He visto todo esto y más de primera mano y son feos.

Una cosa que realmente no odio son las guerras ideológicas del lenguaje. La parte pública es solo la masturbación mental. La parte de la empresa es valiosa. No quieres productos diseñados willynilly. Las empresas necesitan normas.

Answer 14

Estoy de acuerdo con la mayoría de las personas que figuran aquí (especialmente las interrupciones).

Aquí hay uno que no estoy seguro de si es común, pero me ha sucedido muchas veces en varias compañías.

muchos cocineros en la cocina

Existe la creencia de que la programación siempre es compleja y difícil y que un solo desarrollador no puede manejar la carga de trabajo de Sin embargo, muchas veces me parece que el trabajo en sí es bastante manejable si simplemente se deja un desarrollador. solo, no distraído, y no se requiere administrar otros desarrolladores en el equipo. El proceso de diseño siempre se realiza sin problemas porque puedo escribir código, refactorizar, rediseñar, todo en mi tiempo, y entregar código limpio de alta calidad en un período de tiempo bastante corto. De hecho, a menudo es difícil encontrar formas de dividir una característica en tareas divididas que se puedan dividir entre las personas. Trabajando solo, no dependo de nadie más para cometer su código, no tengo que fusionar código (lo cual, si hay un conflicto, es un problema tratar con él), no me arriesgo a que otras personas lo cometan. una fusión y tener que depurarlo, y no tengo que corregir el código de otras personas cuando no funciona.

Encuentro que a menudo los gerentes dimensionarán los equipos según su propio “sentimiento de tripulación”, generalmente no basado en el conocimiento técnico; influenciado por desarrolladores y arquitectos que inflaban estimaciones fuera de proporción; y no se basa en la realidad o en lo que realmente es el alcance del trabajo. Luego me exigen que mágicamente haga un trabajo para encargar a los desarrolladores más jóvenes, al tiempo que introduce arbitrariamente la integración general de las personas en el proyecto en general. En mi caso actual, estoy escribiendo trabajos de análisis de datos independientes que son más fáciles de diseñar, ajustar y completar por un solo desarrollador. Nos demoramos más en nuestros proyectos al tratar de forzar con fuerza bruta a un “equipo colaborativo” en proyectos que realmente no requieren más de 1 o 2 buenos desarrolladores.

Answer 15

Los programadores a menudo se odian a sí mismos por los siguientes puntos

• Optimización de la culpa. Por una vez, me estremezco cada vez que reviso el código que escribí hace un tiempo y pienso: “¿Escribí esto cuando estaba drogado?” . Estoy seguro de que no solo soy yo, sino que otros sabrían esto, que la mayoría de las veces tomamos decisiones sobre hacer algo de cierta manera solo para cubrir la fecha límite, o para llegar a tiempo para la liberación, pero sin reservas sabiendo que se pudo haber hecho. mejor.
• Refactorización. Los programadores rara vez refactorizan su propio código, no porque no quieran, sino por otras 1000 cosas que han surgido y que nos mantienen ocupados.
• Documentación. Irónicamente, juzgo a otros programadores por no documentar su código.

Además, a continuación hay algunas cosas que podemos odiar aparte de nosotros mismos.

• Tendencias Mantenerse al día con las tendencias en tecnología. Por mi parte, ¡absolutamente odio esto! En un momento me decido por aprender algo nuevo y hay rumores sobre algo mejor que de alguna manera “siempre” ha estado allí, y ahora también tengo que aprender eso.
• Reuniones Reuniones de pie, reuniones de aceptación de usuarios, reuniones para organizar reuniones, más reuniones para configurar más reuniones. NUNCA parecen terminar.
• Líneas de tiempo. ¿ETA? por el amor de Dios, no me pida una ETA para un proyecto en el útero, PUEDO simplemente darle una figura del estadio, pero por favor no vuelva a mí después de un año y pregúnteme por qué no se cumplió la ETA. Podría haber un millón de razones por las cuales.
• “La zona”. La gente, es una cosa, es real, existe, la reconoce. Cuando vea a un programador pegado a su pantalla sin responder a ningún tipo de estímulos externos de buena gana, están en su hábitat natural, déjelos, si pierden ese impulso debido a usted, lo odiarán.

Answer 16

He estado leyendo las respuestas a esta pregunta durante mucho tiempo, y creo que es hora de que escriba una respuesta para mí, pero con una edición especial:

¿Qué odian los programadores de juegos ?

1. ¿Por qué tu juego se ve tan feo? Como soy programador, mi trabajo es escribir código, no dibujar un botón ni crear un modelo 3D. Es como si estuvieras diciendo a los artistas por qué sus juegos son tan buggy.
2. Eres programador, ¿por qué necesitas una PC más rápida? Porque el juego se ejecuta en mi máquina, con un montón de código experimental y no optimizado. Y esperar a que la PC vuelva a funcionar desde el último bloqueo es muy doloroso.
3. No necesitas más de un monitor. Infierno no Cada programador debe tener dos monitores. O tres, a menos que digan que solo necesitan uno.
4. Cambia esto, es fácil. No es nada fácil, conozco bien el código base actual y cómo las nuevas características lo afectan. Puedo implementarlo por ti, pero por favor no me digas que es fácil, a menos que yo lo diga.
5. Hey, hay un error. ¿Y? ¿Podrías, por favor, decirme más sobre los detalles? ¿Cuándo ocurre el error? ¿Qué hiciste para que aparezca? ¿Qué esperas ver como el resultado de tu acción? ¿Y está incluso en los putos requisitos?

Answer 17

• Día 1

Requisito: Necesidad de desarrollar una funcionalidad que cancele automáticamente aquellos Bills que tengan alguna discrepancia.

Línea de tiempo: es un requisito urgente, aunque esta es una tarea cuesta arriba. Necesitamos esto en el servidor de producción con alta prioridad al final de esta semana (Total de 7 días hábiles, incluidos sábado y domingo).

Gerente: Ashish, usted tiene experiencia en el procesamiento de lotes y algoritmos. ¿Puedes por favor hacerlo en alta prioridad?

Ashish: (Desde entonces, a Ashish no le gusta la paz y la felicidad en su vida). Él dijo: ‘Sí, lo haré’, sin mirar el requisito.

Gerente: Muy bien, luego transmitiré al equipo en el lugar que está trabajando en ello. Y lo entregarás a tiempo.

Ashish, lee ese diseño técnico. WTF, no se puede hacer en 3 semanas. Y se supone que debo hacer en 7 días. Pufff! Me jodi

---

• Día 3

Son las 2:00 AM, estoy escribiendo código desesperadamente para cumplir con la fecha límite. ¿Comí, Oh! ¿a quien le importa?

A las 5:00 de la mañana, completé mi código. Gracias a Dios, lo he hecho. Ahora puedo irme a casa y dormir.

Al día siguiente, comencé las pruebas unitarias.

Al final del sexto día. Terminé con 76 casos de prueba para mi módulo.

• Dia 7

Después de trabajar durante 16 horas seguidas durante una semana, entregué mi código al equipo de QA (Quality Assurance).

QA probó ese módulo, pasó con éxito todos los casos de prueba.

---

• día D

El código se implementa en la producción. El momento más feliz de mi vida, como si ganara la batalla.

Al día siguiente, estaba esperando un correo de agradecimiento del cliente . Desde que completé la tarea casi imposible con fecha límite definida.

Y el correo más esperado apareció,

“El módulo que has desarrollado ya no es necesario. Ya que hemos manejado esa funcionalidad en otro módulo, no se cancelarán facturas de su código.

Desafortunadamente, necesitamos descartar este código “.

Y luego, otro correo aparece:

“¿Podemos desarrollar esta funcionalidad? Este es un requisito muy urgente, queremos que este módulo esté en producción a fines de esta semana “.

Desde entonces, a Ashish no le gusta la paz y la felicidad en su vida. Él dijo: “Sí, jódeme”.

---

Entonces, si tengo que resumir. Lo que los programadores odian:

1. Plazos agudos, aunque eso no es un requisito urgente.
2. Demasiado trabajo, en un corto período de tiempo.
3. Tareas sin una imagen clara de los requisitos.
4. Y por último, después de dar demasiado esfuerzo. ‘Tu código ya no es necesario’.

Answer 18

Interrupciones : muchas personas han mencionado esto, pero vale la pena repetirlo. Las interrupciones son asesinas. La programación no es fácil; tomamos ideas y pensamientos humanos y tratamos de traducirlos a un formato que una máquina que habla en 1 y 0 puede entender.

Se necesita tiempo para ingresar a la “zona”, y cuando saca a un programador de la zona, es como cambiar los canales 45 minutos a un programa de 1 hora.

Ambigüedad : si no nos dice exactamente lo que quiere, o cuál es exactamente el problema, obtiene nuestra interpretación de sus palabras . Soy un desarrollador web que se especializa en front-end para sistemas de gestión de contenido.

La gente me ha dado fotos e incluso videos de lo que quiere, y lo he entendido mal porque nadie se molestó en usar estas cosas claras llamadas “palabras” para comunicar estas otras cosas claras llamadas “ideas”. Si no nos dice lo que quiere en términos específicos y objetivos , hará nuestras vidas un infierno.

Estereotipos: no todos los programadores son un introvertido tartamudo con rostro pálido y socialmente inepto, de 80 libras que pasa 18 horas al día frente a una computadora.

Conozco a los programadores que salen a filmar los fines de semana. Otros que compiten con los coches. Aún otros que hacen mecánica o carpintería. Conozco a uno o dos que hacen herrería y soldadura.

Algunos programadores son veteranos de guerra. Otros son fanáticos del fitness.

Probablemente podría asumir con seguridad que la mayoría de los programadores son introvertidos. Pero la introversión no es un estado binario. Es una escala; Algunos son más introvertidos que otros. Si bien me gusta mi tiempo a solas, cuando hago entrenamientos o presentaciones, me animo y me convierto en una persona diferente. Hablar en público me emociona .

Ah, y no todos los programadores son un tipo, tampoco.

La computadora de todos los demás: mi computadora está configurada de la manera exacta en que yo quería que estuviera configurada para hacer las cosas que hago. Cuando tú

A) quitalo

B) me hacen usar el de alguien mas

Se siente raro. como sentarse en el sofá de otra persona donde claramente tienen su propio surco de glúteos trabajado.

Si me das una computadora portátil nueva, me llevará días o incluso semanas antes de que me sienta bien al usarla.

[Adicional:]

Ver a otra persona usar una computadora : Pasamos mucho tiempo frente a la computadora. Nos hemos acostumbrado a formas específicas de navegar a través de él, ya sean los atajos de teclado, los trucos del mouse, etc. Los programadores y los profesionales de TI son “rápidos” en las computadoras en comparación con la población general.

Por lo tanto, ver a alguien que no es experto en computadoras tratar de usar una computadora es terriblemente doloroso.

Finalmente, dejé de sentarme con mi profesional de impuestos cuando trabajamos con nuestros impuestos porque simplemente no podía soportar verla usar una computadora. El bloque H&R podría ganar algunas horas serias de productividad si enviaran una nota sobre cómo funciona la tecla de tabulación.

Answer 19

Ciática

Es muy incómodo, especialmente cuando tienes que sentarte mucho en una silla, disminuye tu concentración (porque no puedes concentrarte en nada que no sea el dolor de nervios que dispara y te quema toda la pierna) y tu mente creativa que solías tener (antes de la ciática). ) llega a su fin. Realmente puede arruinar tu vida.

Pura paralizante y dolorosa.

Sé que esta respuesta será enterrada en poco tiempo, pero si alguien la ve, cuida tu salud, porque NADA merece la pena. Sé que es un cliché, pero es mucho más fácil prevenir una enfermedad que tratar de solucionarla (en este caso, no puedes), por lo que es mejor educarte un poco, aprender sobre las enfermedades antes de que te enseñen, de la manera más difícil. Sigue algunos blogs de medicina / estilo de vida si quieres. Creo que todos deberían aprender medicina (hasta el punto de saber cuándo estamos / no estamos jugando con nuestros cuerpos).

No dé por sentado su dolor de espalda, simplemente no puedo expresar cuán importante es su columna vertebral en palabras, pero entendió mi punto.

Answer 20

• Cuando trabajas para un jefe que no sabe nada de programación pero sigue preguntando: “¿por qué esto no se ha hecho todavía? Pensé que no tardaría más de 30 minutos “. Cuando en realidad te pedía que tiraras todo al fuego y rehicieras toda la biblioteca de matemáticas de 500 líneas.
• Cuando está siendo perseguido por el jefe de programación que no sabe nada y está tratando de encontrar y resolver un error subyacente.
• Cuando estás luchando contra un jefe exigente y un error subyacente al mismo tiempo, era el código de otra persona quien ya había dejado la compañía.
• Cuando se trata de errores principales y subyacentes en el código de otra persona, literalmente no hay documentación ni comentarios, y las variables se nombran con caracteres individuales, por ejemplo, a = b + c. WTF son a, byc !?
• Cuando estás lidiando con jefes e insectos al mismo tiempo, y estás trabajando en el código de algún amante. Finalmente, resultó que había alguien del departamento de gestión de datos que cambió el formato de los datos sin avisar a las partes interesadas. Más tarde, su jefe le preguntó por qué no lo descubrió de inmediato, como si debiera saberlo todo.
• Después de haber escrito una función perfecta después de trabajar duro durante un par de días y es reutilizable para otros problemas, estás muy orgulloso de ti mismo, y el equipo de negocios surgió en la próxima actualización y dijo: hey, mira, nosotros Tenía otro pensamiento y tal vez podamos hacerlo de manera diferente …
• Después de entregar el aviso de salida, la gente comenzó a preguntar por un fragmento de código que escribió hace unos años y no podía recordar por qué ahora. Gritar “lee mis documentaciones primero, no puede ser más claro” en tu cabeza y tratar de ser amable y responder las preguntas.