Posted on Sep 23 • Originally published at egolesscrafting.org A catarse intelectual e afetiva consiste em livrar-se dos preconceitos e opiniões. Em 2009, o Software Craftsmanship Manifesto foi publicado como uma extensão do Manifesto Ágil , para corrigir o desvio de parte do movimento Ágil em reconhecer a importância da excelência técnica.Conheça seus príncipios!Nenhuma prática é perfeita e você tem que aceitar que alguém possa criticar as práticas que você usa. A crítica à sua prática não é uma crítica a si mesmo. Tenha em mente que as práticas evoluem, adaptam-se e eventualmente tornam-se obsoletas quando as suas limitações impedem a resposta aos desafios tecnológicos em constante mudança.Só porque você aplicou com sucesso uma prática em uma experiência anterior, não significa que ela funcionará em todos os casos: o contexto é importante. Cada contexto é diferente, os parâmetros que garantiram este sucesso anterior podem não existir em todas as situações.Na maioria das vezes, esquecemos que as Pessoas são importantes no contexto e essa é a variável mais importante que você precisa considerar. Você deve identificar as dores contra as quais as pessoas estão lutando. Só então você poderá sugerir uma prática de acordo com seus benefícios em relação a essas dores. Você deve aceitar e reconhecer que cada equipe evolui em seu próprio ritmo, equilibrando obstáculos operacionais e curvas de aprendizado.O que salvou você pode não funcionar para os outros, então não force. Considere o fato de que você pode estar fazendo isso apenas para se convencer de que fez a escolha certa naquele momento.Quando você é solicitado a revisar uma solução,** é tentador tentar moldá-la de acordo com sua preferência.** Sempre existem várias soluções para o mesmo problema. Não deixe que suas preferências pessoais tragam entropia improdutiva às discussões.Durante uma revisão, sempre que outra implementação vier à mente, tente se perguntar se ambas as soluções apresentam os mesmos benefícios. Caso contrário, comece por melhorar a primeira solução na sua lógica antes de propor uma implementação alternativa, sem esquecer de considerar as possíveis desvantagens.Repita o procedimento acima, substituindo “implementação” por “decisão” e “prática”.Software bem elaborado é um valor apresentado no Manifesto de Artesanato de Software. Infelizmente, alguns aspirantes a artesãos de software parecem se importar apenas com o código. Isto se deve em parte ao fato de que as práticas mais populares na caixa de ferramentas de elaboração são centradas no código – por exemplo, Código Limpo, Desenvolvimento Orientado a Testes ou Katas.No entanto, código não é software. Ao escrever código, você apenas faz suposições sobre o que os usuários realmente precisam. Essas hipóteses são validadas (ou não) quando os usuários interagem com seu ambiente de produção: então a produção importa. A entrega frequente à produção é a única maneira de agregar valor de forma constante. Adotar uma prática como o Desenvolvimento Orientado a Testes terá um impacto muito limitado na qualidade do seu produto, se você receber feedback sobre o que está construindo apenas uma ou duas vezes por ano.**Não somos pagos para criar software apenas por diversão. Nosso know-how técnico deve servir o negócio.** Portanto, construir parcerias produtivas com nossos especialistas em domínio é necessário para melhor atender às necessidades de nossos usuários: O Domínio Empresarial é importante .“Não é o conhecimento das partes interessadas, mas a ignorância dos desenvolvedores que é implantada na produção”. Alberto BrandoliniExiste uma falsa crença comum que afirma que os desenvolvedores produzem software, o que leva a uma espécie de Síndrome do Herói. Conforme afirmado acima, as habilidades de desenvolvimento não são suficientes para construir software. É a sua organização multidisciplinar que produz software.A influência da estrutura organizacional na qualidade do software: um estudo de caso empírico (Nagappan, Murphy, Basili - 2008) demonstrou que a qualidade da estrutura organizacional era um melhor preditor de propensão a falhas do que as métricas tradicionais - como cobertura de código, complexidade de código ou Code Churn – no caso do Windows Vista.Não importa quão habilidoso você seja, a comunicação e a colaboração sempre terão um impacto maior no sistema projetado e você não pode projetar um sistema sozinho. Seja curioso e preste atenção e respeito aos demais atores envolvidos na construção do software: Design e Organização importam.Pode ser muito tentador ficar entre artesãos para evitar o trabalho de convencer. No entanto, esta filosofia gera uma auto-segregação e prende os artesãos numa bolha deletéria de meios que nunca são desafiados.A caixa de ferramentas de elaboração rapidamente se tornará obsoleta sem ser questionada por visões externas e sem se beneficiar da experiência complementar de toda a comunidade de profissionais de software. A sua capacidade de responder a novos desafios será bastante limitada.É também por isso que o manifesto tem como subtítulo a elevação da fasquia: o objetivo é ajudar toda a comunidade profissional. Ao ajudar, aprendemos e descobrimos contextos que fogem às nossas formas comuns e diferentes de pensar.Ao trabalhar com pessoas de fora do movimento, tenha em mente que nunca se deve vender uma prática como uma injunção de meios, mas sempre convencer pelos benefícios que esta prática traz. Em outras palavras, se você “vender” o Domain-Driven Design explicando que é o melhor método no mercado para modelar um domínio de negócios, então você o está “vendendo” mal.As pessoas tentam fazer o seu melhor em contextos onde são pressionadas a chegar a um acordo pelas autoridades locais. Portanto, não julgue as deficiências do que foi feito. Identifique as reais dores dessas pessoas e veja como você pode ajudá-las. No entanto, lembre-se de que você deve fornecer ajuda, nunca infligir ajuda .Só porque você reproduz as práticas, ferramentas e processos de outra pessoa não significa que alcançará o mesmo sucesso. Como mencionado acima, o contexto é importante. Essa pessoa “outra pessoa” pode ter meios, restrições ou facilitadores que você não tem.Cuidado, sua atividade não é igual à das grandes empresas de TI. S*ó porque o Google usa o Kubernetes não significa que você precisa do Kubernetes* e que ele atenderá às suas necessidades.Sempre analise o espaço do problema e defina suas necessidades antes de pensar em uma solução. Não deixe que o hype e as figuras de autoridade lhe ditem o que fazer.Ter mais experiência ou ser coach não faz de você um desenvolvedor melhor do que as pessoas que você ajuda. Você aprenderá coisas com seus pupilos, e eles podem até ser melhores do que você em alguns aspectos. E tudo bem: ninguém espera que você seja o melhor em tudo. Você deve permitir que os outros expressem seu potencial e ajudá-los a fazê-lo.Não use sua autoridade para impor sua opinião. Software Craftsmanship é uma comunidade de realizadores. Não construa para si uma torre de marfim da qual lançará seu conhecimento “acima do solo” em relação à realidade da área. Da mesma forma, tome cuidado com os pregadores em sua própria torre. Lidere pelo exemplo e pela ação, organize sessões de programação em pares ou mob com pessoas onde você interage durante a construção do software.Respeite e trate os outros como iguais seja qual for o seu nível para que a transmissão do conhecimento possa ser feita de acordo com uma abordagem horizontal, evite a abordagem vertical que tem a infeliz tendência de criar cultos. Ouvir e humildade são essenciais para construir uma parceria produtiva e de confiança. Desenvolvimento de software é trabalho em equipe.Software Craftsmanship é escolher a melhor ferramenta para a situação certa. A desvantagem de ferramentas poderosas é que você acaba pensando que elas são suficientes para garantir o sucesso. Ferramentas e práticas recomendadas são modelos criados para melhor atender a um caso de uso específico. Às vezes, esses modelos podem ser aplicados com sucesso a novos casos de uso para os quais não foram originalmente pensados, com algumas adaptações.Mas todos os modelos têm os seus limites: nunca serão adequados para todas as situações existentes e nem sempre serão igualmente eficazes. Não existe Bala de Prata . Além disso, os limites e eficiências de cada uma das nossas ferramentas são apenas muito mal documentados cientificamente (através de estudos rigorosos).É por isso que é preciso saber deixar espaço para a experimentação de novas ferramentas, sejam elas “aprovadas pelo Craft” ou não. Mais uma vez, é mais importante concentrar-se nos resultados das práticas implementadas do que nos meios. Esta é a única maneira de inovar .Tenha em mente que não há menção a nenhuma ferramenta como Desenvolvimento Orientado a Testes ou Kata no Manifesto de Artesanato de Software. Usá-los não fará de você um artesão, assim como não usá-los não desqualifica alguém de ser um artesão.Quando alguém é convencido pelos méritos de um movimento, facilmente se transforma em evangelista. Mas esta postura pode rapidamente tornar-se uma prisão de crença, mantendo a sua própria escalada de compromisso com o movimento ao embarcar toda uma estrutura rumo a um fracasso programado, ao mesmo tempo que cria exclusão à sua volta.No entanto, uma crença firme em algo é muitas vezes vista como um ponto forte:O dogmatismo é um veneno que trata a dúvida como uma fraqueza. Mas a dúvida é na verdade um vetor de melhoria, através do questionamento. O questionamento sempre terá um resultado positivo: seja destacando um ponto fraco de uma prática que poderia ser melhorado, seja melhorando a compreensão de quem expressa a dúvida. A dúvida é um pilar disruptivo fundamental do pensamento científico.Egoless Crafting tenta reorientar o Software Craftsmanship, não em práticas, ferramentas ou código, mas em comportamentos humanos. Devem refletir os valores do manifesto. Ou seja, a Cultura importa e é a única forma de corrigir os excessos que hoje podemos presenciar #egolesscrafting.“A cultura come a estratégia no café da manhã.” Peter DruckerOriginal > https://egolesscrafting.org/Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well Confirm For further actions, you may consider blocking this person and/or reporting abuse Tanushree Aggarwal - Sep 22 Arthur Fücher - Sep 22 Mafuzur Rahman - Sep 22 Karlgusta - Sep 22 Once suspended, urielsouza29 will not be able to comment or publish posts until their suspension is removed. Once unsuspended, urielsouza29 will be able to comment and publish posts again. Once unpublished, all posts by urielsouza29 will become hidden and only accessible to themselves. If urielsouza29 is not suspended, they can still re-publish their posts from their dashboard. Note: Once unpublished, this post will become invisible to the public and only accessible to Uriel dos Santos Souza. They can still re-publish the post if they are not suspended. Thanks for keeping DEV Community safe. Here is what you can do to flag urielsouza29: urielsouza29 consistently posts content that violates DEV Community's code of conduct because it is harassing, offensive or spammy. Unflagging urielsouza29 will restore default visibility to their posts. DEV Community — A constructive and inclusive social network for software developers. With you every step of your journey. Built on Forem — the open source software that powers DEV and other inclusive communities.Made with love and Ruby on Rails. DEV Community © 2016 - 2023. We're a place where coders share, stay up-to-date and grow their careers.