Eu estava lendo um email quando um anúncio me chamou a atenção (coisa rara de acontecer). Era um anúncio sobre o Ironmq. O Ironmq é um serviço de filas, assim como existe um na Amazon (SQS - Simple Queue Service), por exemplo.
Não foi exatamente o Ironmq que me chamou a atenção. Comecei a pensar na evolução de como os sistemas foram/são/serão desenvolvidos. Cada vez mais os diferentes aspectos de um sistema (persistência, segurança, integração, performance, escalabilidade, etc.) estão ficando mais especializados e de melhor qualidade, e novos nichos em desenvolvimento estão se delimitando mais claramente.
Eu realmente acredito que daqui há pouco profissionais de desenvolvimento terão títulos como "Definidor de Métodos de API para Filas" e esse cara vai ter que ter um conhecimento profundo sobre como definir contratos; "Integrador Persistência/API de Serviço" e ela vai ter que saber qual é o melhor jeito de uma API (como serviço) acessar um banco de dados não relacional, por exemplo. Esses dois exemplos são de funções muito técnicas. Aí, a maioria dos desenvolvedores das consultorias de hoje, no futuro, serão basicamente usuários desses serviços -- vai ser mais uma questão de montar os sistemas do que de codificá-los. O desenvolvedor "normal" de hoje, no futuro, vai passar muito mais a configurar do que codificar ("onde vamos persistir os dados dessa solução?", "qual o endereço do autorizador, mesmo?", "descobri ontem um serviço novo pra processamento pesado, eles estão dando 50% de desconto pra quem for usuário do XPTO").
Antigamente, você cultivava, fazia a colheita e preparava sua comida. Hoje, a gente não cultiva mais -- pelo menos, as pessoas do meu círculo de convivência. Alguns preparam e outros nem preparam mais, só sentam, são servidos ou se servem e comem. Eu acho que essa é uma boa analogia do que está acontecendo com sistemas. Desenvolvimento self-service por KB.
Você concorda que o caminho seja esse?
Não foi exatamente o Ironmq que me chamou a atenção. Comecei a pensar na evolução de como os sistemas foram/são/serão desenvolvidos. Cada vez mais os diferentes aspectos de um sistema (persistência, segurança, integração, performance, escalabilidade, etc.) estão ficando mais especializados e de melhor qualidade, e novos nichos em desenvolvimento estão se delimitando mais claramente.
Eu realmente acredito que daqui há pouco profissionais de desenvolvimento terão títulos como "Definidor de Métodos de API para Filas" e esse cara vai ter que ter um conhecimento profundo sobre como definir contratos; "Integrador Persistência/API de Serviço" e ela vai ter que saber qual é o melhor jeito de uma API (como serviço) acessar um banco de dados não relacional, por exemplo. Esses dois exemplos são de funções muito técnicas. Aí, a maioria dos desenvolvedores das consultorias de hoje, no futuro, serão basicamente usuários desses serviços -- vai ser mais uma questão de montar os sistemas do que de codificá-los. O desenvolvedor "normal" de hoje, no futuro, vai passar muito mais a configurar do que codificar ("onde vamos persistir os dados dessa solução?", "qual o endereço do autorizador, mesmo?", "descobri ontem um serviço novo pra processamento pesado, eles estão dando 50% de desconto pra quem for usuário do XPTO").
Antigamente, você cultivava, fazia a colheita e preparava sua comida. Hoje, a gente não cultiva mais -- pelo menos, as pessoas do meu círculo de convivência. Alguns preparam e outros nem preparam mais, só sentam, são servidos ou se servem e comem. Eu acho que essa é uma boa analogia do que está acontecendo com sistemas. Desenvolvimento self-service por KB.
Você concorda que o caminho seja esse?
