Programmers need to start meditating

Most people that happily use the LLM for coding either are not responsible for the code running or have no qualms to being a reverse centaur.

Ironically I don't think software engineering has progressed much at all since vibe coding got fashionable. Real, meaningful engineering advances are being drowned out by the AI coding religion.

It is not just what you do or don't do in the code (e.g. MISRA or CERT C) but there is also a lot about how you test, review, show that your tests cover everything relevant (not just code coverage, but also specification coverage), show how you check that everyone involved followed the process, etc.

Not true if they kept going the wrong direction.

And for me, it is boring and painful AND useful. And took weeks to start to show any benefits at all. Sort of like going to the gym. And people should know that that is a common thing, that you might hate meditation practice but still find it useful and continue.

I'm convinced that meditation doesn't work for a lot of people because it has too much dogma about what it's supposed to be, and maybe those aspects are valid for certain pursuits, but it obscures the core principle.

Take exercise as an example first. It's also a practice that is layered under heaps of nonsense and complexity or fluffed up with idealisms and systems. If you strip all of that away it's about one simple thing: strengthening the muscles and connective tissues of your body including organs like your heart and lungs. Muscle and living tissue only responds to repeated exertion and rest (rest includes nutrition). If you never exceed your current capacity, it will never grow or strengthen and will probably weaken. So exercise becomes simply pushing yourself a little beyond your current capacity and then properly resting afterwards. How you do that is up to you, taking a longer walk than you did last week, slowly mastering calisthenic poses, progressive overload weight training, becoming actually good at ballroom dancing or ballet, competing in field sports, the same principle applies and you get much the same results.

Now returning to meditation, the first thing we should do away with is the label because it is almost as much an error as calling all exercise bodybuilding. It should really be thought of as "attention training" where you are improving your control over and the capacity of your attention. Like with your body, your mind responds to exertion and rest. Both are required. How you train your attention is up to you, sitting without distraction is perhaps the most accessible but it's about as challenging as limiting yourself to doing prison cell bodyweight exercises. Walking without distraction is a very valid practice but is harder to manage since it requires isolation and freedom from interruptions that many people would find on a walking route. Many other techniques have been developed with many different aids and systems but the important thing to remember is that you are trying to do the same thing for your attention as you are for your muscles, push it a little more beyond your current capacity each week and giving it sufficient rest between sessions (including proper nutrition and sleep). If the usual things that are sold as meditation practices don't work for you then try things that seem more natural to you but which still stretch your attention. This could be viewing a piece of art for a set amount of time, finding a location with a fairly static view and doing the same, holding or placing an item you own in front of you and examining it, repeating a line from a book or a poem, listening to a single note repeated on an instrument or hummed. It doesn't really matter much what it is as long as it takes effort to contemplate it for a long duration and isn't so complex and changeable that it overwhelms your untrained ability to fully consider each part of it. Even more active practices can train your attention like writing, penmanship / calligraphy, painting / sketching, yoga, dance, martial arts and others but they are probably not the best place to start if you are fully untrained.

This dovetails into the point of the article, that programming is a form of "meditation" for many people. Really, it's something that you can infinitely stretch your capacity for and exert your attention on.

It works extremely well, and I don't do it as consistently as I should, precisely because it's actually kind of hard work and the reward is uncertain and delayed (though it can also be enjoyable at the time sometimes).

So I'm also in the boat where I don't get the benefits I could get, I get it. Making it a routine is legitimately hard.

I just find it hard to believe that it wouldn't be beneficial to most people if they stuck with it, because so many human problems are caused by fixating on the past and future and ignoring the present.

I can't experience what it's like to be someone else, but based on what other people say and do, most people seem to be experiencing similar problems to me in this regard.

Having said that: if you have any kind of mental health condition like depersonalisation, derealisation etc, you should consult a medical professional before starting any kind of meditation programme.

These are powerful techniques that can be dangerous if used inappropriately by the wrong person

There is a fine distinction here that I believe is often glossed over, so the two things it's delineating get muddled together. One of those two things is coding—the rote, mechanical encoding of meaning into computer instructions. It can be argued the LLM is fit to take this out of hands hands almost entirely, and it's almost indisputable the LLM is better at this in at least a certain sizeable subset of coding tasks.

But the other thing is the choosing, determination, specification of the intended meaning itself. This I think is squarely the job of the human, because letting this fall through to the AI means it is no longer the human that is making the decisions. This then becomes not merely automating work but ceding control. This, ultimately, is a bad thing.

So if we accept the premise that the specification of the intended meaning is the job of the human, the question is how you do that. Today many of us do it somewhat half-assedly, by writing lots of natural language text at the LLM and hoping it sticks. It is our hope that the text, given that there is a lot of it, will drive the stochastic machine in a sufficiently correct direction. This works to a degree—meaning we've ceded some control but not the majority of it—not least because we still read (most) of the code but cannot work in the limit, if code reading ceases.

A more proper way to specify the intended meaning is to specify (or "model") your system formally in a system that is mechanically verifiable. Then the final artefact produced by the LLM can be validated by verifying that it aligns with the specification. However this type of high-assurance specification looks a lot like a certain type of programming. In my opinion, writing this kind of specification is the future of human software engineering.

I do not accept the approach of simply rolling the dice and hoping the machine knows better than us, though I'm sure that church is also going to have its acolytes.

Worked great for me, when other techniques haven't. Just a good fit.

Much gratitude to you and u/phyzix5761. Sadly, I lost touch with that meditation group and I have been looking for something similar. Now I have your pointers.

We've had 4 teams on this model and sure it helped in some things (mostly data analysis and scripts) but generating code and doing architecture is utter crap 90℅ of the time. So much so that we've even had juniors noticing some design patterns that, and I quote: "this is one the examples of bad code we were taught in sw design classes'. The worst is how non deterministic they are. The same prompt from different people yields vastly different results

SW engineering is mostly x + y + z Where x=planning, y=writting code and z=reviewing, then rinse and repeat. Llm spedup y but made everything else take so much longer that equation result is much worse. Now reviewing is utter torture and during planning we're dicussing how to mitigate the pitfalls of LLM (like over engineering, too many abstractions) that we spend fewer time on the planning of the engineering itself and more on cuddling this brain addled tool

I've bounced off Claude Code (et al) multiple times.

But very recently I've had some successes. With some bulk bug fixes, it felt the same as scripting data quality fix ups. With proof of concepts in mind, tried 3 very different ideas.

Two quickly flamed out, revealing that I needed to chew on those ideas (a lot) more. If we're measuring how to "fail faster", I'd score these as useful efforts.

But one has been a very unexpected delight to work on. Almost addictive, like coding feels when you're in the flow.

Any way. The current mania for coding harnesses is total insanity. Mario of Pi.dev fame is spot on and far more insightful and articulate than me.