Trabalhei na ABA por um tempo antes da fundação da FAST e tive boas e más impressões.

Sobre os tópicos: o canal de comunicação é realmente muito bom, seguro saúde, previdência e vale alimentação também eram bons, no entanto, sobre salários eu acho que a ABA deixa a desejar nas áreas que não são Educação. Até onde soube, professores recebiam bem, no entanto a realidade no departamento de informática não era a mesma (lembrando que estive por lá em 2004 e 2005, mas estou comparando com valores praticados na época). Não havia oportunidade de crescimento e plano de carreiras para TI, o plano era -> Estagiário, Funcionário, Gerente de TI, Aposentado. A FAST abriu pagando 50% a mais para os estagiários do que a ABA pagava. Desenvolvimento profissional, pelo menos pra TI não era muito, tanto que o turnover foi bem alto… dos 7 do departamento da minha época, só resta 1 pessoa hoje. Todos os outros PEDIRAM pra sair.

O ambiente de trabalho era ótimo mesmo. Divertido, com espaço para inovações. Diria que é ótimo para estagiários e jovens profissionais… no entanto… não há espaço para alguém mais pleno ou senior (Falando novamente de TI, para professores, sim HÁ!). Programas sociais, biblioteca, e busca por novas tecnologias também estão sempre presentes.

Gostei de trabalhar na ABA, fiz amigos, aprendi, mas não acho que seja um lugar para fazer uma carreira de TI, não há oportunidades e bons salários, apesar de ter espaço pra inovações. Hoje, sei que o departamento está se expandindo… espero que as coisas tenham melhorado por lá, nesse sentido.

aguardo sua visita

No nosso caso, o ganho foi medido e não foi mísero, especificamente por causa das condições que expliquei acima. Em muitas outras aplicações, no entanto, essa otimização, com certeza, pode não ser o melhor caminho.

Acho importante deixar claro pros leitores que a contribuição deste post não é “deixe de usar double.IsNan” e sim:

1. Procure entender a fundo as coisas que você está trabalhando (busque definições, faça disassembly, etc)

2. Tire métricas realistas do “antes e depois” de tudo que você está otimizando

3. As vezes, não tenha medo de ousar e fazer uma coisa que “não faz sentido”. Inline de métodos REALMENTE deveria ser papel do JIT, não do programador. Pena que o do .NET compact, no device que estamos trabalhando, não tem essa capacidade.

Abraços