What is programming like?
What does a developer do?
These are two of the several questions that arise to those who flirt with the idea of dedicating themselves to this profession and do not have the opinion of someone who’s had first hand experience in this topic. The uncertainty in many cases translates into insecurity and, in the long run, into defectors from the field. Every day the gap between professionals in the discipline and the demand of the market deepens. According to data from Computer Science Zone , only for 2018 it is forecast a total of 190,000 vacancies in the industry. This gap is estimated to increase by up to one million positions in the next 10 years compared to students entering to college. The difference is translated into losses of around 500 billion in wages. On the basis that technology is expected to be the industry that grows the most by 2020, we should step back and take a look to the big picture. What is all the hype around programming and developer?
A developer by definition makes programs. Not only that, they also have fun and, like the rest of humanity, suffer.
The program.
Often in the newspapers, social media, coffee machine chats, BBQ’s and or birthdays, is mentioned the story about how two dudes from the comfort of their living rooms put together an application that is revolutionary -or disruptive- and now -continues the legend- both are swimming in millions of dollars while displacing the efforts of entire teams of the establishment. Developers are usually fans of these kind of romantic elaborations, especially because from their -our- perspective, mounting a highly efficient, robust and disruptive system is possible on their -our- own. If this is a rule of thumb, then why are not all industrial teams replaced by pairs of living room MVPs? Mainly, because a program far from the productive environment, that is to say, in the theoretical world, is quite cheap and easy to maintain. This program is what developers have in mind when making estimates and daydreaming. The evolution of theory to reality, from the program to the programming product — and therefore the growth of costs — is given by two axis. The first, the integrations with other systems. A totally isolated program can hardly provide more value than a calculator. Therefore integrations suppose in general terms, the triple of effort. Which is translated in the triple of the initial cost of the elaboration of the program. The second axis, the robustness of the program. That is, the testability, maintainability, flexibility and — even if developers consider it a bad word — the documentation, this effort also triples the costs.
When you move forward on these lines, you have a programming product that can be maintained and extended independently of who created it. It can be used in different operating environments and supports multiple types and input formats. It is so solid that you can trust and rely on it. That is, it requires substantial test cases and exploration of the limits and ranges of the inputs and the algorithm. No less, it is documented in such a way that it is possible to make modifications, updates and extensions. In addition to having its own specifications of memory space and processing. This professional product costs 9 times what it can cost a program fresh out of the oven — or the living room. But it is really a useful object, the desired product of most programming efforts.
It is fun. But why?
Mainly, for the pleasure of creating things. Just as a boy delights himself making his mud cakes, the adult enjoys building, especially those that are his own designs. I consider that this delight must be a small and superfluous resemblance of God’s delight in doing things, a delight that is appreciated in the novelty that each cycle of life involves, each leaf that springs, each snowflake. Second, the satisfaction of doing useful things for other people. Deep in our hearts, we want others to use our work and find it useful. In this sense, a programming product is not very different from the clay crafts that children make in the kindergarten for their parents’ offices. Third, the fascination of designing complex objects that resemble puzzles of intersecting parts and being able to see them work in subtle cycles, unleashing the consequences of the principles with which they were elaborated since their conception. A computer has all the charm of a music box or the Lego bricks, taken to the excess of abstraction. Fourth, the happiness of constantly learning, which arises from the non-repetitive nature of the task. In one way or another, problems are always new and whoever solves them learns at every opportunity: sometimes something theoretical, sometimes something practical, sometimes both at the same time. As Heroclitus stated, nobody bathes twice in the same river, because everything is flowing. Analogously, I could say that nobody codes the same algorithm twice. Finally, there is the delight of working in a malleable environment. The developer, like the poet — and I personally consider that this is what attracts me — works slightly away from pure thought. As the poet, builds castles in the air, from air, creating by effort of their own imagination. Few means of creation are so flexible, so easy to polish and rework, or are so capable of elaborating large complex conceptual structures so promptly. However, the developer’s construct, unlike the words of the poet, is real in a sense that it moves and works, producing visible outputs, separated from the construct itself. Prints results, draws images, produces sounds, moves arms. The magic of myth and legend has become reality in our days. One writes the correct incantation on a keyboard and our screen comes back to life, showing things that never were and never could be.
Programming is fun because it gratifies the deep creative yearnings that lie in our souls and delights the sensitivities we have in common with all humans.
No pain, no gain.
Like life, this is not a fairy tale. Knowing the riddle in advance, allows somehow to get prepared before they appear. First, it is necessary to perform perfectly. The computer resembles once more the legendary magic in this sense. If a character, a word, a pause of the enchantment is not articulated correctly, the magic does not work. Human beings are not accustomed to being perfect, given that few areas and activities require perfection. Adjusting to this requirement is perhaps the most difficult part of learning to program. Additionally, other people define the developer’s objectives, provide resources and polish the information. Rarely does the developer control the circumstances of his work or even his goal. In managerial terms, the developer’s authority is not sufficient for his responsibility. However it seems that many other jobs, things are done without the need to commensurate authority with responsibility. In practice, authority is acquired at the very moment in which the task is accomplished. Dependence on others has a particularly painful case for the integrations developer. He depends on other people’s programs, which might happen to be poorly designed, poorly implemented, half delivered and barely documented. That being the case, they must spend hours studying and fixing things that in the ideal world would be complete, available and usable. Another pain with which the developers find is that the design of great concepts is fun, but finding flaws in the design makes the work become the virtual equivalent of delousing applications. As in any creative activity, it requires dedication, tedious hours of sweat and tears. Programming is not the exception. Another grief, one finds that debugging -delousing- has a linear convergence or worse.
When the developer is really waiting for a quadratic approach to reach the end. That being the case, the tests are extended indefinitely, making the last bugs to be found, more difficult than the first ones, taking more time to be discovered. The last of the pains and often the most bitter is that the product on which they have been working for so long seems to be obsolete even before it is released. When colleagues and competitors find themselves pursuing new and better ideas. When the displacement of the child from the virtual entrails of the developer is not only already conceived but presumably planned. This always looks worse than it really is. The new and better product is usually not available when one finish its own; his appearance in the market is hardly commented. So this in turn will have months of development. Of course, the technological base on which one builds is always advancing. At the very moment in which one freezes the design, it becomes obsolete in terms of concepts. But the implementation of real projects requires the division into phases and quantification. The obsolescence of an implementation must be measured against other existing implementations and not against concepts that have not materialized. The challenge and the mission is to find real solutions to real problems based on real schedules, with the available resources. This is programming, from my own perspective. Both quicksand and a creative activity with pains and glories of its own nature. For many, the glories surpass the pains. And for them this writing aims to throw a hand to get out of the quicksand.
Check our Virtualmind magic ✨
Our website — Facebook — Twitter — Instagram
