Ser programador puede ser interesante y divertido, pero ser desarrollador de software es un infierno. Las computadoras son lógicas, las personas no lo son. Por desgracia, en la industria moderna del software no pagan por la programación. Pagan por el desarrollo de software, y esto implica completar tareas en equipo, junto con otras personas. Los comandos están formados por personas rebeldes, no por clases y métodos Java.
El éxito de un proyecto de software depende de ingenieros inteligentes que a menudo son vagos, ignorantes, egoístas, irritables y simplemente miserables. El éxito depende de personas que a menudo no saben cómo comunicarse, compartir conocimientos, liderar y obedecer, y seguir instrucciones. Depende de nuestra capacidad para formar equipos y participar en sus actividades. Y también por nuestras habilidades sociales, a veces en mayor medida que por las habilidades técnicas.
Drama Estoy de acuerdo Este drama se aplica a cada uno de nuestros hermanos en la profesión, así que si quieres sobrevivir en esa profesión, lee este libro.
Egor Bugaenko .
El desarrollo de software hoy implica más que escribir código. No se trata de algoritmos, fórmulas, bytes, archivos o protocolos. Y no se trata de instrucciones, operadores, pruebas unitarias, interfaces de usuario o escenarios de implementación. Y ni siquiera sobre rendimiento, escalabilidad, tolerancia a fallas o confiabilidad. Todos estos componentes son importantes, pero no hacen que un programador sea más efectivo que otro, o algún equipo de desarrolladores tiene más éxito que los competidores. Otra cosa juega un papel decisivo en el mundo moderno del software y el hardware: no se trata de computadoras, sino de personas.
El éxito de un proyecto de software depende de personas que a menudo son flojas, ignorantes, egoístas, molestas y simplemente infelices. Depende de las personas que a menudo no saben cómo comunicarse, compartir conocimientos, administrar y obedecer, y seguir instrucciones. Depende de nuestra capacidad para formar equipos y participar en sus actividades. Y también por nuestras habilidades sociales, a veces en mayor medida que por las habilidades técnicas.
En este libro, conocerá a un pequeño grupo de programadores, arquitectos y ejecutivos a quienes se les paga para crear software. En las próximas más de doscientas páginas, resolverán problemas, eludirán situaciones de conflicto y analizarán las características del trabajo en equipo. Espero que sus diálogos y monólogos lo ayuden a comprender la importancia del aspecto social del desarrollo de software y, como resultado, a convertirse en un desarrollador o líder aún mejor.
Capitulo 1
Adrian
Ser programador puede ser interesante y divertido, pero ser desarrollador de software es un infierno. Las computadoras son lógicas, las personas no lo son. Por desgracia, en la industria moderna del software no pagan por la programación. Pagan por el desarrollo de software, y esto implica completar tareas en equipo, junto con otras personas. Los comandos están formados por personas irracionales, no por clases y métodos de Java. Voy a conseguir un trabajo en uno de estos equipos y sobreviviré en él. Puedo escribir en Java, pero esto no es suficiente para el éxito. Se necesitarán otras habilidades allí. Y algunos de ellos aún no los he desarrollado.
Mineros y mineros
Le dije a la secretaria:
- Tengo una reunión con Chris, él me está esperando.
Algún día tendré mi secretaria, mi oficina, mis programadores y mi startup con inversores, y una gran misión que seguiremos. Y seré famoso y exitoso. Mientras tanto, no necesito pagar la vivienda. Parece que estos tipos son lo suficientemente ricos como para tratar conmigo en los próximos meses, y parece que les gustó mi currículum. Ahora tengo que convencerlos de que sueño con quedarme con ellos para siempre.
Dado que cualquier arquitectura de software es un producto de las actividades de las personas, para mejorar un producto, primero es necesario mejorar a las personas.
"En realidad, esta es ella", respondió la secretaria secamente.
Chris apareció un minuto después. Vamos a la sala de reuniones, ella ofrece café, pero yo pido un vaso de agua. Sale y yo automáticamente saco mi teléfono y reviso Facebook. Chris regresa con un vaso de agua y lo acompaña un tipo con una camiseta oscura con el logo de GitHub. Ella dice que está muy contenta de conocerte y se va. El nombre de Dude es Adrian, él es un desarrollador. Estamos comenzando una conversación. Con sus preguntas, da la impresión de una persona bastante experimentada. Me siento bastante cómodo: es obvio que soy tecnológicamente superior a él, por lo que claramente no hay nada de qué preocuparse.
"Necesitamos a alguien para arreglar nuestra arquitectura", resume Adrian después de media hora.
"Más bien, necesitas que alguien te corrija antes de poder hacer algo con la arquitectura", pensé, pero dije en voz alta:
- Estaré encantado de ayudar. Me parece que su proyecto es interesante tanto tecnológicamente como desde el punto de vista de los procesos comerciales. Realmente no me gusta trabajar en proyectos aburridos, no importa cuánto paguen por ello. Prefiero ser un apasionado de mi negocio, por lo que quiero hacer algo interesante y moderno.
Adrian sonríe melancólico. Tal vez escuchó esto de cada segunda persona sentada en esta sala ...
Me hace una pregunta difícil:
"¿Cuándo estás listo para comenzar?" ¿Cuánto tiempo necesitas para completar tus proyectos en curso? Estamos buscando una persona a tiempo completo.
Parece muy orgulloso de lo que se dijo. Aparentemente, piensan que un trabajo de tiempo completo será absolutamente bueno para mí. Ya me di cuenta de que tendría que sentarme en esta oficina de nueve a cinco, calculando mi salario. Si bien no tengo mi propia startup, aparentemente, será así. Esta semana esta es la tercera compañía donde me están entrevistando. Los dos anteriores aún no me han respondido, aunque parecía que era adecuado para ellos. Este tipo se ve mucho más desesperado. Sospecho que sus servidores se bloquean casi cada dos noches, y esto se convertirá en mi problema tan pronto como firme el contrato. Necesito tener cuidado
"Quizás una semana sea suficiente para completar todo el trabajo".
Digo lo que tengo que decir, aunque ahora no tengo proyecto, ni trabajo, ni ingresos. No puedo decirle la verdad: debes seguir las reglas del juego. Tengo que parecer popular y muy ocupado. Pero, por otro lado, ¿parece lógica la promesa de completar todas las cosas en una semana? ¿En qué tipo de proyecto estoy trabajando ahora que podría completarlo en solo una semana? Por supuesto, ambos entendemos que esto es una mentira ... pero también entendemos que no podemos hacer nada al respecto.
Una persona que promete ser leal a una compañía inmediatamente deja de ser leal a otra.
- ¿Cuánto tiempo llevas trabajando en esta empresa? Le pido que cambie de tema.
"Dos años", responde Adrian.
- ¿Has creado la mayoría de los proyectos de la compañía?
- Sí, soy el primer desarrollador aquí. Hace dos años, conocí a Tony, nuestro cofundador y director técnico. Lo verás en la próxima entrevista.
Veo cuán respetuosamente Adrian habla de él. Por qué, Tony le paga dinero.
- Estaré encantado de conocerlo! Respondí y terminamos la conversación.
Chris me escribió tres horas después. Tony quiere verme mañana por la mañana. Ella dice que Adrian habló positivamente de mí. Al parecer, están interesados. Las dos compañías anteriores todavía están en silencio, así que puedo trabajar para Tony. Aunque ni siquiera sé cuánto están dispuestos a pagar, el anuncio dice que el pago es "decente".
Ni siquiera quiero imaginarme trabajando para otra persona. Puedo sentirme bastante cómodo en su oficina, fingiendo ser interesante para mí, riéndome de las bromas de Tony y preguntándole a Adrian cómo están sus hijos. Pero no quiero escribir código para ellos o, peor aún, ser responsable de sus fallas técnicas. Y esto es lo que intentarán hacer: poner tantas cosas como sea posible sobre mis hombros.
No soy una persona perezosa en absoluto. Me encanta escribir código, pero hacerlo para que la otra persona se convierta en millonario, no, gracias. Mi vida vale más que el salario que pueden ofrecer.
"¿Cuánto puede pagar un empleador?" - La pregunta correcta que debe hacerse un especialista.
Honestamente, creo que fue precisamente esta actitud mía la causa real de los problemas que había encontrado en mi trabajo anterior (y en varios trabajos anteriores). Todos querían que fuera un buen empleado, y yo quería hacer lo que me gusta: traducir mis propias ideas escribiendo código en Java. Ya me han despedido cuatro veces, pero solo tengo 29. Hasta ahora, no es una carrera muy impresionante. ¿Qué estoy haciendo mal?
He escuchado muchas veces de diferentes personas: cuando el empleador lo entrevista, también debe entrevistarlo. Este enfoque me parece correcto, pero no porque deba ser selectivo al elegir una empresa, de la que queremos formar parte: son todos iguales en la etapa inicial, solo nombres, mercados y presupuestos diferentes. Debemos "entrevistarlos por nuestra parte" para demostrar que estamos especialmente interesados en ellos. Esto es como conocer a una chica2: debes hacer preguntas y pretender que estás interesado en su alma, y no solo en su cuerpo.
Al principio, cada nueva empresa, equipo o proyecto es un misterio. No importa cuántas preguntas haga sobre sus procesos DevOps, principios de gestión y análisis estático, porque cualquier respuesta puede ser una mentira, su invención o todo puede no funcionar como lo imaginan. Nunca escucho lo que dicen en las primeras entrevistas. Esto es a lo que le presto atención: 1) el dinero que están dispuestos a pagarme; 2) el tamaño del equipo; 3) el puesto que se me ofrecerá.
La cuestión del dinero es obvia: cuanto mayor sea el salario, mejor. No solo porque soy codicioso y preferiría Mercedes-Benz en lugar de Chevrolet, sino también porque una buena financiación significa que el proyecto es valioso e interesante. Considere esto desde una perspectiva de mercado: si pueden pagar más que otros, tienen dinero de algún lado.
El salario es el principal indicador explícito de la importancia de su contribución al mercado.
Quizás lograron atraer grandes inversores (lo que significa que creían en sus ideas); tal vez ya estén obteniendo un ingreso decente (de esto se deduce que el consumidor los valora más que sus competidores). O tal vez el fundador heredó un par de millones y los invirtió en una startup loca (lo que significa que en lugar de ser malgastados en Las Vegas, estos dólares calientan el mercado a través del negocio en el que estoy invitado a participar).
En cualquier caso, el dinero es un indicador de la importancia de este negocio en particular en el mercado. Cuanto más dinero, mayor es la demanda del mercado para este proyecto. Cuando el proyecto en el que está trabajando se queda sin dinero, es hora de pasar a otro, más importante para el mercado. Este enfoque puede parecer desleal, pero sigue siendo cierto si te preocupas por tus clientes y no por los jefes que reducen sus salarios cada dos semanas.
Elegir un proyecto que pague menos y que "parezca más interesante" es injusto e ilógico. No corresponde a los programadores decidir qué tan interesante y valioso es esto. Dichas decisiones deben ser tomadas por el mercado, representado por clientes solventes o inversionistas. Y nos transmiten las decisiones tomadas con la ayuda de nuestros salarios. Cuando aumenta el salario, el mercado está satisfecho con lo que hacemos por él. Cuando el salario baja, es hora de hacer la pregunta: ¿por qué sigues haciendo este trabajo para el mercado, si el mercado ya no lo aprecia?
El segundo indicador importante para mí es el tamaño de la empresa. Demasiado pequeño y demasiado grande no son buenos. Cuando la empresa es demasiado pequeña, los especialistas técnicos se ven obligados a combinar muchas responsabilidades, realizando trabajos diversos: escribir código, configurar servidores, preparar presentaciones para inversores e incluso organizar muebles y arreglar una máquina de café. Desde el punto de vista profesional, esto es degradación y el riesgo de perder tiempo. Como resultado, tendrá que hacer mucho trabajo que no esté relacionado con la posición inmediata, solo para ayudar al equipo a sobrevivir.
Las grandes empresas son demasiado políticas, las pequeñas son demasiado caóticas.
Y las posibilidades de supervivencia de las pequeñas empresas son bastante pequeñas (como dicen las estadísticas). Prefiero mantenerme alejado de proyectos que emplean a menos de 20 técnicos.
Por otro lado, todas las grandes empresas tienen un tipo diferente de problema: la política. La gente no trabaja allí, luchan entre sí. Sobreviviré en el nivel inferior de la jerarquía corporativa, con el título de "desarrollador senior" y obteniendo una taza una vez al año en mi cumpleaños, o me convertiré en un maestro de la intriga en un grupo particular de cretinos. Ninguna de las opciones me atrae. Por lo tanto, no me gustaría ir a una empresa que emplea a más de mil personas.
El tercer factor al que presto atención es la posición que me ofrecen. Me refiero a la posición real en la jerarquía. Todas las empresas se caracterizan por una jerarquía de empleados, sin importar lo que digan los seguidores de la holocracia. Siempre hay un superior, luego hay personas que lo obedecen (hasta el nivel más bajo). Mantenerse en el nivel inferior siempre trato de evitarlo. No solo porque tengo autoestima, sino también porque soy vago. Cuanto más bajo esté en la jerarquía, más trabajo tendrá que hacer y menos dinero obtendrá. La división del trabajo en acción (y no solo en el campo del software).
Por lo tanto, cuanto más baja sea la posición propuesta y más técnica sea, más dificultades habrá: tendré que trabajar para alguien, no para mí. Esto es exactamente lo que odio hacer. Estoy listo para trabajar duro cuando sé que el resultado será mío. Pero en los equipos de desarrollo con una capa gerencial gruesa, los niveles más bajos crean ingresos que son consumidos por niveles más altos. Entonces, ¿qué sentido tiene quedarse abajo?
¿Alguna vez has oído hablar del experimento que Didier Desor y sus colegas realizaron en la Universidad de Nancy? 2 Tomaron diez células idénticas, cada una plantó cinco o seis ratas macho. Para obtener comida, los roedores tuvieron que atravesar un pequeño agujero, nadar a través del acuario hasta el comedero, tomar algo de comida y nadar para comerlo (era imposible comer directamente del comedero). Al final del experimento, en todas las jaulas, las ratas se dividieron en dos grupos: presas y no presas. Los mineros nadaron en busca de comida, y los mineros les robaron esta comida.
¿Qué nos enseña esta historia? Que trabajas o robas. Las ratas no sabían acerca de los diez mandamientos. No tenían idea de que el robo era un pecado. Parece que la naturaleza no tiene nada contra el robo (para ella, esta es la distribución natural de los roles). Del mismo modo, para algunas personas, el trabajo es la actividad preferida. Para otros, el robo es más común.
Nosotros, por supuesto, no somos ratas, y nuestro comportamiento es mucho más complicado, pero el principio general es el mismo: trabajamos o asignamos el resultado del trabajo de los demás. Se inventaron jerarquías de control para controlar este proceso y evitar batallas constantes (como entre ratas en jaulas). Ya no luchamos con nuestros jefes, solo les damos los beneficios que producimos, creyendo en la justicia. Por supuesto, ellos mismos también producen algo, pero los beneficios que aportan son claramente menores y el salario es mayor.
Cuanto más alto se encuentre en la jerarquía, menos tendrá que hacer específicamente y más se le acreditarán los demás.
Basado en esto, la posición más conveniente para mí en el sistema moderno de "mineros y mineros" es parecer un minero, pero recibir el pago como minero. En otras palabras, parecerse a un ingeniero de software trabajador, en realidad, que no hace prácticamente nada.
La gran mayoría de los equipos en el campo del desarrollo de software no pueden lograr que los programadores den lo mejor de sí mismos. El manual, especialmente en los niveles más altos, no comprende la diferencia entre Java y JavaScript. Por otro lado, en un nivel inferior, es más difícil engañar al jefe, pretender estar escribiendo código, pero en realidad publicar una nueva publicación de Facebook en ese momento. Por eso, cuanto más alto sea mi posición, mejor. Nadie entenderá lo que realmente estoy haciendo, así que puedo hacer lo que quiero. Participo en proyectos por los que me pagan, pero prefiero hacerlo cuando quiero y cuando es realmente necesario. No a las nueve de la mañana.
»Se puede encontrar más información sobre el libro en
el sitio web del editor»
Contenidos»
ExtractoPara Khabrozhiteley 25% de descuento en cupón -
Nuestro código