LO
Informática
Forma-te para modelar um problema com precisão suficiente para uma máquina o executar, e para raciocinar sobre o que acontece quando o faz em escala, sob falhas e com alguém a atacá-lo.
Começa a pasta semanal de revisões de código. Quatro entradas até ao fim do semestre são melhor sinal do que qualquer certificado.
Um único número para um curso inteiro esconderia o que importa: este curso treina várias competências distintas, e nem todas se estão a mover no mesmo sentido. A automatização atua sobre tarefas, por isso qualquer avaliação vive nas páginas de profissão em baixo, e não aqui.
Escrito para os cursos de quatro anos de informática e de engenharia de software. Os programas da via de investigação e os centrados em hardware são materialmente diferentes.
O que é que este curso treina mesmo#
Não o plano de estudos: as competências que estão por baixo, e se cada uma vale mais ou menos do que valia.
Modelar um problema com precisão
Vale mais do que antesTransformar algo que uma pessoa descreveu de forma vaga numa especificação sem casos indefinidos.
A geração está a jusante da especificação e amplifica uma especificação errada mais depressa do que uma pessoa teria feito. Quem escreve a especificação determina agora mais do resultado do que quem escreve o código.
Raciocinar sobre as falhas
Vale mais do que antesSaber o que se parte com a concorrência, com uma falha parcial e com uma entrada inesperada, antes de se partir.
É aqui que o teto do código gerado se vê mais claramente. O código fluente que está errado sob carga parece idêntico ao código correto até estar em produção.
Ler um sistema desconhecido
Vale mais do que antesTer na cabeça o suficiente da base de código de outra pessoa para saber que observação seria decisiva.
À medida que mais código é produzido por máquina, mais parte do posto é ler código que ninguém escreveu à mão. Rever código plausível mas errado é uma competência distinta e recentemente central.
Escrever código de rotina
Vale menos por si sóProduzir implementações corretas e idiomáticas de coisas bem especificadas.
Bem especificado, muito representado nos dados de treino, e verificável de imediato executando-o: o caso mais forte para a geração de código. Mas repara: não consegues julgar código que não terias sabido escrever, por isso isto continua a ser um pré-requisito mesmo deixando de ser um produto.
Fundamentos
Mantém-seComplexidade, estruturas de dados, modelos de concorrência, como um computador executa de facto.
A parte do curso que mais devagar caduca e que não se tira de um tutorial. É o que te permite raciocinar sobre um sistema que nunca viste.
Aonde pode levar#
9 direções, nunca uma. Cada uma está escrita por extenso na sua própria página: o que a tua formação reaproveita, o que costuma faltar a quem se licencia, a realidade de entrada e uma coisa para testar este semestre.
- Engenharia de software, entrando de propósito · Programador de software júnior →
- Domínios onde errar sai caro · Programador backend →
- Entre a engenharia e o problema
- Pensamento de engenharia numa área que não é software
- Testes e engenharia de qualidade · Testador de software / engenheiro de QA →
- Pôr a IA em produção dentro de uma empresa · Responsável de implementação de IA →
- A camada em que as pessoas mexem mesmo · Programador frontend →
- As condutas, e quem responde pelo que sai · Engenheiro de dados →
- Sistemas cujo comportamento é aprendido · Engenheiro de aprendizagem automática →
Lê-as todas por extenso: o que serve, o que falta, o que testar →
Aonde leva segundo a tabela oficial, ao lado dos nossos percursos →
O que acrescentar fora da sala de aula#
Isto é sobre o que costuma faltar na prática a quem se licencia; não é uma acusação de que a tua escola não o ensinou.
Tempo numa base de código com consequências reais: um estágio, um projeto aberto de que há gente dependente, qualquer coisa em que errar tenha consequência. Os projetos de brincar não conseguem ensinar critério porque não há nada em risco.
Rever código de outras pessoas, incluindo código gerado, de propósito e com regularidade. É a competência de que o mercado anda com falta e a que a universidade menos avalia.
Escrever. Documentos de desenho, relatórios de incidentes, explicações. Quem avança em engenharia são aqueles cujo raciocínio os outros conseguem seguir.
Este semestre#
Uma ou duas ações, e cada uma produz algo que podes mostrar a alguém. Não é uma lista de leituras.
Começa a pasta semanal de revisões de código. Quatro entradas até ao fim do semestre são melhor sinal do que qualquer certificado.
Lê de ponta a ponta um sistema em produção de uma área onde a correção sai cara. A profundidade num sítio ganha à amplitude em cinco.
Perguntas frequentes#
Vale, mas por uma razão diferente da de há cinco anos. O curso valia porque te permitia produzir código; agora o valor é permitir-te julgar código, e não consegues julgar o que não terias sabido escrever. O que mudou de facto foi o mercado de trabalho na ponta de entrada: o trabalho de rotina que antes pagava a gente júnior enquanto ela desenvolvia critério é a parte que está a ser automatizada. Ou seja, a formação continua a funcionar, mas o velho arranjo em que o teu primeiro emprego te ensinava à custa da folha de pagamentos de outro está a enfraquecer. Planeia essa lacuna explicitamente em vez de partires do princípio de que o primeiro emprego a fecha.
A informática é o caso estranho: as ferramentas são melhores exatamente naquilo que o curso te ensina a produzir, e o emprego de entrada a que dá acesso está no grupo em que o emprego dos trabalhadores mais jovens caiu. Esse é um argumento real, e não é um argumento para sair: é um argumento para entrares com um plano de como vais chegar ao trabalho de critério, porque o degrau de programação de rotina que antes te levava lá adelgaçou.
Vale a pena quando muda para o que te podem contratar (investigação, sistemas, uma especialidade com poucos praticantes) e não vale a pena como forma de esperar que passe um mercado de recém-licenciados fraco. Um mestrado que ensina as mesmas competências de produção um nível acima compete com as mesmas ferramentas. Verifica o laboratório ou o grupo concretos, e não o nome do grau.
Alguma coisa que tenhas depurado e não tenhas escrito. Ler código fluente mas errado com cuidado suficiente para encontrar o que está confiantemente partido é a tarefa que este sítio assinala como recentemente central, e é a única coisa que um portefólio de projetos gerados não consegue demonstrar. Um contributo real para uma base de código que não começaste ganha a cinco projetos pessoais acabados.
Método#
As avaliações vivem sobre tarefas, não sobre cursos. Segue qualquer uma das direções em cima até à sua página de profissão para veres que tarefas estão a mudar, que força tem a prova, e o que ela ainda não mostra.