How do you acquire the fundamental computer skills to hack on a complex systems project like OCaml? What’s missing and how do you go about bridging the gap?
KC gives several resources for students to get up to speed with contributing to OCaml.
One of the interesting resources is MIT’s the Missing Semester. This semester I created our own version of this course, covering git, docker, VMs, terminal/bash, testing, static analysis and LLMs for code.
While we cover how to do a Pull Request, I don’t believe students are ready to actually contribute. Reading large codebases is a skill that even our graduate MSc students don’t have. Courses are designed to be contained, with projects that need to be graded with few human effort, resulting in standard assignments for all the students.
I would love to run something like the Fix a real-world bug course Nuno Lopes runs. But being able to review so many PRs is a bottleneck in a regular course.
To really understand a concept, you have to “invent” it yourself in some capacity. Understanding doesn’t come from passive content consumption. It is always self-built. It is an active, high-agency, self-directed process of creating and debugging your own mental models.
If ChatGPT can produce research papers that are indistinguishable from what most scientists can write, then maybe scientists can focus on actually advancing science—something that ChatGPT has thus far proven unable to do.
Looking at the proceedings of our conferences over the past few years, I find that most of the papers are simply uninteresting. Moreover, it seems that every first-year PhD student is now required to write a systematic review on their topic — supposedly to learn about the field while producing a publication.
Let me be blunt: every systematic review I’ve read has felt like a waste of time. I want to read opinionated reviews written by experts — people who have seen enough to have perspective — not by PhD students who have just skimmed the past decade of papers on Google Scholar.
We need far fewer papers (I’m doing my best to contribute to that cause), and the ones we do publish should be bold, revolutionary, and even a little irreverent. We need innovation and the courage to break expectations. Incremental research has its place, but that doesn’t mean it always needs to be published.
To make this possible, evaluation committees — both nationally and within universities — must rethink their processes to move away from bean-counting metrics. Our current incentive system discourages genuine peer review, and even when proper reviews happen, they often waste effort on work that adds little value.
Otherwise, yes — the bean-counting-reinforcement-learning AIs will take our jobs.
No caso das licenciaturas, estas taxas servem para as universidades públicas receberem mais dinheiro do que a propinas que está definida por lei. A nível de doutoramento, serve para manter o valor da propina naquele que a FCT suporta nas suas bolsas (2750 euros).
A verdade é que os alunos vêem um preço anunciado, e depois é-lhes impossível acabarem o curso pagando apenas esse valor. É literalmente publicidade enganosa.
Precisamos de duas mudanças: eliminação das taxas por parte das Universidades e Politécnicos, englobando esse custo na propina. Um aluno pagando a propina, deve conseguir ter acesso a assistir às aulas, ser avaliado e obter o diploma, sem qualquer taxa.
E o estado precisa de majorar o financiamento das universidades, que claramente têm de recorrer a estas acções eticamente discutíveis para manter a sustentabilidade económica que lhes é exigida pelo Tribunal de Contas.
Every day I am convinced that Software Engineering should be taught without AI. AI can give you answers to easy problems. But you won’t be able to create mental models of how things work, which will help you solve hard problems.
This next semester I am teaching a course on practices and tools in Software Engineering (my take will be inspired by MIT’s The Missing Semester). AI usage will be one of the topics, where we will explore MCP, IDE integrations and AI-assisted documentation.
But I have no idea how to write assignments for other topics. It is very likely that an AI will be able to complete the assignment without any human intervention. If students opt to do that (they will, that’s the faith I have in our grade-oriented system), they will not achieve the learning outcomes.
Students will question: if AI can do these tasks, why should we learn it? Well, math teachers in school still assigned me problems that machines could already solve by then. But creating mental models of how things work is essential in education.
Now the real question is about the incentives. We should assess whether students can use their mental models, and not whether they can solve the task. Especially with 100 students, where exams or take-home assignments are the norm.
In 2010 Carmen Reinhart and Kenneth Rogoff published Growth in a Time of Debt. It’s arguably one of the most influential economics papers of the decade, convincing the IMF to push austerity measures in the European debt crisis. It was a very, very big deal.
In 2013 they shared their code with another team, who quickly found a bug. Once corrected, the results disappeared.
Greece took on austerity because of a software bug. That’s pretty fucked up.
As more and more scientific publications are dependent on code, trusting code is more and more needed. Hillel asks for solutions, I propose to tackle the problem in two fronts.
1 – More engineering resources
Writing production-level quality software requires larger resources (usually engineerings, but also some tooling). Most scientific software is written once and read never. Some PhD or MSc student writes a prototype, shows the plots to their advisors who write (some or most of) the paper. It’s rare for senior researchers to inspect other people’s code. In fact, I doubt any of them (except if they teach software engineering principles) has had any training in code inspection.
We need research labs to hire (and maintain) scientific software engineering teams. For that to happen, funding has to be more stable. We cannot rely on project funding that may or may not be awarded. We need stable funding for institutions so they can maintain this team and resources.
2 – More reproducibility
Artifact Evaluation Committees are a good addition to computer science conferences. Mostly comprised of students (who have the energy to debug!), they run the artifacts and verify whether the results of the run justify the results presented in the paper. Having done that myself in the past, it is very tricky to find bugs in that process. Mostly we verify whether it will run outside of your machine, but not whether it is rightly implemented.
What would help is to fund reproduction of science. Set 50% of the agency funding for reproducibility. Labs that get these projects should spend less than the original project to reproduce the results (and most of the challenging decisions are already made). In this approach, we will have less new research, but more robust one.
Given how most of the CS papers are garbage (including mine), I welcome this change. We need more in-depth strong papers that move the needle, and less bullshit papers that are just published for the brownie points.
Overall we need better scientific policies with the right incentives for trustworthy science. I wonder who will take this challenge on…
I remember having side-projects suggestions during my courses. Maybe that’s something I have to incorporate in mine.
Most of what I’ve learned during my degree was doing side-projects. From competing in hackathons, creating a junior company, organizing conferences, doing a couple of research internships, and doing some freelancing work, these projects all taught me something that was not in the syllabus. That’s what separates you from the average student, and what will get you a good job in a world where unemployed software engineers are aplenty.
The last four will give you an heads up in the programming language world. I might even have an internship for you.
Perhaps you’re a user of LLMs. But I might suggest resisting the temptation to use them for projects like this. Knowledge is not supposed to be fed to you on a plate. If you want that sort of learning, read a book – the joy in building toy projects like this comes from an exploration of the unknown, without polluting one’s mind with an existing solution.
Recommended audience: Startups and large companies who intend to sell software to universities.
Most SAAS is sold on a per-seat basis. But this does not scale to universities, as we have a large number of possible seats, but most of them (students, possibly from different scientific areas) do not use the software, at least for it to be worthwhile.
On the other hand, unpredictable costs (when paying per activity) is also something that does not work, as we need other budget it yearly.
My first day of uni, I received these two t-shirts designed by the student group.
While I completely forgot about the top one, I keep the bottom one near my heart. While I found it amusing, I did not find it to be true. I did learn a lot during these years, and I gained much more than the degree (which is only required for the Portuguese bureaucratic system where Simon Peyton Jonescouldn’t even get a position as Assistant Professor).
Now 19 years later, I no longer find it to be funny. I feel the scholarly spirit is dying and young people do not care about learning or knowledge. They care only about grades and getting the degree. And GPT is the TLA that takes them from the donkey without the diploma to the donkey with the diploma.
This tradition started back when I was a student. I installed random software for each of the 5 courses I took every semester. I ended up with wasted disk space, random OS configurations and always a complete mess in my $PATH.
So I started formatting my Macs at the end of every semester. And I continue doing that today. Being a professor, I also deal with the software baggage every same semester — otherwise I would probably format it every year.
Most of the people I know think this is insane! Because they spend days in this chore, they avoid it as much as possible, often delaying it so much that they end up buying a new computer before considering formatting. And they also delay buying a new computer for the same reason.
My trick is simple: I automate the process as much as possible, such that it takes ~20 minutes now to format and install everything, and another 2 hours to copy all data and login into the necessary accounts. And you can watch a TV Show while doing it.
I keep a repository with all my dot file configurations, which also contains scripts to soft link all my configurations (usually located at $HOME/Code/Support/applebin) to their expected location ($HOME). This process also includes a .bash_local or .zsh_local where I introduce machine or instance-specific details that I don’t mind losing when I format it in 6 months. Long-lasting configurations go in the repo.
If the machine runs macOS, I also run a script that sets a bunch of defaults (dock preferences, Safari options, you name it) that avoid me going through all settings windows and configuring it the way I like it.
But the most useful file is my Brewfile, that contains all the apps and command-line utilities I use. I should write another usesthis, where I go through all the apps I have installed, and why.
My process starts with copying my home directory to an external hard-drive (for restoring speeds). During this process I usually clean up my Downloads and Desktop folders, which act as more durable /tmp folders. When it’s done, I reset my MacBook to a new state. I then install homebrew and Xcode command line utilities (for git), I clone my repo and run the setup script. At the same time, I start copying back all my documents from the external drive back to my Mac. Then it’s time to do something else.
Two hours later, I can open the newly installed apps and login or enter registration keys, and make sure everything is working fine.
“scientists often use code generating models as an information retrieval tool for navigating unfamiliar programming languages and libraries.” Again, they are busy professionals who are trying to get their job done, not trying to learn a programming language.
Very interesting read, especially since we teach programming to non-CS students, which is fundamentally different. Scientists are often multilingual (Python, R, bash) and use LLMs to get the job done. Their goal is not to write maintainable large software, but rather scripts that achieve a goal.
Now I wonder how confident they are that their programs do what they are supposed to do. In my own research, I’ve found invisible bugs (in bash, setting parameters, usually in parts of the code that are not algorithmic) that produce the wrong result. How much of the results in published articles is wrong because of these bugs?
We might need to improve the quality of code that is written by non-scientists.
Advice people with long careers on what worked for them when they were getting started is unlikely to be advice that works today. The tech industry of 15 or 20 years ago was, again, dramatically different from tech today. I used to joke that if you knew which was was up on a keyboard, you could get a job in tech. That joke makes no sense today: breaking into the field is now very difficult, and getting harder every year.
The industry is undervaluing junior developers, by thinking LLMs can do their work. This is true at this instant, but junior developers have the potential to become senior developers.
I still remember years when my team did not have interns at Uber; and years when we did. During the time we did: energy levels were up, and excluding the intern I’d wager we actually did more. Or the same. But it was a lot more fun. All our interns later returned as fulltime devs. All of them are now sr or above engineers – at the same company still (staying longer than the average tenure)
It is up to your faith whether LLMs can eventually be promoted to senior developers (or management). And if you believe it, you may need to reconsider your own job.
I’m pretty sure that the most popular programming language (in terms of number of people using it) on most campuses is R. All of Statistics is taught in R.
End-user programmers most often use systems where they do not write loops. Instead, they use vector-based operations — doing something to a whole dataset at once. […] Yet, we teach FOR and WHILE loops in every CS1, and rarely (ever?) teach vector operations first.
The main take away is that you do not teach Programming 101 to non-Software Engineering/Computer Science the same way you teach to those students. The learning outcomes are different, and so should the content.
Funny how Functional Programming (via vectorized operations) is suggested to appear first than imperative constructs like for or while. This even aligns with GPU-powered parallelism that is needed when processing large datasets.
1. A candidatura é feita pelos possíveis investigadores doutorados. Isto não faz sentido: a candidatura apoia as entidades (privadas ou públicas) e portanto estas deveriam ser as candidatas. Na situação actual mostra um compromisso maior realizar a candidatura do que escrever apenas uma carta de apoio (proposta actual). Mas na realidade, a entidade deveria-se candidatar ao apoio para a vaga, independentemente da pessoa que for ocupar a vaga (nem submetendo o currículo). É que estes resultados demoram meses a sair, e no entanto os candidatos actuais de topo acabam por arranjar outras alternativas.
2. Estão excluídos os candidatos que já tenham um contrato sem termo. Ora uma pessoa que para financiar o seu doutoramento tenha conseguido uma posição de técnico sem termo, termina o doutoramento e não pode concorrer a estes apoios. É uma restrição completamente desnecessária.
Carga lectiva até 4 horas (opcionais segundo o BE, decidido pelas instituições nas outras duas versões).
Permite alguma mobilidade entre a carreira de docência e investigação, mantendo o ordenado original.
Análise
Alinhamento com carreira docente
O alinhamento com a carreira docente parece-me um ponto positivo, em geral, visto que a diferença entre as duas carreiras se distinguem pelo peso da componente lectiva. Honestamente, parece-me um esforço desnecessário fazer uma carreira separada, quando bastava propor uma carreira única, onde a componente lectiva podia ser variável entre 0 a 100%, sendo a avaliação proporcional a essa fatia. Leis mais simples perduram mais tempo.
Infelizmente os graves problemas que existem com a carreira docente são transpostos para a carreira de investigação:
O período experimental é demasiado elevado. Quando comparado com o privado e outras áreas da função pública, os contratos permanentes são atribuídos nos primeiros 2-3 anos ou mesmo na celebração do contrato. Porque não podem as universidades e centros a liberdade de oferecer à tenure imediata a candidatos de excelência e CV apropriado.
Dá-se importância à agregação/habilitação. Embora seja mais fácil contratar investigadores de entidades estrangeiras onde não exista este título, é exigido na mesma aos nacionais que estejam na indústria. Devíamos descartar a necessidade de habilitação para qualquer posição: o currículo científico já é avaliado na totalidade pelo júri. A existência deste requisito não é justificado, senão para alinhar com a docência (onde também não encontro justificação).
Investigadores Auxiliares não gerem projectos. A separação entre investigador auxiliar e principal baseia-se no princípio que os principais gerem projectos. Ora a realidade é que os investigadores auxiliares gerem projectos (desde exploratórios até aos projectos de 3 anos FCT), criando uma situação impossível. Nesse caso, bastava serem investigadores principais de um projecto financiado para progredirem automaticamente para a categoria de Investigador Principal.
Os investigadores não doutorados têm de ser doutorandos. Não existe enquadramento para investigadores que não tenham nem queiram ter doutoramento. Passaram por mim já alguns jovens que queriam ser investigadores por alguns anos sem tirarem doutoramento. Estão satisfeitos com a formação de mestrado e estão a ser produtivos (com vários artigos publicados como primeiro autor). Porquê exigir que todos tenham doutoramento?
Avaliação de 3 em 3 (ou 5 em 5) anos é insuficiente. Tal como na docência, um período experimental de 5 anos (ou limite de 3 anos para convidados) torna uma avaliação ao final de 3 anos insuficiente para alterar o curso. Devemos promover avaliações ao final de semestres ou pelo menos anuais para docentes/investigadores convidados ou em período experimental. Assim, há de facto feedback útil para melhorarem.
Curiosamente, um grupo de investigação do meu departamento tem já feito trabalho na área, tendo lançado dois modelos (Albertina e Gervásio) em Português Europeu. Deu agora uma entrevista muito educativa ao Dinheiro Vivo:
Por exemplo, um banco quer apenas ter um assistente virtual para os seus clientes, que fale acerca de depósitos, levantamentos, etc. Não vai querer que o seu chatbot faça tradução automática, sumarização, dê a biografia do Friedrich Nietzsche e faça piadas.
Um LLM não é um chatbot. Um LLM é, numa analogia que as pessoas compreendem, uma espécie de um motor e a partir de um motor nós podemos fazer diferentes modelos de carros. O LLM é aquilo sobre o qual se pode desenvolver diferentes aplicações, uma das quais é o chatbot, outra, por exemplo, a tradução automática, ou o diagnóstico médico, etc.
Então, a nossa proposta nesse artigo de opinião, que saiu no Público em fevereiro de 2023, é que o que precisamos de uma IA aberta e de desenvolvimento de LLMs em código aberto, licença aberta e distribuição aberta para que outros atores e outras organizações, seja da investigação, seja da administração pública, seja do setor da inovação, possam eles próprios construir as suas propostas de valor e tirar partido desses LLMs sem estarem dependentes do fornecimento desses serviços, das big techs. Portanto, quanto mais houver uma oferta cada vez mais variada, mais se reduz o risco de dependência de um pequeno oligopólico que nos fornece esses serviços.
Acabaste de entrar em Engenharia Informática numa das universidades ou politécnicos em Portugal? Se não fazes ideia do que te espera, este post é para ti. Baseado nas minhas próprias experiências como aluno, e nos mais de 15 anos de docência em engenharia informática, deixo aqui alguns esclarecimentos e dicas de como melhor aproveitar esta nova fase da vida.
Ensino Superior vs Secundário
Enquanto passar do ensino básico para o secundário não teve mudanças significativas, entrar na universidade é um passo radical, por vários aspectos.
O primeiro é que são considerados maiores de idade (mesmo que entrem com 17 anos, como foi o meu caso). Já mais ninguém vai ver as vossas notas (nem mesmo os colegas), nem verificar as vossas faltas. Por isso, cabe-vos a vocês fazerem essa gestão, de forma responsável. Para alguns, entrar na universidade implica sair de casa dos pais e mudar de localidade. Essa mudança é óptima para um crescimento pessoal, mas também exige muito mais responsabilidade.
O segundo aspecto de diferença é o tamanho das turmas e consequente relação professor-aluno. Um professor fàcilmente tem entre 100 a 400 alunos por semestre (muito superior aos 60-90 do secundário). Portanto os professores não vão criar uma relação tão próxima com todos os alunos, ou preocupar-se se estão a ter um fraco aproveitamento. De notar que os chumbos no superior são bem mais comuns que no secundário, e por isso os professores não fazem disso um bicho de sete cabeças, nem leva a reuniões no final do ano onde ainda se pode salvar o aluno. Se chumba no projecto ou exame, chumba e que faça para o ano. Cabe-te a ti como aluno comunicar ao professor que dificuldades estás a ter, bem como dar feedback sobre a cadeira. Naturalmente os professores criam ainda alguma ligação com os alunos que vão às aulas e são participativos.
Ainda outra diferença é o facto de que, em engenharia informática, a avaliação não se resume a testes e exames. São poucas as cadeiras que são avaliadas apenas por exame. Normalmente têm exames, mais projectos (e eventualmente mais mini-testes, fichas nas aulas e outros). Mas aquele onde mais se aprende é nos projectos, que simula o tipo de tarefas que vão fazer quando acabarem o curso. E é nos projectos que vão aprender a ser engenheiros de software, que vão aprender a programar e a resolver problemas. É muito tentador na primeira cadeira de programação pedir ao ChatGPT (ou ao colega do lado) a solução do exercício. E embora possam passar à primeira cadeira com boa nota, estão a garantir o chumbo nas cadeiras seguintes. A ideia é que quando acabarem o curso vocês dominem o vosso computador (e outros tantos) e consigam fazer tudo aquilo que desejarem, sem se sentirem perdidos. Não tomem atalhos, e aproveitem para tornar os vossos projectos algo de que se orgulhem e possam mostrar na vossa primeira entrevista de emprego.
Dou-te o primeiro truque secreto para passar a qualquer cadeira: todos os professores têm todas as semanas um horário em que estão no seu gabinete disponíveis para esclarecer quaisquer dúvidas. Se há algo que não estás a perceber, dá um salto no gabinete e tens a dúvida tirada pela pessoa que mais percebe do assunto (e te vai avaliar mais tarde). Quase ninguém aproveita esta oportunidade bem escondida, pelo que, com sorte, podes ter o professor quase uma hora só para ti!
A última diferença a nível de ensino é que não existe bem o conceito de turma que tem todas as aulas juntos. Conforme a disciplina e a tipologia (teórica em anfiteatro, ou teórico-práticas ou práticas laboratoriais), as turmas vão ser diferentes. Esta diferença implica um desenvolvimento de uma ginástica social maior, porque precisam de ser mais activos no vosso círculo de amigos.
O que é Engenharia Informática
Porque escolheste Eng. Informática? Muitos dos candidatos escolheram este curso porque há muito emprego, e gostam de estar no computador (normalmente a jogar jogos, redes sociais e afins).
Há uma fatia ainda significativa que não gostam de engenharia informática (apesar de poderem gostar de informática), e demoram imensos anos a fazer o curso. Conheço também vários casos que depois de um primeiro ano de frustração, decidiram mudar de curso para onde foram ser mais felizes. Se não for o que gostam, não tenham medo em mudar para outra coisa. Um ano “perdido” é na verdade um ano ganho, se a alternativa for demorar 7 anos a acabar o curso de informática sem nenhum prazer.
Desde o primeiro dia que deves tentar perceber o que faz um engenheiro informático. E não estou a falar da versão romantizada das séries e filmes. Um engenheiro típico não passa o dia em salas escuras com terminais pretos a entrar ilegalmente em sistemas do FBI, NASA ou companhia, em menos de 30 segundos. Apesar de existirem especialistas de segurança que o fazem, trata-se uma minoria dos profissionais.
Outro motivo popular para escolher Engenharia Informática é porque gostam de jogos de computador e gostariam de criar jogos. Mais uma vez, apenas uma minoria acaba por conseguir fazer isto, talvez por ser muito exigente, tanto tècnicamente como socialmente.
Uma noção mais realista do protótipo de engenheiro informático envolve as seguintes tarefas:
Arquitectura, realizado por elementos mais seniores, com muita experiência em projectos semelhantes
Desenvolvimento (Sobretudo programação), realizada por elementos mais juniores da equipa.
Testes, tarefa realizada por membros que podem não ser engenheiros sequer
Suporte, consiste em ajustar configurações, corrigir bugs, e lidar com clientes (ou representantes deles)
Existem outras tarefas menos representativas, como gestão de sistemas ou administrador de bases de dados (que estão cada vez mais a fazer parte do desenvolvimento).
Finalmente, existe outra actividade que todos fazem parte, e cuja duração aumenta à medida que progridem na carreira: gestão de equipas e gestão de produto/projecto. Se escolheste informática para evitar ter de lidar com pessoas, isso não vai acontecer de todo.
O mais provável quando acabares o curso é passares 20% do tempo a perceber o problema que te deram e a desenhar uma solução (como se fosse um puzzle de lógica ou um problema de matemática) e os restante 80% a tentar perceber porque é que a solução que encontraste falha em alguns casos. Esta realidade é normalmente uma fonte de frustração para os alunos, especialmente porque os problemas no secundário eram fechados (as soluções vinham de um conjunto de 5 ou 6 alternativas dadas durante o ano) e havia uma resposta certa. Em informática, as alternativas são quase infinitas e os problemas estão normalmente sub-especificados. Estamos mais perto do mundo real, não de exercícios académicos.
Dito isto tudo, para quem tem gosto em construir coisas ou resolver problemas difíceis, esta é uma profissão que pode trazer muita satisfação (com algumas dores de cabeça, como é óbvio). E para quem é bom, paga muito bem.
Quatro receitas para o sucesso
1. Ir às aulas
Como expliquei, ir às aulas é opcional. No entanto, os alunos que vão passam quase todos, e os que faltam chumbam quase todos. E quem chumba no primeiro ano (ou pior, passa com 10 ou 11 sem perceber nada) acaba por chumbar também em anos seguintes. Portanto só há em ganhar em ir às aulas, certo?
Bem, os teus colegas de anos anteriores não concordam a 100%. Pré-covid, faltavam para ir a festas até às tantas, e faltavam às aulas para dormir. Depois de faltar durante o primeiro mês nas festas de recepção, percebiam que já tinham perdido o fio à meada, e faltavam também o resto do semestre. Pós-covid, penso que os alunos acham que estudar em casa pelos vídeos gravados é suficiente. Spoiler alert: não é! E esses alunos acabam por chumbar também.
Ir às aulas é a receita para fazer o curso com sucesso. Em primeiro lugar, criam-se laços com colegas de curso (laços esses impossíveis de serem criados no Discord, visto que 90% da comunicação é não-verbal), colegas esses que vos vão ajudar a manter focados, a tirar dúvidas, apoiar quando estiverem com dificuldades ou abatidos, e em festejar depois de se livrarem de uma cadeira. Notem que, em informática, é normal ficar mais umas horas na universidade a fazer trabalhos em salas que existem para o efeito. Aproveitem bem esta oportunidade. As ligações feitas nestes momentos não se comparam aos discords e whatsapps. É também um bom treino para a interação que vão ter no mundo de trabalho.
Finalmente, ir às aulas permite esclarecer dúvidas em tempo real, ganhar experiências e dicas que não estão nos slides, nos livros ou na internet. Em grande parte das vezes as respostas às perguntas do exame são dadas nas aulas teóricas e práticas. É uma grande vantagem estar presente!
2. Não deixar para a última
No seguimento de ir às aulas, a segunda dica é fazer os projectos quando o enunciado é lançado. O principal motivo é porque os alunos são muito maus a estimar o tempo que demoram. Primeiro, porque acham que os trabalhos demoram o mesmo tempo que os exercícios nas aulas (não é bem verdade), segundo porque assumem que se lembram de tudo nas aulas (não é verdade se não os fizerem logo) e em terceiro porque se esquecem que a informática tem muitos meandros, que podem tornar uma simples tarefa muito demorada (lembram-se dos 80% a resolver problemas com a solução?).
E fazer o trabalho no dia que sai o enunciado tem a vantagem de ainda se lembrarem das dicas que os professores deram nas aulas. Passado duas semanas, perto da deadline, essas dicas já foram há muito esquecidas.
E por mais que achem que trabalham melhor sob pressão, isso não é verdade. Chama-se procrastinação, e fazer as coisas em cima da hora não dá tempo para testar e afinar, coisas essenciais nos trabalhos de informática.
3. Grupos
Em informática, a maior parte dos trabalhos são em grupo, e ter um bom grupo é meio caminho andado para ter boa nota.
Em primeiro lugar, tenta encontrar colegas que tenham as mesmas cadeiras que tu. Isto vai fazer com que estejam sempre alinhados nas mestas, e trabalhem ao mesmo tempo. Grupos com cadeiras diferentes (e de diferentes anos) vai resultar em trabalhares num projecto sozinho, que o teu colega está a trabalhar noutro. Depois os professores apercebem-se disto (é muito fácil, sobretudo com discussões), e podem os dois ter 0 no trabalho, e ser acusados de plágio.
O segundo critério é que os teus colegas de grupo estejam mais ou menos ao teu nível, seja em motivação para fazer a cadeira, seja em capacidades de fazer o trabalho. Juntar um aluno de 20 e um aluno de 11 é uma excelente receita para ambos passarem à cadeira, mas o de 8 vai chumbar a todas as cadeiras seguintes por falta de bases. Dois alunos de 11 com motivação facilmente têm uma nota melhor, e ficam com as bases para os anos seguintes.
4. Actividades
Uma das melhores coisas do ensino superior é conhecer pessoas com interesses iguais. Para isso sugiro que olhes para os núcleos e grupos da tua universidade (desde grupos culturais, tunas, rádio, desportos etc..) e experimenta dois ou três. É muito importante teres também um grupo social fora do curso, para perceberes as diferentes realidades no mundo. Nem todas as pessoas vão ser eng. informáticos bem pagos. Muitos outros cursos vão ter baixa empregabilidade, ou dificuldades em fazer trabalhos de campo, ou festas bem mais interessantes, ou rádios de género bem diferentes do de informática. É bom ter contacto com outras realidades.
Pessoalmente, recomendo contra ocuparem-se com jogos de computador. Já vais passar imenso tempo em frente ao ecrã a fazer os trabalhos e deves cortar no tempo em ecrã para fins recreativos. É uma questão de saúde: a vossa vista vai diminuir, vão ter problemas de costas, pulsos e outros. Para que tenhas uma carreira (e vida) longa, recomendo que escolhas actividades ao ar livre ou com actividade física para compensar a ausência disso no teu curso. Pessoalmente, sou fã de jogos de tabuleiro como alternativa a jogos de computador, mas certamente a tua universidade tem várias actividades por onde escolheres.
Perguntas frequentes:
Que computador comprar?
É um mito que precisam de um computador super potente para fazer o curso de informática. A coisa que pode ser mais exigente é correr máquinas virtuais, que nos dias que correm, qualquer computador mediano suporta. As minhas recomendações para um computador que dure a faculdade inteira é um portátil com pelo menos 16GB de RAM, 512GB de disco, e um processador Intel Core i3, AMD ou ARM. Uma placa gráfica integrada serve perfeitamente, e uma gráfica potente só ajuda nos jogos de computador, aquilo que queres evitar.
Fazer estágios?
Muitas empresas oferecem estágios de verão. Embora Portugal tenha um tempo fantástico para passar o Verão na praia, um estágio de verão pode distinguir-te dos teus colegas do teu ano. Numa altura onde as contratações na área estão difíceis para juniores (substituição por ChatGPTs e despedimentos em massa nas FAANG), devem ganhar o máximo de experiência diferenciada. Outra alternativa é contribuir para projectos open-source ou ajudar professores em projectos de investigação.
Seguir para mestrado?
Normalmente Engenharia Informática é vendida como licenciatura + mestrado. Embora seja perfeitamente possível arranjar emprego com apenas uma licenciatura, conseguem posições mais interessantes se tiverem o mestrado. No mestrado tipicamente podem escolher as cadeiras nos tópicos que mais gostam, pelo que tipicamente é bem mais agradável que a licenciatura, e custa menos.
A divisão entre licenciatura e mestrado foi criada para os alunos poderem fazer o mestrado noutra instituição. Durante o ensino, devem tentar ter contacto com outras realidades académicas, seja mudando no mestrado para outra universidade/politécnico, seja aproveitando o programa Erasmus e ir para fora um tempo.
Preciso de saber Inglês para fazer o curso de engenharia informática?
Honestamente, sim. Apesar das licenciaturas em Portugal serem em português e existirem vários livros em Português, a verdade é que grande parte dos recursos online estão em inglês. Desde documentação de linguagens de programação e software, até documentos científicos, passando por blogues técnicos e por páginas detalhadas da Wikipédia que só existem em inglês, precisam mesmo de dominar essa língua franca. Se não estiverem à vontade, recomendo que procurem cursos livres numa universidade perto. (U.Lisboa, U.Coimbra, U.Porto, U.Aveiro, U. Minho)
O autor escreve no acordo ortográfico de 1945, como crítica ao novo acordo ortográfico. O autor agradece também à Catarina Gamboa, Paulo Santos e Antónia Lopes pelo feedback sobre o draft inicial, sem prejuízo de poderem não partilhar da opinião na sua totalidade
Over the last couple of years, I have spent a significant amount of time browsing and scoring resumés (Vitae is the common name in Portugal) for different positions, both in academia and industry. The majority of those had been poorly designed. In this post, I try to help you design the perfect resumé, and avoid common pitfalls. While this is designed towards Software Engineering, you might find this relevant for other areas.
The Header
You should have your basic information on the top of your CV: Name, email address, location and optionally phone number. A few tips:
If your student email is something like sch34134123@…, please use a personal email address instead.
Never use your current employer’s email. Use a personal email address.
Do not use your full address. Your street number is useless for this purpose and you don’t want your personal information on the internet. Just list your current city/county.
I would suggest having the Country specified, as it helps companies in understanding if they can’t hire you (due to visa and immigration issues).
A plain (meaning non-party) picture. I would suggest towards including if there is an expectation that the hirer would know you (e.g. if you are applying for a research grant with a professor).
First things first.
The next two sections are Education and Experience. If you do not have real-world experience or if you are applying to an academic position, you should have Education first. Otherwise, I would have Experience first.
Experience
Experience should come in reverse chronological order. Have your last (or current) job first. This is usually what most recruiters will focus on. Besides the start and end dates, title and company, you should have a small paragraph explaining what were the main activities and responsibilities of your position. If you were a software developer, you should explain what kind of software you worked on, and what was your contribution. Some people also like to include technologies they have worked on, which works well with HR people.
If you had odd-jobs outside your field, please leave them off the first page and in “Other Experience”. Not that you should feel ashamed of them, but let recruiters focus on what’s important for the role they are pursuing.
Education
Stick with reverse chronological order. If you are currently taking (or just signed up for) a degree, please include it, as well as the expected graduation year. If you have other degrees like Biology or Music Theory, please leave them off the front-page (and move them to Other Education) except if that might be relevant for the job application! Examples would be a company that works on software for DNA processing, or on software for Audio Synthesis.
For each degree, you should list your average grade, as well as highlight the top 5 or top 10 courses in which you had the best grades, or which are relevant for the job application.
Projects
This section is specific for Computer Science and it is only relevant if you do not have a lot of experience. In this case, you should write one paragraph about the projects (even if it’s coursework) that you did, what technologies you used and what you learned. 3 projects are more than enough, and if they were developed outside course work (opensource or in a research environment), it’s more valuable. Include a link for the code repository (Github or similar), making sure you already have the final grade for that course.
Other Activities and Awards.
You can have some other activities listed in your CV, but make sure they are relevant for the job if they are in the first page. As a rule-of-thumb, you should list those that reveal organizational or leadership. Being a casual chess player is not a relevant activity (It’s actually a hobby, and you should leave it off the Resumé) but being the President of your local Chess chapter can be relevant.
Final Remarks
Show your CV to more senior colleagues and even professors and ask for feedback. You want your CV to shine compared to those Europass form-generated CVs.
