Programmers are Dying
Very few people really pay attention or give it a responsible consideration, but when programming, or more specifically, when designing how to implement a software system, there are actually (at least) two types of architectures.
Let us call them functional and non-functional architectures because they are strongly related to functional and non-functional requirements; but there are other names like macro and micro architecture for example. Perhaps there is not much consensus on the concept precisely because it is not deemed much important.
Why is that? For the most part, in modern times, teams of developers are indoctrinated in that the only thing they should be doing is delivering value in each iteration of the product development. Rarely a team member is willing to invest efforts on non-functional architecture.
More than that, functional architecture is easier, most of the time, teams won’t “reinvent the wheel”, will just be combining different technologies available (which, for functional architecture, there are countless); and won’t really know what can or should be done at the level of non-functional architecture.
Nevertheless, there are technologies for non-functional architectures as well, but they pretty much stop at frameworks, that although are important, more often than not, parts of their philosophy or guidelines are skipped in order to “code faster”.
From my experience in quite a number of companies, and the experience shared by friends whom are developers, the usual popular excuse is “I didn’t have time to make it proper, next time I’ll refactor it”.
Were they feeling that something more essential was expected of them? Why do developer teams cooperate negatively against their own health?
How do we incur in such mentality? It makes me think of interviews; usually during interviews, technical interviewers will only focus at assessing the capacity to build functional architecture and whether the candidate is able to fulfill a product customer need.
Requesting demos or exercises in which they have to demonstrate they are able to build a “working” endpoint, or whether they are able to “design” a system, with what technologies (even though technologies are constantly changing and evolving), like it is the perfect thing to measure.
When the interview process is formulated in that manner, one is not realizing that it will just assess how well-prepared a candidate is at being interviewed, and their ability to be taletellers of functional architecture.
Because of that, programmers are becoming more and more expendables, and we are digging our own graves. This article is titled with the intent to make a, although drastic, metaphorically accurate comparison to hazardous industries from the last century. Mining for instance, they had little care for worker safety and only cared for the output or productivity of the specific mining activity because there is where the money was; regardless of many workers dying.
Respectively, the hazards in our case are the lack of non-functional architecture in every code base that keeps growing unmaintainable and uncategorized, which will force us to dig the same tunnel multiple times or have it collapse on ourselves, and that is how, figuratively, programmers are dying.
Much arises from a modern mindset. Many entities, from individuals to big name companies promote indiscriminate programming claiming that “extensive” learning is not a need. Even camps with catchy phrases like become a programmer in a couple of weeks learning a «particular platform».
Don’t get the wrong idea, it is a good start to the programmer journey, but do not make it sound like knowing a particular language or some basics is enough, like it is nothing and there is no science behind it. It is not like learning how to tie a knot, and even knots have science behind them.
This is not a revelation; everybody knows that knowledge and education is power. For those who have not experienced it, believe it, knowing more, understanding how the things one knows of come to be, being aware of the extension of one’s knowledge and grasping how much more is yet to be known, makes one feel much better and confident to have any desired job.
Might it be that the ulterior motive of this mindset is to mass produce a docile and cheap labor force of expendable programmers? Wow, that’s evil.
Do not take programming principles as a given. Prioritize science over technology, how to lay and dispose code rather than finishing the working endpoint, otherwise what kind of mess will the code base become when there are hundreds of endpoints? Take into account that technologies have changed in the past and will eventually change again, so do not rush into sticking only to the functional architecture. Study and develop the other side, and do not neglect it on supposedly lack of time or priority.
Do not contribute in creating a precarious tunnel of code for our future selves and our fellow programmers. Do not work in the mine blindly, for our own sake. Promote developing software into a healthy environment. Unite as programmers.
It is perfectly fine, no, it is a good thing to massively grow new programmers but do not disregard the science and engineering behind it. We have a modern digital world full of software, because people in the past really studied it. It is childish and disrespectful to take it for granted. We have the responsibility to maintain this profession as elevated as it can be, so a programmer can be taken more seriously as it used to be.
