Programming is not a piece of c++e

Programming is not a piece of c++e 700 464 Comidor Low-code Automation Platform

Programming is not a piece of cake, but if you think that the best programmer is the one who can type by heart all the libraries and frameworks, line by line, then you are quite wrong! Most programming skills are about translation, rather than memorization skills. The role of the programmer is to successfully translate the human problem into machine language and then leave the dirty job of calculation for the machine (that’s why we invented them in the end).

While working on global projects I met hundreds of programmers, juniors to seniors, from all over the world. Amongst them, Italians not speaking a word in English, Filipinos speaking only Spanish, Latin Americans speaking half Spanish half English, English not understanding my English and Indians communicating mostly with head gestures… Different languages, backgrounds, beliefs, communication methods, professional behaviors, business etiquettes and, above all, different coding styles. With this global experience I realized that the significant difference between a good programmer and an excellent one was the ability of the latter to grab the concept of the Requested Functionality (RF) and translate it in his mind in a flow diagram (an intermediate state between the human words and machine code) containing blocks not only from this RF, but also from related processes, integrated functionalities, project priorities, team responsibilities, time constraints and deadlines, already implemented code, removed code and more.

Translation Skills

The translation skills actually mean that the excellent programmer interprets the whole picture around the RF without isolating it. This all-around translation approach has various positive effects during the project phases:

a) Analyze Phase: The programmer has the confidence to participate during meetings (where typically is not invited)

more contribution => more engagement => apply the 100% => more results

b) Design Phase: The programmer is proactive

foresee integration conflicts => avoid anomalies and incoherencies => less hot potatoes

c) Build Phase: Economy in coding

reuse implemented code from similar processes => saved time and cost

d) Test, Deploy and Support Phases: The programmer is harvesting the fruits of his holistic RF translation by having fewer issues to solve.

e) Extension Phase: The all-around translation pushed the programmer to write “extrovert” code (code which integrates with other pieces), which means that the code is already OPEN to new RFs.

Above all, programming skills are simple. The programmer should be a good translator, not seeing the tree (RF) isolated, but also understanding the forest around it. Some time ago, Alan Turing focused on the question (the problem), not the answer (the solution). He considered more important that the programmer develops his way of thinking first, rather than to spend endless nights in calculations. He knew that the solutions were the task of the machines and History proved him right. Programming is not a piece of code.