youtube.com/watch?v=awulq0-V… #ElixirLang #MyElixirStatus #SmallTalk #GToolkit #MoldableDevelopment @feenkcom Original post: elixirforum.com/t/the-real-p…

Is anyone working on "lovable for private repo/product" style of tool? I either build myself one or use something out there that can help non-tech stakeholders to do #moldabledevelopment on an app. DM me if you want to join the waitlist

🧠 𝐌𝐨𝐬𝐭 𝐝𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫𝐬 𝐝𝐨𝐧'𝐭 𝐬𝐩𝐞𝐧𝐝 𝐭𝐡𝐞𝐢𝐫 𝐭𝐢𝐦𝐞 𝐜𝐨𝐝𝐢𝐧𝐠. 𝐓𝐡𝐞𝐲 𝐬𝐩𝐞𝐧𝐝 𝐢𝐭 𝐟𝐢𝐠𝐮𝐫𝐢𝐧𝐠 𝐭𝐡𝐞 𝐬𝐲𝐬𝐭𝐞𝐦 𝐨𝐮𝐭. Tudor Girba (@girba) makes a compelling case: software engineering isn't just about building. It’s about understanding. And we’ve been doing that the hard way for decades. 🔍 Historical Insight 🔹In 1979, researchers estimated that 67% of dev time was spent on maintenance. 🔹By 2018, a large-scale study found that 58% still goes to comprehension, with another 24% just navigating! Despite all our progress, the problem persists: we spend more time trying to understand systems than improving them. 🚦 Why? Because understanding is about decision-making and we’re using reading (the most manual, slow, and incomplete method) to do it. 💡 Girba reframes this with a key insight: let’s call this process Assessment: The act of understanding enough to decide what to do next. And let’s optimize around that. 🔧 Enter Moldable Development Instead of reading code line by line, what if we built custom tools to extract exactly the insight we need? That’s moldable development: tools shaped by context, not one-size-fits-all. 📊 Since software is data, we should treat it like data. Use tailored, quick-to-create tools to analyze and understand systems. Faster, clearer, smarter. 🤖 And yes, for all AI-Africanos out there, Moldable Development tools can and should be powered by AI. Imagine local, context-aware assistants generating the right visualizations, insights, and actions tailored to your system. That’s the next leap. 📢 Let’s change the conversation. Stop defaulting to code reading. Start designing tools that work with us. 🔗 Link to the article: buff.ly/w6bywJs #MoldableDevelopment #SoftwareEngineering #Productivity #AI

The choice is not between vibe coding and not vibe coding. There is a middle ground that does not require us to suspend our ability to understand and make decisions about our system. It's almost vibe coding but not quite. It's AI-enabled software engineering. Of course, this requires appropriate tools to help you understand the system faster than by reading the code. Now, where does the chat happen? In a contextual view in the inspector in which each message is a shown in an inspector with contextual views. Even when the output from the AI is verbose we can just pick what we are interested in using tools that help us work with the code in a tight feedback loop right there in the chat. And what are the conversations about? They are about any part of our system we want, starting from a single snippet or a single object. These abilities allow us to both specify the context we are interested and to grasp the AI output. We are not confined to a basic chat somewhere at the outskirts of our system. We can make sense of and steer the system from deep inside of it and use AI where and how it makes sense. #MoldableDevelopment

Tobi Lutke’s recent memo about AI being an expectation at Shopify made the rounds these last days. I enjoyed the memo, but there is a little assumption in there that’s worth unpacking. I think it’s great when a CEO takes software engineering capabilities seriously and that understands that new abilities take time to internalize and leverage. Indeed, working with AI is certainly an interesting capability that does take time to get used to and learn how to adapt to needs and how to adapt to it. But this message has a hidden assumption. Along the way he says that in a company that grows continuously, personal skills growth is expected as well. And then he says that “before asking for more headcount and resources, teams must demonstrate why they cannot get what they want done using AI”. The implication here is that growth can come from either a headcount increase or from AI. That assumption is wrong today. A large source for productivity improvement can come from how you understand your systems. Same people. Just new skills. And perhaps a new kind of tooling. AI can indeed help, but it’s not essential and it’s not where you should start from either. It does not mean that investing in AI is not interesting. Of course, it is. I particularly liked the idea of having the AI present in the GSD Prototype phase. Still, that hidden assumption lingers silently in the background. If you look closer, you might find that the way you can leverage AI beyond that prototyping phase depends on how you understand and make decisions about your systems (especially related to their insides). #MoldableDevelopment

Consider this: you cannot experience anything about a system except through a tool. That makes the tool rather fundamental for software engineering. It also follows that we should be paying particular attention to the characteristics of the tools we reason through because they will influence how we are going to think. LLMs muddy the water a bit, but let’s ignore them for a second. All tools are not created equal. For example, how would using Word as a code editor (and nothing else) influence your problem solving abilities? I suspect significantly. In other words, simply changing the tool can make a problem harder or easier. I find this fascinating. Don't you? If you do, then let's take that observation a little further: if choosing an appropriate tool can carry such power, what if we could choose the right tool for every single development problem? And if there doesn't exist such tool, what if we’d build one just for that problem? It turns out that this idea can lead to better problem solving. It’s called #MoldableDevelopment.

The 2020 and 2021 StackOverflow surveys had a fascinating "What do you when you get stuck" question in it. In 2021, the top spot was taken by "Google it" (~90% of the responses), with "Visit StackOverflow" coming second (~80%). I guess if they'd ask today, "Ask ChatGPT" would be the top preference. "What's so fascinating about it?" Let's think about a scenario. We want to engineer a system. We get a problem. And the best engineering way to find a solution is to go ask someone else that has not seen our specific system in the hope that they somehow stumbled across something resembling a solution. Well, it certainly is a way, but it does not have much engineering in it. "But what's wrong with searching on StackOverflow?" Nothing, actually. The problem lies in the very idea that an answer about our system is better found somewhere else than in our system's environment. StackOverflow is not a problem at all. But its success reveals a systematic problem in the underlying engineering discipline. We somehow got used to the idea that getting answers from our systems is expensive. That does not have to be the case though. We can decrease the cost of answering questions significantly compared to how it happens today. "ChatGPT solves that problem!" Well, not how it's typically used today. People ask ChatGPT a question, get a response and treat it like an actual answer much like how they treat a StackOverflow answer. The essence is similar. It just happens faster now. Integrating LLMs into the development environment helps because there is more customization. It also helps that LLMs are confident all the time. But engineering should not only be about finding some solution. It should be about choosing a solution by understanding the tradeoffs. By understanding cause and effect. A response becomes an answer when we can make the choice. When we can understand how we got to the answer, how accurate the answer is and how representative it is for the system. Otherwise, it's just a response. It might be a good answer, but we wouldn't know it. Just like it could be a bad answer looking as a good answer. If we want to be decide what gets into production, we should strive to understand our systems. "And how do you propose doing it?" I believe the solution is to decrease the cost of answering questions about our systems through a systematic method. When we are stuck, we describe the problem by making what we know about the system visible. To make the system visible, we use tools. Not generic tools. Tools that are specifically made for the very problem we are looking at. Tools that we create as part of an engineering discipline. We can program such tools ourselves or we can use LLMs to propose them. But that's mostly a technical issue. How we create tools is essential, but it's not the most important part. The most important part is the ability to incorporate custom tools at every level of software engineering to find answers faster. #MoldableDevelopment

This announcement is fascinating. Not because it announces the generation of documentation for software systems, but because of the motivation. Let's take a look. "Today, developers report they spend an average of just one hour per day coding." This is not new, of course, but it's great to see it out loud. Indeed, writing occupies a small fraction of software development. I am actually surprised it gets to 1h per day, actually. But then comes this: "They spend most of their time on tedious, undifferentiated tasks such as learning codebases, writing and reviewing documentation, testing, managing deployments, troubleshooting issues or finding and fixing vulnerabilities." There exist indeed "tedious, undifferentiated" tasks in software development. But they do not quite look like what they list here. Take deployments, for example. #DevOps commoditized much of the tedious parts. The same applies to testing. And if people are still testing or deploying manually, the solution is not AI. That said, there exist tedious tasks carried out in software engineering. In particular, developers spend most of their time reading through textual artifacts as a way to figure out what to do next. This is the most manual way to extract information from systems. Only the solution is not AI here either. We can automate a great deal of this activity by creating custom tools. Like we did with testing and deployment. AI can play a role, but before we can exploit it for software engineering, we have to understand the foundation of software engineering. For example, let's say that you want to use #GenAI for testing purposes. Would you consider an AI which takes the code and answers if there are bugs or not without showing you any test artifacts? Or would you rather prefer a solution that generates a test that you can investigate and run yourself? The former might sound tempting, but it's only the latter that can be a useful software engineering tool because it can be explained and adapted to various needs. Testing is the goal indeed, but the engineering way is to get the tests that you can run yourself to check. The same applies to any topic, including documentation. If you ask an AI for a diagram of the code, would you trust it? How do you know if what it tells you is correct and complete? The alternative is to ask it for a tool that you can use to create the diagram. That tool can be explained and adapted to various needs. That's the engineering path. But we'll only find that path if we, as engineers, expect it. Today, engineers are just fine with reading as a means to learn about a code base. It's tedious indeed. And much of it can be automated away. Just not with AI. As long as we want to make decisions about what gets deployed, AI is only an optimization in this space. p.s. There is another point that this announcement reveals. It sees code as a utility. This perspective misses a large source of value creation: code as encoded knowledge. #MoldableDevelopment

The typical discourse about #DX (Development Experience) entails two pervasive assumptions: 1) that it's only for developers, and 2) that it's primarily for writing. We have to outgrow both. Any decision about a system, regardless of whether it is technical or it is business focused, requires information from the system. This information has to be synthesized somehow from the system, and the only way to do that is through a tool that provides an experience. A Development Experience. Thus, DX is paramount for any meaningful system development. We have to understand what characteristics should it have... "Wait a second ... DX for business?" Yes, exactly. Not just for business analysts. The C-level and the executive board should be integrated, too. In fact, there are situations when you want to accommodate customers as well. "That sounds crazy. I haven't seen anyone doing that!" Just because you haven't seen it practice does not make it crazy. In fact, it is because this perspective is quite opposite to the status quo that makes it an opportunity: those adopt it first can exploit it as a competitive advantage. "But do you expect a C-level to write code?" And this brings us to the second point. I know that it's active part of building a system that captures people's imagination, but even developers today write code for a fraction of their time. They spend most of the time reading through it because they want to understand what to do next. The largest cost in software engineering is figuring the existing systems out. It's reading, not writing that we should optimize our work for. And that is the interesting bit. DX should help us make systems explainable to various audiences. #MoldableDevelopment

I often tend to talk about #MoldableDevelopment in too abstract terms. I did it in a call just now. It's not the most useful inclination. That's when I wish I had @swardley next to me to bring me down to earth and show concrete examples. Like he did in this chat when he had me show him how I construct a custom tool for exploring an API on the spot. What do you think about this example?

I am talking quite a bit about making systems explainable through #MoldableDevelopment. This is a new way of programming and I am still searching for the effective compact narratives. If you are interested to learn how it can apply your specific context (technology, domain, process), please ask questions either publicly or in a DM. I will answer them. I believe it will make the exercise more interesting for you and it will certainly be helpful for me as well. Win-win 😃. So, what do you say? Care to comment?

#MoldableDevelopment is about programming through custom tools. Little tools, often in the shape of object views. The key to making this practical is to decrease the cost of creating those custom views. While we already could create them in minutes, we've always been interested to get to costs measured in seconds. Yes, yes, I know that #GenAI can be interesting in this context. But before we explore that path we should first try to exhaust possibilities that are much more approachable, explainable and ... less magic. Like the approach described below. Once we accept that tools can be combined in a myriad of ways, we can get to all sorts of unexpected properties. Let's look closer at the scenario from the video. We start with a file reference that points to an MP4 file. We see a view with the file path, but we'd rather also see a movie player. So, we write a script that produces an element that can play that movie in a web browser. Then we ask the object to give us a default view and Voilà! This scenario is possible because we could combine the result of dynamic execution with the static extraction of a view and bring that magic in an interactive editor. There is a tremendous potential for augmenting our human ability to relate to systems. And the key lies in the environment.

Most interesting questions in software engineering require traversing multiple levels of abstractions and combining different perspectives. Decreasing the cost of the exploration can dramatically accelerate engineering. Let's take a concrete example: How does a post on @bluesky that contains an embedded link appear in the data? This implies at least: - find a post that has an embedded link - find how to get the data for a post - find what the different parts describing the embedded part mean Take a moment to imagine how you'd go about doing this exploration. Perhaps you'd start with exploring the posts in the web app. After finding an interesting post to explore, turning that post link into a code query to get the data. And then exploring the data values, and perhaps using a web browser again. Three actions requiring three different mediums. Now, take a look at the attached video. There is only a single medium in which the tools magically appear in context. The exploration is seamless. "Looks interesting, but this is just a demo." That's the thing. It's not a demo. It's an excerpt of how #MoldableDevelopment looks like in practice. There is no single tool. The exploration is made out of discrete small tools that we can combine in context while we explore. These tools are create specifically for that context. Whenever we have a question, we look around to see if we have the most interesting tool to find the answer. If we do not find one, we build it right there and then we continue the exploration. In our case, we do not see this part as the tools already existed because we already had other questions for which we needed those tools. But what we do see is how once tools exist their value compounds over time as we can combine them in many ways to explore arbitrary explorations. This decreases the cost of answering questions about our systems. Once we can answer faster, we get to ask more questions. And like this, we get to find better solutions faster. It looks small, but it leads to a new way of programming.

By all means, make your code readable. It's relevant when you look at code in the small. But you should not rely on reading as the primary means to reason about a system. Code is best seen as data. It can be interesting to read it occasionally, but for the most part it’s more appropriate to approach it through dedicated tools that summarize it. Why is that important or even needed at all? Today, developers spend most of their time reading code. They do that because they want to understand enough to figure out how to change the system. Reading is the way they extract information from the system. As code is data too, we can build tools that extract the information we care about from it. #MoldableDevelopment

After working with it for a while, we found that hiding parts of the code that are less relevant for the main domain flow works really nicely in practice. But we were not entirely satisfied. We still wanted to know exactly what will get hidden before hiding. So, now we can see it. In this example, we are hiding the wrapping code around the domain code. When we hover over the hiding button we highlight only the wrapping part. And all this is happens through a styler that gets enabled contextually when the code is using a specific telemetry library. What do you think? #MoldableDevelopment with #GToolkit

Clifton Johnson was an early photographer, and he wrote this about photography and painting in 1900 (*): "Up to a certain point, the accuracy of the camera in depicting life gives the photograph unrivaled merits. It portrays with exactness everything set before it, and its value in recording contemporary work, costumes and manners can hardly be overestimated... No paintings, however masterly, could wholly take the place of them; for you can never be sure just how much an artist may have put in or left out, and how much is reality and how much imagination." This was written during a time in which photography was getting adopted and replacing painting as the way to depict reality. We can learn from this in software engineering as well. Pictures about the system are important as they summarize the system from a certain perspective. However, when you draw a diagram about the existing system by hand, you are painting and we do not know what you may have put in or left out. Instead, you can take a photograph of the system through a visualization that shows the system without human mediation. Interestingly, once photography got more adopted, painters could get free of representing reality and they started to focus on representing ideas, a trend quite visible in the early 20th century art. The same can and should happen in software. Paintings are great for depicting our ideas. Use them for expressing where you want to go. But look at the present through photographs. (*) The Saturday Evening Post 1900-12-08: Vol 173 Issue 23 #MoldableDevelopment

Observability signals are useful as they allow us to reason about the execution of a system. Still, when the signals emitting code is intertwined with the domain code, it can also hinder readability. Well, that is just a tool issue. Some signals emitting code can be added orthogonally with the domain code. For example, we can have annotations around a method. But often we want to have detailed signals from inside the domain logic. That can produce unwanted noise when reading that particular part of the code. So, a solution is to have the ability to hide the unwanted parts. There is only one tiny complication though: emitting signals depends on libraries. This means that we need some way to tell the editor about those code patterns. That's of course, possible. Take a look at the example from the video. It's a method from #GToolkit which holds signal code snippets that are wrapping the interesting code. A custom editor styler detects them and offers a button in the editor to collapse and expand the signal wrapping code. That's it. The essence of #MoldableDevelopment starts from the premise that most code reading can be automated because it is actually searching for interesting code. But every once in a while we want to focus on a piece of code that we do want to read. A moldable development environment should support that, too.

If you are a technical person and want to convince your business manager to invest in better skills and tools for legacy modernization, start from the business perspective. Say you looked into #MoldableDevelopment and are now convinced that you need to invest in it because it's your way out of what feels like a legacy hell. But how do you convince your business manager to invest in it? One way is to start from a problem that business can quantify. Investing in the skills and technology needed to create custom tools is not on any business person radar today. Furthermore, often programming itself is still perceived as just a cost rather than an investment. In such situations, it can be difficult to argue for more investment. But they do have problems that they want to see addressed. There are at least two kinds of such visible problems: 1) long standing problems that do not seem to be ever addressed, or 2) pressing problems that are (about to be) triggering crises. In the long standing category could be decreasing the cost of bug fixes after a release. It can be speeding up the customer support. It can be accelerating the adaptations to external systems. It can be limiting the risks associated with a long running migration. It can be improving the performance or scalability. You get the idea. In this category you can take a sample of the problem and show how that can be improved. Most of the time these problems are due to lack of visibility. Build dedicated tools for them to get a better perspective. It inevitably leads to new insights that you can then act on. A recognized pressing problem can be another point to start from. I say "recognized" because there are always problems but most are typically not acknowledged on the business side. When in a crisis with no visible way out, people tend to be more inclined to try last resort actions and accept apparent magic. You can use this as an opportunity. Create tools that provide insights that are directly relevant for the crisis and build from that. All in all, instead of selling the custom tools idea, you can show outcome. Start from a quantified problem and deliver a quantified result. Once you've done that you can show how you've done it and argue for more investment. Btw: this path does not require scale. It can start with a single programmer.

#MoldableDevelopment is a way of programming through custom tools. We approach every development problem through a custom tool built specifically for that problem. This often leads to thousands of little tools per system... "Thousands of tools? But is this not expensive?" Well, no. Quite the opposite. They are cheaper to build than not to build. These tools do away with most need to manually read code, and reading code is the most expensive activity in software engineering today. Instead, these custom tools, built specifically for the questions we have, summarize the system and help us make decisions much faster and more systematically. "So, these tools summarize the system. What AI are you using to build them?" Ahh, well, summarization is not the same as AI. For example, a view over some data summarizes that data. Such a view is produced by a small program that can be created to capture what we are specifically interested in at that moment in time. Through such views we can make decisions much faster than we can by reading the data directly. And everything in a system is data, including source code, configurations, logs etc. While AI can play a role in this equation, it is not essential. We can indeed rely on some AI to generate tools but that is mostly an optimization. "But tools are expensive. How can it be practical to build thousands of them?" Well, that's the thing. Tools do not have to be expensive. They can be as inexpensive as a few lines of code built in minutes. "It's hard to believe this." I know it is. That is why we built Glamorous Toolkit. Take a look. "Ah, so this is whole Moldable Development thing is just an ad gimmick for your commercial tool?" Not really. Glamorous Toolkit is free and open-source. We built it exactly so people can experience the idea of custom tools by themselves, in their own terms. Moldable Development is a practice. We used and validated it extensively. You can use #GToolkit to solve actual engineering problems with your systems. At the same time, and perhaps more important, Glamorous Toolkit is an extensive case study of Moldable Development showcasing literally thousands extensions that explain the inner workings of the environment.

The most basic development tools are the object inspector and the snippet. Pretty much any other tool is derived from these. This also means that we can just use these two to compose contextual tools for all sorts of situations. For example, here we are browsing a set of Apache Hive scripts. We are using two inspectors, one for a model that shows us the tables involved, and one for a table. The table inspector shows an editor that offers links and expanders to explore more in context. This tool is already quite interesting, but if you look closer, there actually is no tool. It's just a concatenation of two inspectors with some custom views. Any part of a system can be explained through similar combinations. #MoldableDevelopment