rolgalan
LightNews LightNews
rolgalan.bsky.social
rolgalan
@rolgalan.bsky.social
32 followers 58 following 140 posts
I usually post about engineering processes, development productivity and anything related to software industry, with a particular interest in Android.
Posts Replies Media Videos
rolgalan.bsky.social
«Dismissing European concerns about technological sovereignty as “Cold War thinking” misreads reality. This isn’t ideological competition — it’s economic warfare where technology is a national weapon built through political and industrial choices.»
The roots of Europe’s predicament are to be found, first, in the stranglehold of neoliberal orthodoxy on European economic thinking. This caused decades of austerity and made Europe the poster child of hyper-globalization: free trade without economic statecraft, bans on state aid, trickle-down economics dogmas, no long-term public investment and the systematic rejection of industrial policy. All of this was gospel preached by the U.S., even as Washington protected its own national security interests and subsidized Silicon Valley. Europe, in other words, internalized the ideology of market neutrality while others practiced strategic capitalism. American technological dominance wasn’t born from free markets but from massive state intervention — DARPA, NASA and the National Science Foundation provided the patient capital and guaranteed markets that made Silicon Valley possible. As Linda Weiss’s work on the national security state and Mariana Mazzucato’s research on the entrepreneurial state have documented, innovation ecosystems do not emerge spontaneously — they are structured through public direction. Every core technology in the iPhone — the internet, GPS, touchscreens, voice recognition — emerged from decades of public research funding. The Pentagon’s procurement budgets functioned as venture capital at a continental scale. Meanwhile, Europe internalized market fundamentalism more thoroughly than its own inventors intended. The Stability and Growth Pact threatened strategic industrial investment as a violation of fiscal discipline. Competition policy, instead of preventing Big Tech dominance via bold antitrust action, prevented the formation of European champions while American firms achieved monopolistic scale. Europeans were lectured that industrial policy violated market principles by the very Americans who systematically practiced it.
November 9, 2025 at 5:49 PM
rolgalan.bsky.social
The analysis shows that AI assistants makes way simpler to add new code (recommendations are also usually longer), but help little with refactoring and maintenance. More duplications than ever are introduced, making harder to maintain the code in the long term.
The combination of these trends leaves little room to doubt that the current implementation of AI Assistants makes us more productive at the expense of repeating ourselves (or our teammates), often without knowing it. Instead of refactoring and working to DRY ("Don't Repeat Yourself") code, we’re constantly tempted to duplicate “Copy/Pasted” code, as measured on a per-commit basis here, quantifies the frequency of non-keyword, non-autogenerated, non-comment lines of code that are committed in a single git commit. Historically, developers have avoided this by creating a single method/function that is invoked by many callers. If necessary, developers parameterize the function so it can be utilized by many call sites [A0] . The more times a function is reused, the more battle-tested it becomes. Performed in moderation, revising recent code is often a good thing. It suggests a developer is conscientious about submitting code that has been tested & polished. But the 2024 ratios for “what type of code is being revised” do not paint an encouraging picture. During the past year, only 20% of all modified lines were changing code that was authored more than a month earlier. Whereas, in 2020, 30% of modified lines were in service of refactoring existing code. In git repos that maintain their change velocity over the course of years, developers must divide their attention between implementing new features and updating/removing legacy code. If every new feature is implemented via added code (without seeking out update , move , and delete opportunities), the repo grows crowded with cloned and near-cloned blocks. Adding new developers becomes increasingly expensive, as they struggle to determine which function, among a multitude of similar choices, should be considered the “canonical” version that their code should call.
September 28, 2025 at 2:40 PM
rolgalan.bsky.social
Muy relevante este artículo con un mensaje muy claro: Hemos confundido la capacidad de generar código con la capacidad de entregar valor.

Esto ya sucedía antes de la IA generando código, pero utilizarla sin disciplina tiende a agravar el problema.

nikeyes.github.io/el-codigo-ge...
¿Dónde está realmente el valor? La IA es brillante resolviendo problemas ya resueltos: autenticación, CRUD, backoffices, etc. Pero el valor de tu producto no está en el boilerplate. El valor está en: Las reglas de negocio específicas de tu dominio El conocimiento único que tu equipo tiene sobre tus usuarios La complejidad inherente del problema que resuelves Estos son exactamente los elementos que la IA no puede generar porque no existen en Stack Overflow. Son únicos de tu contexto, y aquí es donde tu experiencia humana es insustituible.
September 24, 2025 at 3:30 PM
rolgalan.bsky.social
«Our role as leaders is not to demand quality as if it were an optional extra, but to understand that it is the foundation for sustainable speed, for reducing waste, and for maximizing real impact.»
There is a fundamental paradox: the more we obsess over immediate speed at the expense of quality, the slower we become. Teams that accumulate technical debt, unresolved bugs, or hard-to-maintain code make each new feature exponentially more expensive. What seemed like a "pragmatic" decision becomes a burden that slows down the entire system. Building with quality is not just a matter of technical practices: it is, above all, a matter of leadership. Our role as leaders is not to demand quality as if it were an optional extra, but to understand that it is the foundation for sustainable speed, for reducing waste, and for maximizing real impact. Quality is not a goal or an option: it is the operating system upon which everything else relies. If that system fails, any attempt to move fast leads directly to collapse. Our job as leaders is to create the conditions where quality does not depend on individual will, but becomes the easiest, fastest, and most natural path. Where building with quality is not a heroic act, but the inevitable one.
September 21, 2025 at 9:47 AM
rolgalan.bsky.social
«When the system is easy to understand, test, and change, the team can focus on delivering value, learning faster, and better adapting to customer needs.»
In reality, well-understood quality is an accelerator. When the system is healthy—with reliable automated tests, simple design, and robust processes—every step we take has less friction. The team’s confidence in its ability to change the system grows, feedback is faster, and the cost of change drops dramatically. In other words, we go faster not despite quality, but thanks to it. Moreover, when the team trusts its system—because it knows that errors are detected in time, that the design allows for easy evolution, and that experiments can be conducted without breaking anything—it dares to innovate, try new ideas, and quickly adapt to what it learns from the user. In short, it enables the continuous delivery of value.
September 21, 2025 at 8:57 AM
rolgalan.bsky.social
This is insane, a really simple task as copying URLs does not have 100% of success rate for most #LLMs. This is a really nice use case as a single character wrong might break the whole url.

Just consider the outcome of trying autonomous agents with this confidence level.

github.com/Mankind-Tech...
Table displaying accuracy of different LLMs models to copy urls. With 200-300 samples most models are above 90% success rate, but some drop to 70% or even 50%.
September 17, 2025 at 6:54 PM
rolgalan.bsky.social
It’s 2025, if your company provides an #Android library and you're still asking your clients to mess up with their Proguard rules you are not mature enough.

Please use the `consumerProguardFiles` so AGP will handle this for you and your host app automagically.

developer.android.com/topic/perfor...
Screenshot from the documentation of an Android SDK integration guideline where it is mentioned that the host application must add some rules to prevent Proguard from removing classes. The actual sdk name is blurred out.
July 16, 2025 at 8:56 AM
rolgalan.bsky.social
Try saying: «The goal is to maintain the ability to easily and safely implement changes in a system that is continually evolving. This system should exist in a context that is nearly free of technical debt. Then, technical teams could provide new functionality in a shorter time and with fewer bugs.»
Rather than continually repeating the phrase “technical debt” like an old, broken record, we should talk business language and refer to technical debt as operational risk: the risk of losses caused by faulty or failed processes, policies, systems, or events that disrupt business operations. We should focus on discussing: - Systems most prone to critical failures and their potential costs (e.g., loss of sales, time spent fixing errors, loss of trust, low team morale, burnout). - The impact of maintaining a system with low quality, performance, or maintainability. - Actions to improve system resilience and prevent cost overruns. All of the above will definitely cost money and require investment. So, be ready to do your numbers and present your plan based on strong arguments.
June 29, 2025 at 10:52 AM
rolgalan.bsky.social
I had never read before the original brief article from Ward Cunningham where the #techDebt concept was introduced in the world of software engineering.

It was already more than 30 years ago! 🤯, this is history of programming.

c2.com/doc/oopsla92...
Another, more serious pitfall is the failure to consolidate. Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.
June 29, 2025 at 10:02 AM
rolgalan.bsky.social
This is devastating. The Emperor has no clothes.
If you can’t use a billion dollar AI system to solve a problem that Herb Simon one of the actual “godfathers of AI”, current hype aside) solved with AI in 1957, and that first semester AI students solve routinely, the chances that models like Claude or o3 are going to reach AGI seem truly remote.
June 8, 2025 at 5:50 PM
rolgalan.bsky.social
A few excerpts with some ideas worth to think about.
As we don’t have the time to think anymore, we masquerade our lack of ideas with behavioural tricks. We replaced documents with PowerPoints because it allowed lack of structure and emptiness to look professional (just copy paste the data of the last PowerPoint you received in a text file and see by yourself how pitiful it is. PowerPoint communications at NASA were even diagnosed by Edward R. Tufte, author of the "The cognitive style of PowerPoint", as one of the causes that led to Space Shuttle Columbia’s disaster). The root problem is that, for the first time in human history, our brain is the bottleneck. For all history, transmitting information was slow. Brains were fast. After sending a letter, we had days or months to think before receiving an answer. Erasmus wrote his famous "Éloge de la folie" in several days while travelling in Europe. He would never have done it in a couple of hours in a plane while the small screen in the backseat would show him advertisements. In "Deep Work", Cal Newport tries to promote the opposite stance, the art of taking the time to think, to ponder. In "The Ideas Industry", Daniel Drezner observes that long, subtle and complex ideas are more and more replaced by simplistic slogans, the epitome being the famous TED conferences. In 18 minutes, people are sold an idea and, if the speaker is a good salesman, feel like they’ve learned something deep and new. The mere fact that you could learn something deeply enough in 18 minutes is an insult to all the academic world. Without surprise, the same academic world is seen by many as boring old people spending their time writing long articles instead of making a catchy slogan to change the world. The root cause is there: we don’t have any mental framework left other than spying on people and steal their attention. Business schools are teaching how to do catchy PowerPoints while stealing attention from people. Every business is at war with the other to catch your attention and your brain cycles. Even academy is now fighting to get grants based on catchy PowerPoints and raw number of publications. This was the raw observation of David Graeber: even academics have stopped thinking to play the "catch your attention game".
April 21, 2025 at 9:33 AM
rolgalan.bsky.social
Time. More time to think is what happened.

Increasing the difficulty in a chess engine meant to evaluate more positions. In such old computers this took a quite noticeable increase in time. This gives the player more time to think as well, so is more prepared for the next movements.
Our Mind, the Bottleneck. In the early 90s, after tweaking my MS-DOS computer, I was able to play games. One of those game was called "Battle Chess". A Chess game were pieces were really fighting against each other. It was fun. I was, and still am, a mediocre chess player. I was mate in less than 10 or 15 turns at the easiest level. For the sake of the experiment, I turned the difficulty to an harder level and started playing. Something strange happened: I was still losing but it took a lot more turns. I was able to protect my game, even to manage a few draws. Was it a bug in the game? Even as a young teenager, I quickly understood the reason. With the setting set to "hard", the game would try harder to find a good move. On my 386 processor, without the mathematical coprocessor, this would take time. Several seconds or even one minute by turn. During that time, I was thinking, anticipating. With the easiest setting, computer moves would happen immediately. I knew I had all the time I wanted but I was compelled to move fast. I could not take the time while the other side was immediately reacting to my moves. The world we are living in is that same chess game on the easiest setting. Everything happens immediately, all the time. White-collar work can now be summarised as trying to reply as fast as possible to every single email until calling it a day and starting again in the morning, a process which essentially prevents any deep thinking, as pointed by Cal Newport in his book "A world without email".
April 21, 2025 at 9:33 AM
rolgalan.bsky.social
The reasons why average people might like more AI poems could be because they are simpler than human poems: so easier to understand the message without the analysis/effort that human poetry usually requires.
So why do people prefer AI-generated poems? We propose that people rate AI poems more highly across all metrics in part because they find AI poems more straightforward. AI-generated poems in our study are generally more accessible than the human-authored poems in our study. In our discrimination study, participants use variations of the phrase “doesn’t make sense” for human-authored poems more often than they do for AI-generated poems when explaining their discrimination responses (144 explanations vs. 29 explanations). Indeed, this complexity and opacity is part of the poems’ appeal: the poems reward in-depth study and analysis, in a way that the AI-generated poetry may not. But because AI-generated poems do not have such complexity, they are better at unambiguously communicating an image, a mood, an emotion, or a theme to non-expert readers of poetry, who may not have the time or interest for the in-depth analysis demanded by the poetry of human poets. In short, it appears that the “more human than human” phenomenon in poetry is caused by a misinterpretation of readers’ own preferences. Non-expert poetry readers expect to like human-authored poems more than they like AI-generated poems. But in fact, they find the AI-generated poems easier to interpret; they can more easily understand images, themes, and emotions in the AI-generated poetry than they can in the more complex poetry of human poets. They therefore prefer these poems, and misinterpret their own preference as evidence of human authorship. This is partly a result of real differences between AI-generated poems and human-written poems, but it is also partly a result of a mismatch between readers’ expectations and reality. Our participants do not expect AI to be capable of producing poems that they like at least as much as they like human-written poetry; our results suggest that this expectation is mistaken.
April 13, 2025 at 9:29 AM
rolgalan.bsky.social
Amazing discussion between John Ousterhout and Uncle Bob where the former dissects some parts of Clean Code (comments, method length and TDD). Really passionate debate between both going deep into the details. Quite recommended.
github.com/johnousterho...
The second general error in Clean Code has to do with balance. Design represents a balance between competing concerns. Almost any design idea becomes a bad thing if taken to the extreme. However, Clean Code repeatedly gives very strong advice in one direction without correspondingly strong advice in the other direction or any meaningful guidance about how to recognize when you have gone too far. For example, making methods shorter is often a good thing, but the Clean Code position is so one-sided and extreme that readers are likely to chop things up too much. We saw in the PrimeGenerator example how this resulted in code that was nearly incomprehensible. Similarly, the Clean Code position on TDD is one-sided, failing to recognize any possible weakness and encouraging readers to take this to a tactical extreme where design is completely squeezed out of the development process.
March 9, 2025 at 11:30 AM
rolgalan.bsky.social
This is a fascinating technique to improve App Startup time on iOS apps by optimizing the order of the code in the final binary ensuring that everything required for the startup is placed together.

Quite smart @emergetools.bsky.social!

www.emergetools.com/blog/posts/F...
Why is so much of the binary used on startup? The answer lies in how iOS deals with memory. As new instructions are fetched from an app's binary file they must be loaded from disk into memory. Rather than loading one instruction or one byte at a time, the kernel loads one large chunk of memory, known as a page. On iOS a page is 16kb[2]. So the first time an instruction is needed from the app binary, the entire 16kb region surrounding that page is mapped into memory. This process is called a page fault. Say the first 16kb of a binary contains code used by an obscure feature like captcha verification, but happens to include a single 100 byte function that's executed during app startup. Now the entire captcha feature needs to be loaded just to start the app. In practice, most or all of the binary will end up being loaded into memory during startup like this, as the startup functions are scattered around the binary.
March 1, 2025 at 9:32 AM
rolgalan.bsky.social
Alerting on causes might have high false positive ratio, which adds burden to the oncall who eventually would ignore them, missing actual incidents. Symptoms will most of the times tell you that something is really wrong, impacting your business, which the oncall have to investigate.
Answers to “what external behaviour manifests that my service is not healthy” tend to overlap with answers to “how would a user tell that the service doesn’t work” or “how would the business tell that we’re making money“. Symptoms get you talking about page loading times, conversions, successful page loads, and so on. Terms closer to user experience and business objectives. They may seem too far away from the guts of the system, but will give you clarity and purpose. It’s almost impossible to figure out how much time per month you can tolerate with >90% CPU utilisation. It’s much easier to figure out what is the acceptable percentage of failed requests. High CPU usage might signal a failure with, for example, 75% success rate. But that also means a 25% chance of being false positive. Every time this alert triggers preemptively you place a burden on the operator to confirm whether it is actually relevant. As you add more metrics for the many other possible causes of trouble, the odds of suffering false positives accumulates to unpleasant levels quite fast. Discomfort is not even the biggest problem with noisy alerts. Lots of alerts with low signal ratio slowly induce your team to ignore them, miss actual incidents and worsen their impact.
February 23, 2025 at 10:14 AM
rolgalan.bsky.social
I think these numbers are the most relevant conclusion.

This is the amount of users you would need to track for reliable monitoring based on expected impact. Remember this is per dimension. Time is also a dimension. If you want to catch this in minutes you will need that amount in that time window.
Going back to the original problem and applying it to a concrete example: I would like to have 99% confidence that I am tracking enough users to detect any crash. Depending on the severity, the formula above tells us that we will need a minimum volume of users: - For crashes impacting 0.001% of users, n should be at least 470k. - For crashes impacting 0.01% of users, you would need to track 47k users or more. - For crashes impacting 0.1% of users, 4.7k tracked users will be enough.
December 13, 2024 at 5:04 PM
rolgalan.bsky.social
«Celebration is also an underrated way to change other people’s behaviors. People want to do more of whatever gets them praised [...] This is an effective way to build #influence even without being a manager.»

www.nehrlich.com/blog/2023/01...
Celebration is also an underrated way to change other people’s behaviors. People want to do more of whatever gets them praised, so if you celebrate a behavior, you’ll get more of that behavior. If you catch them doing something even vaguely in the direction you want, praise it in the moment. This is an effective way to build influence even without being a manager; nobody gets enough praise in corporate America, so people are starved for positive feedback, and respond very well to those who offer it.
December 9, 2024 at 5:22 PM