The marshmallow experiment

Created on 2025-05-18 07:08

Published on 2025-05-18 08:17

Somewhere in the 70s psychologists at Stanford University made an experiment about "delayed gratification". Children were offered marsh mallows that they could eat immediately or, if they delayed it for 15 minutes, they would also get some extra treat as a bonus. Following up the results they found a correlation between those that were able to delay gratification and their later results in life being better in comparison to those who were not able to do it.

On the other hand we are pushed towards immediate gratifications by a lot of factors that our society is based. We are sold the idea that everything should be "Bigger, better, faster, more" and we need to "want it all, and want it now". If things are fast we pat ourselves on the back considering ourselves "efficient". Is it true? Are the results similar to the Marshmallow experiment?

https://ownmygrowth.com/2020/09/27/instant-gratification/

The current trend for boosting efficiency is the use of AI everywhere. The most relevant trend is now the "vibe coding" - fast results with minimal effort. Yes, results are impressive, the assistants are able to produce code, sometimes better code than the humans in a fraction of the time as they have indexed HUGE amounts of ALREADY WRITTEN CODE. Hence a task that used to take days could be theoretically be finished in hours if not even in minutes. That is great and saved a lot of time.

But the question is what we do with that time? How do we spend it? Do we take just another task from the Jira board and throw it to the army of assistants asking the correct prompts or prompting an assistant to prompt another assistant to do it? Or we try to "grok" it ourselves? Do we invest the gained time in something creative and new? In my opinion creativity doesn't boost in the same way, contrariwise, creativity comes generally from scarcity not from abundance. Having everything served immediately reduces the need for searching and understanding the solutions for the problem at hand. As a recent Microsoft study revealed we are just trusting the response as it seems plausible and after a while we take it for granted as being correct without double checking it.

Doing something good as a human requires effort, delayed gratification. Try learning a new instrument. It will take a long time to produce something that resembles music, especially for those that at their first musical experience. I was, and I still am, an horrible player, practiced for years until I was able to play something that sounded good (depending to whom you ask). But I enjoyed the trip. Before playing that solo i had to learn not only the instrument, chords, and finger-picking but I learnt about bands, trends , music in general and, probably the most important thing, I got to know people with similar interests. Putting effort into doing something is the key to progress as Derek Muller explains it.

The lack of delayed gratification leads to stagnation, lack of desire to do something, no imagination for what might be the end of the trip. A general state of INFANTILIZATION might appear as the skills needed to obtain something will be underdeveloped and tantrums will be satisfied unconditionally. The issue is that also decision makers will be affected by the same symptom as all their goals will apparently be satisfied instantly with no rebuttals.

AI is a wonderful tool, I am all in for that. The issue is not AI, as it is not sentient, it is us in our infantile way of using it to get immediate gratification instead using it wisely - try first, get feedback or advice, try again cycle. If we are more efficient day after day, we should take some time to understand it. How embedding works, what is quantization, what risks MCP poses. Try replicate and understand the mathematics behind it, go back to the Algebra and Calculus one neglected earlier in life, verify the responses by reading the literature suggested as source (if it really exist) or try learning to draw something with pen and paper just to understand the techniques after asking the AI to do it as an example. Try to delay the gratification and dream of some better reward. Most of the time it worth it.

To finish in a darker note:

https://www.orau.org/health-physics-museum/collection/radioactive-quack-cures/pills-potions-and-other-miscellany/vita-radium-suppositories.html

Somewhere in the '30s Radium suppositories were seen as a great thing, as Radium was something novel at that time as a cure to slowness as their advertising was reading. Not understanding something completely and using it JUST BECAUSE IT WAS ADVERTISED is dangerous at least. Short term gratification cycle is just followed once again.

Weak Discouraged Men! Now Bubble Over with Joyous Vitality Through the Use of Glands and Radium

“If YOU are showing signs of “slowing up” in your actions and duties, perhaps long before you should—if you have begun to lose your charm, your personality, your normal manly vigor—certainly you want to stage a “comeback.” The man who has lost these precious attributes of youth knows how to appreciate their value. He realizes that happiness depends on his ability to perform the duties of a REAL MAN. Sweet, glorious pleasures of life. Nature intended that you should enjoy them.”

“Now is the time to act! Today! RIGHT NOW! Tomorrow may never come.”

Links:

1. https://www.lifehack.org/353923/instant-gratification-short-lived-you-should-aim-for-long-term-goals

2. https://medium.com/@darinleavitt/the-epidemic-of-instant-gratification-aef2a8d38903

My response to "From Mere Engineer to True Artist"

Created on 2024-04-11 15:28

Published on 2024-04-11 18:58

Codecamp Timisoara took place today, and it was quite a nice conference. The lineup was top-notch, and the topics were quite diverse. There were also some talks that seemed overly specialized, possibly requested by sponsors, but overall, it was quite an entertaining edition.

James Coplien delivered an interesting talk called "From Mere Engineer to True Artist" at the end. Coplien is known for stating unpleasant truths, and this is okay; it provides food for thought.

He pointed out many elephants in the room somewhat bluntly, but radical candor is necessary to shake up the industry. However, some of his assertions today were not entirely true, as there are many nuances that I struggle with.

• What are architects? Everybody is an architect; there is nothing to argue about here. At a certain scale, architecture is present in every detail of the field; every commit is an architectural decision. However, the title "architect" carries more implications. The term "architect" originates from the Greek ἀρχιτέκτων (archi - first/over, techton - builder/mason). Architects were defined by Vitruvius as mediators, experienced workers able to mitigate stakeholders' needs. Architects have scars from previous battles and failed buildings, which gives them another "unnamed quality" of being able to steer and communicate to avoid repeating the same mistakes.

• The lack of importance of a "4-year CS degree" and the notion that "CS is not a science/engineering." I completely disagree. In my view, CS is a science, residing somewhere between a branch of mathematics, a cornerstone of electrical engineering, a niche of quantum physics, and a domain of philosophy, yet with some fundamental ideas of its own. Of course, talent and hard work can compensate for formal education, but formal CS studies help evolve it from a craft to an engineering discipline by incorporating the feedback of countless generations of practitioners, creating something as solid as civil or chemical engineering. Maybe CS is not a true science yet, but it is at least "science in the making", gaining substance year after year. A 1-year boot camp could theoretically create good programmers but not scientists or engineers. The graduates of these boot camps could be productive, but they would mostly align with the 90% that Coplien fears will disappear, especially if their motives for choosing CS as a profession are not fueled by passion and continuous learning. He argued that kids can create software. True, they can create impressive things from a young age, but sometimes their creations are naive, functional indeed but lacking the details that a seasoned practitioner would add — details that provide an edge in terms of usability, performance, and quality. Kid's creations, even if not completely abstract are full of abstractions

Unicorn drawn by a kid

vs.

Unicorn drawn by a professional

Coplien argued that Renaissance architects who delivered value had no architectural studies; still, they created wonderful buildings. In my opinion, it was not necessary at that point in time, as during that period, the arts and crafts were mostly similar, and practitioners were genuine polymaths.

• Commissioned work: Most of the examples of great architecture he presented (Brunelleschi, Michelangelo, da Vinci) worked on commissioned buildings. The artists worked at the order of a sponsor, as artists are often poor, in need of money. There are just a few self-sustained artists, mostly in the 20th century, who were able to market themselves so that they could create at their own will. Even these exceptions had to do commissioned work at the beginning until they were able to create independently. Starchitects like Oscar Niemeyer created "commissioned works of art" - for example, the city of Brasilia. It was their genius that transformed a mundane request into an unforgettable work of art, but they did not initiate the project themselves with their own funds.

• Abstractions are bad: Again, I do not agree. Abstractions are the foundation of science and art. If we observe the evolution of Picasso's bull, we see it goes from concrete to abstract, refining the shape to its bare essence. There is nothing that one can take out from the last image and still have a bull. Abstractions create flexibility, a quality that permits evolution. If we abandon abstractions, modern art would still resemble the bucolic style of the 16th century, and software would still be in Fortran dialects. Functional programming and object-oriented programming are based on abstract concepts that allow them to express real-world problems in an understandable manner and create higher-order simplifications of the problem at hand.

• Beautiful code: With some references to Christopher Alexander's "unnamed quality," Coplien wants us to deliver beauty. The problem lies in how he characterizes beauty. His aesthetic criteria are vague. Beautiful code is not only visually appealing; what if we cannot see? Perhaps one has a test-sensing organ that is sensitive to testable code and code with a lot of tests - a testable flower and its petals. We all strive to write beautiful code, even in suboptimal languages, but let's be honest - we do what we can to meet our deadlines. Maybe we write truly beautiful code once or twice in our careers, but often, we write code that brings value. Value can be delivered not only by ethereal, elegantly crafted code but also by solid, practical code. While he advocates for the axiom of delivering value first, his subsequent request for beauty is in stark contradiction.

Delivery pipelines

Created on 2023-08-11 09:14

Published on 2023-08-11 10:18

The industry is buzzing currently with term as Continuous Delivery, Continuous Deployment an Pipelines. Pipelines are techniques to seed up the processing time by sequentially running a set of tasks on specialized stages, at every moment of time one step consumes the output of the previous one. The concept is not new, it has been started in the early 1900 when it was applied to factories and assembly lines. But the current pace of software development just put a lot of spotlight on them.

The software pipeline most often do a set of operations as check-out code from VCS, compile/build it, package it, run tests on it, deploy the artifacts to a repository and inform the stakeholders of the result, update various metrics and dashboards. These actions require a script to put things in the right order and check the results in every step.

In software the pipelines are generally defined through a specific language, either a visual one or a text based one - generally YAML or Groovy. These are run by specialized software as Jenkins, GitHub Actions, CircleCI, etc. The high level pipeline described in YAML is calling various other scripts that define the individual steps - like micro-operations.

The build step for example is the invocation of a Makefile, shell script or a Maven build. The pipeline will wait for the completion of the build step before passing the artifacts for testing or packaging. Such a situation is interesting because there will be two points of control in the pipeline. One at pipeline level and one at step level but their responsibilities will bleed into each-other.

This might lead to some problems:

1. Inefficient pipelines: If the result of a step can be guessed before the whole step completes the pipeline should fail fast. It makes no sense to wait for the completion. Imagine that you have a multi project build. In the trivial case the projects are built and packaged. But what if one of them has an issue? Should we wait for completion of all builds and then juts cancel the packaging step? What if there are modifications on a single project that has no egress dependencies? Again - it makes no sense to package all other projects as they haven't been modified. However with the split logic this is hard to achieve as the operations on pipeline level are quite coarse-grained. On the other hand most build tools (Gradle, MSBuild, ...) are perfectly able to run more parts of the process by themselves - create archives, containers, publish artifacts - and probably they should do it. Fail fast and incremental builds are essential for accelerated release cycles. The build tool is in a better position to understand what it is building by looking in the source code than the pipeline that is merely an orchestrator of some loosely coupled processes. Caching build results and artifacts, using parallel builds could reduce build times from 20 minutes to less than a minute - so some DORA metrics will look way better and will make both developers and managers less impatient. Speculative execution and rescheduling is well known in CPU pipelines - software engineers should have some inspiration from the clever solutions that hardware folks are successfully applying for more than two decades.
2. Portability: The high level pipeline logic is hard to be moved from one type of executor to the other. Pipelines built for Jenkins will be hard to be ported to another CI/CD system. The worst part is that it won't be easy for a developer to run the pipelines locally in order to have similar results as on the server. Dev/Prod parity should be not only on the tooling versions but also on the environment where code is built. Being able to run the pipeline locally would mean that a developer can also debug it if it's the case - it creates better visibility in the whole project - enabling a DevOps culture. Having an ops/build team that is managing the pipeline in secrecy is in my own view an anti-pattern. The devs will happily throw any issue away to the build/ops as "it works on their computers" - creating some knowledge towers. Also the posibility of running the pipelines on the local machines will ultimatly reduce the load on build machines and the queuing - improving again the metrics.
3. Mutability: The environment on which the pipeline runs should be immutable in order to produce consistent results. This is well treated by GitHub actions but for Jenkins (or other on premises CI/CD solutions) or even locally on the developer machine this is slightly complicated. However this can be solved if the pipeline can run in a container which is immutable. Many IDEs today offer the possibility of a development container that provides trusted and stable environments. This is extremely important nowadays in order to mitigate supply chain attacks. The immutability of the environment would mitigate issues as those described in Ken Thompson's paper from 1984 "Reflections on Trusting the Trust". This immutability contrasts partially with the caching needed for mitigating the speed but this can be solved quite elegantly nowadays with crypto methods so no cache poisoning can be inflicted.

Containerized pipelines solve both portability and mutability issues - so the developers could have both freedom of choosing tools and rigor for their builds in the same time. I learnt about a company that creates Visual Studio customized installations and pushes them every night to the developer's machines in order to solve the issues above. This is not only inefficient (hundred of gigabytes transferred and computers never in standby) but it is also error prone as a there are a lot of machine specific issues that might interfere - so in the end there is no certitude that the configuration is identical on all computers and that there is no drift. Imagine that in a large project a single library has some different settings - it will take hours for the developer to investigate an error caused by an obscure glitch that happened overnight. Running pipelines locally in the container would enable the developers use Rider or VS Code on Windows while still being able to test and build on trusted environments and deliver Linux software. Jenkins has this feature also, but is somehow exposing it in a clumsy way despite its huge value. Contrariwise GitHub Actions make it completely transparent for the consumers of the steps - one has to look in the action's source to know that it uses containers.

Speed is a crosscutting concern and can be addressed regardless if the pipeline runs or not in a container. A slow build won't get faster if done in docker. An aggregated approach - with the right tools could improve the development experience, speed and security of an organization.

#pipeline #containers

2022 Highlights

2022 was quite interesting. I made some changes in my toolbox.

The most interesting bits were:

1. Vercel and Supabase usage that worked flawlessly. 

2. I have ditched Docker completely and moved to Rancher Desktop and Podman. 

3. Still on Fedora 36 for all my machines. 

4. Moved some personal workloads to Oracle Cloud.

5. Visted Norway

6. Toured Romania

Felt dumb most of the year. And somehow powerless - cannot really get a grab, authority wise on the development of the  project.

Not much here, huh?

 I wrote most of my rants elsewhere. But this kind of sucks...

 

Legacy

Created on 2022-11-17 12:29

Published on 2022-11-19 19:56

The life that we are currently living is shaped in many ways by "legacy". In most cases, the word legacy carries positive connotations related to wealth, culture, and tradition. However, this is not the case with software. Here the word "legacy" has a lot of negative meanings associated with it. What is "legacy" in software? Why do we consider it bad?

Legacy software simply means that the code base is old, probably unmaintained, and hard to read. It says nothing about the value or the quality of the code, it just states that is old. Then why do we consider it bad? In the real world legacy is a source of wealth, something we grew upon. Probably the answer lies in our laziness. How many of us can fluently speak or write in Latin for example? Or classical Greek, old Norse, medieval French maybe? A few of us can, although is a pity, many fundamental works of mankind were written in those languages. Still, we do not read them in original, it is more convenient to read modern versions of those in a familiar language.

The same happens in software. Programmers are using contemporary languages and lost the ability to read older ones, so the code they stopped understanding became mysterious and potentially dangerous for them. As with classical languages, there is just of handful of people that have the patience to study and understand older code and those are the ones still able to explain the values that we, in our pride and ignorance, cannot see in the old code.

Many critical infrastructures and day-to-day codebases are "legacy", still, they work well, and they keep supporting our daily life. Banking still relies on Cobol and RPG, scientific computations still use Fortran, and operating systems still build on C.

I have to praise a relatively unknown "legacy" programming language and runtime: Concept. Concept is a 4GL (4th generation language) that started in Norway during the '80s. Googling it might yield 0 results, nevertheless, it delivers daily for a few million people. The language has all the features one would expect UI library, database connectivity, and it can run both server side and client side, it's kind of memory safe. The syntax seems a little dated but is still expressive enough to implement huge projects. As the community of Concept developers is not large it starts to lack new talent and also tooling. Despite this, there is still maintenance effort and is kept as much as possible in line with the latest industry trends: REST, JSON, MQs, 64bit code generation, containers, and such.

Understanding older languages is never easy. As I said before, due to our laziness we tend to ignore them and rewrite everything with no guarantee of a better job. Probably it is often a better idea to rewrite, but we first need to understand what we are replacing. We need tooling for understanding older code bases, especially when the original specifications of the software are lost. We need helper tools that guide us through the syntax and structure of the code and could provide handlers for the business logic already written in the old code bases enabling true reuse. Developing tooling that would transparently retarget old languages on new platforms will guarantee that the legacy received is still producing the expected results and we can build more interesting things in a more cooperative way. Rewriting software with feeble specifications or no specification at all, using the legacy system as a model but not fully grokking it, is in my opinion far more dangerous than keeping battle-tested code running.

The Five Ideals

Created on 2022-09-10 06:35

Published on 2022-09-10 14:15

Locality and Simplicity; Focus, Flow, and Joy; Improvement of Daily Work; Psychological Safety; Customer Focus - these are the five ideals of an organization that might blossom into a unicorn.

While some of them can be grown from the inside, starting from the development and operations teams and evolving them into a 'DevOps' culture, others are leveraged mostly by managers.

Helping teams improve for the first four ideals in the company creates more room for the latter. Those create a lot of turmoil and non-functional requirements but in the end, the price paid yields probably squared.

This is why managers that act toward the five ideals are as precious as mythical animals. This is also why when such a manager leaves it's quite sad.