Hola La programación es un tema complejo, y el desarrollo de software industrial es muy complejo. En nuestra industria de TI, no es tan raro escuchar preguntas de colegas junior en la serie "¿Cómo me desarrollo?", "¿Qué debo hacer para convertirme en un profesional de alto nivel y lo más rápido posible?", "¿Qué debo hacer si no puedo desarrollarme, pero ¿no hay proyectos interesantes? ”,“ ¿qué debería saber el medio? ”. Si tiene de 0 a 3 años de experiencia en TI, es un especialista principiante (o está a punto de convertirse en uno) y establece objetivos similares para el crecimiento profesional y profesional, está buscando las formas correctas de lograr estos objetivos: esta publicación es para usted, bueno quejarse bajo gato. Quizás también sea de interés para los líderes y gerentes de equipo, en general, para todos aquellos involucrados en la capacitación y el desarrollo de especialistas.
Para comenzar, permítanme presentarme. Mi nombre es Anatoly, y si omito las publicaciones y los rangos, primero que todo soy un Desarrollador, porque en el sentido amplio de la palabra, he estado involucrado en el desarrollo, investigación y gestión de desarrolladores a lo largo de mi carrera. Mi experiencia en la industria es de más de 10 años. Es bastante diverso y se extiende desde sistemas financieros y sitios web hasta productos, algoritmos y sistemas de aprendizaje automático. Sin embargo, me parece que lo principal es que yo mismo estaba en el lugar de los lectores objetivo de este artículo y posteriormente comencé a involucrarme en varios aspectos del desarrollo de los programadores jóvenes. En este momento, un total de más de 2 docenas de desarrolladores junior y pasantes han pasado por mí. Por lo tanto, creo que tengo algo de qué hablar. Una gran cantidad de materiales sobre el tema en discusión que se pueden encontrar están dedicados a temas puramente técnicos o, por ejemplo, a seguir casi ciegamente a Scrum. (como: "si no sabe qué hacer, intente trabajar en scrum y todo saldrá lastimado" :)) Como si se tratara de las realidades y estadísticas de equipos y especialistas individuales, está lejos de todas las cosas que componen la práctica y la cultura del desarrollo de software. Por lo tanto, pensando en qué escribir, decidí que no repetiría esta información, sino que trataría de centrarme en temas sobre los que no se escribe ni se habla mucho. Vamos!
Sí, como descargo de responsabilidad , me gustaría decir que lo descrito es mi opinión personal, confirmada por la experiencia y el conocimiento teórico, que han sido probados en esta experiencia. Puede que no se corresponda con la realidad en la que te encuentras, así que déjame darte el primer consejo del artículo de inmediato: en primer lugar, en cualquier situación difícil, vale la pena analizar su diseño antes de aplicar cualquier práctica y patrón que conozcas como "si entonces ". Los detalles son muy importantes. Ahora vamos! :)
1. Especialización amplia vs estrecha
A menudo, las personas que solo quieren aprender a programar se preguntan qué tecnología elegir para estudiar y, de hecho, en qué idioma, en términos generales, "es mejor escribir código". Las personas que obtienen su primer trabajo están pensando si su tecnología actual será prometedora y demandada en un par de años y más. (algunos, no piensan en absoluto, pero a menudo esto no es bueno) " Mejor " y "más prometedor " aquí son conceptos muy subjetivos, definidos a nivel de sentimientos y posibles beneficios para una carrera profesional más avanzada. Con la suficiente rapidez, puede ser claro para los recién llegados a TI que muchos proyectos se realizan en un número suficientemente grande de tecnologías, y es imposible saberlo todo. Entonces, ¿es necesario perseguir a todas las liebres?
Por ejemplo, en mi primer año de trabajo, recibí un valioso comentario del líder de mi equipo de que es necesario centrarse en un área en particular, porque un especialista es un especialista en algo o, en términos generales, no un especialista en nada. Para saber algo a un nivel bastante alto, debe hacer esto constantemente y profundizar en los detalles: la verdad pura y es difícil discutir con eso. De hecho, la práctica confirma esto: la mayoría de los especialistas que conozco (a quienes se puede considerar como tales) son especialistas limitados. Algunos de ellos simplemente conocen brillantemente su Asunto y, por lo tanto, resuelven los problemas de inclinación sin precedentes dentro de él. En este punto, se podría decir "OK, eso significa que el principio es correcto: todo encaja", si no fuera por unos pocos, PERO. El hecho es que la gama de proyectos donde se requerirán especialistas tan limitados es mucho más limitada que, por supuesto, entre especialistas de un perfil más amplio. Más de una vez me he encontrado con proyectos en los que la participación sería simplemente imposible sin la disponibilidad de un amplio conocimiento en varias tecnologías a la vez. Las personas que poseían este conocimiento descubrieron puertas nuevas, a veces inaccesibles. Y la participación en un proyecto excelente y único es una prueba de carrera muy seria y útil que puede brindarle mucha experiencia valiosa y otros beneficios. El segundo PERO es que el mundo de la tecnología cambia constantemente y se limita estrictamente al conocimiento de una o dos tecnologías o PL, naturalmente puede comenzar a perder su ventaja competitiva y convertirse en un especialista menos buscado.
En resumen, podemos decir esto brevemente: ¡no tengas miedo de probar las tecnologías que te gustan! Es posible que no se convierta en un experto en 3 lenguajes de programación a la vez, o en 5 marcos, pero el conocimiento de sus fundamentos y estructura interna es una gran ventaja competitiva, si todo lo demás es igual, obtiene un trabajo que requiere un fuerte conocimiento de 1 tecnología y Básico varios otros. Lo principal aquí es la medida y la limitación. Es importante priorizar claramente qué tecnología pasa la mayor parte del tiempo estudiando y qué queda para aprender qué tecnología.
2. Área funcional
Desde la especialización en lenguajes de programación y tecnologías de desarrollo, pasamos sin problemas al siguiente aspecto importante: el área funcional . Es fácil dar un ejemplo de la vida: al igual que los médicos tienen dentistas, y hay cardiólogos, por lo que existe una especialización entre los desarrolladores, y esto no se trata solo de las tecnologías o los lenguajes de programación mencionados anteriormente. Los desarrolladores se especializan en diferentes formas: alguien trata con interfaces de usuario, alguien procesa datos en clústeres, alguien reconoce imágenes y alguien escribe lógica para un bot de juego. Muchos ejemplos
Tal vez en los primeros 2 años de trabajo, o incluso más, no se preocupe por el tema de la especialización, ya que ingresar a los proyectos y tecnologías en los que ingresa tomará un tiempo considerable, y este problema simplemente no será relevante de manera natural. Sin embargo, a partir de un momento determinado, sentirá la facilidad para resolver problemas cada vez más complejos en un área determinada, y el resultado se determinará de muchas maneras, no por el grado en que, por ejemplo, conozca la biblioteca estándar de ese idioma con el que usted trabaja, o qué tan magistralmente posee la sintaxis avanzada de este PL, y su experiencia en un área funcional específica. Gráficos por computadora, lingüística informática, programación financiera: todas estas son áreas específicas para el estudio y para adquirir experiencia práctica en los meses y años. Si te propones convertirte en un especialista de alto nivel, busca el área que realmente te gusta. Y si realmente te gusta, desarrolla y trabaja con placer, ¡y todo saldrá bien!
3. Mentores y autoestudio
No hay dos proyectos completamente idénticos. No hay equipos idénticos. A veces no existe una solución única y correcta, ya sea una decisión global sobre la arquitectura de una gran parte del sistema o una decisión local sobre cómo almacenar archivos en el repositorio. Un especialista novato se enfrenta a muchas preguntas y dudas. Preguntas que, debido a la falta de experiencia, pueden no responderse de inmediato. Obtuviste un código listo y no funciona en absoluto, aunque otros colegas están bien; el procedimiento de instalación del servicio en 1 caso de 6 termina con un error, y al menos se suicida, pero no está claro por qué; no puede configurar la parte de red del servicio, aunque hace todo de acuerdo con las instrucciones y ya lo vuelve a leer 7 veces. Tales situaciones para desarrolladores, probadores y administradores surgen constantemente. El grado de dificultad de los problemas puede variar desde el nivel de "probablemente necesite cavar en algún lugar" hasta "dónde cavar, no está nada claro". El primer consejo bien conocido y dado por profesionales experimentados (y probablemente ya haya escuchado de ellos) es que debe aprender a lidiar con los problemas de la manera más independiente posible cuando se quede atrapado en ellos. Como regla general, para esto es necesario concentrarse en una relación causal y aprender a formular las preguntas correctas sobre el problema. En primer lugar, para sí mismo, y en segundo lugar, para Google. No es solo "todo no funciona", incluso si está seguro de ello, intente regresar "al principio" para encontrar la verdadera causa del problema. Y, lo más probable, no eres el único con un problema similar, solo búscalo en Google y compruébalo por ti mismo. Además, el siguiente consejo simple: solo después de haber realizado varios intentos fallidos y analizar el problema usted mismo, después de haber pasado un tiempo significativo (generalmente medido en horas, a veces en días), comuníquese con colegas de alto nivel. Por lo tanto, no pasará su valioso tiempo resolviendo un problema de mierda, que usted mismo podría resolver fácilmente con mucha perseverancia. De esta manera, demostrará que ha desarrollado el enfoque correcto para resolver problemas. Muchos problemas que parecen complicados e incomprensibles a primera vista se resuelven buscando en Google en el sentido literal de 5 minutos.
Pero hablar es fácil, pero en realidad el conocimiento insuficiente de las tecnologías de desarrollo y la falta de experiencia práctica será un factor muy doloroso. Por lo tanto, la tarea correcta número 1 es el estudio de tecnologías de desarrollo y ejemplos de su uso en un modo bastante intensivo. Y de nuevo: es fácil de decir, pero de hecho hay más materiales de capacitación, no todos son comprensibles, no todos son relevantes, no todos cubren problemas que deberán resolverse en la práctica en el proyecto. Y aquí el medio ambiente puede ayudarte. Estar en un equipo de "expertos" que no solo poseen un alto nivel de conocimiento, sino que también están dispuestos a compartir hábilmente este conocimiento: esto es lo mejor que puede ser al comienzo de una carrera. Sí, es cierto, primero debes concentrarte en el autoestudio, pero de una forma u otra, tendrás un límite máximo natural para la velocidad. Los mentores competentes ayudarán a superarlo. Sin embargo, antes de recurrir a ellos, hágase la pregunta: ¿está atascado y no puede avanzar de forma independiente en la solución del problema al menos un paso?
Total: ¡busque un trabajo donde haya personas que conozcan el tema y estén interesadas en hacerlo saber mejor! Esto le permitirá aumentar significativamente el nivel de su experiencia en un tiempo bastante corto. Evite los lugares donde no está listo para compartir conocimientos. 4 años de trabajo en ese lugar serán iguales a dos (o menos) en otro.
4. No hay bala de plata
El trabajo en la industria de TI es un diálogo constante, un debate, a veces una lucha de opiniones y, a veces, una guerra de principios. Créeme, conocerás a muchas personas que te convencerán de que ellos y solo ellos tienen la decisión u opinión más correcta, lo respaldan o no con hechos. ¡A veces este sentimiento también te hará explotar!
¿Es posible o imposible completar la tarea a tiempo? ¿Qué es mejor: tecnología A o tecnología B para la tarea C? ¿Según qué metodología vale la pena desarrollar un proyecto y organizar el proceso de trabajo? ¿Es el código escrito lo suficientemente bueno y es hora de dejar de pulirlo, o aún necesita ser refactorizado? ¿Aprovecha la oportunidad de expandir el sistema desde el principio, incluso si no se espera la expansión, y no ve la imagen completa de su nivel de desarrollador junior? ¿Cómo evaluar la calidad del producto y qué papel tienen los desarrolladores en este proceso? Y una docena o dos preguntas similares diferentes.
A menudo, es imposible dar una solución inequívoca a estas y muchas otras preguntas en una situación específica. Me gustaría tenerlo, pero a veces simplemente no es visible objetivamente, porque el nivel de incertidumbre en el proyecto puede ser bastante alto. En cierto sentido, esto va en contra de una cultura tácita ampliamente aceptada en la programación: la búsqueda constante y la oferta de mejores soluciones utilizando tecnologías más avanzadas. Constantemente nos obligamos instintivamente a tomar decisiones basadas en datos incompletos.
Y aquí, la programación en su microcosmos y el desarrollo de proyectos de TI ya a gran escala dejan de ser disciplinas arbitrariamente precisas y comienzan a ser arte. El arte se basa en principios y enfoques, está determinado por ellos.
Al completar otro proyecto o una tarea menos masiva, mire hacia atrás y analice: ¿qué principios han ayudado a que esta tarea o este proyecto tengan éxito (o viceversa - zafeylyat)? ¿Era la cuestión de qué lenguaje de programación se eligió y cómo funcionó maravillosamente, o tal vez el nivel de interacción con su cliente o socio fue tan bueno que pudo lidiar con la tarea la mayor parte del tiempo sin perder tiempo? costos de comunicación? Analice constantemente, busque nuevos principios y consulte con los mentores cómo ver y definir estos principios.
5. Sobre grandes y pequeñas empresas, sobre TI y no sobre TI
Muchos profesionales jóvenes quieren trabajar para empresas de las que han oído hablar y cuyos productos o productos usaron. En algunos Apple, Google o Microsoft (recientemente ha aparecido un buen término: "Guyandbuk") o sus homólogos rusos (tanto como sea posible). Comenzar una carrera en una gran empresa es una experiencia muy, muy valiosa. (Comprende esto especialmente en el 11º año de esta experiencia :)) Para ver cómo funciona una gran empresa desde adentro y cómo se organizan los procesos en ella, créame, vale la pena. Probablemente, es difícil para mí imaginar algo mejor que un conjunto de una gran empresa de TI y un equipo inteligente al comienzo de mi carrera. Sin embargo, siempre hay PERO.
La primera PERO es que una "gran empresa de TI" es bastante diferente de una "gran empresa" (especialmente en las realidades rusas). Si tiene una opción, vaya a una compañía de TI pequeña o mediana o vaya a una compañía grande que no sea de TI (por ejemplo, un banco u otra compañía financiera o comercial), debe comprender las posibles consecuencias. Y las consecuencias en el peor de los casos serán las siguientes: si la compañía de TI cierra o si desea dejarlo, se va con conocimiento y principios. Si no quiere pasar de una compañía de TI a una compañía de TI, entonces, por varias razones, esto lo hará más difícil. Esto puede ser la falta de la experiencia necesaria y relevante, y la especificidad de los proyectos y la selectividad de los reclutadores y colegas contratantes para sus lugares de trabajo anteriores (recuerde la compañía Pearson Hardman de la famosa serie que contrató solo a Harvard. Tales historias no son infrecuentes y en realidad. Solo contratamos de empresas alimentarias ", etc.). En las empresas donde la TI no es el principal tipo de negocio, todo gira literalmente en torno a este negocio. El resultado es muy importante, el proceso para lograrlo es mucho menos importante. Pero es el proceso correcto que establece los principios correctos, que luego lo ayudan a tomar decisiones y producir algo de muy alta calidad y complejo en el resultado de proyectos bastante complicados. Si produce algo de alta calidad y útil, este es su objetivo, considere esto.
6. Empresas de alimentación y outsourcing.
Uno de mis temas favoritos, ya que trabajé en el primero y segundo. Continuando con el tema de la delicadeza, existe una cierta opinión en la industria de que trabajar en empresas de TI de alimentos no solo es más prestigioso, sino también financiero, y esto también viene con un conjunto de los proyectos más interesantes que puede encontrar. El trabajo de outsourcing en proyectos a pedido, según algunos expertos, es una clase baja. ¿Es esto cierto o no?
Contestaré: No. No es tan simple
La principal ventaja de las compañías de alimentos es que una persona que viene allí tiene la oportunidad de elegir un proyecto / producto o campo de actividad, con todas las consecuencias que se derivan de esto (por ejemplo, la capacidad de trabajar en tareas verdaderamente únicas y complejas). Una de las principales consecuencias: desarrollará SU producto, haciéndolo mejor cada día. No siempre irá de la manera que desee, pero este es su producto. Influyes mucho en su éxito, al menos a tu nivel.
En las empresas de outsourcing, por regla general, un empleado no tiene esa opción, y además, periódicamente se ve obligado a sentarse en agujas debido a esto. Los integradores y subcontratistas participan en aquellos proyectos por los cuales pagan dinero aquí y ahora. No todos estos proyectos serán interesantes para una determinada clase de programadores. Para un empleado de una empresa de outsourcing, siempre existe el riesgo de estar en un proyecto absolutamente desinteresado y estancado, y, a menudo, la única forma de cambiar el proyecto es abandonar la empresa.
— legacy ( ), . — . 5 . , , , .
7. vs
. : . , . , , . , – . , ( ) , . , , , . , . , , () () . . ? – . – . , , 2 : ) ) ( ). : , . , . , , , , , . – .
: - ( - ) , - . - , ( — , ) – .
8.
. , , - . - , . , , , . . . , . , . — . .
— , , , , . , , , , ( ), : , — , , .
? , ? .
, ? : , , , , , , , .
9.
(, ) , backend . (, Web , ). - . , ? , . , . , — . — . , . : , , . . , . , , . . , : , , UX/UI — , , , , .
10.
: . . - : , .
, , . : 1.5-2 . , , , , . . , 1-2 , - . — 4 , ? : , B. , . , , . , . , , — , , . , , , , .
: 1-3 , , . : skills 3 — 1. , — 2. — 3. , , , , 4 , , .
Conclusión
— , , . , . , , — . . , , ! , : ) hard skills ) c ) . , !
PD: El autor estará encantado de criticar y comentar sobre el artículo en los comentarios y HP. Especialmente si le gustó el artículo y su tema, escriba sobre los temas relacionados que le gustaría leer en los siguientes artículos.