14 principios que todo CTO deve ter.

rick nos explicando os principios

Acredito que para ser um CTO, também se faz necessário ser um bom programador, com isso faço uma lista de 13 princípios que todo CTO devem ter.

1. Gestão ≠ Liderança

Felizmente, este é óbvio: gerenciamento não é o mesmo que liderança. Você é um líder porque seu povo o segue. E você é um gerente porque seu pessoal trabalha para você. Existem gerentes que não são líderes e líderes que não ocupam cargos gerenciais.

Gestão e liderança não são a mesma coisa, mas andam de mãos dadas. Portanto, como meu primeiro ponto sugere, você precisa desenvolver os dois para ter sucesso em sua nova posição.

2. You Aren’t Gonna Need It — YAGNI

É simples e autoexplicativo — mas nem todo mundo o segue. Ao adicionar código, certifique-se de que ele seja necessário imediatamente. Não deixe o código suspenso porque você acha que pode ser útil mais tarde.

Isso se aplica ao refatorar. Se você refatorar um método / classe / arquivo, não deve hesitar em remover quaisquer métodos que foram deixados pendurados. Mesmo que fossem úteis no passado — não são mais.

Pode chegar o dia em que eles serão necessários novamente e você poderá usar o repositório git para trazê-los de volta dos mortos.

3. Liderança Como Membro

“Eles não se importam com o quanto você sabe até que saibam o quanto você se importa.”

Parabéns! Você agora é um membro da sua equipe. Ou, para ser mais preciso, agora você é um líder com coração de membro.

Os princípios da liderança servil são simples, mas a maioria das pessoas em posições de liderança luta para abrir mão do poder. Seu trabalho NÃO é estar acima de seu pessoal para mandar neles, resolver os problemas técnicos por conta própria, micro gerenciá-los ou exercer comando e controle. Você não comanda, mas persuade. Você coloca sua equipe antes de você. E durante tudo isso, você age com humildade.

Você está nesta posição para ajudá-los a se tornarem melhores e a trabalhar de forma harmoniosa e produtiva. O ideal é que você se torne um multiplicador, ajudando sua equipe a atingir níveis mais elevados de produtividade.

4. Don’t Repeat Yourself — DRY

Este conceito foi formulado pela primeira vez pelo livro de Andy Hunt e Dave Thomas, The Pragmatic Programmer: From Journeyman to Master.

A ideia gira em torno de ter uma única fonte de verdade. Afinal, o que é isso?

“No projeto e na teoria de sistemas de informação, a fonte única da verdade (SSOT) é a prática de estruturar modelos de informação e esquema de dados associado de forma que cada elemento de dados seja dominado (ou editado) em apenas um lugar. … Os sistemas SSOT fornecem dados que são autênticos, relevantes e referenciáveis. ”

- Wikipedia

Manter uma única fonte de verdade ajudará a ter uma base de código mais sólida e mais autoexplicativa.

Ter código duplicado é um desperdício. Você terá que manter a mesma lógica em dois lugares, fazer os testes em dois lugares, e quando um lugar mudar, você terá que se lembrar de mudar o outro.

Na maioria das vezes, a duplicação de código vem da falta de conhecimento do sistema. Antes de codificar qualquer coisa, seja pragmático: dê uma olhada. Talvez o recurso tenha sido implementado em outro lugar. Talvez essa lógica de negócios já exista em outro lugar. Reutilizar código é sempre uma escolha inteligente.

5. Comunicação

A causa raiz da maioria dos problemas gerenciais que testemunhei em minha carreira tem sido a comunicação. Provavelmente é muito difícil se tornar um bom líder sem ser um comunicador competente primeiro. Esta é outra área em que você pode precisar trabalhar.

Sempre que você tiver a opção, escolha a comunicação face a face. Para a maioria de nós, o meio escrito não é a melhor maneira de transmitir todas as complexidades de nosso pensamento. Ao se comunicar, você gostaria de ser capaz de ler a linguagem corporal de seu (s) interlocutor (es) e reagir de acordo.

Já que estamos neste tópico, aqui vai um aviso: não insista que a comunicação flua através de você. Deixe sua equipe conversar com outras equipes, com outros gerentes ou até mesmo com seu gerente diretamente. Incentive as ideias a fluírem livremente, sem se conformar aos “canais adequados” para o bem da sua empresa.

Como gerente, você aprenderá a reconhecer informações críticas e como lidar com elas. Você deseja que esse tipo de informação seja recente. Essa é uma das razões pelas quais os 1-contra-1 são uma ferramenta muito importante que você precisa aprender a usar.

6. Keep It Simple, Stupid — KISS

Este princípio de design é um princípio de design observado pela Marinha dos Estados Unidos em 1960. Este princípio afirma que sistemas mais simples funcionarão melhor e com mais confiabilidade.

Você pode encontrar muitas semelhanças quando este princípio e reinventando a roda, que leva de volta na década de 1970. Foi usado como uma metáfora comercial e publicitária.

Aplicado ao desenvolvimento de software, significa exatamente isso — não faça engenharia excessiva. Às vezes, a solução mais inteligente é a mais fácil. Construir código eficiente e de alto desempenho com simplicidade é lindo.

Hoje em dia, um dos erros mais comuns é tentar usar as novas ferramentas apenas porque são brilhantes. Os desenvolvedores não devem estar motivados para usar as tecnologias mais recentes apenas porque são novas — mas porque são certas para o trabalho.

7.Transparência

Transparência é o principal pilar que sustenta a confiança e o companheirismo que um bom líder se esforça para construir.

Em um nível superior, queremos uma cultura empresarial que abrace a transparência. Todos nós gostaríamos de saber o quão bem nossa empresa está indo e para onde estamos indo. Um dos motivos pelos quais fundadores e gerentes às vezes relutam em ser transparentes é o medo da reação que acham que receberão por más notícias. Mas somos adultos e queremos ter o controle de nossas carreiras. Sabemos que a vida nem sempre oferece boas notícias e que o caminho para o sucesso raramente é reto. Queremos sentir que temos um capitão confiante e competente ao volante, especialmente durante uma tempestade. Além disso, aprendemos com essas falhas fazendo retrospectivas e ajustando e melhorando continuamente. Não é uma das melhores maneiras de melhorar o que estamos fazendo?

É semelhante no nível de sua equipe. Comemore suas vitórias, mas carregue os fardos juntos como uma equipe. Se você inspecionar e se adaptar rigorosamente como uma equipe, você deixará cada mini-tempestade mais forte do que antes.

Além disso, você não perde autoridade por ser transparente. No mínimo, você deseja que seu pessoal saiba que você não tem medo dos desafios que a vida lhe lança e que é capaz de permanecer firme. É assim que você ganha a confiança de sua equipe.

8. Grande design inicial

Esta abordagem de desenvolvimento de software é crucial — e muitas vezes ignorada. Antes de pular para a parte de implementação, certifique-se de que está tudo bem pensado.

“Muitas vezes, pensar nas coisas com antecedência nos salvou de sérias dores de cabeça de desenvolvimento mais tarde. … Fazer essa alteração nas especificações levou uma ou duas horas. Se tivéssemos feito essa alteração no código, isso teria adicionado semanas à programação. Eu não posso te dizer o quão fortemente eu acredito no Big Design Up Front, que os proponentes da Extreme Programming consideram anátema. Eu sempre economizei tempo e criei produtos melhores usando o BDUF e estou orgulhoso de usá-lo, não importa o que os fanáticos do XP afirmem. Eles simplesmente estão errados neste ponto e não posso ser mais claro do que isso. ”

- Joel Spolsky

Muitos desenvolvedores acham que não estão progredindo se não começarem a codificar. Isso esta errado. Ao traçar um plano específico, você está evitando a possibilidade de ter que começar do zero novamente.

Às vezes, outras pessoas precisam estar envolvidas nas falhas de um projeto. Quanto mais cedo essas conversas acontecerem, melhor para todos.

Um contra-argumento muito comum é que o custo de corrigir problemas é menor do que o tempo necessário para planejá-los. Isso certamente não é verdade. Quanto menos bugs / inconsistências o usuário enfrentar, melhor será a experiência dele. Você pode não ter outra chance de contatá-los.

9. Confie no seu pessoal

Como mencionei na seção Liderança do Servo, você não está aqui para resolver todos os problemas sozinho. Transmita sua visão, comunique a missão e confie em seu pessoal na execução.

Para que isso funcione, você precisa se comunicar bem para que sua equipe faça a coisa certa. Você também precisa desenvolver as habilidades de sua equipe para que eles façam as coisas da maneira certa.

Há outro aspecto nisso: você precisa de um ambiente onde o fracasso não seja visto como o fim de todas as coisas. A princípio, pode parecer contra-intuitivo fazer seu pessoal sentir que está seguro se falhar, mas de que outra forma você pode incentivá-lo a ser criativo e mostrar todo o seu potencial? E, se acontecerem, as falhas devem fazer parte do ciclo de feedback e dos gatilhos que fazem a roda da melhoria contínua girar.

Deixe-os falhar, mas não deixe que sejam fracassos.

10. SOLID

É o princípio de software mais conhecido. Solid é um acrônimo para:

Princípio de responsabilidade única

Sua importância não pode ser exagerada. Cada objeto, classe e método precisa ter uma única responsabilidade. Se seus objetos / classes / métodos estão fazendo muito, você terminará com o conhecido código espaguete. Aqui está um exemplo:

Este método parece inofensivo, mas está fazendo muito:

1. salvando o objeto no BE
2. cuidando da notificação da IU
3. alguma navegação

Outro efeito colateral é o teste. É mais difícil testar a funcionalidade emaranhada.

Princípio aberto-fechado

As entidades de software devem ser abertas para extensão, mas fechadas para modificação. Quer dizer, não devemos substituir métodos / classes apenas adicionando mais funcionalidades conforme precisamos.

A herança é uma boa maneira de fazer isso. Em JavaScript, isso é feito principalmente por composição.

Regra geral: se você modificar uma entidade para torná-la extensível, você falhou nesse princípio na primeira vez.

Princípio de substituição de Liskov

Este princípio diz que os objetos de uma superclasse devem ser substituíveis por objetos de suas subclasses, e o aplicativo deve funcionar como esperado.

Princípio de segregação de interface

Este princípio foi definido por Robert C. Martin durante a consultoria para a Xerox, e é óbvio.

“Os clientes não devem ser forçados a depender de interfaces que não usam.”

Robert C. Martin

O software deve ser dividido em várias partes independentes. Os efeitos colaterais devem ser reduzidos o máximo possível para garantir a independência.

Certifique-se de não forçar os objetos a implementar métodos de que nunca precisarão. Aqui está um exemplo:

Nem todos os animais podem voar, andarou nadar, portanto, esses métodos não devem fazer parte da interface ou devem ser mantidos como opcionais.

Princípio de inversão de dependência

Este princípio não pode ser exagerado o suficiente. Devemos confiar em abstrações, não em implementações concretas. O software deve ter baixo acoplamento e alta coesão.

Você não deve se preocupar com a forma como as coisas são construídas — mas sim com a forma como funcionam. Um exemplo fácil é ao usar datas em JavaScript. Você pode construir sua própria camada de abstração. Dessa forma, se você mudar o data provedor de, terá apenas um lugar para trocar e não mil.

Às vezes, construir essa camada de abstração exige algum esforço, mas compensa no longo prazo.

Como um exemplo, verifique date-io, ele cria aquela camada de abstração que permite que você o use com vários Date fornecedores de.

11. Liderando pelo exemplo

“O que você é fala tão alto que não consigo ouvir o que você está dizendo.” — Ralph Waldo Emerson

Você é a sua melhor ferramenta para influenciar sua equipe. Não é o que você diz, mas principalmente o que você faz que envia os sinais certos (ou errados) para sua equipe. Suas ações indicarão o que é mais importante. O que você mede, reconhece e recompensa será o foco de sua equipe.

Normalmente, eu resumo esses pontos pelo conceito de liderança por exemplo. As mensagens não verbais que você enviará com seu comportamento falam muito mais alto do que suas palavras. Por exemplo, se você quer que eles saibam a importância de ser pontual, você sempre tem que chegar na hora certa para as reuniões de equipe ou individuais.

12. Evite a otimização da otimização

É a prática que incentiva os desenvolvedores a realizar otimizações desnecessárias antes que seja provado que é necessário. Eu acho que se você aplicar o KISS e o YAGNI, você não deve cair nessa.

Não me interpretem mal, é bom tentar antecipar que algo ruim vai acontecer, mas antes de entrar nos detalhes da implementação, você precisa verificar se essas otimizações são realmente úteis.

Um exemplo muito fácil é o dimensionamento. Você não vai comprar 40 servidores porque acha que seu novo aplicativo será viral. O que você fará, em vez disso, é adicionar servidores conforme necessário.

A otimização prematura pode levar a atrasos em seu código e, portanto, aumenta o custo de tempo para os recursos de mercado.

Muitos conhecem a otimização prematura como a raiz de todos os males.

13. Motivação e engajamento

Em sua essência, a vida é ter experiências agradáveis. Portanto, não é surpresa que pessoas felizes sejam mais produtivas.

Você está lá para garantir que a motivação e o engajamento de sua equipe sejam de alto nível. Tome cuidado! Pode-se estar motivado, mas não engajado. Você precisa entender as diferenças e maneiras diferentes de aumentá-las quando necessário ou mantê-las em um nível apropriado.

Naturalmente, prestar atenção aos outros pontos deste artigo criaria um ambiente mais saudável para o desenvolvimento da motivação e do envolvimento. Por exemplo, ser um bom comunicador, ser acessível e responsivo e manter contato pessoal regularmente aumentará muito sua eficiência em motivar seus funcionários e criar um melhor engajamento.

Além disso, não presuma que seu pessoal é motivado pelas mesmas coisas que o motivam. Use um a um para descobrir o deles.

14. Seja você mesmo

À primeira vista, isso pode parecer óbvio e até um pouco irrelevante. Mas me escute!

Um dia você estava trabalhando com seus colegas e membros da equipe, no dia seguinte você volta ao escritório como seu gerente e espera se tornar seu líder. Nesse ponto, seria fácil cair na armadilha de criar uma nova persona e começar a bancar o chefe. Infelizmente, isso certamente falhará. Você se lembra do que mencionamos acima? Seu trabalho não é mandar nas pessoas e criar uma estrutura de comando e controle. Seu trabalho é criar um ambiente onde eles possam se tornar melhores.

14. Advoge para sua equipe

Os líderes promovem uma visão que é adotada pela equipe. E o que sua equipe está fazendo é importante.

Em um ambiente onde nenhuma equipe é uma ilha (a maioria das empresas conta com várias equipes), é importante falar sobre a missão de sua equipe e a importância dela para seus colegas e para a alta administração. Cultivar um bom relacionamento com outros gerentes, os influenciadores e os tomadores de decisão em sua empresa pode ser importante para o sucesso e a longevidade de sua visão.

Conclusão

Esses princípios não são muito complicados. Na verdade, sua simplicidade é o que os torna tão bonitos. Se você está sobrecarregado, não fique. Por enquanto, apenas tente aumentar sua consciência e tente incluí-los um de cada vez em sua rotina diária.

Ter alguns princípios básicos — mas poderosos — para seguir o ajudará a se tornar um programador melhor e a ter uma ideia mais clara de por que está fazendo as coisas.

Se você estiver aplicando a maioria deles intuitivamente, é bom ter aquele momento aha em que você vê por que está fazendo as coisas de determinada maneira.