Escribir respuestas a los artículos es fácil y divertido. No tiene que estudiar minuciosamente la estructura del artículo durante horas, es suficiente seguir el plan de otra persona y solo expresar claramente sus pensamientos en papel. Sin embargo, me atrevo a sugerir que una mirada crítica "desde el otro lado" sobre los temas planteados en el artículo "
Miedo y asco en TI " por respetados
eugene_crabs seguirá siendo interesante. Hoy, soy el defensor del diablo, que defiende el sistema inhumano.
A diferencia de él, no uso las borlas del señor, y tengo un par de años menos de experiencia en desarrollo, y no tengo una educación especializada, para ser honesto. Pero no tuve problemas con un interés básico en el trabajo, y me parece que la razón es una percepción ligeramente diferente de la realidad.
Un artículo para una amplia gama de lectores.
RE: Complejidad excesiva
Sección OriginalCuando trabajé en las glándulas, realmente me gustó la propiedad que veo a través de cómo funciona esto: qué bytes se mueven, en qué área de la memoria sucede esto y cómo el compilador manejó el código. Había una sensación de calma y control. Cuando cambié al desarrollo de backend un poco más tarde, me reí de infinitas configuraciones xml para EJB o el mismo resorte. Sabría lo que me espera en el futuro. Ahora simplemente no entiendo (y ya estoy desesperado por entender) lo que está sucediendo dentro de mi apego sin complicaciones. Un montón de capas de abstracciones, contenedores en contenedores, toneladas de manuales, scripts, herramientas, versiones, archivos de configuración. Todavía no he descubierto cómo se está implementando el proyecto, en el que he estado trabajando durante seis meses. Y, por supuesto, no puedes hacer un monolito, al menos en la primera etapa. Asegúrese de dividir inmediatamente todo en microservicios, porque es correcto (en la conferencia dijeron que lo hacen en la empresa X). Y, por supuesto, no podemos usar el viejo y Apache HTTP Client para ir al servicio que necesitamos una vez cada pocos minutos, porque este cliente no es asíncrono y no tiene un limitador de velocidad, mecanismo de contrapresión u otros elementos sofisticados integrados. A mi pregunta, "¿Por qué es todo esto necesario para una carga de 1 solicitud / min?" Recibo solo una mirada de reproche de mis colegas, en cuyas frentes brilla la inscripción "Aquí eres estúpido".
Un tema separado es Mr. Javascript con sus innumerables marcos. Sinceramente, no entiendo cuántas cosas podrían inventarse para una herramienta que solo necesita dibujar formularios en páginas web y, de vez en cuando, enviar una solicitud para un backend. Qué bueno que hago el backend.
En el ejemplo de la interfaz (y no solo eso), podemos ver claramente cómo caminamos en círculos: ejecutemos toda la lógica en el lado del servidor -> y ahora en el lado del cliente -> y ahora en el servidor nuevamente y así sucesivamente hasta el infinito. Escribamos el frontend y el backend en un idioma -> y ahora vamos a diferentes idiomas -> y volvamos en uno. Hagamos esquemas para formatos de datos -> esquemas solo para veteranos -> y no, los esquemas son necesarios de todos modos. Uno de mis compañeros compila su biblioteca de código abierto de yaml a xml, simplemente porque hay esquemas allí y es genial cuando se ríe de una configuración enorme, y un IDE consciente de XSD puede hacer la mitad del trabajo por usted. El siguiente problema se deduce de lo anterior.
Por supuesto, es bueno manipular sistemas simples. Entiendo esa magia cuando entiendes cómo funciona hasta el más mínimo detalle: cuando bajas al nivel de ensamblador y código de máquina, y cuando profundizas aún más, a donde el procesador es una serie de puertas lógicas.
La situación actual es tal que los desarrollos convencionales tanto en software como en hardware de procesadores ya están muy lejos de una comprensión cristalina de cómo funciona esto por una sola persona: los procesadores están llenos de lógica generada, caché multinivel y predictores de ramificación tanto que los errores en ellos no son tan no son notados, o incluso asumidos, por equipos de desarrollo completos, y florecen tan violentamente que rompen sus efectos al nivel del usuario. Además, nos vemos obligados a arrastrar una gran cantidad de funciones antiguas, asegurando así la compatibilidad con versiones anteriores, de lo contrario ganaremos velocidad y simplicidad, pero perderemos en el trabajo para el que se desarrolló originalmente este hardware.
La situación es la misma con el software: la comprensión, y aún más, la escritura de instrucciones de ensamblaje, permanece solo en áreas estrechamente especializadas, y los marcos y capas de abstracción reinan en lo que vive y gira en las inmediaciones del usuario.
Desde el punto de vista de una persona que quiere controlar su código y su máquina, esto es malo. Desde el punto de vista del usuario, bueno, ya que simplifica la comprensión, el trabajo y el camino de la idea al producto. El precio que pagamos por este deseo de los usuarios es que las crecientes capacidades del procesador se consumen de inmediato por la complejidad de los programas, lo que, al parecer, no está justificado por nada y no conlleva ninguna ventaja (fuente de alimentación, como decían en mi lugar de trabajo anterior).
Sin embargo, si profundiza más, resulta que estamos cambiando estos recursos para aumentar la audiencia al simplificar la interacción.
Anteriormente, las terminales de boletos aéreos exigían conocimiento de abreviaturas, entender cómo funcionan las aerolíneas y la capacidad de trabajar con una terminal de texto, ahora cualquier usuario acude al Aviasales condicional y recoge un boleto barato en una ruta difícil sin muchas hemorroides.
No puede hacer que una interfaz sea comprensible para la persona promedio en un terminal de texto, porque la claridad de la interfaz es tanto la resolución del monitor como buenas imágenes que no asustan al cerebro y fuentes hermosas y consejos que aparecen cuando pasa el mouse sobre el botón y la interfaz táctil.
Y también, la capacidad de probar todos estos chips, centrándose en el comportamiento del usuario. Trabajando en cascada, lanzas un lanzamiento una vez al año, recopilando comentarios sobre la versión actual durante todo el año. Hasta alguna etapa de la interfaz pasas diez años, diez lanzamientos. Al implementar correcciones menores y probarlas allí, llegará a la misma etapa en un año y medio. Pero ese trabajo requiere un ritmo diferente, otras herramientas y tecnologías, y el rechazo de ciertas cosas. Honestamente, de lamer el código: todo debería funcionar ahora, porque requiere un proceso de este ritmo.
A cambio, esta carrera loca por nuevas características nos brinda una base de usuarios cada vez mayor: cuanto más simples se presionan los botones, más personas pueden presionarlos, y la creciente base de usuarios aporta dinero no solo a sus salarios, sino también al desarrollo de nuevo hardware. Mientras más personas puedan usar el teléfono inteligente de manera productiva, más lo comprarán, mejor será el hardware en la próxima versión. El hecho de que inmediatamente cambiemos este hierro no por vuelos a Marte, sino a una audiencia creciente ... bueno, esto se puede comparar con una compañía que invierte todas sus ganancias en desarrollo, y no en dividendos y ganancias en el informe anual. Solo ahora, por alguna razón, justificas cuando Musk y Bezos hacen esto, pero no puedes justificar a la industria.
Para bien o para mal, uno puede discutir. Por un lado, la calidad del software, por otro: progreso constante en hardware, audiencia y altos salarios en la industria. Quizás elegiré el segundo (aunque preferiría reducir la velocidad), pero entiendo a las personas que eligen el primero.
Pero una cosa nos unirá: no podemos hacer nada con esto.
RE: demasiadas cosas
Sección OriginalHerramientas, idiomas, libros, conferencias, marcos, etc. Durante mucho tiempo detrás de aquellos días en que, para el desarrollo de software, era suficiente tener conocimiento de un PL, un par de bibliotecas, y eso es todo. Ahora estamos esperando cientos de marcos, con una docena de idiomas (incluso dentro del marco de un proyecto), DBMS de moda y no demasiado, corredores de mensajes ubicuos, cientos de kilómetros cuadrados de rastrillos y otra diversión. Como regla, un programador promedio no tiene tiempo para estudiar todo esto en el trabajo (a excepción de las herramientas que ya se utilizan en sus proyectos), porque necesita trabajar en ello. Muchas personas tienen que pasar tiempo personal estudiando estas tecnologías, aunque lo más probable es que el 90% de los estudiados nunca sean útiles. Yo mismo tengo quinientos artículos en mi bolsillo, un montón de vistas de video no vistas de conferencias, y cada llamada a Habr presagia una visita obligatoria a McConaughey.
Pero incluso el trabajo duro con un idioma específico o, por ejemplo, un DBMS en su empresa a veces no le permite mantenerse en tendencia, porque Las tecnologías se vuelven obsoletas antes de que puedan aplicarse. Incluso Java ahora se lanzará a la velocidad de Firefox.
Gracias a la corriente interminable de conocimiento en rápido crecimiento, muchos de nosotros nos sentimos como estudiantes e impostores eternos, sin importar cuántos sistemas haya construido realmente. Y esto es muy beneficioso para los RR.HH. y los empleadores: puede reducir fácilmente su RFP con un par de preguntas difíciles. Este tipo de carrera de ratas HR es políticamente correcto llamado autodesarrollo.
El hecho de que haya muchas herramientas es una continuación lógica del párrafo anterior. Cuando hay mucha energía en la región, esto le permite gastar energía extra en probar hipótesis, algunas de las cuales fallarán, otras se secarán, pero otras formarán la base de los nuevos estándares de la industria. Las quejas sobre el caos son similares a las quejas sobre la ineficiencia de la evolución, que por alguna razón creó un grupo de especies, la gran mayoría de las cuales murieron en silencio, e incluso la mayoría no tienen mucho éxito y viven en un rango estrecho. ¿Es realmente imposible crear de inmediato una persona que pueda sobrevivir incluso en el polo norte, incluso en el desierto, a pesar de que él mismo es bastante frágil: no corre rápido, no hay garras, sus dientes son pequeños y sin brillo, el ángulo de visión es pequeño.
Es bueno mirar el resultado de la evolución desde un lado, y preguntarse a sí mismo cuánto se tardó en crear una ventaja completamente obvia: un dedo flexible y un cerebro desarrollado.
Pero al comienzo del viaje, el resultado no fue tan claro: los dinosaurios también una vez reinaron en la tierra, y si hubiera analistas de intercambio en su tiempo, pocos pondrían ratas en algunos mamíferos contra este obvio favorito.
El desperdicio en forma de herramientas "incorrectas" es un compañero constante del camino que conduce a la cima.
RE: El programador debe ser un analista de negocios y entrevistas de trabajo
Sección OriginalRecientemente, he estado observando una tendencia de imponer la autoridad de un departamento comercial a los desarrolladores. Ahora, además de cumplir con sus tareas principales, el desarrollador está obligado a comprender el tema a nivel de un buen analista y, en general, a pensar en los negocios. Déjame en paz, no sé cómo aumentar tu tasa de conversión.
Entrevistas de trabajo
Este es el tipo de disciplina especial más importante y querida. De hecho, de hecho, depende de esto si dormirás en un viejo sofá aplastado en un odnushka alquilado en algún lugar fuera de la carretera de circunvalación de Moscú, o si tendrás que esconderte en cartón sobre una calefacción principal debajo de un puente. Si al comienzo de mi carrera la entrevista fue una charla sincera, ahora es más como un examen. Quizás esto se deba al hecho de que en aquellos días no había salarios y multitudes tan grandes que quisieran ingresar a TI o simplemente a la moda, no lo sé. Pero el hecho es que cuando viene a una entrevista para el puesto de desarrollador sénior, con un alto grado de probabilidad, se encontrará con tareas sazonadas con preguntas de prueba. “Bueno, resuelve un problema en una hoja de papel que robamos ayer con Leetcode. ¿Mal en una unidad en la condición límite? Fuuuuu goof! No sabes cómo funciona% methodName% en el% frameworkName% más moderno. ¿Quién lo puso aquí? ¡Seguridad! ”A nadie le importa que tu cabeza esté organizada de manera diferente y no puedas enfatizar la mirada despectiva y condescendiente de los nerds de nariz alta rápidamente y sin errores para envolver el algoritmo para una tarea en la que aún no has tenido tiempo de pensar. Como cuántos kilómetros de código y sistemas de producción están detrás de usted. Bueno, al menos las preguntas del rompecabezas están muertas, y gracias por eso.
No, no debería, por supuesto. Pero en las condiciones de la necesidad de una prueba de hipótesis rápida, es mucho más productivo hacer esto en la misma cabeza que toma decisiones sobre arquitectura, simplemente porque hay menos sobrecarga: necesita deliberar durante dos días y pensar durante una hora. Sabes cómo hacerlo en el área temática: bien hecho, duerme en un sofá arrugado. Si no sabe cómo, lo están esperando en aquellas áreas donde la confiabilidad es más importante que el progreso: espacio, medicina, militar, sistemas de comunicación de señales. Estas áreas son, y no son menos importantes frontend. Es cierto que pagan menos. Tal sesgo en el mercado, que me gustaría corregir, pero esto es algo más alto que no solo una persona, sino la mayoría de las empresas.
Por cierto, este mismo factor le permite despreciar los recursos humanos con preguntas difíciles, hasta "No sé a qué me aferro, hablemos con el director técnico". ¿No quieres ser analista, pero quieres escribir código en un TK lamido ya hecho? Vea arriba - otras áreas para usted: también son muy necesarios buenos programadores que no cometan errores y que implementen TK de manera eficiente y competente.
RE: personas de TI
Sección OriginalAquí analizaremos algunas subespecies de esta población, con las que a menudo tenemos que lidiar.
Realmente desarrolladores y simpatizantes. Contrariamente a los estereotipos, en su mayor parte no son nerds ortodoxos, sino muchachos normales. Pero, por regla general, no hay nada de qué hablar con ellos. Todas las conversaciones fuera del horario laboral se reducen al trabajo. Pero, ¿de qué otra manera, si se ve obligado a aprender toda esta tecnología a toda hora? Mi consejo es mantenerse alejado de los hombres con camisas a cuadros con mochilas, de lo contrario puede ganar una dosis letal de aburrimiento. Muchos de ellos van a trabajar no a trabajar, sino a jugar juguetes. Reinventemos la rueda, fijemos un nuevo marco (y sacaremos la comida de la noche) y ciertamente dejaremos todo a la mitad, porque este juguete está cansado y trajeron unos nuevos. Pero luego nos volaremos las mejillas y diremos en las conferencias cómo vencimos el problema que nosotros mismos creamos. BENEFICIOS! Estas personas son tan fácilmente conducidas a todo tipo de basura como "tareas interesantes" y "sistemas complejos" (es imposible construir una calculadora sin una docena de microservicios en la cultura de TI), lo que en términos humanos significa recoger la mierda de un mamut, pero para menos dinero, reduciendo así los salarios de la industria. Como en una broma "- Papá, ¿qué vamos a comer hoy?" "Nada, hijo, estoy trabajando en tareas interesantes en un equipo amigable".
Gerentes de proyecto. Honestamente, durante 10 años no entendí quiénes son los gerentes de proyecto y por qué son necesarios. En oficinas completamente diferentes, se veía más o menos así: hay un montón de tareas, ordenar qué hay allí y cómo, y hacerlo antes de esa fecha. Y fui a buscar un café con leche de los hipsters en el primer piso y escribí en Instagram lo difícil que es hoy. Solo una vez vi a un tipo que construyó todos estos horarios aburridos, hizo malabares con las tareas y era nuestro asistente, y no solo un tipo genial que no podía programar, sino que realmente quiero un ITP.
Camareros Muy querido por muchas categorías. Gracias a su dumping, no pueden entrar en la industria juicios razonables e ideológicos: en busca de un largo rublo, muchos trabajadores rodantes están listos para trabajar de forma gratuita.
Nos mantendremos en silencio sobre el resto.
¿Desarrolladores aburridos que solo hablan de trabajo? Es extraño, me parece aburrido que quiera cortar silenciosamente el código de acuerdo con el TK terminado de 9 a 18. Ambos estamos equivocados, pero estoy hablando de otra cosa: una organización de la mente, en la que la tarea gira constantemente en la cabeza, da un impulso significativo a la velocidad de desarrollo y prueba de hipótesis. Un poco más allá del límite, y el agotamiento se cierne allí, pero se trata de controlar la salud mental. Lo que no niega el hecho de que algunas compañías (no señalaremos con el dedo a quienes pagan a los empleados de taxi después de 22 horas, alentándolos a permanecer en el trabajo) al darse cuenta de que un empleado en llamas funciona mejor, brindan todas las condiciones para esta quema.
Proyectos? Simplemente no sabes cómo cocinarlos. Un proyecto es una herramienta universal: por un lado, conlleva patadas mágicas para los programadores (un programador, dejado a sus propios dispositivos, cambia a hacer cosas divertidas para su amada), y por otro lado, los arquitectos y los líderes de equipo pueden descargar la mayor parte del trabajo organizativo en él. organizar reuniones, mantener la relevancia del cronograma, informes sobre el trabajo realizado, comunicación de rutina con el cliente, etc.
RE: Negocios
Sección OriginalEl software en el mundo moderno no se hace simplemente porque es divertido (aunque a veces parece). Se realiza con mayor frecuencia para ganar asistentes, directa o indirectamente. Y en relación con este hecho, podemos dividir a las personas en 2 categorías.
Aquellos a quienes les importa cómo, para que todo en su interior sea hermoso y correcto.
Quienes se preocupan por lo que son esas personas que se preocupan por la esencia del producto que fabrican.
Por lo general, el desarrollador contiene ambas categorías, solo en diferentes proporciones.
Para los dos, tengo una triste noticia.
Para la primera categoría, desde el punto de vista de ganar dinero, no importa cómo se elija la arquitectura correcta y cuán hermoso sea el código. Al igual que toda su seguridad, mejores prácticas, etc. Puedes poner muletas, ganar abuelas, y luego el gerente que hizo todo esto salta al bote vecino "para obtener una nueva experiencia", y el equipo atormenta los establos por la noche.
Para la segunda categoría, el 90% de ustedes hacen lo que otros han hecho hace mucho tiempo. Con raras excepciones, todos sus productos son profundamente secundarios. Sin embargo, los empresarios astutos están tratando de dar "ideología" al próximo sistema de pago, la banca en línea y similares. Revisé todo esto yo mismo, y debo decir que es mucho más fácil trabajar cuando tienes una respuesta clara a la pregunta "¿por qué es todo esto necesario?". “” - , , . , , . “ , ” . , HR, , 146% - “ , , ”.
Dio la casualidad de que a un hombre se le ocurrió dinero. No lo hicieron en la generación actual, y ni siquiera hace cien años. El dinero ha demostrado ser una excelente herramienta para organizar una sociedad heterogénea con diferentes conceptos de belleza y diferentes deseos de las personas incluidas en ella.Puedes intentar inventar otra cosa, pero hasta ahora no has encontrado nada fundamentalmente mejor. Existe, por supuesto, motivación como el apoyo social y el espíritu de equipo, pero el primero es un derivado del dinero que el estado ha digerido, y el segundo es el condimento, no el plato principal. En una pizca, postre.Te pagan por tu trabajo. Si su trabajo no trae dinero, lo siento, las empresas no lo necesitan. Grosero, lo sé. Probemos más suave.El negocio necesita dinero. Un negocio es una organización que hace dinero. Si no se le da dinero para lo que considera necesario, entonces no ha demostrado cómo esto le traerá a las empresas aún más dinero. Aprenda a justificar el desperdicio de recursos, pruebe que es beneficioso, incluso a largo plazo, y habrá recursos. Sin embargo, los negocios y la toma de decisiones en este sentido son mucho más adecuados que la persona promedio: cuando una persona intenta comprar un boleto por medio año por diez mil, porque es mucho dinero, y preferiría comprar un boleto por dos mil cada mes, solo una empresa está interesada figura: beneficio del dinero invertido. 16% de ganancia? ¡Tómalo! Sin dinero, pero ¿puedo obtener un préstamo para este gasto del 5%? ¡Tómalo!Si una empresa no puede justificar una revisión de código porque su código dura tres meses, después de lo cual es reemplazado por uno nuevo, entonces se queda sin eso, ¿qué está haciendo allí? Hay una gran cantidad de compañías para las cuales la revisión de código y la refactorización son componentes importantes del proceso. Y la primera compañía se centra en la prueba de hipótesis, no en la codificación: esto también es normal y le permite encontrar un nuevo nicho en el que puede crecer, madurar, acumular grasa y comenzar a practicar la revisión y refactorización.No debe culpar a un diseñador que construye una casa de ladrillos de juguete sin sujetarlos con mortero: vivir en un hámster en esta casa, y la tarea de esta casa es probar la hipótesis de la apariencia y no servir como una casa. E incluso si este diseñador está listo para pagarle por ayudarlo a construir su casa de juguetes, no lo escupe con el hecho de que necesita un mortero y un pozo de cimentación, sino que se conforme con los constructores normales.RE: salud
Sección Original, , ( ) . , . , - , . , . , , , . 35+ , “ , 25 ?” “ ?”. — .
Quizás este es el único punto al que no tengo nada que responder completamente. Además, en mi mundo una persona tiene la voluntad y la razón, y si cree que no necesita levantar pesas, no las levantará.