Conselhos dos gringos: Até que ponto devo seguir?

Assuntos Gerais
#101

[quote=utluiz]
Complexidade vs Complicado

Concordo plenamente com o Vini. Esse conceito é sentido na prática e provado na teoria. Leia o Mythical Man Month do Brooks, de 1975, ele já falava sobre a complexidade inerente do software. Há regras de negócio que são inerentemente complexas e vão resultar em código complexo.

Claro que, se pensarmos em nível de loops e condicionais, nada é realmente complicada, mas se considerarmos o nível de algoritmo, basta ver como existem algoritmos complicados. Você pode ter 50 anos de experiência em programação e conhecer todas as linguagens, mas se alguém lhe pedir para resolver o problema do Caixeiro Viajante, por exemplo, de anda adianta tudo isso. Para um problema complexo, é necessário um algoritmo complexo que, mesmo sendo implementado com um código simples, não é inteligível para a maioria dos programadores.

Porém, mesmo um código extremamente complexo pode ser quebrado em blocos mais simples. Você pode dividir uma implementação muito grande e complexa em diversas módulos, classes e métodos. Cada método por ser ser tão simples quanto um código que alguém no primeiro ano de faculdade pode escrever, porém a complexidade está na forma como os objetos se relacionam, nos padrões arquiteturais adotados e assim por diante. [/quote]

Da mesma forma, você pode ter experiência de 50 anos sobre algoritmos ensinados na faculdade, em diferentes linguagens, mas se alguém lhe pedir pra implementar uma regra de negócio (complexidade inerente) e não saber, de que lhe adianta tudo isso?

ps: Brooks diz que as regras de negócio é o essencial no software e acho que ele diria que uma regra de negócio complexa é formado por vários algoritmos simples, e não por um algoritmo que é do tamanho do problema que ele resolve. O software todo é complexo, mas o desafio é reunir algoritmos simples de maneira que fique coerente com o resultado esperado.

#102

[quote=utluiz]
Java defasado?

Java não vai virar um Cobol tão cedo porque ele ainda compete com todas as linguagens mais modernas. Eu concordo que a sintaxe da linguagem é verbosa, possui limitações e muitas vezes é desagradável criar certos tipos de estruturas que em outras linguagens você tem abstrações e syntax sugars bem legais.

Porém, a vantagem do Java é que ele é fácil de aprender, justamente pela sintaxe não permitir construções absurdamente complexas como em linguagens funcionais. E mesmo que você queira fazer isso, você pode rodar praticamente qualquer linguagem dentro da JVM (Ruby, Python, JavaScript, Scala, …). O maior acerto, em minha opinião, da arquitetura do Java foi não tentar vencer outras linguagens, mas juntar-se à elas.

Além disso, os frameworks Java como play! e Spring Boot/Roo fazem praticamente tudo o que frameworks mais modernos como Rails fazem. E você consegue ainda trazer todos os recursos do Java também, além da performance que (por enquanto) é bem melhor.

Enquanto as tecnologias Java conseguirem competir de igual para igual com as tecnologias alternativas, não há razão para imaginar que o Java vai virar um gigante legado. Talvez as aplicações feitas com EJB 2, milhares de linhas de XML e similares possam ocupar esse papel, mas ao mesmo tempo é possível utilizar as tecnologias de ponto usando a mesma plataforma. Isso acaba sendo uma grande vantagem!

Além disso, sinceramente não vejo nada de inovador em muitas das tecnologias que alguns xiitas defendem. Um exemplo: não há motivo técnico porque Rails é melhor melhor do que um framework Java como Spring. Pode ser mais legal, escrever um pouco menos de código a princípio, mas no decorrer de meses e anos não creio que a produtividade seria tão diferente. Além disso, Rails resolve um problema muito específico do desenvolvimento de software. A maioria das tecnologias da moda só resolvem um problema muito específico e, a partir do momento em que começam a crescer e a amadurecer, geralmente elas incorrem nos mesmos problemas que as tecnologias existentes.

Só vou acreditar que o Java está realmente ultrapassado quando surgir um paradigma de desenvolvimento largamente usado que não seja atendido bem por esta plataforma.

Dito isto, sugiro fortemente e urgentemente que quem só sabe Java aprenda mais uma ou duas plataformas para sair fora da caixa. :D[/quote]

Melhor análise técnica da situação que li nos últimos tempos.

ps: quando um xiita fala que Java virou COBOL, eu vejo isso como algo positivo, afinal, significa que a empresa usou Java para implementar as regras de negócio, que é a parte mais importante do software. Entre a oportunidade de trabalhar com uma linguagem “cool” sem nenhuma relação com o negócio, e Java, eu prefiro a segunda porque é uma posição com mais status.

#103

[quote=pfk66][quote=utluiz]
Complexidade vs Complicado

Concordo plenamente com o Vini. Esse conceito é sentido na prática e provado na teoria. Leia o Mythical Man Month do Brooks, de 1975, ele já falava sobre a complexidade inerente do software. Há regras de negócio que são inerentemente complexas e vão resultar em código complexo.

Claro que, se pensarmos em nível de loops e condicionais, nada é realmente complicada, mas se considerarmos o nível de algoritmo, basta ver como existem algoritmos complicados. Você pode ter 50 anos de experiência em programação e conhecer todas as linguagens, mas se alguém lhe pedir para resolver o problema do Caixeiro Viajante, por exemplo, de anda adianta tudo isso. Para um problema complexo, é necessário um algoritmo complexo que, mesmo sendo implementado com um código simples, não é inteligível para a maioria dos programadores.

Porém, mesmo um código extremamente complexo pode ser quebrado em blocos mais simples. Você pode dividir uma implementação muito grande e complexa em diversas módulos, classes e métodos. Cada método por ser ser tão simples quanto um código que alguém no primeiro ano de faculdade pode escrever, porém a complexidade está na forma como os objetos se relacionam, nos padrões arquiteturais adotados e assim por diante. [/quote]

Da mesma forma, você pode ter experiência de 50 anos sobre algoritmos ensinados na faculdade, em diferentes linguagens, mas se alguém lhe pedir pra implementar uma regra de negócio (complexidade inerente) e não saber, de que lhe adianta tudo isso?

ps: Brooks diz que as regras de negócio é o essencial no software e acho que ele diria que uma regra de negócio complexa é formado por vários algoritmos simples, e não por um algoritmo que é do tamanho do problema que ele resolve. O software todo é complexo, mas o desafio é reunir algoritmos simples de maneira que fique coerente com o resultado esperado.
[/quote]
Negócio se aprende na relação com o cliente. É mais humanas do que exatas, não adianta mesmo gastar energia estudando milhares de linguagens se a cabeça não tiver relaxada e mais disponível para atender uma atividade fim que não é TI. O Negócio é mais importante que TI.

Lado técnico é importante estar acompanhando o que está em volta. Claro se a pessoa trabalha por fins de TI ou é educador, ai sim terá que cair dentro em tecnologias diversas.

#104

[quote=javaflex]
Lado técnico é importante estar acompanhando o que está em volta. Claro se a pessoa trabalha por fins de TI ou é educador, ai sim terá que cair dentro em tecnologias diversas.[/quote]

Ou, por exemplo, se pretende concorrer no mercado global.

#105

[quote=A H Gusukuma][quote=javaflex]
Lado técnico é importante estar acompanhando o que está em volta. Claro se a pessoa trabalha por fins de TI ou é educador, ai sim terá que cair dentro em tecnologias diversas.[/quote]

Ou, por exemplo, se pretende concorrer no mercado global.[/quote]
Sim, quando se adaptar não for suficiente.

#106

[quote=javaflex][quote=A H Gusukuma][quote=javaflex]
Lado técnico é importante estar acompanhando o que está em volta. Claro se a pessoa trabalha por fins de TI ou é educador, ai sim terá que cair dentro em tecnologias diversas.[/quote]

Ou, por exemplo, se pretende concorrer no mercado global.[/quote]
Sim, quando se adaptar não for suficiente.[/quote]
Normalmente não é. Empresas globais procuram oxigenar seu capital humano contratando fora de suas fronteiras, justamente para agregar outras características essenciais ao seu crescimento (inclusive sobrevivência).

#107

[quote=A H Gusukuma][quote=javaflex][quote=A H Gusukuma][quote=javaflex]
Lado técnico é importante estar acompanhando o que está em volta. Claro se a pessoa trabalha por fins de TI ou é educador, ai sim terá que cair dentro em tecnologias diversas.[/quote]

Ou, por exemplo, se pretende concorrer no mercado global.[/quote]
Sim, quando se adaptar não for suficiente.[/quote]
Normalmente não é. Empresas globais procuram oxigenar seu capital humano contratando fora de suas fronteiras, justamente para agregar outras características essenciais ao seu crescimento (inclusive sobrevivência).[/quote]
Em relação a essa questão técnica, pelo menos das pessoas que conheci e quiseram trabalhar fora ou daqui lá pra fora, continuaram trabalhando na mesma tecnologia (ASP.NET), não precisando se preparar para outras coisas técnicas, apenas se adaptar à particularidades do local. Claro se a pessoa está trabalhando com algo obscuro tem que se preparar mesmo para o que é usado hoje no mundo.

#108

Quando eu cheguei aqui ( em 2008 ) eu trabalhei junto e aprendi muito com um dos autores desse livro aqui:
http://www.amazon.com/gp/product/0596527934 (Java Power Tools)

Desde entao nunca me senti abaixo da media diante aos programadores neozelandeses, tive muita sorte :smiley:
Mas como disse antes “O pessoal daqui (NZ) tem uma boa fundacao teorica, universidades sao de boa qualidade…”

Alem disso “utluiz” (Luiz) levantou um ponto bem importante que e’ o seguinte:
“em países desenvolvidos o acesso à tecnologia de ponto é muito mais fácil…”

Como eu disse: “Muitos dos estudantes de TI depois de terminar”.
E… muitos != todos. :wink:

#109

[quote=pfk66]Da mesma forma, você pode ter experiência de 50 anos sobre algoritmos ensinados na faculdade, em diferentes linguagens, mas se alguém lhe pedir pra implementar uma regra de negócio (complexidade inerente) e não saber, de que lhe adianta tudo isso?

ps: Brooks diz que as regras de negócio é o essencial no software e acho que ele diria que uma regra de negócio complexa é formado por vários algoritmos simples, e não por um algoritmo que é do tamanho do problema que ele resolve. O software todo é complexo, mas o desafio é reunir algoritmos simples de maneira que fique coerente com o resultado esperado.
[/quote]

Agora, é muito mais fácil acreditar que um bom conhecedor de algoritmos, com algum esforço, passe a entender e aplicar seus algoritmos em regras de negócio do que ao contrário.
Por mim, isso soa a desculpa de analista de sistemas preguiçoso. Daqueles da época onde o bom analista não precisava programar, e nem queria.

Não adianta se escorar na desculpa que sua formação é “mais humana” e de que, portanto, seu diferencial está em outro lugar. Até porque, um analista de negócios tem que ter na ponta da lingua a capacidade de dizer se algo será ou não viável, ou qual a escala desse empreendimento.

Alguns “algoritmos simples” podem levar anos de estudo para serem modelados desse jeito. Por isso que eu digo, que um software complexo é bem diferente de um código complicado. Pegue por exemplo, qualquer algoritmo gráfico. A maior parte deles é relativamente simples… desde que você saiba algebra linear. Muitos problemas de threads são modelados de maneira bastante elegante… desde que você gaste uns 2 anos para entender exatamente o que são os problemas, e quando aplicar a forma elegante.

PS: Não estou desmerecendo de forma alguma o papel do analista de negócios. Acho uma profissão muito importante, como qualquer outra. Ou mesmo, o programador que tenha mais habilidade em regras de negócio. O que estou querendo dizer é só que você não pode usar isso como desculpa para ser um mau programador. Especialmente hoje, com métodos ágeis, onde raramente alguém se esquivará de colocar a mão na massa.

#110

Tenho uma visão um pouco diferente, apesar da denominação comum de um cargo, por exemplo, “programador”, temos na verdade diversas especializações embutidas que não são formalmente descritas.
Não vejo um médico especialista cobrar de um clínico geral algum conhecimento que fuja da sua área de atuação, inclusive porque é facultado a atuação em determinadas áreas apenas aos formalmente graduados na especialização.
Por isso, creio, devemos ter um certo cuidado em ficar rotulando de acomodados ou preguiçosos quem não conhece alguma técnica ou algoritmo sem verificar se tal conhecimento não seja uma especialização.
Como foi dito, uma especialização pode demandar anos de estudos, então não dá para improvisar: se quer ser especialista, precisa de um plano de carreira para alcançar tal objetivo.
Não dá para contratar um “programador geral” e exigir conhecimentos de um “programador especialista”, nem desejar contratar um “programador especialista” pelo salário de um “programador geral”.
Não vejo demérito nenhum em ser um “programador geral”, mas, é claro que o mercado valoriza uma (ou mais) especialização(ões) e se um cargo exija alguma especialização, não adianta ficar de mimimi contra as exigências mil dos recrutadores!
Não quero dizer, com tudo isso, que não existam os chamados “preguiçosos ou acomodados”, para esses recomendo que sempre existe a possibilidade de dar uma reviravolta na carreira, mas precisamos ter cuidado em separar o joio do trigo, até porque, existem mais que duas possibilidades, não é?

#111

[quote=A H Gusukuma]Tenho uma visão um pouco diferente, apesar da denominação comum de um cargo, por exemplo, “programador”, temos na verdade diversas especializações embutidas que não são formalmente descritas.
Não vejo um médico especialista cobrar de um clínico geral algum conhecimento que fuja da sua área de atuação, inclusive porque é facultado a atuação em determinadas áreas apenas aos formalmente graduados na especialização.
Por isso, creio, devemos ter um certo cuidado em ficar rotulando de acomodados ou preguiçosos quem não conhece alguma técnica ou algoritmo sem verificar se tal conhecimento não seja uma especialização.
Como foi dito, uma especialização pode demandar anos de estudos, então não dá para improvisar: se quer ser especialista, precisa de um plano de carreira para alcançar tal objetivo.
Não dá para contratar um “programador geral” e exigir conhecimentos de um “programador especialista”, nem desejar contratar um “programador especialista” pelo salário de um “programador geral”.
Não vejo demérito nenhum em ser um “programador geral”, mas, é claro que o mercado valoriza uma (ou mais) especialização(ões) e se um cargo exija alguma especialização, não adianta ficar de mimimi contra as exigências mil dos recrutadores!
Não quero dizer, com tudo isso, que não existam os chamados “preguiçosos ou acomodados”, para esses recomendo que sempre existe a possibilidade de dar uma reviravolta na carreira, mas precisamos ter cuidado em separar o joio do trigo, até porque, existem mais que duas possibilidades, não é?[/quote]

Sim, eu concordo com sua visão.

O que estou comentando é que no mínimo da programação geral o cara não vai escapar. É conhecimento básico, disso não tem como o cara fugir.
E já vi analista de sistemas tentando escapar, usando como desculpa o fato dele ter uma área mais humana. O resultado disso são péssimos analistas.

O pior é que, numa empresa mais waterfall, esses analistas ainda ganham a falsa sensação de serem chefes de programadores e aí, cria-se um clima péssimo entre as duas equipes.

#112

[quote=ViniGodoy]
Sim, eu concordo com sua visão.

O que estou comentando é que no mínimo da programação geral o cara não vai escapar. É conhecimento básico, disso não tem como o cara fugir.
E já vi analista de sistemas tentando escapar, usando como desculpa o fato dele ter uma área mais humana. O resultado disso são péssimos analistas.

O pior é que, numa empresa mais waterfall, esses analistas ainda ganham a falsa sensação de serem chefes de programadores e aí, cria-se um clima péssimo entre as duas equipes.[/quote]
Concordo plenamente, por isso, coloquei o meu post isoladamente e não como uma resposta ao seu post anterior. É evidente que temos problemas na formação de líderes que ocupam posições hierárquicas de comando em muitas empresas, mas isso é mais um reflexo do nosso sistema educacional e empresarial em vigor. Mas, isso é outra história.

#113

[quote=keller][quote=Júlio Murta]
Em algum momento você se sentiu abaixo da média diante os programadores neozelandeses?
[/quote]

Quando eu cheguei aqui ( em 2008 ) eu trabalhei junto e aprendi muito com um dos autores desse livro aqui:
http://www.amazon.com/gp/product/0596527934 (Java Power Tools)

Desde entao nunca me senti abaixo da media diante aos programadores neozelandeses, tive muita sorte :smiley:
Mas como disse antes “O pessoal daqui (NZ) tem uma boa fundacao teorica, universidades sao de boa qualidade…”

Alem disso “utluiz” (Luiz) levantou um ponto bem importante que e’ o seguinte:
“em países desenvolvidos o acesso à tecnologia de ponto é muito mais fácil…”
[/quote]

Mas você considera o programador médio brasileiro (fazedor de crud e relatório) abaixo dos caras que vê por aí?

#114

Obrigado! Também sou, e agora mais ainda… :smiley:

#115

Sim, mas justamente por ser mais fácil se sobressair muitos desenvolvedores brasileiros ficam aquém do seu potencial, caso fossem expostos a um ambiente mais competitivo. Há vantagens e desvantagens em tudo.

Se você for bom não vai ter dificuldades. Nós brasileiros não somos inferiores em nada e o dólar alto só ajuda nesse caso. O problema é que às vezes você precisa provar ser MUITO bom para trabalhar fora. Pense em quem contrata, se tiverem alguém do mesmo nível do mesmo país, porque eles iriam querer você? Ou você é em geral melhor que os desenvolvedores de lá ou mais barato ou os dois.

Sim, o problema é que eles tem mais recursos do que a maioria de nós. Sem falar que, no geral, os estrangeiros têm mais disciplina que os brasileiros nos estudos. Mas claro que quem se esforça chega lá, não há dúvida, fica até melhor que a grande maioria dos gringos.

Dói, mas é a mais pura verdade. :S

#116

[quote=ViniGodoy][quote=pfk66]Da mesma forma, você pode ter experiência de 50 anos sobre algoritmos ensinados na faculdade, em diferentes linguagens, mas se alguém lhe pedir pra implementar uma regra de negócio (complexidade inerente) e não saber, de que lhe adianta tudo isso?

ps: Brooks diz que as regras de negócio é o essencial no software e acho que ele diria que uma regra de negócio complexa é formado por vários algoritmos simples, e não por um algoritmo que é do tamanho do problema que ele resolve. O software todo é complexo, mas o desafio é reunir algoritmos simples de maneira que fique coerente com o resultado esperado.
[/quote]

Agora, é muito mais fácil acreditar que um bom conhecedor de algoritmos, com algum esforço, passe a entender e aplicar seus algoritmos em regras de negócio do que ao contrário.
Por mim, isso soa a desculpa de analista de sistemas preguiçoso. Daqueles da época onde o bom analista não precisava programar, e nem queria.

Não adianta se escorar na desculpa que sua formação é “mais humana” e de que, portanto, seu diferencial está em outro lugar. Até porque, um analista de negócios tem que ter na ponta da lingua a capacidade de dizer se algo será ou não viável, ou qual a escala desse empreendimento.

Alguns “algoritmos simples” podem levar anos de estudo para serem modelados desse jeito. Por isso que eu digo, que um software complexo é bem diferente de um código complicado. Pegue por exemplo, qualquer algoritmo gráfico. A maior parte deles é relativamente simples… desde que você saiba algebra linear. Muitos problemas de threads são modelados de maneira bastante elegante… desde que você gaste uns 2 anos para entender exatamente o que são os problemas, e quando aplicar a forma elegante.

PS: Não estou desmerecendo de forma alguma o papel do analista de negócios. Acho uma profissão muito importante, como qualquer outra. Ou mesmo, o programador que tenha mais habilidade em regras de negócio. O que estou querendo dizer é só que você não pode usar isso como desculpa para ser um mau programador. Especialmente hoje, com métodos ágeis, onde raramente alguém se esquivará de colocar a mão na massa.[/quote]

  1. quais algoritmos que a pessoa precisa estudar pra não ser considerado um mau programador?

  2. por que você acha que a universidade tem um monopólio sobre esses algoritmos?

#117

O mínimo é o sujeito ter uma boa noção sobre estruturas de dados, bancos de dados e sobre integrações. Não pode ter dúvida no básico também, e é interessante já ter atuado como desenvolvedor para ter uma boa noção da dificuldade e tempo que as coisas levam.

Não acho.

#118

[quote=Júlio Murta][quote=keller][quote=Júlio Murta]
Em algum momento você se sentiu abaixo da média diante os programadores neozelandeses?
[/quote]

Quando eu cheguei aqui ( em 2008 ) eu trabalhei junto e aprendi muito com um dos autores desse livro aqui:
http://www.amazon.com/gp/product/0596527934 (Java Power Tools)

Desde entao nunca me senti abaixo da media diante aos programadores neozelandeses, tive muita sorte :smiley:
Mas como disse antes “O pessoal daqui (NZ) tem uma boa fundacao teorica, universidades sao de boa qualidade…”

Alem disso “utluiz” (Luiz) levantou um ponto bem importante que e’ o seguinte:
“em países desenvolvidos o acesso à tecnologia de ponto é muito mais fácil…”
[/quote]

Mas você considera o programador médio brasileiro (fazedor de crud e relatório) abaixo dos caras que vê por aí?[/quote]

Se não me engano lá eles falam inglês, então eu diria que o programador brasileiro já começa no prejuízo sim, porque tem que aprender inglês.

#119

Programador que não fala inglês já vai ter problemas no Brasil, quem dirá fora.

#120

[quote=pfk66][quote=Júlio Murta][quote=keller][quote=Júlio Murta]
Em algum momento você se sentiu abaixo da média diante os programadores neozelandeses?
[/quote]

Quando eu cheguei aqui ( em 2008 ) eu trabalhei junto e aprendi muito com um dos autores desse livro aqui:
http://www.amazon.com/gp/product/0596527934 (Java Power Tools)

Desde entao nunca me senti abaixo da media diante aos programadores neozelandeses, tive muita sorte :smiley:
Mas como disse antes “O pessoal daqui (NZ) tem uma boa fundacao teorica, universidades sao de boa qualidade…”

Alem disso “utluiz” (Luiz) levantou um ponto bem importante que e’ o seguinte:
“em países desenvolvidos o acesso à tecnologia de ponto é muito mais fácil…”
[/quote]

Mas você considera o programador médio brasileiro (fazedor de crud e relatório) abaixo dos caras que vê por aí?[/quote]

Se não me engano lá eles falam inglês, então eu diria que o programador brasileiro já começa no prejuízo sim, porque tem que aprender inglês.
[/quote]

Me refiro ao nível de conhecimento técnico de nossos profissionais. Russos e chineses também não falam inglês nativamente, mas isso não os impede de aprender e terem uma comunidade de desenvolvedores forte.

Muitos indianos falam inglês nativamente, e nem por isso são referência em qualidade.