Conforme o tempo passa me convenço que a esmagadora maioria (possívelmente todos) dos problemas relacionados ao desenvolvimento de sistemas tem sua origem na má compreensão da linguagem.
Quando iniciei a pesquisa que resultaria no meu livro “Vire o Jogo com Spring Framework” esta se dividiu em duas frentes: bibliografia e comportamental. Na segunda vi que a maior parte das pessoas usavam em seu dia a dia os conceitos nos quais o Spring se baseia, como inversão de controle, injeção de dependências, AOP e todo o resto, porém sem ter a menor idéia da razão real pela qual o fazem e o que estes conceitos significavam de fato. Ao questionar estas pessoas a respeito do que era injeção de dependências, por exemplo, a resposta que eu obtia era sempre mais ou menos esta:
Ah, é um negócio que eu uso pra definir as propriedades dos meus beans.
Repare bem nesta resposta: eu pergunto o quê é, e não “pra que”. Talvez os desenvolvedores estejam sendo lobotomizados sem se dar conta disto. Acredito que seja decorrência do foco exagerado na produtividade ao invés da qualidade. Afinal de contas, é muito fácil ser produtivo escrevendo código ruim, mas impossível obter qualidade da mesma forma. Qualidade requer tempo para se obter o conhecimento a respeito da essência do problema, ou seja, para entender com o quê estamos lidando.
Tenho uma teoria para uma das causas deste problema: o mercado está usando o idioma errado. Chamo este idioma de industrial, e a melhor maneira de compreendê-lo é a partir do seu conceito mais popular que é o de “fábrica de software”.
O idioma industrial e sua fábrica
O vocabulário do indivíduo é formado a partir da sua experiência de vida: o que lemos, nossas conversas, ambiente em que estamos. A linguagem usada por cada um corresponde na prática à sua percepção do mundo. Quando nos deparamos com algo novo nosso primeiro instinto é o de escolher uma analogia entre aquele objeto e nossa linguagem “pessoal”. Sendo assim, nada mais natural que vejamos analogias como fábrica de software, programador pedreiro, arquiteto mestre de obras e outras sendo usadas por pessoas que não possuem vivência no processo de criação e desenvolvimento de software.
Chamo idioma industrial este conjunto de metáforas que se instalou em nosso meio que relaciona o ofício de desenvolvimento de sistemas a atividades que geram bens materiais como indústrias, construção civíl, etc. Na minha pesquisa infelizmente não encontrei uma origem histórica precisa deste idioma, porém tudo sempre leva a administradores ou investidores que possuem em comum apenas a pouca experiência na área.
A analogia em um primeiro momento para o leigo se mostra irresistível: vê-se alguns papéis, o analista de requisitos, o arquiteto, o desenvolvedor, testador, etc. A impressão criada é a de que o trabalho de um necessáriamente gera a saída para o próximo: cascata se mostra como a mais óbvia, produtiva e aplicável. O interessante é que não se pensa nas consequências desta analogia: quando pensamos em fábrica, junto a este conceito vêm a idéia de linha de montagem.
Montar componentes para gerar um produto final é um processo quase mecânico (ao menos me parece), mas que torna possível fazer um paralelo direto com o mercado atual. Na linha de montagem há um designer inicial que projeta o produto e seleciona os componentes. Logo em seguida há o operário que seleciona os componentes, os integra, testa e passa para o próximo passo, que é a entrega para o cliente. Há também o pessoal do marketing que alimenta o designer com a visão do que o mercado quer. Reparou a relação? Se não, aqui vai ela explícita: marketing > analista de requisitos, designer > arquiteto de software, operário > programador.
Como principal consequência desta metáfora ruim é que junto a esta vêm um conceito de produtividade que normalmente se manifesta em frases como a abaixo:
“A produtividade média da nossa equipe é de X horas por ponto de função usando tecnologia Y baseando-se no nosso registro histórico”
O problema é que na linha de montagem sempre se monta a mesma coisa, enquanto na fábrica de software cada caso é único. A partir do momento em que se aceita este fato fica nítido que todo planejamento baseado nestes princípios está fadado ao erro na esmagadora maioria das vezes (claro, a não ser que você esteja desenvolvendo sempre o mesmo software (o que não sei se faz sentido)). E ainda pior: é um discurso cruel com o desenvolvedor, pois dado que o objetivo de todo negócio é crescer sempre, qual seria o momento em que este atingiria sua produtividade máxima? Talvez isto explique o por quê do foco estar sendo mais no como fazer do que na definição da tarefa.
Fábrica de máquinas não pensantes
Como resultado direto em cima dos desenvolvedores, o que observo é uma ânsia pela entrega rápida, o que fica claro no foco em como fazer. Talvez por isto a busca por exemplos em grupos de discussão ao invés das definições de conceitos seja tão mais popular. E como o trabalhador novato já entra em um ambiente no qual prevalece o idioma industrial, este acaba por aceitá-lo como verdade por ser a sua experiência inicial como profissional. A partir deste momento o foco em leituras rápidas em busca de soluções imediatas se instaura e podemos até ter um profissional extremamente produtivo, mas aí eu me pergunto: será que gera qualidade?
Vêmos então uma ênfase brutal na criação de componentes, desapego ao valor por parte do trabalhador, que agora se vê alienado do seu direito de pensar. Sim, de pensar: por que a partir do momento em que métricas como a que expus acima são aplicadas, o tempo que este possuí para entender o problema é racionado. Sim: a consequência direta do idioma industrial é esta:
O idioma industrial aliena o trabalhador do seu direito de pensar
A solução
O leitor que chegou neste ponto do texto deve estar pensando que para mim o tempo de desenvolvimento de software é infinito e que prazos não devam ser levados em consideração. Nada disto! Afinal de contas, desenvolvemos software para alguém que tem uma necessidade a ser cumprida em um determinado espaço de tempo e custo. A grande questão é que ao usarmos metáforas inadequadas como a que descrevi acima acabamos por gerar estimativas erradas e, com isto, traçar um planejamento que não seja tenha a ver com a realidade do nosso ofício.
Sinceramente, não sei quais seriam as melhores metáforas a serem aplicadas ao nosso trabalho. Mas sei de alguns atributos que deveriam estar relacionados: a imaterialidade do que produzimos, sua essência intelectual e rara repetição do produto. Talvez algo relacionado a artesanato ou literatura chegasse mais perto da realidade. Deixo esta decisão a cargo do leitor.
Acredito que a solução seja começarmos a pensar de maneira mais profunda nos conceitos que usamos em nosso dia a dia. O que é de fato desenvolvimento de software? Arquitetura? Gerência? O que estas palavras e tantas outras de fato significam e como eu, e o ambiente a minha volta as compreendemos? Este pra mim é o primeiro passo fundamental pra que possamos trocar o idioma corrente.
Concluindo
Cozinho esta idéia na cabeça já faz alguns anos. O leitor assíduo deste blog talvez agora perceba que o fui preparando para este post. Muito tempo atrás eu comecei a escrever sobre o problema do determinismo linguístico. Recentemente tratei do conceito de valor para tentar justificar o quê fazemos. Logo em seguida tentei tratar da “mecanização” que nos foi imposta quando escrevi sobre os excessos da componentização. Há ainda um elo faltante nesta conclusão que seria tratar o conceito de qualidade, que ainda vou tratar em um post futuro com certeza (já estou inclusive trabalhando nisto).
Talvez o leitor tenha uma fábrica de software. Por favor, entenda que não estou a lhe agredir neste post, mas sim expondo um problema linguístico de nossa área que talvez, ao ser tratado, lhe ajude a obter um lucro maior com o seu negócio. Afinal de contas, para fazer algo bem feito, primeiro precisamos saber do que estamos falando, certo?
Um pensamento complementar que me ocorreu é que qualidade e produtividade têm muito a ver também com a habilidade dos profissionais em usar as ferramentas, frameworks e demais recursos aos quais tem acesso na execução de seus trabalhos. Tem a ver com o entendimento dessas ferramentas e seus conceitos, tempo e investimento, por parte das empresas, para que seus colaboradores desenvolvam suas habilidades na medida da cobrança da qualidade, de prazos e custos. O que eu tenho observado é uma grande cobrança e um investimento desproporcionalmente pequeno nas equipes. Recentemente eu disse a um colega que temos um novo paradigma de programação: a programação orientada ao Google. Como não há tempo de desenvolver capacidades e entender conceitos, assim que uma coisa não sai da forma que se imagina, faz-se uma breve pesquisa no Google em busca de uma solução para o problema. A análise critica da possível solução na maioria das vezes nem existe, já que o profissional não tem o conhecimento para isso. Espera-se que aquela resposta encontrada no StackOverflow funcione e não dê dores de cabeça mais adiante. Eu acho essa realidade muito triste mas é o que tenho observado comumente em fábricas de software.
Oi Matheus, exato: por que isto, porque o profissional se sente pressionado a encontrar a solução antes de sequer entender o problema.
Eu sinceramente acredito que a causa raíz é o uso destas metáforas ruins que só nublam o nosso conhecimento sobre o assunto.
Num rola aquele paralelo do livro Hackers and Painters? E, no fim das contas, temos mesmo que fazer paralelos entre as nossas metáforas (de produção, criação, nada a ver com a linguagem para comunicação com o cliente) e metáforas de outros contextos quaisquer?
Aquela metáfora é muito interessante: fico pensando em como transportá-la para o mundo comercial.
O mercado está sempre pronto pra receber produtos de qualidade.
Eu vejo isso no insucesso das linguagens e tecnologias ditas “da moda” e boto no bolo: python, ruby, node.js etc… Que acho que deveriam estar substituindo as linguagens dominantes java, asp.net etc… Mas nao é isso que acontece vemos um monte de projetos inovadores usando essas tecnologias mas a maioria dos desdenvolvedores continuam usando os padroes… Nunca entendia por que … imprudentemente acabei tomando odio dessas linguagens padroes… Trabalho como freelancer e sempre estou mexendo com algo novo, um dia python, no outro ruby, algums projetos com node.js e ate addons de jogos em lua, por isso nao entendia por que o pessoal gosta tantto de java uma limguagem que um hello word correto precisa de 15linhas (kkkk)…
Descobri que era por causa da fabrica de software… Java é tao ingessado que vc pode colocar alguem que nao sabe nenhum padrao de desenvolvimento do lado de um programador e em duas semanas os dois terao a mesma produtividade… Por que nao da para fazer de forma “facil” certas magicas/gambiarras da programacao o novato tera que seguir todo o protoclo do java e se procurar no google vai achar a resposta correta…
Com python nao é assim a linguagem prega todo um zen de bons costumes(identacao é obrigatoria) e vc pode fazer o que quiser isso é ÓTIMO, mas nao funciona em fabricas de software “tipicas” . Eu tinha uma brincadreira que fazia com meus amigos eu dizia que era impossivel fazer um codigo python ilegivel… Doce ilusao meus amigos que mexiam com python eram amantes de programacao como eu…e nossos codigos eram legiveis … Um certo dia encontrei um script python e tive que parar com a brincadeira…
Foi ai que comecei a repensar na estrategia do java e comecei a perceber que era valida… Uma das implicancia que eu tinha com java era os getters e setters e um dia desses programando em lua me vi direcionado a implementa-los . O meu problema com java é linguistico… Eu sempre me perguntava: pra que colocar um setter e um getter numa classe? Em python é so fazer obj.propriedade = valor ( e mesmo se quiser controle sobre as variaveis eu posso fazer isso via uma classe meta..)
Nesse script de lua eu vi uma utilidade clara para esse padrao. Eu parei de pensar em como “fazer funcionar” e sim em como “deve ser feito”… Claro isso varia de app para app e o desenvolvedor tem decidir quando usar o padrao e quando isso nao é necessario….
Mas o que isso tem haver com as linguagens da moda? É que a seguranca e estabildiade de limguagens como java faz com que o modelo da linguagens industrial seja domintante… NAO ESTOU DIZENDO QUE JAVA É UMA LINGUAGEM INDUSTRIAL mas que ela concerteza facilita a vida de quem quer usar esse modelo… Hoje eu quero usar java e sei que posso fazer otimos usos dessa linguagem em seu contexto porem nao estou prezo em nenhuma linguagem e tento sempre ver qual é melhor para determinada applicacao….
Acho que ser progamador nao é sobre saber como usar uma lingaugem de programacao especifica e sim como se adaptar a tarefa do momento…
Por exemplo nao vejo problema em aprender objetive-c para programar um app para iphone (aprender faz parte de programar) pois sei que por causa dela o iphone é mais rapido pois foi otimizado para lidar com ela… Mas me sinto frustado em ter que programar em java para android (quando poderia ser C/C++) por que google escolheu o java como linguagem padrao apenas por “facilidade” e é bem provavel por causa do legado e da comunidade gigante…
Eu acho que isso é o grande prejuizo da linguagem industrial… De um lado temos programadores se preocupando com codigo e entregar componentes de forma rapida e facil ( apps funcionais porem sem planejamento e designer: Android) do outro programadores preocupados com a experiencia do cliente (apps com designer, por exemplo a maioria dos apps do iphone).
Observem que nesse exemplo tudo é mais dificll para os programadores IOS eles nao podem usar eclipse, eles tem que ter um Mac para programar para a plataforma e ainda tem que aprender o inutil objective-C que nao sera usado em nenhu outro projeto que ao seja para a plataforma apple…
Mas é inegavel que seus apps (na maioria) tem melhores designers que os das plataformas concorrentes… Porque? Porque nao ha desculpa para fazer menos… A dificuldade de fazer algo feio/funcional e algo bonito e vendivel é praticamente a mesma (nesse contexto) por isso a maioria é praticamente obrigada a fazer o melhor…. Infelizmente nao posso dizer isso da comunidade java, ja que a maioria dos apps pode ser reusmido como uma simples janela com menu superior e alguns inputs e botoes no meio….
Interessante. Se bem entendi, o que você quer dizer é que o modelo de fábrica acaba nos forçando a usar linguagens como Java, é isto?
Mais ou menos….
Quero dizer que modelo industrial faz com que fiquemos presos em certas tecnologias (que geralmente são as dominantes com mais mão de obra)…
sou a favor da adaptação por projeto.
Eu gosto muito de python e javascript me sinto tranquilo nessas linguagens se pudesse fazia tudo nelas mas não seria correto fazer isso.
Acho que na nossa profissão não deveriamos ter linguagens dominantes e sim apenas linguagens… Mas isso exige a compreensão do “que” e não do “como” da forma que vc falou no artigo. Sabendo o “que” procurar vc escolheria a melhor lingugem para determinado contexto de applicacao… É claro toda linguagem pode fazer qualquer coisa mas isso é preguiça do programador… aprender uma nova linguagem deve durar no maximo um dia quando vc sabe o “que” procurar.
Por isso não vejo por que devemos ficar preso a qualquer uma
Entendi, é interessante este seu ponto sim.
De fato, muitas vezes a linguagem é vista como componente, e não como o que de fato é, que é: uma ferramenta de expressão.
Oi Kico!
Até o momento, considero a Área da Saúde Humana uma metáfora mais interessante para a TI, pois ambas não são um fim em si mesmas e tem como objetivo fazer um corpo sobreviver, manter, crescer e se desenvolver.
Os profissionais da saúde com o ser humano (corpo físico) e os profissionais de TI com um corpo juridico (empresas) ou civil (sociedade). Há uma ligação clara na Análise SWOT [http://pt.wikipedia.org/wiki/Analise_SWOT] das teorias da administração.
O problema da metáfora industrial (linha de produção) na área de software tem sido discutida com exaustão no movimento Artesanato de Software [http://en.wikipedia.org/wiki/Software_craftsmanship] que culminou em um manifesto em 2009 [http://manifesto.softwarecraftsmanship.org/].
Mas considero muito raso considerar opressores x oprimidos ou burguesia x proletariado, pois, além dos empresários também serem ‘oprimidos’ por um mercado extremamente competitivo, se torna cada vez mais comum na nossa área empregados se tornarem empresários – o que não ocorreria se fossemos simplesmente forças braçais sem acesso aos meios de produção [http://pt.wikipedia.org/wiki/Prolet%C3%A1rio].
Enfim, considerando que uma metáfora é uma abstração de algo mais complexo para facilitar a comunicação, tal como uma abstração ela sempre terá furos (Lei da Abstração Furada, Joel Spowsky). Seja ela engenharia, seja artesanato…
Abraços!
Wans
Oi Mr. Wanderson!
Também não curto este papo opressores x oprimidos. Interessante esta relação com a saúde que você faz: da muito material pra pensar.
O que vejo é o seguinte: o domínio destas metáforas ruins nublam o nosso raciocínio sobre o nosso ofício e acabam nos levando a tomar decisões muito equivocadas. Sou a favor de enterrar este tipo de comparaçãompor qualquer outra que seja mais próxima da essência do que fazemos que é o trabalho intelectual.
Sendo assim, que se inicie a caça à melhor metáfora!
também gostei bastante dessa metáfora com a área da saúde, um grande problema é que as pessoas dificilmente iriam imaginar essa linha de raciocínio do “manter um corpo funcionando”, a primeira vista acho que uma teoria dessas enfrentaria uma certa resistência por pessoas menos técnicas, algumas (acredito eu) pensariam que desenvolvedores iriam querer essa analogia em busca de status (que médicos possuem na sociedade), depois parei para pensar que muita gente da nossa própria área não entende isso, fazendo que inclusive muitos “pedreiros de software” pensassem isso também. Resumindo, isso é razoavelmente complexo para a maioria das pessoas…
Sugiro que pratique esta metáfora pois acredito que vai se surpreender.
As pessoas menos técnicas entendem muito bem, pois todos já foram consultados por um clínico geral ou por um especialista de área, tiveram tratamentos com sucesso e insucesso, remédios que resolvem no ato, enquanto outros precisaram de tempo pra fazer efeitos ou ajustes na dosagem, e principalmente os efeitos colaterais e suas consequências…
Quando tiver tempo e paciência escrevo um artigo sobre isso, pois vale a pena.
as pessoas técnicas entendem muito bem?
o que mais se tem noticia é das perolas que o povo solta… os vidadeprogramador e vidadesuporte por exemplo você vê várias delas…
pessoalmente eu vejo as vezes gente mesmo técnica dando uns deslizes meio feios para alguém técnico…
Sr. Kico, parabéns pelo post! Posso lhe afirmar que agora tenho um embasamento maior para argumentar formalmente contra pessoas que vêm me procurar porque precisam de algo “para ontem”. Eu sempre procuro recusar esse tipo de serviço porque sei a porcaria que vai ficar, mas somente dizendo “é uma política minha não fazer trabalhos correndo porque geram muitos problemas lá na frente, que podem comprometer minha imagem” é difícil convencê-los. Eles não estão preocupados comigo, e se eu recuso dessa forma aí que fico queimado mesmo … :( Seu post me ajudou a definir alguns dos porquês, melhor do que eu mesmo já sabia.
Oi Éderson, bacana ler isto. Valeu!
Não havia pensado sobre esta ótica. :)
Fantástico!
O Vinicius Teles, em seu livro sobre XP, já havia comentado a respeito dessas analogias com o modo de trabalhar de uma indústria. E esse post só agrega valor tratando de forma mais específica das metáforas.
Desde que li sobre isso venho pensando a mais ou menos 1 ano, e não conseguiria expressar de forma tão elaborada como fez neste post.
A nossa profissão é nova e incompreendida pela maioria esmagadora dos profissionais de outras áreas, e arrisco dizer que muitos que trabalham com TI também não compreendem. Como o caso citado pelo prof. Perluigi de Piazzi em seu livro Aprendendo Inteligência, que diz sobre uma pedagoga que nunca gostou e deu importância às disciplinas da exatas e agora com sua posição define o que os alunos irão estudar nessas disciplinas, suas ideias e pensamentos tendenciosos fazem com que os alunos criem o desgosto e desprezo por estas matérias, assim como ela, e infelizmente acabem passando este pensamento adiante.
Abraço
Oi Hercules, legal que tenha gostado, valeu.
Sabe, exatamente por ser algo novo é que estamos no momento exato de definir o vocabulário que usamos pra descrever a nossa atividade. Com este post meu objetivo foi justamente fomentar esta discussão pra ver o que surge a partir deste problema.
E esse livro do Vinicius Teles… tá na minha lista já faz algum tempo pra ler. Acho que este seu comentário foi a gota d´água que eu precisava, valeu por lembrar!
Olá Kico,
Achei excelente o modo como você tratou o assunto e logo quando você citou o conhecimento raso dos profissionais sobre os assuntos ao qual então envolvidos diretamente. Lembrei-me de inúmeras situações onde tive que aturar por horas
pessoas que acreditavam piamente que sabiam do que estavam falando, mas no fundo sabiam que estavam se enganando.
Eu particulamente sou coeso a idéia de componentes, pois ainda acredito que o bom desenvolvedor é o que tem curiosidade em saber de quais peças determinado motor é feito, e quando isso acontece não existe componentização que o emburrece.
A tecnologia de hoje é muitoo diferente da que existia a 5 anos atrás, hoje as cobranças são outras e por este motivo eu apoio a componentização, pois ontem todos ficavam impressionados com o “did you mean: xyz?” do Google e hoje isso virou coisa de criança. As ondas hoje são maiores e agora se pensa em análise de sentimentos, aprendizado de máquina, realidade aumentada, processamento bigdata etc, etc, etc.
Resumindo, para mim o mundo velho deve ser atacado com armas novas e o mundo novo deve-se buscar incessantemente o controle.
Meus parabéns pelo artigo!
abraço :)
Opa, valeu Marcelo, obrigado!
Também acho que os componentes tenham sua razão de existir e seu lugar. Meu medo é a componentização industrial que menciono acima.
Existem 10 tipos de profissionais de software: criadores e medidores de produtividade.
Olá Kiko, acho que estou meio atrasado no post, mas vou comentar ainda sim. Também venho pensando nisso desde os primeiros meses na faculdade. Qual a melhor metáfora para o que estou aprendendo (Desenvolvimento de software)?
Os professores ensinam a programar sempre usando o exemplo da receita de bolo e usam analogias para explicar a teoria do desenvolvimento de software com a engenharia civil. Já vaguei nos extremos de entender o desenvolvimento como engenharia pura até arte pura. Mas na verdade, acredito que o que melhor descreve o que criamos é algo bem mais óbvio. Nós criamos empresas com nossos algoritmos e com isso vamos desde a engenharia civil da empresa até a organização burocrática da mesma. Fazemos tudo, construímos todo o mundo para que aquela empresa exista e damos o sopro de vida. É como criar jogos: é preciso implementar a engine e através dela implementar a história, construir os personagens, cenário etc. Nisso tudo temos ciências humanas e exatas interagindo uma com a outra. Precisamos identificar o que se associa melhor com engenharia civil, com arquitetura, com arte etc, no momento em que desenvolvemos um software.
Mas entendo que além do problema da linguagem, temos muitos problemas que temos que resolver antes mesmo de começar a pensar em criar um software. Por exemplo, será que a organização burocrática das nossas universidades fazem sentido? Será que os alunos, professores e pesquisadores entendem o que é uma universidade e qual o papel deles ali dentro? Acredito que não há uma sequer universidade no Brasil, mas no máximo, cursinhos profissionalizantes. Nossas discussões estão esvaziadas de conceitos e você atentou bem para isso quando comentou, em outras palavras, que estamos copiando e colando códigos ao invés de nos aprofundar no conteúdo, para que sejamos produtivos. Veja que sabemos o que é orientação a objetos, mas será que entendemos o que é de fato uma classe? Qual a origem desse termo? Falamos sobre isso dia após dia nas empresas. Crie uma classe para isso, crie uma classe para aquilo outro etc, mas será que sabemos o que é uma classe? O Brasileiro nem sequer sabe a que classe pertence dentro da sociedade (burguesia, proletário etc), como conseguirá identificar com realidade, as classes que devem ser implementadas em um software para representar a realidade um negócio específico?
Gostei muito dos assuntos que você trata em seus posts. Tratam da realidade do nosso dia a dia. Obrigado e parabéns por isso.
Oi Arthur, fico feliz que tenha gostado do meu blog, obrigado!
Sabe, eu acho que você tocou no ponto. Jà faz alguns anos que ficou nítido pra mim que a raíz dos nossos problemas profissionais e técnicos (e pessoais, e todos eles) tem como fundamento a linguagem que usamos para descrever o mundo ao nosso redor. Seu questionamento é válido: a partir do momento em que você se questiona a respeito das palavras que usa, seu mundo se amplia, e a sua visão do mundo acaba se tornando mais apurada.
Aliás, não é invenção minha isto: Wittgenstein já dizia a mesma coisa em 1929 quando publicou o seu primeiro livro (o Tractactus Logico Philosophicus). Infelizmente nossas faculdades focam mais no momento imediato que no seguinte, e consequentemente vêmos sairem d elá excelentes DBAs da versão atual do Oracle e péssimos analistas que sequer saber conceituar o básico. :(
De fato nossos alunos não sabem mesmo conceituar o basicão. Digo isso porque fui aluno, então, no mínimo, estou falando sobre uma verdade. Aliás, isso puxa um outro comentário. Hoje, com alguns anos no mercado de trabalho, vejo uma sede enorme das pessoas de darem certo, mas uma falta de mira incrível. As principais investidas dos nossos profissionais são certificações, MBA’s e quando muito, um mestrado. Todavia é impressionante a falta de resultado dessas tentativas caras e rápidas. Quando comentei que as pessoas não sabem identificar nem a que classe social pertencem, não quis mostrar uma proximidade desses assuntos, mas o contrário, enfatizar a distância do início do problema, que é, repito, a baixa qualidade intelectual dos profissionais formados, que atuam no desenvolvimento de software. Um exemplo mais simples teria sido se tivesse comentado o fato de uma porcentagem enorme de alunos universitários serem semi-analfabetos. A distância do centro do problema citado com o problema abordado, está há uns 15 a 20 anos. O problema está lá no tempo de aprender a ler, escrever e estudar. Ora bolas, a base do conhecimento é a arte literária, como ter conhecimento sendo analfabeto? Me lembro de uma escola cujo lema é: “Ensinando o aluno a estudar”. Quem dera se isso fosse verdade. A falta de latim nas escolas elimina completamente a possibilidade de o aluno ter o poder de concentração necessário para ser um bom estudante. Cito isso da gramática latina no Napoleão Mendes de Almeida, cujo prefácio elucida de forma definitiva a importância do Latim para o desenvolvimento da habilidade de auto-educação. Claro que não podemos voltar no tempo e nossa sede por crescimento profissional é claramente honesta, então temos que voltar nossas atenções para uma solução que resolva o nosso problema hoje. Estou tentando uma abordagem, se der certo aviso. :)
Você lê coisas muito interessantes. Encontrei alguns livros do Wittgenstein na livraria do seminário de filosofia. Inclusive encontrei o livro Filosofia da Linguagem que me pareceu um bom início para pessoas como eu, que estão no início mesmo. hehe Segue o link: http://livraria.seminariodefilosofia.org/Filosofia-da-Linguagem/Filosofia-da-Linguagem/flypage.tpl.html?keyword=Wittgenstein
Muito obrigado pelo seu comentário.