Oi A programação é um assunto complexo e o desenvolvimento de software industrial é muito complexo. Em nosso setor de TI, não é tão raro ouvir perguntas de colegas juniores da série "Como desenvolvo?", "O que devo fazer para me tornar um profissional de alto nível e o mais rápido possível?", "O que devo fazer se não conseguir desenvolver, mas não há projetos interessantes? ”,“ o que o meio deve saber? ”. Se você tem de 0 a 3 anos de experiência em TI, é especialista em iniciantes (ou está prestes a se tornar um) e define metas semelhantes para o crescimento profissional e de carreira, está procurando as maneiras certas de atingir essas metas - este post é para você, bom reclamar sob o gato. Talvez ele também seja de interesse para líderes de equipe e gerentes, em geral, para todos os envolvidos no treinamento e desenvolvimento de especialistas.
Para começar, deixe-me me apresentar. Meu nome é Anatoly, e se eu omitir os cargos e classificações, antes de tudo, sou Desenvolvedor, porque no sentido amplo da palavra, estive envolvido no desenvolvimento, pesquisa e gerenciamento de desenvolvedores ao longo da minha carreira. Minha experiência no setor é de mais de 10 anos. É bastante diversificado e se estende de sistemas financeiros e sites a produtos, algoritmos e sistemas de aprendizado de máquina. O principal, no entanto, parece-me, é que eu mesmo estava no lugar dos leitores-alvo deste artigo e, posteriormente, comecei a me envolver em vários aspectos do desenvolvimento de jovens programadores. No momento, um total de mais de duas dúzias de desenvolvedores juniores e estagiários passaram por mim. Portanto, acredito que tenho algo para conversar. Um grande número de materiais sobre o assunto em discussão que podem ser encontrados são dedicados a tópicos puramente técnicos ou, por exemplo, a seguir quase cegamente o Scrum. (como - "se você não sabe o que fazer, tente trabalhar no scrum e tudo vai doer" :)) Como se fosse da realidade e das estatísticas de equipes e especialistas individuais, está longe de tudo o que compõe a prática e a cultura do desenvolvimento de software. Portanto, pensando no que escrever, decidi que não repetiria essa informação, mas tentaria focar em tópicos sobre os quais não há muita coisa escrita ou falada. Vamos lá!
Sim, como aviso de isenção , gostaria de dizer que a descrição é minha opinião pessoal, confirmada pela experiência e conhecimento teórico, que foram testados nessa experiência. Pode não corresponder à realidade em que você se encontra, então deixe-me dar a primeira dica do artigo imediatamente: primeiro, em qualquer situação difícil, vale a pena analisar seu design antes de aplicar quaisquer práticas e padrões conhecidos por você como "se, então ". Os detalhes são muito importantes. Agora vamos! :)
1. Especialização Broad vs Narrow
Muitas vezes, as pessoas que querem apenas aprender a programar se perguntam qual tecnologia escolher para estudar e, de fato, em que idioma, grosso modo, "é melhor escrever código". As pessoas que obtêm seu primeiro emprego estão pensando se sua tecnologia atual será promissora e demandada em alguns anos e além. (alguns - eles não acham nada, mas isso geralmente não é bom) " Melhor " e "mais promissor " aqui são conceitos muito subjetivos, definidos no nível dos sentimentos e dos possíveis benefícios para uma carreira futura. Rapidamente, pode ficar claro para os novatos em TI que muitos projetos são realizados com um número suficientemente grande de tecnologias e é impossível saber tudo. Então é necessário perseguir todas as lebres?
Por exemplo, no meu primeiro ano de trabalho, recebi um comentário valioso do líder da minha equipe de que é necessário focar em uma área específica, porque um especialista é especialista em algo ou, grosso modo, não é especialista em nada. Para saber algo em um nível bastante alto, você precisa fazer isso de maneira constante e profunda nos detalhes - pura verdade e é difícil argumentar sobre isso. De fato, a prática confirma isso: a maioria dos especialistas que conheço (que podem ser considerados como tais) são especialistas restritos. Alguns deles simplesmente conhecem brilhantemente seu Sujeito e, portanto, resolvem os problemas de inclinação sem precedentes dentro dele. Nesse ponto, pode-se dizer “OK, isso significa que o princípio está correto - tudo se encaixa”, se não por alguns, MAS. O fato é que a gama de projetos em que especialistas tão restritos serão necessários é muito mais restrita do que, é claro, entre especialistas de perfil mais amplo. Mais de uma vez conheci projetos nos quais a participação seria simplesmente impossível sem a disponibilidade de amplo conhecimento em várias tecnologias ao mesmo tempo. As pessoas que possuíam esse conhecimento descobriram portas novas, às vezes inacessíveis. E a participação em um projeto excelente e exclusivo é um teste de carreira muito sério e útil que pode lhe trazer muita experiência valiosa e outros benefícios. O segundo MAS é que o mundo da tecnologia está constantemente mudando e se restringindo estritamente ao conhecimento de uma ou duas tecnologias ou PL. Você pode naturalmente começar a perder sua vantagem competitiva e se tornar um especialista menos procurado.
Em resumo, podemos dizer o seguinte: não tenha medo de experimentar as tecnologias que você gosta! Você pode não se tornar um especialista em três linguagens de programação ao mesmo tempo ou em cinco estruturas, mas o conhecimento de seus fundamentos e estrutura interna é uma séria vantagem competitiva; se, apesar de tudo igual, você conseguir um emprego que exija um forte conhecimento de básico vários outros. A principal coisa aqui é medida e limitação. É importante priorizar claramente qual tecnologia você passa a maior parte do tempo estudando e o que resta para aprender qual tecnologia.
2. Área funcional
Da especialização em linguagens de programação e tecnologias de desenvolvimento, passamos sem problemas para a próxima coisa importante - a área funcional . É fácil dar um exemplo da vida: assim como os médicos têm dentistas e há cardiologistas, há uma especialização entre os desenvolvedores, e isso não se refere apenas às tecnologias ou linguagens de programação mencionadas acima. Os desenvolvedores são especializados de diferentes maneiras: alguém lida com interfaces de usuário, alguém processa dados em clusters, alguém reconhece imagens e alguém escreve a lógica para um bot de jogo. Muitos exemplos.
Talvez nos primeiros 2 anos de trabalho, ou mais, você não se incomode com a questão da especialização, pois a inserção dos projetos e tecnologias em que você trabalha levará um tempo considerável, e essa questão simplesmente não será relevante de maneira natural. No entanto, a partir de um certo momento, você sentirá a facilidade em resolver problemas cada vez mais complexos em uma determinada área, e o resultado será determinado de várias maneiras, não pelo grau em que detalhadamente, por exemplo, você conhece a biblioteca padrão dessa linguagem com a qual você trabalha ou com que habilidade possui a sintaxe avançada deste PL e sua experiência em uma área funcional específica. Computação gráfica, linguística de computação, programação financeira - todas essas são áreas específicas para o estudo e a obtenção de experiência prática em meses e anos. Se você definir uma meta para se tornar um especialista de alto nível, encontre a área que realmente gosta. E se você realmente gosta - desenvolva e trabalhe com prazer, e tudo vai dar certo!
3. Mentores e auto-estudo
Não há dois projetos completamente idênticos. Não há equipes idênticas. Às vezes, não existe uma solução única e correta, seja uma decisão global sobre a arquitetura de grande parte do sistema ou uma decisão local sobre como armazenar arquivos no repositório. Um especialista iniciante enfrenta muitas perguntas e dúvidas. Perguntas que, devido à falta de experiência, podem não ser respondidas imediatamente. Você tem um código pronto e não funciona, embora outros colegas estejam bem; o procedimento de instalação do serviço em 1 caso em 6 termina com um erro - e pelo menos se mata, mas não está claro por que; você não pode configurar a parte de rede do serviço, apesar de fazer tudo de acordo com as instruções e relê-lo 7 vezes. Tais situações para desenvolvedores, testadores e administradores surgem constantemente. O grau de dificuldade dos problemas pode variar do nível de "provavelmente você precisa cavar em algum lugar lá" a "onde cavar - não está nada claro". O primeiro conselho que é bem conhecido e dado por profissionais experientes (e você provavelmente já ouviu falar deles) é que você precisa aprender a lidar com os problemas da maneira mais independente possível quando ficar preso neles. Como regra, para isso, é necessário se concentrar em um relacionamento causal e aprender a formular as perguntas certas sobre o problema. Primeiro de tudo, para si mesmo e, segundo, para o Google. Não é apenas "tudo não funciona"; mesmo que você tenha certeza, tente voltar "ao início" para encontrar a causa real do problema. E, provavelmente, você não é o único com um problema semelhante, apenas pesquise no Google e veja por si mesmo. Além disso, os seguintes conselhos simples: somente depois de ter feito várias tentativas malsucedidas e analisado você mesmo o problema, tendo passado um tempo significativo (geralmente medido em horas, às vezes em dias), entre em contato com colegas seniores. Portanto, você não gastará seu tempo valioso resolvendo um problema de besteira, que você mesmo poderia resolver facilmente usando muita perseverança. Dessa forma, você demonstrará que desenvolveu a abordagem correta para resolver problemas. Muitos problemas que parecem complicados e incompreensíveis à primeira vista são resolvidos pesquisando no Google no sentido literal de 5 minutos.
Mas falar é fácil, mas, na realidade, o conhecimento insuficiente das tecnologias de desenvolvimento e a falta de experiência prática serão um fator muito doloroso. Portanto, a tarefa correta número 1 é o estudo de tecnologias de desenvolvimento e exemplos de seu uso em um modo bastante intensivo. E, novamente: é fácil dizer, mas, na verdade, existem mais materiais de treinamento em dofig, nem todos são compreensíveis, nem todos relevantes, nem todos cobrem os problemas que deverão ser resolvidos na prática no projeto. E aqui o ambiente pode ajudá-lo. Estar em uma equipe de “especialistas” que não apenas possuem um alto nível de conhecimento, mas também desejam compartilhar esse conhecimento com habilidade - é o melhor que pode ser no início de uma carreira. Sim, está certo, você deve primeiro se concentrar no auto-estudo, mas de uma forma ou de outra, você terá um limite natural de velocidade. Mentores competentes ajudarão a superá-lo. No entanto, antes de se voltar para eles, faça a si mesmo a pergunta: você certamente está preso e não pode avançar independentemente na solução do problema pelo menos um passo?
Total: procure um emprego em que haja pessoas que conheçam o assunto e que estejam interessadas em fazê-lo conhecê-lo melhor! Isso permitirá que você aumente significativamente o nível de sua experiência em um tempo bastante curto. Evite lugares onde você não está pronto para compartilhar conhecimento. 4 anos de trabalho nesse local serão iguais a dois (ou menos) em outro.
4. Não há bala de prata
O trabalho na indústria de TI é um diálogo constante, debate, às vezes uma luta de opiniões e às vezes uma guerra de princípios. Acredite, você encontrará muitas pessoas que o convencerão de que elas e somente elas têm a decisão ou opinião mais correta, apoiando ou não apoiando-a com fatos. Às vezes, esse sentimento também vai explodir você!
É possível ou impossível concluir a tarefa no prazo? Qual é o melhor: tecnologia A ou tecnologia B para a tarefa C? De acordo com qual metodologia vale a pena desenvolver um projeto e organizar o processo de trabalho? O código escrito é bom o suficiente e é hora de parar de polir ou ainda precisa ser refatorado? Você aproveita a oportunidade para expandir o sistema desde o início, mesmo que a expansão não seja esperada, e você não vê toda a imagem do seu nível de desenvolvedor júnior? Como avaliar a qualidade do produto e qual o papel dos desenvolvedores nesse processo? E uma dúzia ou duas perguntas semelhantes diferentes.
Sob o freqüente, sobre essas e muitas outras questões, é impossível dar uma solução definitiva em uma situação específica. Eu gostaria de tê-lo, mas às vezes simplesmente não é visível objetivamente, porque o nível de incerteza no projeto pode ser bastante alto. Em certo sentido, isso contraria uma cultura não dita amplamente aceita em programação: a busca constante e a oferta de melhores soluções usando tecnologias mais avançadas. Instintivamente, nos forçamos a tomar decisões com base em dados incompletos.
E aqui, a programação em seu microcosmo e o desenvolvimento de projetos de TI já em larga escala deixam de ser disciplinas arbitrariamente precisas e começam a ser arte. A arte é construída sobre princípios e abordagens, é determinada por eles.
Ao concluir outro projeto ou uma tarefa menos massiva, olhe para trás e analise: quais princípios ajudaram essa tarefa ou esse projeto a ter sucesso (ou vice-versa - zafeylyat)? Foi a questão de qual linguagem de programação foi escolhida e como ela funcionou maravilhosamente, ou talvez o nível de interação com seu cliente ou parceiro seja tão bom que você possa lidar com a tarefa na maioria das vezes sem perder tempo custos de comunicação? Analise constantemente, procure novos princípios e consulte os mentores como ver e definir esses princípios.
5. Sobre grandes e pequenas empresas, sobre TI e não sobre TI
Muitos jovens profissionais querem trabalhar para empresas que ouviram falar e cujos produtos ou produtos eles usaram. Em algumas empresas da Apple, Google ou Microsoft (recentemente apareceu um bom termo - "Guyandbuk") ou de seus colegas russos (o máximo possível). Iniciar uma carreira em uma grande empresa é uma experiência muito, muito valiosa. (Você entende isso especialmente no 11º ano dessa experiência :)) Para ver como uma grande empresa trabalha por dentro e como os processos são organizados nela - acredite, vale a pena. Provavelmente, é difícil para mim imaginar algo melhor do que um conjunto de uma grande empresa de TI e uma equipe inteligente no início da minha carreira. No entanto, sempre há MAS.
O primeiro, MAS é que uma "grande empresa de TI" é bem diferente de apenas uma "grande empresa" (especialmente nas realidades russas). Se você tiver escolha, vá a uma pequena ou média empresa de TI ou a uma grande empresa que não seja de TI (por exemplo, um banco ou outra empresa financeira ou comercial), deve entender as possíveis consequências. E as consequências, na pior das hipóteses, serão as seguintes: se a empresa de TI fechar ou você quiser sair, você sai com conhecimento e princípios. Se você deseja deixar de não uma empresa de TI para uma empresa de TI, por vários motivos, isso tornará mais difícil. Pode ser a falta da experiência necessária e relevante, a especificidade dos projetos e a escolha dos recrutadores e da contratação de colegas para seus empregos anteriores (lembre-se da empresa Pearson Hardman de uma famosa série que contratou apenas Harvard. Essas histórias não são incomuns e, na realidade. de empresas alimentícias "etc.). Nas empresas em que a TI não é o principal tipo de negócio, tudo gira literalmente em torno desse negócio. O resultado é muito importante, o processo para alcançá-lo é muito menos importante. Mas é o processo certo que estabelece os princípios corretos, que ajudam a tomar decisões e produzir algo de alta qualidade e complexo na produção de projetos bastante complicados. Se você produz algo de alta qualidade e útil - esse é seu objetivo, considere isso.
6. Empresas de alimentos e terceirização
Um dos meus tópicos favoritos, desde que trabalhei no primeiro e no segundo. Continuando o assunto de exigente, existe uma certa opinião no setor de que trabalhar em empresas de TI de alimentos não é apenas mais prestigiado, mas também financeiramente, e isso também vem com um conjunto dos projetos mais interessantes que você pode encontrar. O trabalho de terceirização de projetos sob encomenda, segundo alguns especialistas, é de classe baixa. Isso é verdade ou não?
Eu vou responder: Não. Não é tão simples.
A principal vantagem das empresas de alimentos é que uma pessoa que chega lá realmente tem a oportunidade de escolher um projeto / produto ou campo de atividade, com todas as consequências que se seguem (por exemplo, a capacidade de trabalhar em tarefas verdadeiramente únicas e complexas). Uma das principais conseqüências: você desenvolverá SEU produto, melhorando-o todos os dias. Nem sempre vai da maneira que você quiser, mas este é o seu produto. Você influencia muito o sucesso dele, pelo menos no seu nível.
Nas empresas de terceirização, como regra, um funcionário não tem essa opção e, além disso, é periodicamente forçado a sentar nas agulhas por causa disso. Integradores e terceirizados estão envolvidos nos projetos pelos quais pagam dinheiro aqui e agora. Nem todos esses projetos serão interessantes para uma certa classe de programadores. Para um funcionário de uma empresa de terceirização, sempre existe o risco de participar de um projeto absolutamente desinteressante e estagnado e, geralmente, a única maneira de mudar o projeto é sair da 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 , , .
Conclusão
— , , . , . , , — . . , , ! , : ) hard skills ) c ) . , !
PS: O autor terá prazer em criticar e comentar o artigo nos comentários e na hp. Especialmente se você gostou do artigo e do assunto, escreva sobre os tópicos relacionados que gostaria de ler nos artigos a seguir.