Devo continuar minha prática de codificação autodidata ou aprender a codificar profissionalmente? [fechadas]

Ultimamente, tenho conseguido trabalho profissional, saindo com outros programadores e fazendo amigos na indústria. A única coisa é que sou 100% autodidata. Isso fez com que meu estilo se desviasse extremamente do estilo daqueles que foram treinados adequadamente. São as técnicas e a organização do meu código que são diferentes.

É uma mistura de várias coisas que faço. Eu costumo misturar vários paradigmas de programação. Como Funcional e OO. Eu me inclino mais para o lado funcional do que OO, mas vejo o uso de OO quando algo faria mais sentido como uma entidade abstrata. Como um objeto de jogo. Em seguida, eu também seguirei o caminho simples ao fazer algo. Por outro lado, às vezes parece que o código que vejo dos programadores profissionais é complicado por causa disso! Eu uso muitos fechamentos. E, por fim, não sou o melhor comentarista. Acho mais fácil ler meu código do que ler o comentário. E na maioria dos casos, acabo lendo o código, mesmo que haja comentários. Além disso, me disseram que, por causa da simplicidade de escrever meu código, é muito fácil lê-lo.

Eu ouço programadores treinados profissionalmente falando sobre coisas como testes de unidade. Algo que nunca usei antes, por isso nem tenho a menor idéia do que são ou como funcionam. Muitos e sublinhados "_", que não são realmente o meu gosto. A maioria das técnicas que uso são diretamente de mim ou de alguns livros que li. Não sei nada sobre o MVC, já ouvi falar muito sobre isso, com coisas como o backbone.js. Eu acho que é uma maneira de organizar um aplicativo. Isso apenas me confunde, porque agora eu já criei minhas próprias estruturas organizacionais.

É um pouco de dor. Não consigo usar aplicativos de modelo quando aprendo algo novo como o Quickly do Ubuntu. Tenho dificuldade em entender o código que posso dizer que é de alguém treinado. A programação completa de OO realmente deixa um gosto ruim na minha boca, mas isso parece ser o que TODOS OS outros estão usando estritamente.

Isso não me deixa tão confiante na aparência do meu código, nem me pergunto se causarei faíscas ao ingressar em uma empresa ou talvez contribuindo para projetos de código aberto. Na verdade, eu tenho um pouco de medo do fato de que as pessoas acabarão verificando meu código. Isso é algo normal que qualquer programador passa ou devo realmente procurar mudar minhas técnicas?

Na verdade, eu tenho um pouco de medo do fato de que as pessoas acabarão verificando meu código.

Boa. Estar consciente de que as pessoas vão olhar para o seu código fará com que você se esforce mais.

A programação se tornou um campo incrivelmente grande. Existem dezenas de tópicos, ferramentas, nichos e especializações, algumas das quais são carreiras inteiras. Existe uma grande quantidade de aprendizado e conhecimento e, quando você trabalha com outros programadores, sempre haverá coisas que você sabe que não sabem e coisas que sabem que você não conhece. Isto é uma coisa boa.

Se você está preocupado com o fato de sua experiência estar incompleta, existem várias etapas que você pode seguir para corrigi-lo por meio de educação formal e colaboração com especialistas treinados. Mas parece que você tem medo de que haja um marco quantificável após o qual as pessoas digam "Ok, agora que eu já dominei isso, sou oficialmente um programador". Não existe esse marco. Definitivamente, tive momentos em que pensei "sim, agora estou chegando a algum lugar" depois de aprender algo novo, mas não há uma lista mágica de coisas que você deve saber e fazer para se chamar um programador.

Conheço muitas coisas sobre programação, usei uma dúzia de linguagens em muitos projetos, e ainda assim o subconjunto de conhecimentos de programação que posso chamar de meu é pequeno. E eu gosto disso. Francamente, um programador não é algo que você é. Um programador é algo que você está constantemente aprendendo a ser.

Faça um inventário honesto de suas habilidades, pontos fortes e fracos. Obtenha feedback de pessoas com mais experiência que você. Procure posições que se alinham muito bem com o que você pensa que está - mas não tenha medo de procurar empregos que estão um pouco fora do seu domínio atual. Se você aceita apenas trabalhos que já conhece, nunca aprenderá no trabalho.

Quando você começa a desenvolver aplicativos em cooperação com outros desenvolvedores, alguns desses pontos fracos de estilo pessoal atrapalham.

Se você começar a trabalhar em uma loja que usa sublinhados, você usará sublinhados. Todos, independentemente de seus antecedentes anteriores, seguem o padrão da loja para o estilo de codificação.

A menos que seu estilo de codificação seja extremamente óbvio, é melhor você se acostumar a escrever comentários claros e concisos, explicando como o código funciona, para que outros desenvolvedores possam segui-lo.

Se você não sabe nada sobre testes de unidade, compre um bom livro. Existem muitos bons livros sobre testes de unidade por aí. O mesmo com o MVC.

Os desenvolvedores de software profissionais sabem como jogar bem com os outros, sem jogar lixo na areia. Os melhores sabem ler e escrever código, independentemente do estilo.

A programação tem um componente de arte e um componente de disciplina. O componente de arte está em pensar nas melhores abordagens e implementá-las; a disciplina consiste em garantir que você fez corretamente e que outras pessoas possam entender seu código e aprimorá-lo quando necessário.

O componente artístico é divertido: você faz porque gosta. Naturalmente, essa é a parte que você ensina a si mesmo primeiro.

O componente da disciplina é mais um incômodo: você faz isso por necessidade. Porém, é um componente vital do trabalho em equipe: você não pode deixar de fazê-lo, pelo menos até certo ponto. Uma vez que seu código é integrado ao de seus colegas de equipe, sua flexibilidade para "mudar as coisas à vontade" dá um mergulho no nariz. No entanto, você precisa alterar o seu código com confiança, em resposta às mudanças de requisitos ou para solucionar bugs. É aqui que entram vários testes "chatos": com muitos testes, é fácil verificar se sua última alteração quebra as coisas ou não.

O estilo do código também ganha importância, porque a adesão a um estilo comum facilita a leitura do código para todos. Em empresas maiores, você encontra trabalhos noturnos que testam a conformidade com os padrões de codificação automaticamente e envia por e-mail avisos desagradáveis ​​quando se desvia.

Voltando à sua pergunta, concentrar-se no componente de arte é um estágio inicial natural do desenvolvimento do programador. Pode levar vários anos de trabalho no setor antes de você começar a apreciar o componente da disciplina. Você não precisa procurar ativamente "mudar suas técnicas": elas se transformarão naturalmente no processo de trabalho em equipe.

Para sua pergunta, sim, você deve sempre procurar mudar sua técnica, abraçar o projeto único e a tecnologia emergente.

O argumento de @ assfallows de "Francamente, um programador não é algo que você é. Um programador é algo que você está constantemente aprendendo a ser". é realmente o ser tudo e terminar toda a codificação.

É ótimo que você esteja percebendo áreas em que você faz algo diferente dos outros, especialmente quando vê que é um padrão. Você viu testes de unidade e MVC - e agora seu próximo passo deve ser aprender sobre eles. Veja como eles funcionam, o que você precisa para implementá-los e tente entender quando é um bom design para implementá-los.

Este é um campo em constante evolução, com novos idiomas e padrões subindo e descendo. Se você estiver familiarizado com o aspecto da codificação, comece a examinar a parte do design. Aprenda o que os torna bons e quando usá-los.

Certamente, ingressar em uma equipe é um grande benefício - você sempre precisa de outros olhos para examinar seu código para identificar áreas nas quais você se apressou ou não pensou em todas as implicações.

Você não precisa ser um comentarista maior. Mas você deve ser um bom colaborador (sim, comece a usar algum tipo de VCS - eu recomendo o Git).

Estilo é algo que SEMPRE evolui. Não se preocupe com isso. Você aprenderá o que é um código reutilizável e o que não é. Mas você precisa praticar e obter ajuda para isso.

Tente ajudar em algum projeto de código aberto no Github. Algumas pessoas são muito legais lá e tentam ajudá-lo. Esta é a melhor dica que posso dar a você.

Na verdade, eu tenho um pouco de medo do fato de que as pessoas acabarão verificando meu código. Isso é algo normal que qualquer programador passa ou devo realmente procurar mudar minhas técnicas?

Como você saberia o que mudar sem o feedback de programadores mais experientes?

Ter outras pessoas revisando seu trabalho pode ser assustador, especialmente nas primeiras vezes, mas é a melhor maneira de obter as críticas construtivas de que você precisa para melhorar suas habilidades. Existe um site SE para revisões de código que você pode achar útil. Pedir aos amigos inteligentes que olhem para o seu código é outra boa maneira de obter algum feedback.

O mais importante é desenvolver flexibilidade. Quanto mais familiarizado com os conceitos fundamentais, mais responsivo você pode ser em qualquer linguagem, abordagem de programação, estilo ou ambiente.

Domínio é menos sobre aprender tudo / há / aprender, e mais sobre aprender / como / resolver um problema, em uma variedade de situações.

E a melhor receita para isso é prática. Você sempre deve ter um projeto; se você estiver entre shows pagos, pegue um brinquedo pessoal. Tempo livre em um fim de semana? Trabalhe no 'olá mundo' para um idioma ou plataforma que você nunca usou antes. Procure maneiras de aprender muito de uma só vez. Por exemplo, crie algo no Google App Engine e você aprenderá tudo de uma vez sobre Python, BigTable e bancos de dados orientados a colunas. Você também receberá uma boa dose de estilo "profissional" do Google.

Um bom general sabe como aplicar suas táticas aprendidas e experiência acumulada em uma variedade de terrenos. Parece que você tem algumas táticas e experiência, mas precisa encontrar algum terreno desconhecido. Essa é provavelmente a melhor maneira de verificar o que você sabe e o que precisa aprender a seguir.

E se você procura um estilo "profissional", assuma alguns projetos "profissionais". Encontre um projeto de código aberto que você goste, atribua a si mesmo uma alteração a ser feita e defina-o. Esteja preparado para revisores imbecis, mas lembre-se de que a maioria das pessoas neste campo não chegou onde está por ter habilidades sociais suaves. O objetivo é se expor ao máximo do que você deseja ser possível. E você tem que se preparar bem o suficiente para fazer isso sozinho. Nenhuma classe pode realmente ensinar você. De fato, hoje existe muita aprendizagem de classe e não há competência sólida no mundo real.

Isso não me deixa tão confiante na aparência do meu código, nem me pergunto se causarei faíscas ao ingressar em uma empresa ou talvez contribuindo para projetos de código aberto. Na verdade, eu tenho um pouco de medo do fato de que as pessoas acabarão verificando meu código. Isso é algo normal que qualquer programador passa ou devo realmente procurar mudar minhas técnicas?

Na minha opinião, não há necessidade de se preocupar com o que os outros pensam do seu código se você se concentrar em medidas objetivas da qualidade dele. É isso

• Corrigir?
• Compreensível?
• Mantida?
• Eficiente?

Como primeiro princípio, deve sempre ser seu objetivo se concentrar nas qualidades objetivas, e não nas opiniões dos outros. Focar na opinião dos outros é o caminho para a mediocridade e, como você está experimentando, a ansiedade.

A única razão para se preocupar com as opiniões dos outros é ser capaz de se integrar bem socialmente (ou em um ambiente de trabalho) a eles. Se você tem em mente o objetivo de melhorar as qualidades objetivas do seu trabalho, não há necessidade de sentir medo das reações dos outros - são apenas oportunidades para aprender ou, na pior das hipóteses, detalhes práticos para lidar com eles. .

Seja verdadeiro consigo mesmo!! Continue aprendendo e aproveitando o que você faz.

Você me lembra depois de ir para a faculdade para ser Engenheiro de Software. Se você quer ser um programador, eu diria que tome uma posição. Você precisará comentar seu código, escrever testes de unidade, entender completamente o código orientado a objetos. Mas agora você não tem motivos reais para fazê-lo. Contanto que você esteja apenas trabalhando em pequenos projetos pessoais. Onde você não precisa responder a ninguém, a não ser a si mesmo. Você não crescerá mais como desenvolvedor.

Admitindo grandes projetos nos quais muitas pessoas estão trabalhando e tendo que responder a perguntas da gerência como "Esta versão é livre de erros? Porque vamos lançá-la para o cliente". Você crescerá como programador / engenheiro. Você receberá algumas pancadas fortes. Você pode achar as coisas que você mencionou mais valiosas e pode encontrar coisas novas que ninguém tem antes. Você vai crescer.

Até minha faculdade falhou em me ensinar essas coisas, mesmo que tentassem.

Para Teste de Unidade, procure Desenvolvimento Orientado a Teste.

Para Comentários, pense no código que você escreveu depois que você se foi. E o tempo que outras pessoas gastam em engenharia reversa.

Para idiomas orientados a objetos. Entenda pelo menos. É uma ferramenta que você pode usar para resolver problemas de uma maneira mais legível.

Boa sorte: D

Em suma, a melhor maneira de aprender é geralmente para sair com alguém que você pode aprender a partir . Se você acha que suas habilidades não são adequadas, sair com pessoas melhores que você é o melhor que você pode fazer. Certamente muito melhor do que se retirar e se isolar ainda mais.

No entanto, acho que você está pintando uma imagem muito simplificada e enganosa. Longe de todos os programadores "ensinados profissionalmente" são realmente bons. Só porque eles fazem algo não significa necessariamente que é a coisa certa a fazer.

E muito (mas não todos) que você está dizendo realmente soa como você é o único que poderia ensinar -lhes um truque ou dois.

Eu me inclino mais para o lado funcional do que OO, mas vejo o uso de OO quando algo faria mais sentido como uma entidade abstrata.

Isso parece ótimo para mim. Os melhores codificadores são aqueles que usam a ferramenta certa para o trabalho. Eu sempre escolhia alguém que conhece os dois paradigmas e usa cada um deles onde faz sentido sobre alguém que religiosamente usa apenas um paradigma.

Em seguida, eu também seguirei o caminho simples ao fazer algo. Por outro lado, às vezes parece que o código que vejo dos programadores profissionais é complicado por causa disso!

Mais uma vez, a simplicidade é boa . Não faça seu código complexo até que ele precise ser complexo. Algumas pessoas não tendem a fazer coisas complexas de uma idéia equivocada de elegância, ou porque "vamos precisar dessa funcionalidade adicional mais tarde". Geralmente, é melhor fazer a coisa mais simples que resolve o seu problema.

Eu uso muitos fechamentos. Boa. É por isso que eles estão lá. Eles assustam algumas pessoas que ficaram presas nos anos 90 e no modelo quase-OOP obsoleto de Java, mas na verdade esse é o problema deles.

E, por fim, não sou o melhor comentarista.

O que deve ser comentado e como é altamente subjetivo. Não existe um "certo" ou "errado" real, mas ao trabalhar em uma equipe, é importante escrever um código que toda a equipe, e não apenas o autor do código, possa entender. E, às vezes, é preciso fazer compromissos para se adaptar ao estilo de codificação da equipe. Isso não significa necessariamente que você deve escrever mais comentários, simplesmente significa que é algo com o qual você e sua equipe terão que concordar.

Eu ouço programadores treinados profissionalmente falando sobre coisas como testes de unidade. Algo que nunca usei antes, por isso nem tenho a menor idéia do que são ou como funcionam.

Bem, pergunte a eles. :) Testar seu código é essencial, e testes de unidade são uma ferramenta popular e útil para isso.

Muitos e sublinhados "_", que não são realmente o meu gosto.

Como nos comentários, isso é subjetivo e depende do idioma. Em C e C ++, lowercase_with_underscoresé uma convenção de nomenclatura bastante comum. Em muitos outros idiomas, você quase nunca verá um sublinhado. Mas no final das contas, isso realmente não é importante. Se uma função é chamada write_to_logou WriteToLognão realmente fará diferença. Alguém vai ter que aceitar e se conformar com o que a equipe concordou lá.

Não sei nada sobre o MVC, já ouvi falar muito sobre isso, com coisas como o backbone.js. Eu acho que é uma maneira de organizar um aplicativo. Isso apenas me confunde, porque agora eu já criei minhas próprias estruturas organizacionais.

Como nos testes de unidade, nunca pare de aprender. Você trabalha em conjunto com pessoas que sabem coisas que não sabem e que têm uma formação diferente da sua. Aprenda um com o outro. Há claramente coisas que você pode ensinar a elas, mas também há coisas que você não sabe, ou nunca ouviu falar, e que elas podem ensinar. Isso não significa que você (ou eles) é um programador ruim. Isso significa que um bom programador é aquele que se esforça para melhorar e aprender com os outros.

Programação OO completa realmente deixa um gosto ruim na minha boca

O mesmo aqui, e eu sou o que você chamaria de "profissionalmente treinado" (um diploma de CS). As pessoas que aprenderam programação diferem tanto quanto as que são autodidatas. Parece que você está trabalhando com alguns que realmente precisam aprender alguns truques novos.

Na verdade, eu tenho um pouco de medo do fato de que as pessoas acabarão verificando meu código. Isso é algo normal que qualquer programador passa ou devo realmente procurar mudar minhas técnicas?

Ambos. É claro que é assustador ter outras pessoas olhando (e julgando) o que você fez. Mas também é muito educativo. Eles podem lhe dizer o que teriam feito de outra maneira ou por que teriam feito de outra maneira. Eles podem ajudá-lo a melhorar e também podem aprender algo. Mostre a eles o código que resolve um problema melhor do que sua solução "preferida" teria, e espero que eles digam "ah, isso é legal. Como você sabia disso? Como você chama isso? Eu deveria usar essa técnica "

Esta não é uma resposta completa, você já tem várias respostas boas. No entanto, existem alguns pontos que, para mim, parecem um pouco confusos e não foram abordados.

É uma mistura de várias coisas que faço. Eu costumo misturar vários paradigmas de programação. Como Funcional e OO. Eu me inclino mais para o lado funcional do que OO, mas vejo o uso de OO quando algo faria mais sentido como uma entidade abstrata. Como um objeto de jogo.

Para mim, parece que você está confundindo programação declarativa versus imperativa , em vez de programação funcional versus orientada a objetos. Se você quer dizer que se inclina para a programação declarativa e para longe do imperativo, isso é uma coisa boa. Declarative procura remover efeitos colaterais, o que deve facilitar a compreensão do seu código.

As linguagens de programação modernas geralmente oferecem suporte ao modelo de programação declarativa. Por exemplo, em C #, usar o Linq resulta em um estilo declarativo, porque você não está dizendo como obter o que deseja; você está apenas dizendo o que deseja.

A programação completa de OO realmente deixa um gosto ruim na minha boca, mas isso parece ser o que TODOS OS outros estão usando estritamente.

As línguas modernas são frequentemente linguagens multiparadigma. É raro alguém usar uma linguagem "pura". Muitas linguagens funcionais suportam objetos e efeitos colaterais. Linguagens consideradas orientadas a objetos geralmente não impõem a restrição de que tudo é um objeto.

O que você quer dizer com OO completo? Eu nunca trabalhei no código OO "puro". Talvez você possa nos dar mais detalhes do que você não gosta. Uma ilustração de um projeto de código aberto pode ajudar.

As programações OO nos oferecem muitos recursos para suportar coisas como: abstração de dados, encapsulamento, sistema de mensagens, modularidade, polimorfismo e herança. Se eu olhasse para uma base de código que não se aproveitasse disso, deixaria um gosto ruim na minha boca.

Resposta curta: sim.

Ensinar a si mesmo é quase tudo de bom.
Filtre com bom senso, bons conselhos.

WRT aprendendo programação profissional, sim.
O que você tem em mente?
Conferências, seminários, certificação, um diploma?
Cada um tem um custo / benefício.
Quando o ROI for bom, se você tiver os recursos, faça-o.

Pese conselhos em graus, considerando a fonte: pessoas com / sem eles têm interesses próprios.
Fale com meia dúzia de cada.

A academia é isolada da indústria? Frequentemente.
Um diploma não vale nada? Em termos de dólares, é difícil argumentar.
Os graduados quase sempre ganham mais dinheiro, mas cuidado com os empréstimos da faculdade.

Em termos de conhecimento? Talvez.
Se você odeia a escola, não vai conseguir mais do que dedica.

Se você acha que um diploma é uma meta valiosa para você, provavelmente é.

Aprofundar e descobrir sobre o programa de estudo, os custos, o meio ambiente. Verifique se você tem interesse, comprometimento, tempo e recursos. Você provavelmente estudou durante treze anos, então o que são outros quatro? Eles serão os mais caros, e a pessoa principal com quem você confiará para torná-los mais valiosos é você.

Os custos podem ser bastante assustadores, mas eles contam apenas uma parte da história, porque existem muitas subvenções e bolsas de estudo por mérito, necessidade e centenas de outras razões.

Se você for, escolha profissionais e botões inteligentes.

Segunda pergunta - Posso usar meu próprio estilo?

Você tem duas perguntas.

O primeiro está no seu título. Por favor, veja minha resposta anterior.

O segundo é detalhado em cerca de cinco parágrafos, onde você caracteriza como seu estilo difere do estilo profissional com os pontos listados abaixo:

• 100% autodidata.
• Diferente em técnica e organização.
• Mistura de funcional e orientada a objetos.
• Menos complicado.
• Muitos fechamentos.
• Poucos comentários.
• Sem testes de unidade.
• Poucos sublinhados.
• Sem MVC.
• Sem backbone.js.
• Nenhum aplicativo de modelo.

Resumindo, acho que você está perguntando se está bem que você use a abordagem de Frank Sinatra - "Eu fiz do meu jeito". Sinto ambivalência quando você chama o profissional de código de outras pessoas, mas você não está envolvido com isso. O estilo é uma questão pessoal complicada, e o debate sobre o que é um bom código é interminável e muitas vezes uma perda de tempo. Alguns problemas podem ser mais fáceis se o seu grupo usar uma convenção de codificação por escrito. Por favor verifique:

http://en.wikipedia.org/wiki/Coding_conventions

Existe uma etiqueta para matar o código de outra pessoa, e isso é outra coisa em que você deve trabalhar com sua equipe. Coloque sua pele grossa e espere que não sejam muito brutais, mas faça o que fizer, não entre em guerra.

Você comentou sobre a ansiedade de outras pessoas verem seu código. Prepare-se porque eles não apenas o verão, mas também o reescreverão e informarão o que há de errado com seu estilo. Seus colegas de trabalho podem ser flexíveis ou rígidos. De qualquer forma, eu recomendo que você não reescreva o código para estilo ou faça de cada ponto de estilo uma negociação.

As razões para ter código uniforme (e treinamento uniforme) são aumentar a velocidade e a produtividade do desenvolvimento e, de alguma forma, institucionalizar o aprendizado das melhores práticas. Problemas como camelCase ou use_underbars podem parecer triviais e mesquinhos, mas há benefícios na consistência.

Esteja aberto a testes de unidade e desenvolvimento orientado a testes. Quando você está sozinho, não faz parte de projetos remunerados, é mais um hobby. Suas coisas não precisam se encaixar no que as outras pessoas estão fazendo. Se o seu código falhar, não é grande coisa. Mas quando você está envolvido com uma equipe, o código que você escreve pode afetar toda a equipe, principalmente se chegar aos clientes.

Da mesma forma, se sua equipe usa MVC, por favor, aprenda sobre isso, espero que das mesmas fontes que eles fazem referência. Métodos de estruturação de programas podem fazer uma enorme diferença, como demonstrado pelo experimento. Novamente, tome o exemplo e a liderança de sua equipe.

Se sua equipe usa o backbone.js, você também o usa. Sua equipe é como patos voando em formação. O alinhamento ajuda-os a gastar menos energia, torna-os mais seguros e ajuda-os a chegar aonde estão indo com mais eficiência. A analogia é quebrada se você insistir muito, mas há grandes vantagens em usar ferramentas, técnicas e alinhamento comuns por trás das decisões da equipe.

O conselho dado é bastante útil, mas tento lembrar que meu principal objetivo é criar 'software funcional' que seja útil para meus usuários. Meu público-alvo geralmente NÃO é um grupo de programadores - eles são pessoas de negócios dispostas a pagar por uma solução automatizada (os usuários não se importam com as metodologias, estruturas, testes de unidade, comentários de código, etc. desligou.)

Encontrei os ideais do Manifesto Ágil úteis em minha carreira (www.agilemanifesto.org)

• Indivíduos e interações sobre processos e ferramentas
• Software que trabalha sobre uma documentação completa
• Colaboração do cliente sobre negociação de contrato
• Respondendo a mudanças após seguir um plano

Eu me relaciono completamente com essa pergunta. Tenho exatamente os mesmos sentimentos e um fundo muito semelhante (mas não exatamente o mesmo). Eu deveria ser treinado profissionalmente (ou melhor, academicamente), então eu deveria saber sobre programação OO, etc. A programação não era o meu principal tópico, mas eu o fiz. Eu aprendi OO em alguns dos meus cursos e não entendi o motivo de sucesso. De fato, a única vez que entendi OO foi quando fiz um trabalho comercial e fui coagido por dois grandes mentores.

Tenho certeza de que meu professor foi igualmente brilhante, mas você vê o benefício real na prática em um ambiente comercial versus programação funcional, mas não tem a chance de vê-lo em um curso projetado para executar, ensinar e terminar dentro de alguns meses . Não tive a chance de trabalhar na estrutura baseada em MVC, mas tenho certeza de que será a mesma coisa, ou seja, eu seria capaz de entender os conceitos de um livro, mas entenderei seu benefício quando o usar em um ambiente comercial. E eu concordo totalmente com você, por que usar OO e MVC e qualquer outra estrutura complexa se você pode resolver um problema de uma maneira mais simples. Meu conselho é não ter vergonha de trabalhar, porque isso o exporá a uma situação diferente e permitirá que você entenda as mesmas coisas sob uma luz diferente.

Claro que aprendi sintaxe e conceitos na minha formação acadêmica, mas é no mundo comercial que comecei a aprender a programar.