DEV Community: Andreas Müller

The point of planning

Andreas Müller — Fri, 27 Mar 2026 05:48:47 +0000

In software development, we love to make plans. We plan everything from 2-week sprints to 5 or more year roadmaps. And yet I sometimes think that the point of planning is misunderstood.

The point of having a plan, for me, is not to have a concrete set of steps. Well, it is that, but that's not the real value of it. The point is understanding the why of the plan, and the how of the steps.

The why of the plan is this: Why does this plan make sense? Why does this plan bring us closer to fulfilling our goals? Without a purpose behind it, a plan is meaningless. I would even go so far as to say that sometimes having a fixed plan at all is counterproductive. Sometimes the product may be in an exploratory phase, and the only plan would be to try a lot of things and see what works. But the why behind this plan is clear: To evaluate a lot of options. Then we could go into the details and schedule the evaluations and timelines for the options we want to explore. The point is that the goal dictates the plan. Not the other way around.

And on a smaller scale we have to understand how the steps of the plan contribute to achieving the goal of the plan, how they contribute to fulfilling the why. The point of this understanding is that often plans can't be executed exactly as they were initially created. But if we understand how something we can no longer do was supposed to contribute to the end goal, then we can intelligently search for a replacement to that something. We can do this because we understand the new situation we're in and we know that we need to find something else to do that fulfills the purpose of the step we wanted to take, but can't.

Actually, I would summarize this whole article with one concrete advice: For every component of a plan, understand the purpose of the component. For the plan as a whole that is the why, and for the steps of the plan that is the how.

Thanks for reading :)

Why software development education has to become more personalized

Andreas Müller — Sun, 04 Jan 2026 18:30:36 +0000

I am currently reading Robert C. Martins "Clean Architecture", and it really made me think about the following question: What knowledge in software development is actually foundational, and what knowledge only applies to specific roles?

I think the answer is that the amount of knowledge that is relevant only in specific roles is immense. Of course there are foundational aspects, like minimizing coupling and maximizing cohesion, that everyone should know. And yet even at this foundational level there is so little knowledge that is actually universally agreed to be true. Much of the knowledge in our field remains heavily debated to this date. Some think not using TDD is irresponsible, and some thing TDD is impractical, or leads to bad designs (because you're not thinking enough about design before starting implementation).

So how can we educate future software developers in the face of a) so little knowledge which isn't dependent on the context you work in and b) so much knowledge which is still being debated?

I think the answer is to personalize education more, and with AI we are now in a great time to actually do that. Today I vibe coded a small web app that communicated with my local LMStudio server, and what I realized is that vibe coding allows you to learn in a more targeted way than is common in traditional education. For example, it generated me an async function in JavaScript, using the await keyword. I neither knew what an async function was (though I could guess of course) nor what the await keyword exactly did. But seeing those keywords in an actual example allowed me to look them up on the mozilla developer network, and quickly grasp the concepts behind those keywords.

And I think that is how education should change. I reflected on what allowed me to learn about those two keywords. And actually it is just one thing: Being able to read code. Because the syntax of the most common programming languages is really similar to the point that if you can recognize what keywords in one are you can spot what keywords in others are. My ability read the function declaration and spot async as a keyword modifying the function, and spotting await as a keyword, allowed me to look those two keywords up.

Of course some computer science is also necessary, but the basic thing is to teach students to read code and then let them get out there, arm them with AI and let them learn on their own. Then, after a time, you come together with the student again and let them present their code and thus see what they have learned. That is how I would envision software development education going forward. Not this frontal assault of "here is some really fancy mathematics you'll never, ever need in practice" but training them to do what they are going to do:

Learn on their own in an age where personalized learning based on your interests is easier than ever - if it is guided by qualified instructors and done in the right way.

Use your debugger less and learn more from debugging instead

Andreas Müller — Sun, 14 Dec 2025 16:05:02 +0000

In my last project, I was working on a big, complex expert system. For various reasons using a debugger to inspect bugs was difficult. One of the reasons was that we got live data from the real system we were trying to replace, so traffic was high, and following one request was problematic.

Especially when we had a bug on the client side debugging was hard. Our client was a custom Java frontend based on Eclipse RCP and we didn't actually have that much experience with the technology (we bought and revised an existing product, we didn't create a green field app. I don't remember what the actual UI framework was). For that reason our UI logic was really hidden in layers upon layers of Java code and XML files. Hard to inspect with a debugger because there was a lot of generic code, which made it hard to trace the execution flow.

In those situations I found a for me new strategy to debug applications. In the past I had almost exclusively used the debugger, but in this system I didn't find the debugger terribly helpful in most cases.

So what I did was the following: Really think hard about what I actually wanted to get out of the debugging. That was the first step. What variables did I actually want to look at, and what properties of their values was of interest? I think debugging with a debugger can often degenerate into a "let's have a look" kind of thing, where you don't think about this question very much before a debugging session. But asking that question beforehand is vital. I only go into debugging sessions empty-handed now if I really have no idea at all what the problem might be from looking at the code, which rarely ever happens.

The next step is to craft a set of log statements, logging the values of the variables you're interested in. The great thing about log-statements is that you can log any information, in any format you want. And one other crucial thing: Log statements can give you timestamp information. I found that really handy to debug timing problems, which I think are very hard to see using a debugger.

Then when you have your log-statements, you either run a local process with them added or you make what we called a temp (for temporary) commit. A temp commit was there only for the duration of the investigation of the bug, and would be taken from the codebase once we merged into main. The nice thing is that with a temp commit, you can deploy your system into test, then throw real data at it and then grab the logs afterwards.

Now you are in a great position to analyze bugs because you can programmatically analyze the logs. In my experience that's way more useful than a debugging session, which unless recorded as a video does not survive the session itself, and everything learned has to be passed by word of mouth. By programmatically analyzing logs you now can't only share your analysis results, but also the data which led to the results and even the analysis code. That way another developer can pick up where you left off with the analysis, even if you get sick or otherwise indisposed. You can even go so far as to build a little framework, making future analysis easier.

All this really helped me a lot in understanding the behavior of the system better. I came to a point in that project where I rarely ever used the debugger anymore. To me logs are a far more deliberate, structured way to analyze bugs than using a debugger.

Where I think debuggers are still useful is when you don't even know what the execution flow is actually like, because for example it is hidden in generic mechanisms in the code and you can't trace it just by reading the code. But even then I only analyze the control flow in the debugger, and once I know the classes involved I switch to writing logs.

If you've never used logs for debugging purposes I hope this piece gives you some new ideas, and hopefully makes debugging a little easier.

Thanks for reading, and feel free to let me know your thoughts in the comments.

Are senior developers misused in your company?

Andreas Müller — Sun, 14 Dec 2025 12:21:46 +0000

This is more of an information gathering post, but I will also share my experience. In my experience: Yes, they are. I've seen this now in 3 big companies I worked for as a consultant. The best developers are chronically overloaded with work. Their schedules are packed with mandatory meetings that they have to attend because they often also have a leadership role. But in some of those meetings their presence is not really required from a standpoint of the content discussed in that particular meeting. They just have to be there because the head of development on a project has to be there.

Someone sometime decided that and the decision was never re-evaluated, and isn't evaluated on a meeting by meeting basis. I guess it is just easier to invite everyone who might have something to say than to carefully consider which presence is really required for the topic at hand. My philosophy on meetings is: Only invite the people which are absolutely necessary to achieve the purpose of the meeting. But in my experience, especially for regular meetings large companies don't seem to share this philosophy.

But that creates an almost tragic waste in my opinion. See, the best developers, those are the guys you want to have a lot of undistracted time to reflect and think deeply. Those are the guys from whom you get the most value from giving them this time. And yet in my experience, those are the guys who are given the least time to think deeply and reflect.

What about you? What is your experience? I would especially like to hear from people working at small companies, because I have no experience working at small companies.

See you in the comments!

Slow programming - why I don't let AI generate production code for me

Andreas Müller — Sat, 13 Dec 2025 13:17:14 +0000

In this post I would like to talk about an idea that I've played around with in my work recently - slowing down.

There is a saying attributed to sharp shooters in the military: "Slow is smooth, and smooth is fast". More and more, I'm learning that this is true in software development as well. And it's not less true in the AI era - on the contrary, I will argue in this post that it is more true in the AI era. Let me explain.

AI promises science-fiction like increases in productivity. But I have a question: Can we, in the long-term, not the short-term, sacrifice quality on the almighty altar of "productivity"? I would argue that this is a highly questionable proposition. Yes, AI can code faster than I can. I don't dispute that. But can it produce higher quality than I can? In places, maybe, yes. But across the board? Across a whole system? I would argue that it is not remotely at that level yet. And I argue from my own experience, using AI daily, albeit more as a research assistant than as something writing code for me.

There are two reasons for that: One is selfish, the other has to do with responsibility and being a craftsman instead of "just" a coder. The selfish reason is that I love to code. It is the best part about the job for me. And I'll quit before I let a machine take something I love away from me.

But the other is that I will gladly put up my ability to produce clean, high-quality code by engaging in a dialogue with business people and architects against any AI you choose. Experienced developers are still way better at producing clean, maintainable and extensible abstractions and therefore code then AI is, and may ever be. I mean generating unit tests for existing classes? Ok, fine, if you carefully review what it generates, then yes, it can save time. Though I have yet to come across a case where I didn't have to modify the output, even for simple classes.

But generating production code in critical systems? Unless someone forces me to I will never do that. The reason is the following: If I make the GIT commit, or even if I just review the GIT commit, I am or at least share in the responsibility for the code. And I'm not just hired to produce code that somehow, by some miracle, does what it's supposed to do. I'm hired to produce high-quality technical solutions that not only customers, but also my fellow developers love to work with. I'm not a code generator. I'm an author of well-designed solutions, and that starts with well-designed code. The ultimate measure of code quality is this: If you write code that is so easy to understand and well-designed that another developer can read it, maintain it and extend it without consulting you then you have done a truly masterful job. In other words, great software developers are, and this is admittedly an ideal we can never completely realize in practice, 100% replaceable.

But to even come close to that ideal you have to code slowly and resist the hype around measuring productivity by raw speed. This is where the title of this post comes in - you have to move slowly. Take your time. Think about each and every line, and never loose sight of the context in which you create the code. All this requires effort - way more effort than producing something that somehow, someway "works". But well-designed systems are easier, and also faster, to extend and maintain than poorly designed ones. I don't agree with Robert C. Martin that making a mess costs us time instead of saving it on every time-scale. In the short term, and to some extent even a little longer than that, making a mess can save time. But not in the long term. In the long term quality saves time, and also money because it produces less bugs.

And in my experience the reward of working this way is the feeling that you are not just someone payed to do a job, but that you are truly practicing a craft, and that you are practicing it well. Doing things well is one of the most fundamental sources of human joy.

So, in the age of AI, you have a decision to make: Do you want to buy into the "it's all about speed" hype - or do you want to be a craftsman in the best sense of the word?

Will you engage in slow programming? Because remember: Slow is smooth. And smooth is fast.

Should developers meditate?

Andreas Müller — Sat, 13 Dec 2025 11:06:52 +0000

Hi there, my first post! I am a dev who has a passion for the, often underrated, topic of taking care of both your body and mind. Especially if you are a developer, whether an aspiring one or an experienced one, you need to take care of your mind.

After all, what is all your education and knowledge worth if you can't think clearly and precisely enough to apply it in practice? Exactly, nothing.

And that's my topic for today: Taking care of the mind. Meditation may still sound like something esoteric or religious to some, and it can be that, certainly. But mindfulness meditation focused on the breath, which is the meditation I've been practicing for 6 years now, is not inherently religious. It came from Buddhism into the west, but there is nothing inherently Buddhist about it.

Mindfulness meditation simply means to practice focusing your mind on a single point of focus. In my practice, the breath. You sit comfortably, in a relaxed, upright posture. Then you close your eyes, focus on the in and out of the breath, wherever in your body you feel it most clearly. When you get lost in thought, as soon as you notice that you are lost in thought you go back to focusing on the breath. There's a little more to it than that, but that's basically it.

Nowadays the science about mindfulness meditation is pretty clear: Regular meditation, as little as 10 minutes per day, measurably changes your brain activity after a while. Anxiety can decrease. Your subjective experience of pain can decrease. Focus increases. And there are other benefits as well.

Why does that matter for devs? Well, who works with the mind more than we do? Our entire job is almost exclusively mental. There really is no physical stress other than sitting a lot on us. What you do, you do with your mind.

I would hesitate to answer the question in the title of this post with a definite "yes", because "should" is very prescriptive. Certainly, you can be a great dev without meditating. But if you feel like you could use a little more stability in your focus, a little more calm, a little more of a relaxed but alert feeling instead of being stressed out all the time - then meditation is something I would encourage you to look into.

How to start? There are many ways nowadays. I started with the app Headspace and found it to be very motivating and accessible. There are other apps, like for example Calm. You probably really can't go wrong if you choose one of the more well-known ones. Books are also a great resource, but one advice on books: Don't start with one about Vipassana. Vipassana is Buddhist insight meditation, and books about it tend to come with a lot of Buddhist philosophy/religion baggage. If you just want something about meditation itself I would recommend books like "The headspace guide to mindfulness and meditation". That book helps a lot to get rid of some of the common misconceptions about meditation, and while the author trained as a Buddhist monk he has a gift for demystifying meditation (which is probably why he was capable of creating Headspace content in the first place). If you want YouTube videos, I can also recommend any interview with Andy Puddicombe, the headspace co-founder.

And before you ask, I'm not affiliated with Headspace in any way. It's just that Andy Puddicombe truly has a magnificent gift to explain meditation concepts in a way that is easily accessible and doesn't come with spiritual/religious baggage.

Courses can also be a great place to start, but I would encourage people to try out meditation with short (10 minutes or under) sessions at home before booking a retreat. In a retreat you sit for hours, and if you've never done meditation you'll probably find 10 minutes quite challenging. I think a retreat as your entry to meditation is a bit too much.

If you have any further questions about mindfulness meditation, let me know below this post. Thanks for reading, and may your mind be happy and peaceful today!

EDIT: If you have a medical condition, especially a psychological one, then please consult with your doctor if meditation is suitable for you. It can be unsuitable for some people depending on the condition.