Serializando problemas
No último fim de semana resolvi retornar a um objetivo antigo: resolver a maior parte dos problemas em sites competitivos de codificação.
O resultado final: mais de 400 linhas de código em um único dia, todos os problemas grátis do CoderByte resolvidos, e três novos problemas do Project Euler, em resumo, um ótimo domingo.
Apesar do objetivo original ser apenas resolver estes problemas, durante a resolução destes problemas eu notei como eles demonstram minha evolução em relação a diversos pontos chaves quando se é um programador, como o domínio sobre uma linguagem, a habilidade analítica e o conteúdo adquirido.
O contexto
Desde o fim do ano passado, quando utilizei pela última vez o Project Euler, eu passei mais tempo me dedicando a projetos profissionais, que incluem entregas internas para clientes ou de automação, bem como outros que poderiam ser utilizados profissionalmente (cdflow e Mockingbird) feitos em tempo livre. Nesse meio tempo eu também fiz um curso de verão sobre estatística, uma das minhas maiores vergonhas como aspirante a cientista da computação (você vai precisar de muita estatística para analisar algoritmos seriamente).
A história
Iniciando a manhã de domingo com os problemas do CoderByte, escolhendo ECMAScript em detrimento do JAVA desta vez, por ser a linguagem que agora utilizo profissionalmente, minha surpresa foi grande ao perceber como algoritmos que eu já havia escrito algumas vezes (filtros, mapas, hashs) de maneira integral durante cursos, me ocorriam naturalmente na forma de métodos da linguagem, sem nem mesmo uma consulta ao MDN, algo impensável para mim algum tempo atrás.
Um problema em especifico me chamou a atenção sobre os poderes que isso pode trazer para um desenvolvedor. Resolvido por mim em três linhas de chamada de métodos nativos, a solução listada como melhor tinha dezesseis, e implementava um algoritmo de reversão em arrays (que pode ser escrito como [].reverse()).
Após resolver os problemas gratuitos, resolvi que era hora de retornar para o meu site favorito quando o assunto são problemas computacionais, o Project Euler. Em um momento de pura pretensão, eu resolvi entrar no problema 100 do site (meu último problema resolvido havia sido o 53). Qual foi a minha surpresa ao me deparar com um problema de combinatória simples! Que no fim eu só sabia resolver por ter estudado no curso de verão sobre estatística!
A dica para minha solução são hipergeométricas, embora você na verdade não deva segui-lá, o que nos leva a habilidade analítica e o meu erro nesse campo.
A impressão que o fato do problema 100 envolver a mesma estatística que eu havia aprendido recentemente, me deixou uma impressão tão forte que desabilitou meu senso critico. Após ter gasto algum tempo programando um algoritmo para resolver distribuições hipergeométricas (adaptado de https://www.sciencedirect.com/science/article/pii/S1570866706000499), as threads que abrem após um problema ser resolvido me trazem uma dura verdade: poderia ser feito com diofantinas, e ainda pior, o Wolfram Alpha resolveria isso com apenas uma consulta de segundos.
A conclusão
Se eu tivesse dedicado um pouco mais de tempo transformando os números originais em uma estrutura genérica, exercendo minha habilidade analítica, um problema poderia ter sido resolvido de maneira muito mais eficiente.
Ficou claro para mim como estes sites podem ajudar a expor suas melhorias assim como pontos em que é necessária uma maior atenção. Na maior parte do tempo os problemas que aparecem online não são parecidos com aqueles do mundo real, ainda assim, usá-los como métrica de progresso e como ferramenta de progressão é uma ótima coisa a se fazer.
Analisar falhas nos mostra também como estamos evoluindo (eu me tornei top 500 do brasil após resolver o problema 100), e caminhos que podem nos levar mais longe.
E que domingo.
