In 2018, I graduated from EPITA, a french engineering “Grande École” specialized in computer science. The subjects I had treated there were very technical: from the implementation of an ISO file reader to a Tiger compiler.
The technical focus, taught in technical programs such as my engineering school, has led me to some small surprises during my first steps in the business world. The following list outlines what I would have liked to have learned before graduation. The article is obviously influenced by computer science, which is the specialty of my school. Nevertheless, I hope that the students will find some teaching in it, whatever the technical field they are targeting.
Human is the New Challenge
Coming from a school whose implicit motto was “the more technical, the better”, I had to quickly get used to the idea that the new technicality coming out of school was primarily human. Don’t make me wrong: having technical knowledge is as necessary as expected by the business world. But if many of us have been trained to take up technical challenges, we have been much less prepared for the strangeness of human behavior.
Technical skills should no longer be your challenge, your challenge should now be human.
Schopenhauer said in The Art of Being Right “A man may be objectively in the right, and nevertheless in the eyes of bystanders, and sometimes in his own, he may come off worst” which in our case could be perfectly translated as “You may be technically right and yet not be supported by others.”. Sometimes engaging technical decisions are taken on the basis of very non-technical arguments, for example:
- you were sick on the day of an important meeting;
- your level in English is not good enough to argue well enough;
- your manager used to work at XYZ, therefore XYZ technology is chosen for the project;
- your ambition to change a design frightens the rest of the team, despite the little amount effort it actually requires;
- your colleague X doesn’t like you, therefore it doesn’t like your design;
The list is endless. Just keep in mind that if you want technical decisions to be accepted, you will have to arm yourself with skills that go well beyond technique, starting with negotiation for example.
The school doesn’t just train engineers in languages or tools, it establishes a culture and a discipline that becomes stronger or weaker by joining a firm. Depending on the business sector, company, project or team, not everyone gives the same attention to software engineering. It is very unlikely that this discipline is the core business of your company, nor even the academic background of your colleagues. The good practices, taken for granted, can then be violently disrupted: no code review, no unit tests, sometimes even no version-control tool.
The intuitive reflex of a young engineer is to bring a purely technical solution: no version-control tool? let’s install git! No code review? Let’s protect the master branch! No unit tests? Install the right testing library! Etc. But here we are, the problem is not technical, the problem is primarily human, more particularly cultural. Changing the corporate culture, or more modestly, the culture of a team is far more difficult to change than any tool.
I will always remember the long struggle to get GitLab for an old project. This was the kind of indispensable work tool for a software engineer. The battle was long, not because the tool did not exist (it just had to be downloaded and installed) but because the required culture was not ready.
It takes time and effort to change a culture, but it is well worth the effort. A tool can always be dropped, a
git push can always be forced, but a disciplined team is hardly swindled. So when choosing between a very well equipped team and a very disciplined team, choose discipline without hesitation!
Professional > Genius
In university, a lot of credit was given to geniuses who, alone, could compile a few thousand lines of complicated code in a single night’s work. When I entered the business world, my vision changed a lot from that kind of profile, capable of doing a lot of work in record time. Their confidence (or arrogance) leads to an extra commitment, which makes it difficult to meet delivery deadlines. And because geniuses understand complex things, they design complex systems that no one understands. Their loneliness makes them unique masters of their subjects, thereby nurturing their self-esteem. Knowledge remains in their heads and their presence becomes necessary for every decision.
But geniuses also have 24-hour days and quickly turn out to be the bottleneck of everything, slowing down everyone else. You don’t need to be a software architecture expert to agree that it is not desirable to over-commit and underestimate a single resource: apart from the inability to scale, the resource is the single point of failure. The design of a single point of failure is unforgivable. Once the engineer gets sick, goes on vacation, or leaves the company, the entire team will have to pay back months or even years of unprofessionalism.
It is a black and exaggerated portrait that I paint here. I can nevertheless bet that you will encounter this kind of profile in your career which, in addition to having a negative impact on entire projects (and on people’s health), will sometimes be claimed as a hero by the organization. Real geniuses are the geniuses also capable of designing simplicity, taking people on board while humble towards humanity and their workload. These are called great professionals. They spread knowledge and responsibility in order to become not the single point of failure or the bottle neck.
Geniuses build scalable services, professionals are scalable geniuses. – Twitter
Do you think there’s a principle missing? Send me your comments! This list will certainly be extended and refined, subscribe to the newsletter if you wish to be notified about it.