Ao longo dos últimos dois anos a Zup Edu, o núcleo de Educação e Pesquisa da Zup, vem trabalhando para, entre outras coisas, oferecer treinos e programas de aceleração que apoiam a construção de um ambiente de evolução exponencial. E nessa história você vai ver como a criação de plano de estudo bem estruturado é importante para acelerar a transferência de aprendizado e habilitar a construção de diferentes tipos de conteúdo.
No último semestre de 2021, começamos a trabalhar com o objetivo de aumentar nosso leque de conteúdo e facilitar também a evolução de carreira das pessoas desenvolvedoras de aplicativos para plataformas móveis.
De Android a iOS, viemos idealizando uma série de conteúdos que vão ajudar profissionais da empresa a dominarem conceitos, mas principalmente transferir o aprendizado para a vida real aumentando de forma concreta a performance entregue no campo de jogo.
Neste cenário me inseri há aproximadamente 8 meses. Como missão: construir um programa de treinos que capacite pessoas desenvolvedoras para o trabalho com desenvolvimento iOS na Zup, ajudando assim a empresa a formar suas equipes com essa habilidade tão escassa no mercado atualmente. O problema: fazer isso tendo construído um mísero HelloWorld App diretamente sobre a plataforma da Apple.
Tem interesse em saber como foi possível essa jornada de aprendizado sobre a plataforma? Então pega uma xícara de café e se prepara que a história é boa.
Contextualizando o desafio
Durante minha carreira como desenvolvedor, tive a felicidade de trabalhar na fronteira entre tecnologia e educação. Os pouco mais de três anos de experiência trabalhando no grupo Caelum Alura foram responsáveis por um aumento drástico na curva de aprendizado, tanto em capacidades técnicas, como também não-técnicas. A oportunidade de aliar engenharia de software ao esforço de estudo aprofundado, construção e curadoria de materiais didáticos e técnicas de ensino no tempo de trabalho foi fator fundamental para isso.
Após um tempo trabalhando exclusivamente com desenvolvimento de produto, recebi o convite para atuar na Zup Edu e topei o desafio de voltar a esse ambiente. A equipe precisava crescer para construir ainda mais acelerações demandadas pela empresa, e por vir trabalhando nos últimos dois anos sobre as plataformas móveis – ainda que a nível não-nativo – a ideia era trazer essas competências para o time.
Havia alguma incerteza sobre as primeiras acelerações necessárias. Desenvolvimento iOS ou sobre as abstrações providas por frameworks como React Native ou Flutter, eram algumas opções. No entanto, após algumas discussões a aposta que parecia mais certeira era investir na plataforma de base sobre a qual as outras dependem direta ou indiretamente do conhecimento. Com isso eu tinha meu desafio: preparar uma aceleração sobre desenvolvimento de aplicações iOS nativas, tendo que, antes disso, adquirir as competências de devs iOS.
De um lado, estava confiante pois já tinha passado por situações parecidas na experiência anterior. Por outro, dessa vez a ideia não era apenas estudar um framework ou conceitos avançados de uma plataforma já conhecida. Era preciso estudar uma plataforma do zero, suas características, especificação de linguagem, alguns frameworks base necessários para construir aplicações, e tudo aquilo que vem no pacote. ?
Todo esse trabalho deveria ainda ser realizado no período mais curto possível, para que as necessidades das áreas interessadas tão logo fossem endereçadas. Era preciso então alguma forma estruturada de guiar o aprendizado, capaz de acelerar essa transferência de conhecimento.
Construindo um método para aceleração do aprendizado
Assim que o processo de onboarding na equipe foi concluído, em meio àquela apreensão causada pela percepção ainda meio turva sobre o volume de coisas a serem estudadas, tivemos nossas primeiras conversas para traçar o plano de estudo. O primeiro desejo era ter mais visão sobre os tópicos fundamentais para dominar o desenvolvimento sobre a plataforma. Tendo isso em vista, poderíamos então dar os próximos passos.
Mapa de habilidades técnicas
Através de um brainstorming, foi possível criar um mapa de habilidades técnicas bem específicas divididas por tópicos organizados entre o que estava relacionado à especificação da linguagem Swift, ao desenvolvimento iOS, aos SDKs fundamentais da plataforma, qualidade de código, ferramentas de gestão e segurança.
| Mapa de Habilidades Técnicas | |||||
|---|---|---|---|---|---|
| Swift | iOS | Infra SDKs: APIse Frameworks | Qualidade | Gestão ePlataforma | Segurança |
| Sistema de Tipos,Variáveis, Constantese Operadores | UIKit | Vídeo, Áudio e Biblioteca de Músicas | Testes Unitários | Gerenciamento de Dependências (CocoaPods) | Gestão dePermissões |
| Tipos Opcionais | Auto Layout | Biblioteca de Fotose Câmera | Testes de Integração | Gestão deCertificados e Profiles | Controles deAutenticação eAutorização |
| Coleções | View Code | Contatos | Testes de Aceitação(end to end) | Automação de Builde Delivery (Fastlane) | 2FA e Tokensde Acesso |
| Controle de Fluxo | Controles deNavegação | Calendário | Análise de Código (SonarQube) | Beta Testing(TestFlight) | Gestão de Senhas,Chaves e Secrets |
| Funções | API de Animações | Geolocation | Formatação eStyle Guide (SwiftLint) | PublicaçãoApp Store | Retenção Mínimade Dados |
| Classes, Structse Protocolos | Swift UI | Sensores | Design Patternscom Swift | Versionamento e Release Management | Termos de Uso e Políticas de Privacidade |
| Extensions e Protocol Extensions | Design System (Voxel) | Social SDKs | Design de Códigoe Arquitetura | Observabilidade(auto capture) | SDKs e Patternsde Segurança |
| Generics | Server-Driven UI (Beagle) | Mapas | Modular Architecture | Logging e ErrorTracing (Sentry) | Comunicação Segura(TLS e VPN) |
| Error Handling | iOS Human Interface Guidelines | Data FetchingHTTP | Crash Reporting (CrashLytics Firebase) | SSL Pinning | |
| Subscripting | Deep Linking | Cloud Messaging (Firebase) | Ofuscação de Código (iXGuard, Obfuscator) | ||
| Closures | Web View | Analytics (Firebase) | |||
| Concorrênciae Paralelismo | Comunicação AppSandboxes | A/B Testing(Firebase) | |||
| Tipos Customizados | Estados e Ciclo deVida da Aplicação | Feature Toggles e Remote Configs (Firebase) | |||
| Gerenciamentode Memória | Persistência | App StoreReview Guideline | |||
| In-app Purchases | |||||
| Push Notifications |
Aqui foi muito importante recorrer ao conhecimento empírico construído na experiência trabalhando com desenvolvimento móvel, mas também utilizar a visão de especialistas da empresa conhecedores da stack utilizada.
Curadoria de fontes teóricas
Assim que identificamos as habilidades técnicas que se desejava desenvolver, foi possível avançar a um próximo passo:
- Como e onde aprender sobre todos estes tópicos?
- Quais fontes teóricas podem ser utilizadas para apoiar o estudo?
- Qual nível de autoridade estas fontes têm sobre o tema?
Estas foram algumas perguntas que inspiraram um processo de curadoria de toda a fonte de conhecimento ofertada na internet e nas plataformas de ensino. Respondendo a elas conseguimos definir quais conteúdos poderiam ser consumidos, ordenados de forma a aumentar progressivamente a complexidade e cujas fontes foram classificadas e selecionadas levando em conta seu nível de autoridade sobre o tema.
As fontes teóricas foram classificadas por nível de autoridade e facilidade de consumo. No geral, quanto maior o coeficiente entre esses dois fatores, maiores as chances de um bom aprendizado sobre o tema.
Quando pensamos em níveis de autoridade, idealizamos uma escala de 1 a 3, sendo 3 o maior grau, representando no geral materiais publicados oficialmente pela própria Apple:
- Formações Swift e iOS da Alura
- Livros e autores O’Reilly Learning e plataforma Raywenderlich
- Apple Books, Documentações e Tutoriais
Já avaliando a facilidade do consumo, levamos em conta o formato de mídia utilizado, nível de suporte e facilitação para a transferência do conhecimento, a qualidade da produção, idioma, entre outros aspectos. Por essa visão temos uma classificação praticamente inversa à anterior.
Estabelecemos então uma estratégia que visava combinar estes dois fatores, favorecendo a performance no consumo, mas sem abrir mão de consumir e validar o conhecimento junto à fonte de maior autoridade.
Dado mais esse passo, temos uma ideia do que e onde estudar, mas ainda falta visão.
Onde esperamos chegar? Como organizar a sequência de eventos necessária para que tenhamos de fato um plano? Essas perguntas precisavam ser respondidas para gerar dois importantes elementos do planejamento.
Objetivos de capacidade
Precisávamos agora idealizar onde queríamos chegar e o que queríamos ser capazes de fazer com a tecnologia. Iniciar os estudos sem objetivos claros a serem atingidos poderia comprometer não só o andamento do processo mas também os resultados esperados ao final dele.
Depois desse exercício de olhar para frente e esboçar as capacidades desejadas, chegamos aos objetivos abaixo.
| Objetivos de Capacidade | |||
| Ser capaz de desenvolveraplicativos com aparência e usabilidade reconhecidas através de avaliações de usuário | Aprender Swift com profundidade. | Ter domínio do iOS SDKe entender os objetivos das decisões de design da plataforma. | Ter bons conhecimentos sobre os Guidelines da Apple para o desenvolvimento de apps. |
| Ter domínio sobre ferramentas e práticas de layout e usabilidade (UIKit, Swift UI). | |||
| Ser capaz de efetuar commits e tê-los aprovados através de Pull Request em projeto relevante para a plataforma iOS ou stack front da Zup. | Aprender Swift com profundidade. | Ter domínio do iOS SDKe entender os objetivos das decisões de design da plataforma. | Conhecer interoperabilidade com Objective-C e heranças do modelo de desenvolvimento anterior. |
| Estudar projetos Open Source. | Estudar e começar pelo Beagle. | ||
| Ser capaz de aplicar mentoria técnica (para JRs/PLs) com foco em desenvolvimento iOS de modo a contribuir coma evolução técnica de mentorandos | Aprender Swiftcom profundidade. | Ter domínio do iOS SDKe entender os objetivos das decisões de design da plataforma. | Ter bons conhecimentossobre os Guidelines da Apple para o desenvolvimentode apps. |
| Conhecer interoperabilidadecom Objective-C e herançasdo modelo dedesenvolvimento anterior. | Ter domínio sobre práticas de qualidade com Swift/iOS. | Ter domínio sobre ferramentas de gestão e segurança. | |
| Estudar sobre mentoria técnica. | |||
| Ser capaz de impactara plataforma móvel da empresa e a comunidade com minhas opiniões sobre o tema | Aprender Swiftcom profundidade. | Ter domínio do iOS SDKe entender os objetivos das decisões de design da plataforma. | Ter bons conhecimentos sobre os Guidelines da Apple para o desenvolvimento de apps. |
| Conhecer interoperabilidade com Objective-C e heranças do modelo de desenvolvimento anterior. | Conhecer funcionamento da LLVM e run time environment. | Consumir conhecimento que está sendo produzido pela comunidade em seus eventos. | |
| Seguir pessoas influentes na comunidade e consumir o que produzem. Interagir se possível. | Conversar com pessoasda Zup e comunidade:slack ios dev br. |
Além de elaborar os grandes objetivos de capacidade, foram listados elementos que se relacionam com as habilidades necessárias para atingi-los.
Com objetivos centrais de capacidade definidos, o quadro foi organizado por complexidade e o primeiro deles foi selecionado. “Ser capaz de desenvolver apps com aparência e usabilidade reconhecidas” que para viabilidade dado o contexto da Zup Edu pôde ser traduzido em “Ser capaz de reproduzir apps com aparência e usabilidade reconhecidas“.
Prática deliberada
Mesmo olhando para os objetivos de capacidade, algo ainda parecia fora do controle. Temos o objetivo, mas nada ainda que consiga guiar, de fato, o processo. Quais os passos que precisamos dar para chegar ao objetivo?
As fontes teóricas selecionadas já apresentavam uma série de atividades práticas e exercícios para ajudar a fixar o conteúdo estudado, mas além de não estimularem a repetição e recuperação de conteúdo de forma suficiente ao longo do processo de aprendizagem, praticar apenas por estes meios nos faria caminhar através do objetivo de aprendizagem de cada material ao invés do nosso.
Precisávamos de uma sequência de atividades práticas que aumentasse a dificuldade do desafio e alimentasse a busca por novas descobertas e desenvolvimento das próximas habilidades, nos aproximando do nível de complexidade necessário para atingir o objetivo de capacidade selecionado.
| Prática Deliberada | ||||
| Aplicativo da Casa do Código (simples – visão de admin) – CRUD de Autor- CRUD Livro | Capacidadesrelacionadas | Aprender Swiftcom profundidade. | Ter domínio do iOS SDK e entender os objetivos das decisões de design da plataforma. | |
| Habilidades técnicas | Type System, Variáveis,Constantes e Operadores. | Tipos Opcionais. | Coleções. | Controle de Fluxo. |
| Funções. | Classes, Structs e Protocolos. | Error Handling. | Tipos customizados. | |
| Closures. | UIKit. | Auto Layout. | Controles de Navegação. | |
| Data Fetching HTTP. | Gerenciamento deDependências(CocoaPods). | |||
| Aplicativo da Casa do Código (visão cliente) – Home com filtro- Tela de Detalhe (push/pop)- Tela de Checkout- Tela de Perfil | Capacidadesrelacionadas | Aprender Swiftcom profundidade. | Ter domínio do iOS SDK e entender os objetivos das decisões de design da plataforma. | |
| Habilidades técnicas | Habilidades doprojeto anterior. | Biblioteca de Fotos e Câmera. | Persistência. | View Code. |
| Design de Código. | Controles de Autenticaçãoe Autorização. | |||
| Gym.app – Splash Screen- Onboardinge Location Permissions- Login- Home (layout design)e Profile- Checkin (geolocation service;listagem de academiascom layout complexoe animações) | Capacidades relacionadas | Aprender Swift com profundidade | Ter domínio do iOS SDK e entender objetivos por trás das decisões de design da plataforma | Ter domínio sobreferramentas e práticas de layout e usabilidade |
| Habilidadestécnicas | Habilidades doprojeto anterior. | Design Patterns com Swift. | Arquitetura. | Formatação e Style Guide (SwiftLint). |
| Testes Unitários. | Testes de Integração. | Testes e2e. | Gestão de Permissões. | |
| Gestão de Senhas, Chaves e Secrets (iCloud Keychain?) | Gestão de Certificadose Profiles* | Beta Testing com Testflight* | Detalhes sobrepublicação na AppStore* | |
| Aplicativo do ITI – Login com Face Recognition/fingerprint scan- Abertura de Conta- Solicitação de Cartãode Crédito- Pix- Movimentações da carteira | Capacidades relacionadas | … | ||
| Habilidades técnicas | … | |||
Além de planejar os desafios com progressão de complexidade, para ter clareza sobre o que se desejava colocar à prova, relacionamos cada um deles com o grupo de habilidades envolvidas no desenvolvimento, assim como os objetivos de capacidade que estavam sendo endereçados no decorrer do trabalho.
*Atividades apenas de estudo aprofundado, sem contexto de execução real ou submissão do aplicativo para a loja.
A escolha dos temas dos apps desafio levaram em conta o conhecimento do domínio dos produtos, focando assim apenas em desenvolver os aspectos técnicos em cada atividade durante a execução do plano.
Com esses quatro grandes elementos combinados tínhamos então nosso plano de estudos estruturado e com ele a possibilidade de encarar cada fase do desenvolvimento de forma mais assertiva.
Implementação do plano de estudo
A partir desse ponto do trabalho tudo estava suficientemente claro. Tínhamos fontes de conhecimento curadas, objetivos traçados, uma série de desafios práticos relacionados a eles e que trabalhavam sucessivamente os grupos de habilidades que precisava desenvolver. Com a adição de alguns prazos para cada “entregável”, agora era só uma questão de executar cada passo.
Em ordem, durante a execução do plano, foram realizadas as seguintes atividades de estudo teórico e prática deliberada:
- Formação Swift/iOS na Alura e leitura de partes específicas do Apple Book The Swift Programming Language. (estudo teórico)
- Desenvolvimento do primeiro desafio: visão de administração da Casa do Código. (prática deliberada)
- Leitura e codificação dos exercícios do livro iOS Programming: The Big Nerd Ranch Guide. (estudo teórico)
- Desenvolvimento do segundo desafio: visão de cliente da Casa do Código. (prática deliberada)
- Raywenderlich.com Pro Articles and Courses. (estudo teórico)
- Leitura de capítulos específicos do Programming iOS 14: Dive deep into Views, View Controllers and Frameworks (Matt Neuburg) – O’Reilly Learning book. (estudo teórico)
- Desenvolvimento do terceiro desafio: App réplica de um famoso serviço de academias e bem-estar. (prática deliberada)
? Durante todo o processo de desenvolvimento foram realizadas consultas ao conteúdo da documentação oficial para assegurar a validade do conteúdo consumido.
? Os apps que foram construídos durante a prática deliberada dos conteúdos estudados podem ser encontrados nos links abaixo. A ideia era justamente codificar aplicações que explorem situações mais próximas da vida real e garantir a aderência dos conceitos.
Tudo correu bem e dentro do esperado. Mas não só graças a todo o planejamento. Como garantir que estamos caminhando na direção certa? Essa era a pergunta feita no início de cada fase de exploração e que levanta importantes pontos de atenção sobre o processo de execução de um plano de estudo.
Validando o aprendizado no decorrer do percurso
O plano serviu muito bem para iluminar o caminho, mas é sabido que durante qualquer jornada é muito possível que nos desviemos ao longo do percurso. Quando se trata então de uma jornada de aprendizado, o risco inerente é sempre o de ter uma falsa sensação de aprendizado, ou de forma mais simples o de “aprender errado”. Assim, um bom processo de estudos precisa contemplar formas de correção recorrentes. Só dessa forma conseguimos assegurar que estamos aprendendo de maneira adequada e avançando na direção do objetivo.
Correções recorrentes e a mentoria
Evidências apontam que as formas mais eficazes de aprendizado são aquelas que envolvem o acesso recorrente a um mestre especialista no assunto, como por exemplo, ter um professor particular nos guiando em todo o processo, fazendo as correções e ajustes necessários. No lado oposto dessa linha que representa a eficácia da forma de estudo se encontram os modelos com menor suporte de especialistas no tema, onde podemos imaginar o estudo de forma autodidata.
Fica clara a importância dessa variável na transferência de aprendizado. Quanto maior o acesso à correção externa, mais confiável tende a ser o resultado.
No nosso caso, como não era possível um modelo com suporte de um mestre totalmente dedicado ao processo de aprendizado, optamos pelo modelo com o maior suporte possível, adotando mentoria técnica.
A mentoria durante o processo de aprendizado se mostrou fundamental para a evolução do plano de estudo. Através de encontros semanais eram debatidos pontos da implementação dos projetos, bem como dúvidas técnicas de temas específicos. O mentor contribuiu para a calibração e aumento da auto-eficácia nos temas estudados, assim como ajudou a remover algum entendimento incorreto de materiais teóricos e a retirar vieses trazidos de experiências anteriores com outras plataformas e linguagens.
Ainda assim, como o acesso às correções não era instantâneo, e todo o trabalho era feito de maneira solo, em diversos momentos foi preciso estabelecer outras formas de se avaliar e corrigir. Então é possível afirmar que durante todo o processo as correções foram feitas progressivamente através de:
- Autopercepção da prática em relação à teoria estudada
Depende única e exclusivamente da percepção da própria implementação tendo como base o conhecimento construído empiricamente sobre qualidade e design de código, somado ao estudo teórico prévio dos conceitos. - Confrontação das implementações resultantes com o conteúdo de artigos e documentação relacionadas aos temas envolvidos
Reforça o anterior adicionando confrontação das implementações resultantes das tarefas com as dos exemplos construídos pelas fontes teóricas (ainda com viés de autopercepção). - Apontamento de possíveis correções e/ou melhorias pelo mentor técnico
Valida de forma mais concreta a aderência dos conceitos estudados, trazendo a visão de um profissional especialista, experiente na plataforma, além de levantar importantes discussões nas sessões de mentoria e através de revisão de código nos Pull Requests dos repositórios.
Práticas de Elaboração e Recuperação
Ao final das implementações e posterior aos ajustes necessários, como forma de reforçar e assegurar o entendimento, notas de ensino sobre descobertas e pontos importantes do aprendizado eram registradas.
Notas como as que estão presentes em alguns dos Pull Requests dos repositórios serviram como uma ferramenta de elaboração, onde se podia explicar e descrever ideias complexas sobre os temas estudados, e também de recuperação facilitada dos conceitos depois de aprendidos – assim como uma forma de compartilhar conhecimento com outras pessoas que possam seguir planos de estudo semelhantes sobre o tema.
Inspirações teóricas
Caso você esteja se perguntando se um belo dia acordamos e pensamos na criação de um plano bem elaborado e cheio de detalhes de implementação como esse, a resposta obviamente é “não”.
Assim como viemos construindo um senso de efetividade no processo de estudo desde as primeiras experiências trabalhando com educação em tecnologia, tivemos também muitas inspirações teóricas e práticas por trás de cada estratégia apresentada até aqui.
Ainda que falar sobre as teorias por trás do estudo não seja o intuito desse post – pois estamos apenas compartilhando um pouco da nossa história como aprendizes – caso se interesse, algumas das referências utilizadas como base para o processo de aprender e ensinar dentro da Zup Edu são as seguintes:
- The Learning Scientists – Downloadable Materials
- Understanding How We Learn – Book
- Four Component Instructional Design
Avaliando o resultado do processo
Como citamos anteriormente, é parte fundamental do processo se desafiar, avaliar e corrigir recorrentemente. Mas ao final de um ciclo de trabalho planejado pensamos que era importante, assim como analisar a qualidade dos apps construídos, uma maior exposição a avaliações externas, algo que fosse mais livre de vieses e representasse um bom desafio adicional.
Sendo assim resolvemos, além de coletar o feedback formal do mentor técnico, participar de processos seletivos para devs iOS em empresas que topassem ajudar no processo. Talvez a única diferença era que, ao invés de participar de um processo seletivo com uma régua definida (por uma vaga para Dev iOS PL, por exemplo) a ideia era fazer algo mais aberto, para que ao final os times técnicos das empresas nos dissessem se me fariam um convite para integrar o time e, caso o fizessem, para qual nível de senioridade ele seria.
Os processos seletivos incluíram duas fases bem comuns: um desafio de código e posterior entrevista técnica para aferir o conteúdo produzido e demais conceitos. Os processos seletivos foram realizados pelas empresas Abastece Aí e Loft, às quais agradecemos pela ajuda.
Abaixo é possível perceber os resultados.
- Feedback formal do mentor técnico:
“Sobre o Rafael, a evolução nos estudos de iOS dele foi bem sólida e consistente. Acredito que a sua bagagem de conhecimento em programação e as metodologias de aprendizado que ele usou foram essenciais para seu desempenho fora da curva.
Achei ele bem motivado, com vontade de querer aprender cada vez mais e fazia além do esperado nos seus estudos. No caso, sobre como ele seria avaliado aqui na Zup como dev iOS, suas experiências passadas são bem interessantes e ajudam na sua bagagem de conhecimento e a preencher alguns itens do role guide Sênior.
Como ele já atuou em desenvolvimento mobile híbrido, web, instrutor na área de programação, já participou de projetos, trabalhou em equipe, resolveu problemas complexos etc, isso é um diferencial. O próximo fator que seria analisado são as suas novas skills de iOS, os projetos que ele entregou, os conceitos que ele sabe, que consegue argumentar e entender bem. E vendo seus projetos, como ele fez e evoluiu, acredito que ele se encaixaria com o nível de desenvolvedor Sênior aqui na Zup. Talvez tenha alguns gaps para preencher ou melhorar, mas pelo seu processo evolutivo até aqui isso seria tirado de letra.”
Ginaldo Junior, Desenvolvedor Especialista iOS na Zup
- Feedback do time do Abastece Aí:
“A análise do profissional é feita normalmente em 3 pilares:
- Análise comportamental
Como o objetivo não era contratar o Rafael, para que tivéssemos o processo mais rápido e assertivo possível não realizamos essa análise, porém de forma geral ele é proativo, flexível e comprometido. Acreditamos que ele preenche todos os requisitos para atuar em times multidisciplinares com desafios intensos.
2. Análise prática
Compartilhamos com o Rafael o desafio: https://github.com/rafael-rollo/desafio-ios
Sempre preenchemos uma página com observações sobre a execução do teste com objetivo de tentar enquadrar o profissional no que reconhecemos dentro da empresa como Jr. Pl. Sr.
Ele realizou com muita maestria o desafio, utilizou recursos complexos para organizar a camada de network e propôs uma arquitetura bem assertiva ao desafio.
3. Análise comunicação
Soube contextualizar, e explicar todos os motivos pelos quais tomou as decisões que implementou. Possui habilidades sensacionais de comunicação.
Conclusão:
Rafael é um profissional ímpar, o time e eu o avaliamos como Sênior I, o que é realmente impressionante pelo tempo de estudo que ele dedicou ao tema.
Com certeza contrataríamos ele para o nosso time!”
Mauricio Olimpio, Mobile Chapter Lead na Abastece Aí
- Feedback do time da Loft:
“Em relação ao código do Rafael, gostei bastante, usou bons nomes de variáveis e métodos. Fez boa organização do código. Seguiu bem o proposto pelo padrão MVVM.
Não chegou a implementar testes unitários, porém me passou outro repositório para eu avaliar. Estava ok.
Deu para perceber que ele domina bem a linguagem Swift. Entretanto ele tem pouca bagagem. Não conhece tanto outros padrões de projeto e nunca publicou apps na App Store. Gostei que ele foi bem honesto e transparente nesse ponto.
Para mim ele seria um Pleno com potencial, justamente por ter pouca bagagem (com desenvolvimento iOS).”
Pedro Neves, Engineering Manager na Loft
Como é possível perceber, por diferentes que sejam as percepções das equipes, elas levantaram pontos importantes sobre o resultado, assim como alguns pontos de melhoria que com o tempo serão endereçados.
O processo de aprendizado é contínuo
Como demonstram alguns dos exemplos utilizados para ilustrar o plano de estudo na jornada de preparação com iOS, nosso processo de aprendizado com este plano de estudo ainda está em curso e ele tende a ser contínuo. Algumas partes importantes dos feedbacks mostram a necessidade de cobrir pontos ainda não atacados pelas atividades realizadas até aqui, e os pontos positivos mencionados servem como principal motivação para as novas iterações.
É importante destacar que alguns anos de experiência produzindo código, aprendendo e ensinando tecnologia contam muito e tendem a tornar o processo mais suave. Mas é inegável o quanto um plano estruturado de estudos pode reduzir o tempo necessário para aprender qualquer que seja o tema desejado.
E aí? O que achou desse relato? Sente que esse modelo pode ajudar você nos seus estudos? Tem alguma outra abordagem de preferência? Compartilhe com a gente suas opiniões.
Espero que tenha gostado da leitura! ?
