I have certainly noticed my stress skyrocket in this new mode of working. I was used to getting a lot done very quickly, with intense pockets of work followed downtime. Now it feels more like a steady stream of medium stress, and there is no opportunity to stop or drop the thread.
I must admit, if this is the new way of doing software development (eg: not actually programming but working with LLMs) I am not going to stick around for that long. It's not what I fell on love with, it's not what I trained for etc. I may as well do a job I don't enjoy that lets me rest my brain for later.
One idea to consider might be going into safety critical embedded work (e.g. brake controllers, critical systems for airplanes/trains, medical devices, some industrial systems, ...). AI hasn't penetrated much here yet. It isn't at all clear how or if you would be able to certify the process for example.
That might change with time, but for now, all I see AI used for is additional code review and side scripts/tooling that don't need to be safety rated.
Of course, that might mean entirely switching language (C, C++ or increasingly but still in minority Rust), learning entirely different skills (control system theory, real time systems, possibly formal verification but usually not), etc.
Safety critical embedded just doesn’t need as many lines of code. Your typical embedded codebase is small and long-lived, and if you’re spending a fortune to do verification and validation on a piece of code, the bottleneck is not the programmer.
A code change at my role recently, the diff was 6 lines, and that took at least 10 hours of combined writing documentation, figuring out which tests to run and then running them, pre-work for me, to propose the change and describe the behavior of the SW. So AI helps in all these processes, but having the agent write the code vs having me write the code makes no difference at all. I think most safety critical systems are like that.
The problem is that everyone is having that idea at the same time! Posts on /r/embedded asking a related question keep being shut down because there are so many web developers now asking daily how they can get into embedded systems because of a perceived lack of LLM penetration.
No such thing! Companies that aren't already actively using AI for embedded development are looking closely at it and experimenting with procedures to incorporate into their workflow. Why anyone would think that a company would ignore a potential improvement to their bottom line is beyond me.
Yeah, it might take a while, but it will happen faster than you think.
Indeed. GPT 5.4 was perfectly happy to help me write some 8051 assembly and integrate it into a weird vendor-specific Eclipse/Keil C51 build system. I would never have had the time or patience to figure it out. Embedded isn’t ready for full vibe coding to the extent that web development is, but it’s certainly not going to be an escape from AI.
The issue with AI isn't that it can't write embedded code (though it is noticeably worse at it), the issue is specifically with the safety certification of code the AI produced. There is a lot of paper trail to show that you followed all relevant standards, a lot of which pertains to your development process.
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.
Especially for developers of server, desktop, or web software. Experience in those fields will be more a hindrance than an advantage if you want to enter embedded development. Embedded is a whole different beast and you’d have to unlearn a lot of bad habits and expectations that your former field instilled in you. No hiring manager will give you the time for that.
The move-fast-break-things crowd is going to come after these as well, along with medical and defense software where lives are fully on the line. Sure, there will be failures and needless deaths and bombings of elementary schools, but that's just the price of being on the bandwagon.
Yeah, same thoughts. And this industry is becoming so volatile, I'm not sure what will happen tomorrow. I mean it's highly unlikely that AI will replace developers at least in the next 10 years, but I'm not sure what will "software developer" become. Certain people love to work with details. If AI is taking away this joy, I'll rather retire as early as possible from this volatile industry.
Maybe we just aren't far enough in the vibe coding side of things and there are still too many people in the industry who still pay attention to details, so no major catastrophes haven't happened yet because of vibe coding. So the people who pay attention to details are still carrying their organizations, but I do wonder how long it is going to be sustainable.
When it comes to joy killers because of AI, then it is dismal how plagiarism (going by the definition of "presenting someone else's work without attribution") suddenly became widely accepted. When I see long lists of bullet points with interspersed bold text, I know that it is something the sender did not write or bother reviewing. Absolute cherry on top when in the end of that text you see the typical LLM suggestion that you can ask for more information, which the sender didn't even bother removing.
They crashed yes, but not for too long and they did recover. And was it ever confirmed it was because of vibe coding? Not sure how much if any it even impacted their stock.
I can confirm that nuclear power plant software has much higher quality level than normal commercial software and extremly extensive testing. In addition, lot of nuclear safety is checked below the software level on hardware level.
Developement of nuclear power plant software is very conservative, it will use LLMs maybe in 10-15 years.
I’m trying to get a bit away from the business stakeholders, into more technically required roles. Eventually my goal is to get into a system programming role.
The issue with roles close to business is that it doesn’t provide the right soil for good engineering . Your stakeholders have no concept of engineering and wants everything ASAP; Your manager is just a yes man who takes all tickets, and want you to use AI for everything because it’s so easy and quick; Your VP thinks your team is not moving quickly enough; Your VP puts speed before quality literally.
The thing is, I believe that some roles and some industries just don’t care about good engineering. If you want to be a good engineer, you have to stay away from them, even if they are high paying, and get yourself into a system programming role, in a company that fails you if you do not have good engineering practices. The only way to be a good engineer is to put yourself in such an environment that you will almost surely fail if you are not a good one. There is a cool-aid and many engineers drink that the most important thing is "business value", and I politely vomit that all out a while ago. The new rule is to become an engineer that they are still willing to pay you even if you spit on their faces.
Those roles and companies can die and I don’t give a fuck about those business clowns.
In my company it's a bit more complicated, but I have the spirit of your thoughts. I think business software (such as the ERP-like software I work on) is often an entropy magnet from the complexity point of view. It doesn't strive to be simple and elegant because business / finance world is messy. Whether all the complexity and messiness of the financial world is accidental or justified, this is irrelevant for me because I don't care about their business problems. It will be soul sucking anyway.
Yeah I agree. And sometimes it is not really the complexity. For example, kernel or compilers are very complicated in certain way, too, but whichever company makes those products probably is way more stringent about the quality comparing to other companies that are happy to move forward with tons of bugs and tech debts.
>> For example, kernel or compilers are very complicated in certain way, too, but whichever company makes those products probably is way more stringent about the quality comparing to other companies that are happy to move forward with tons of bugs and tech debts.
IMHO, the complexity of kernel and compilers is usually more justified and less accidental. At least non technical people are rarely the cause.
It’s not just that. Working with multiple agents and tasks switching will increase cognitive load significantly leading to both poor decision making and increased stress.
10 years is a long time. 10 years ago the Transformer architecture didn't exist. I would call it moderately unlikely at best. At the very least, I would say it's likely that development will require an entirely different skillet 10 years from now.
That sounds dangerously like your organization has overcommitted to AI, is hemorrhaging money and is squeezing their human engineers to make up the difference.
I find the opposite to be true. I'm much less in control when prompting than programming. So I can be much more in the flow during programming and 8h (well stopping to lunch) can be no issue. I feel bad prompting 2h straight.
But the metaphorical goal is to cover distance not get fit or to make the best use of what you trained for. A trained runner on a bike is faster than a trained runner.
At least if the metaphor is about coding as a means to creating usefully functional code as efficiently as possible. Careful coding by hand may eventually be a hobby activity.
Personally, while I do get some satisfaction in coding by hand it was always the production of something useful that I found most rewarding. I was never someone who wrote code for a hobby. With LLM's I'm more productive. And I find that very satisfying.
Not sound harsh but that the people who solved problems with code just because they love coding disappears from problem-solving environments does sounds like a win-win for everyone involved. I've both been in situations where I loved coding the solution more than I want the problem solved, and I got in the way of people who just wanted the solution, and vice-versa where architect-astronauts are more interested in coding then solving things so they get in the way. If these could be better separated, that feels like the right direction, in both cases.
The people I'm talking about literally like coding for the sake of coding (many have shared comments here on HN about it in the past too), which I think is the same group who now are loosing their "passion for software engineering" as the LLM takes over the typing/coding part, but still leaves the design/intention to the human. But yes I agree, one does not equal the other, but if one person has one of those characteristics they tend to also have a bit of the other, at least in my experience.
That type are called "engineers". I used to interview them and I didn't care if they knew anything about the business.
Large codebases are the most complex things we have ever worked on and can easily become unmaintainable. I wanted people who really cared about code quality and consistency in order to offset this.
I think that it would be even more important to hire people like that now and even though we will need less programmers there were never enough of that type to go around anyway.
If you have ever endured the pain of bad code and cumbersome architecture when trying to fix a bug or implementing a feature, you start to be adverse to anything that increase the likelihood of it happening.
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.
This isn't the worst article, and it's triggered a decent amount of discussion (despite being very short). However, I really dislike "What you're doing wrong/failing to do" titles. They are intended to trigger anxiety, which is manipulative and (in this case) precisely contradicts the concern the author is purporting to have for the rest of us.
On the subject: some people find meditation very helpful, others find it a net negative, or useless, or impossible to do. So a categorical "you should do this" isn't correct or particularly helpful. Try it, if it works for you, great; but don't put it about that people who aren't doing it are being negligent in some way.
> On the subject: some people find meditation very helpful, others find it a net negative, or useless, or impossible to do. So a categorical "you should do this" isn't correct or particularly helpful. Try it, if it works for you, great; but don't put it about that people who aren't doing it are being negligent in some way
Absolutely. I've tried mediation in many situations and some classes but it's just not for me. My ADHD brain doesn't work that way. It's painfully boring and not relaxing at all. What does work for me is a walk through nature after a stressful day. There's another thing that works even better but too fringey and a bit nsfw to go into detail :) But anyway mediation definitely does not.
It being boring is part of the point - normally your brain is constantly stimulated so it does indeed feel strange and uncomfortable when that stimulus is taken away.
Pushing through that is what leads to progress.
Meditation is like physical exercise, it's not exactly "fun" at the time, you sort of have to learn to enjoy it, but it's never easy. Like exercise the real reward is backloaded
This is exactly what the OP and I argue against, people insisting that it must be good for everyone. By the way the 'painful' part does more heaviy lifting there, not the boring.
I've really tried a LOT during therapy and in some other situations. And it just doesn't work for me.
Same with traditional exercise by the way. I can't do exercise in a gym (too empty) or have those 'gamification' goals, it must be more natural. I'm extremely anticompetitive and antiauthoritarian so some watch telling me I'm doing great just generates irritation.
That’s all reasonable, and everyone is different , but I do think your original comment needed pushback, because meditation is often portrayed as enjoyable and easy at least in certain kinds of media. And I do think a lot of people give up when they find it boring and painful on their first practice.
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.
You should include the same advice that is given for exercise, it can and should occasionally be a bit painful but you have to discover your safe limits and only push yourself a little past them each time. You don't want to rack weights in 45lbs increments until you tear a muscle, you do it in 2.5lbs or 5lbs increments and practice for several sessions of work/rest at the same level for a while before making another small increment. People often quit both exercise and meditation because they just try to push through the pain and often end up with negative results due to injury or emotional and cognitive strain in the case of meditation.
It's all exertion, for both "meditation" and exercise.
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 eventually worked for you - great. That doesn't prove that it will eventually work for everyone.
At some point, when something is not working, you have to write off the sunk cost. In many cases, there's no obvious threshold as to when you make that decision, and it's easy to think that maybe, if you'd just held out a little longer, been a bit more determined, you could have made it work. But you have to make a call, without knowing for certain either way. And it can be the right call, even if, with perfect information, you'd have made the other choice.
So, while I'm sure lots of the people saying "you should just have tried harder" are doing so with complete good will, it's not helpful. You don't know, for another random person on the internet:
* how much work they put in
* what other burdens they were carrying
* what other needs and responsibilities they could use that time and energy on
* how their mind is different to your mind
etc, etc. In short, you don't have most of the information needed to make that decision for them, and you don't have any call to judge them for it.
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
Relaxation isn't really a goal of meditation. When you do it you cultivate a kind of meta-cognition, an awareness of - and control over - the kind of invasive thinking that usually dominates our awareness.
As a fellow ADHD person I didn't get out the first few times I tried, but now find it quite helpful.
It is a common misconception that the purpose of meditation is to relax. My experience is that meditation is very difficult but has worthwhile benefits for those around me after I meditate.
At the risk of you hating this answer, because I hated this answer, but to me that sounds like you are holding it wrong. I have adhd and found it dumb and boring and possibly not even real / placebo or new agey until during one attempt I hit the phase change and had the holy shit this is amazing moment where it worked for like 3 seconds. The quiet relaxation felt like idk a euphoria in every part of my body just to not be anxiously mentally bouncing around for half a second.
A most elementary form of meditation, is getting used to placing your attention on a sensation and keeping it anchored there - even when other sensations or thoughts arise.
Following the breath- place your awareness, your attention, on the sensation of air passing through your nostrils. Count one inbreath and outbreath cycle as «1», and count until 10 or 21. Decide before you start, how many repetitions of 10 or 21 you will do.
If at any point your attention has drifted to a different sensation - seeing, hearing etc, or thinking, visual imagery etc, then congratulate yourself for noticing, and restart from «1».
I recommend «The attention revolution» by Alan B. Wallace
Thank you. I like the comparison of "meditation" with "sport": it is not all the same, even if there are commonalities between some disciplines.
It is rare to see laypeople discuss some of the different types and which one may be best suited for a particular goal.
If the goal is simply relieving stress, performing some sport outdoors —especially team sports— is probably more effective than any meditation, for most people.
>> I’m clearly much more productive now. I’m doing five things at once very effectively, switching between multiple agent sessions from morning to night.
I feel like it depends on the task, and that's why people seem to disagree on this. Think about a manager managing 5 devs. If he is working on planning and managing work for his dev team, we don't say he is task switching, he's just taking a management role where he takes a high level view of the task at hand and then delegates the deep dive. Where it differs for devs is that we could in theory run multiple agents concurrently, but frequently, currently, we have to dive in and give the agents significant steers and this pulls us in to the detail. The same will happen for managers. The variables are the complexity of the task, the capability of the agent and the number of tasks. There are lots of scenarios where devs can run multiple tasks without too much mental overload, but I think what is hard is that we don't know when an agent will underperform on a task and we will get pulled back into developer mode. Maybe it's a case of running for as long as you can in manager mode and then accept that when one agent needs help, you have to single task with that agent (I think this is what makes us feel like we are the bottleneck, and that's where the feeling of stress creeps in). I thought about this a lot while working on https://www.agentkanban.io which I use to help me partition agent chats by task, run separate worktrees etc
>> I feel like it depends on the task, and that's why people seem to disagree on this. Think about a manager managing 5 devs. If he is working on planning and managing work for his dev team, we don't say he is task switching, he's just taking a management role where he takes a high level view of the task at hand and then delegates the deep dive.
This is assuming you fully trust AI code. AI is still not perfect and sometimes might produce code with insufficient quality even when it works. For example, it can fix a bug in a wrong way, such as removing the symptoms instead of fixing the root cause. And so on. Also, I still have to review and test that generated code, especially in complex systems. Yes, AI reduces coding time, but at the expense of increasing the review / testing time, and review is not something all developers enjoy (both as reviewer and someone who is reviewed). This still doesn't seem to be something that has negligible cost of context switching. Also, AI tends to make you more lazy and care less about understanding the requirements. I'll prefer manual coding with some AI assistance for boring / repetitive tasks and finding potential mistakes for software that I care.
Worth noting that this article is 25 years old. The world was very very different back then, especially when it comes to software engineering.
Context switching is a problem when the cost of switching contexts is non-negligible -- but in the age of agentic development is that still really true? Surely yes for some problems, but for many others I would argue it no longer is.
A personal anecdote for you:
At my company we have a local development CLI our devX team built, it allows for agents to interact with standing up, tearing down and managing local stacks for our software suite. When I receive customer feedback about a broken button, or a poor UX experience, I simply start up a prompt:
/metal user X reported an issue on the trial balance page, they encountered a blank page when using the inception to date filter. We need to investigate the root cause, spin up a new stack, and resolve the bug.
Then off to the next task, maybe some few hours later I'll check back in on the session and I'll see:
After a quick QA session I validate the fix, confirm that our claude reviewer has approved the PR and merge the PR to deploy. The mental burden of switching to this task is quite low, orders of magnitude lower than it would be 25 years ago.
What is also lower is your understanding of the change. So yes, if you are now essentially only doing the final mile of paper pushing for the LLM, then the mental burden is lower but so is the assurance of what has just transpired.
Whether this mode of working is going to be long-term viable is going to depend on how important it is for you to be aware of what has happened for the system in question, how viable the economics are for the LLM usage at this level of assurance and how much ownership you exert over the LLM used or another similarly powered one (because otherwise the LLM can be taken away from you, leaving you at the mercy of a third party with goals that do not align with your own).
> Whether this mode of working is going to be long-term viable is going to depend on how important it is for you to be aware of what has happened for the system in question
This is the million dollar we'll see answered in our lifetime. Software engineering exists to automate work, are we arrogant to think we are not destined to the same fate? Is this truly a job befitting of a human over an agent?
Ever since I discovered my dad's C++ book in highschool I've absolutely loved coding, but i'm not convinced I have a long stable career ahead of me in SWE -- I'm 30 now and have already seen so much change in the industry during my professional career.
> how viable the economics are for the LLM usage at this level of assurance and how much ownership you exert over the LLM used or another similarly powered one
This piece scares me the most, a world where the next generation models are capped behind capital infeasible for the common person to access, further separating the ultra wealthy from what little remains of the middle class.
My hope is that open source models will fill the moat all of these AI companies so desperately want to dig, aready models like Qwen and Kimi are unfathomably better than what we had just a year or two ago.
> This is the million dollar we'll see answered in our lifetime. Software engineering exists to automate work, are we arrogant to think we are not destined to the same fate? Is this truly a job befitting of a human over an agent?
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.
Regarding the multi-tasking induced by this new way of working (agentic coding), I've moved from quick and short iterations to a longer ideally one-shot prompt, optimizing for less reviewing and less context switching.
I used to send a prompt as early as possible, meaning that'd really just give the rough idea, barely a sentence, and see what the model would come up with, thinking that I'd save time if it got it right for the first time, and maybe I'd just need to correct what it got wrong (it's faster at typing than me). That means a lot of multitasking at a rather high pace, which takes its toll if you do it for too long.
I've recently switched to writing longer prompts (doing part of the planning myself), hoping to get better results and to have less to review: I'm realizing I'd rather write more and read less, past a certain threshold. I don't really want to iterate with an agent; I want to tell it, maybe in somewhat verbose terms, what I want, I want a quick confirmation that it'll indeed work, and I want the final output (e.g. a commit), that's it.
That's probably what some users have been doing since the beginning, but with all the hype around this tech, maybe I got caught by this idea that with just a few words, I can get stuff done. In my experience, it's indeed just a few words, but for useless units of work (iterations with a model) rather than what I really want (commit) which itself will often require non-trivial amount of input. In this case, I'd rather give it all in one go, in a somewhat focused state.
As someone brought up in a Hindu household (with Brahmin orthodoxy at that and all the casteism that came with it) and having learnt to shun all of that culture, and the religious indoctrination, here's the essence of mindfulness meditation that I was taught that I still practice and find useful.
1. Sit somewhere comfortable. Sitting "cross legged" or with your "back straight" as the guide linked to above advocates is not necessary. A comfortable chair/couch is fine.
2. The room should preferably be quiet. Though if you have the privilege of access to an outdoor courtyard that's quiet other than birdsong and chirp of insects, you'll probably enjoy it more. But a quiet room is good enough.
3. Phase 1: Set a timer on your watch/phone for 5 mins. Close your eyes. And let your mind wander. Doesn't matter what your mind drifts towards.
4. Phase 2: Restart the 5 min timer. Now, try quieten your mind of thoughts and focus instead on just your breathing. Be gentle with yourself. Your mind will wander again and that's fine. Just gently nudge it back to your breathing.
That's pretty much it. Slowly, over months try and increase Phase 2 from 5 to 10 mins.
When I described this to my partner, I used the analogy of treating your mind like a curious eager pup. In the first phase, cutting of external stimulus of sight by closing your eyes is like having the pup with you in a closed room.
In phase 2, you gently hold the puppy near you and get it to quiet down and stay still.
She mentioned that this analogy helped her a lot.
Honestly, this is pretty much the gist of it. I suspect that you will likely get most of the benefits of advanced meditative techniques with just the 2 simple steps from above. YMMV.
Be patient though. Getting to a fully calm state of mind takes months of practice.
The Mahasi method is quite different. You don't try to calm or control your mind. You observe and note your experiences as they're happening. Over time the calmness comes (and goes) but its not the goal. The goal is to see reality clearly. This clear seeing (which is where the word Vipassana comes from) leads to a change in the habit patterns that cause our stress and suffering.
You're right. This is a different technique. This is my simplification of the TM technique along with "japa" (repetition of a phrase) as is typically taught in the Brahmin scripture school mileu.
Since the OP was about achieving flow state and focus, I thought this was relevant.
Programmers need to stop listening to obnoxious people who are proudly destroying our industry while simulataneously farming our anxiety for attention and validation.
Software enegineering is not the kind of field that should require adoption of some universal coping mechanism. The fact that you're suddenly bing told to adapt to something harming you should raise all kind of qustions and red flags.
I noticed how relaxing and meditative programming can be. It might sound that after day job basically solving other people pronlems I sit down late at noght to just write code for hours on end. But I really enjoy it. Using LLM’s to generate the code ruins it.
I have also done meditation, but I struggle to keep it up for long. I think you should really do it consistently to get majority of effects. Coding, exercising, drawing has always been an easier form of meditation for me.
My favorite metaphor for programming is playing chess. Your opponent in programming is the complexity, you don't see its moves before the coding and design progress, before you make your choices/moves. You solve a problem by writing some code but that causes new problems down the line you didn't know existed before you made your choice of writing some specific code. or choosing a specific design.
Chess-players too are in a very "meditative" state when they play, and they enjoy it, I assume because it let's them focus on the game and forget about everything else.
I think the more stressful part is the management expectation that things will speed up more, especially when you can generate plausible looking frontends relatively quickly. And if you have out of touch control-freak management without any technical experience, you waste more life time arguing with them.
Of course you also might exhaust yourself to some degree, as your own expectation might be that you can develop multiple things in parallel, while also having to review a lot of code where you might not have context, so in a way you have to hold more high level context in your brain state, what might be somewhat stressful. However, when you have been tech lead once, all of that is somewhat familiar.
No. What they need is to stop being told "ok this is good enough now we need you to implement this other highly-necessary half-assed feature using ai as fast as possible."
I don't think this is a constructive way to look at life. You can't control what others say and do, what you can do is choose how you react and act on it.
Although I do meditate, I do not think this is the answer to our career's stress. That answer lies in learning how to generate a climate, a culture of open communications. Communications that include asking why, without triggering expectation that the questions are a lead up to blame, or anything other than understanding. Programmers need to learn communications, because BELIEVE IT OR NOT a software engineer's career is almost entirely some communications situation one after another. That is literally what we do: we translate communications between systems that cannot communicate on their own. That is literally the purpose of software. But this is probably news to a lot of you, and many of you will argue that it is not. That's why this career is in such stress, it does not even realize what it does. Sure we write software, which is an act of translating actions and behaviors into another language and environment which we understand and others outside of our field do not. We're communications professionals with a non-human entity.
I can’t agree that meditation and flow are very equal. In fact they are rather the opposite: while being in the flow (of programming) means been absorbed by your thoughts and you are most likely not be aware of being aware or or being thinking. In most meditation practices the goal is to be aware of your thoughts and inner processes
Meditation is great, but there might also be other options available when it comes to dealing with the effects of context switching.
For me, I find the Pomodoro technique really effective, but there's a key caveat, which is that you try to focus on one thing at a time (which flies in the face of using multiple AI agents working on x number of things at the same time).
Another angle to explore is how much of the process of software development that we do manually can we automate, particularly the parts that still require human input (like code reviews). That may also help with reducing the cognitive load.
>Another angle to explore is how much of the process of software development that we do manually can we automate, particularly the parts that still require human input (like code reviews). That may also help with reducing the cognitive load.
Get your vibe coded software with zero human reviewers away from the public infrastructure.
Meditation can also hype up your anxiety depending on individual circumstances and personality. And it is by no means easy, you have to invest much effort to get results. It's like refactoring your code base (mind).
So far I see it more like "you buy a car to take you between cities, but you end up routinely driving even just 1 km to a store, +50 kg overweight and then prematurely dead due to a heart attack."
But sure, if the most important thing is to mass produce tons of shitty code, it's your life - just don't give people dumb advice on what they NEED to do. :)
I try not to context switch when doing agentic programming. Instead, I use a single agent thread (in pi) and pay extra for faster inference (GLM 5.2 from fireworks.ai, currently; around 100 tokens per second). I rarely spend more than $25 per working week, which is a fraction of a percent of my own fee (I’m a specialist consultant). I also keep an Anthropic subscription and use that for longer research and design tasks.
I’m sure many people produce more than me, but I retain my sanity as well as a high level of understanding of the code that I produce, which in my domain I feel is still important. I’ve tried ultracode-style subagent workflows and find that they rapidly produce reams of slop that I don’t have the patience or energy to properly review.
Just wanted stop here to say that I find myself lucky to be able to retain employment as a gamedev engineer without using any AI or agent in my daily process. I work remote, so I don't know what the experience of my collegues entails. Am I really slipping into antiquity?
You say programming used to be a meditative activity.
Then why get overwhelmed by LLMs and meditate to calm down, when you can just write the code yourself at a healthier pace? Tools are supposed to be designed around humans, it’s not the human that has to adapt to the machine.
In any case, meditating with an end to destress or to reach higher levels of productivity is missing the point of meditation.
This is a common thing to say, but when during the development of human civilization has this actually been the case? Is agriculture designed around humans more than hunting/gathering? Is industrialized work more designed around humans than agrarian society?
I don't mean to sound pessimistic or technocratic; quite the contrary. But I think we shouldn't project our desire for equanimity onto romantized versions of civilization.
It's fine for your pet projects. But for most of professional programming it's no longer feasible as you'll be at a small fraction of your machine assisted performance.
My performance in writing code was never once the problem. I don’t get why I should increase the amount of output by depending on a third party tool to do my thinking to whom I have to explain my very abstract thought process in words.
The point of being an experienced programmer is thinking in data structures and transformations, not in prose. Why would I introduce all that friction?
If you think performance relates to speed and amount of code per unit of time yes. If you're more grounded with the reality of software engineering then no
I have in fact masters in SE and three decades experience of commercial programming. Loved every minute of it (well except the burnout episode) and still do my hobby projects. So I would say no, you are wrong. The models decimate not just the coding (the best and the most fun part of development) but all the pseudo-engineering roles like architects or product managers too. Simply because there's less need for communication in the team as the surface of work for each dev is now quite enormous.
Well and my experience of 2 years working full time with AI (and 15 others of engineering) on safety critical adjacent products tells me you're full of it and wrong.
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 have tried to research what "meditation" really means. I discovered that its meaning is somewhere between "doing nothing" and "processing ceremony". Now it easier for me to analyze those articles with such an optics.
I don’t think this article is suggesting really going for it in terms of meditation. But, as a warning to people, there is evidence that meditation can be dangerous for some people.
I’ve started doing mornings without any llm assisted work, and keeping it only for after 11. I find it gives me back the joy of designing my systems in a highly focused state, while keeping the later part of the day for persisting those well thought out ideas into code.
Honestly, just go for walks or do something else physical that doesn’t involve a screen. Don’t listen to a podcast. Just take in the scenery or focus on what you’re doing.
I was so stressed at work a few years ago. Burnt out. Exhausted. I started meditating. Shared with my manager that I started, and it’s been helping me process all the chaos at work.
He told me that wasn’t normal, and I shouldn’t have to meditate just to function at work :’)
He was a smartass, but also very blunt - unsparingly.
I did not encourage him to, this was just during a weekly 1:1 where I was sharing with him how I’ve been coping with the amount of workload and chaos happening among the team/myself.
He was wanting to empathize me that it’s not normal to have to do that to be functional at work, acknowledging how rough things were at the time.
I kept doing it, but fell out of practice. Also left and no longer work there, due to stress and poor support. Shocker.
> I’m clearly much more productive now. I’m doing five things at once very effectively, switching between multiple agent sessions from morning to night. After working full-time like this for ~8 months, one thing I’m sure of is that this way of working involves much less time spent in a flow state.
What an utter piece of BS. AI goons really like to smell their own crap
I was discussing Buddhism with a few Buddhist friends this past weekend, and I randomly had an enlightenment. It was a very odd experience, I felt like I understood all the weird things I'd heard from them, and I suddenly became very calm and accepting of everything. I also had a sense of sort of "watching" what I was experiencing through my own eyes.
I'm generally hyper rationalist, so this was a very interesting experience, and it happened because a random thing one of my friends said about meditation made something "click" in me.
It lasted about a day, I can't say I have any lasting effects from it now. It'd be interesting to see if I can make it happen again, but when I was in that state, I thought that trying to make it happen would defeat the purpose.
I asked my friend "is the purpose of meditation just to feel existence?" and he said "yes, and also taking your fears, insecurities, etc and throwing them away", and something just clicked.
Personally, I feel that as an individual, it's the right time to complete a program, but as a team, it's become harder.
It's true that the proportion of founders has increased both in the US and in my country, Korea.
And unlike the old days, it feels like what's needed now isn't so much deep, concentrated programming knowledge in one area, but rather broad knowledge across many fields. The claim that "productivity has increased" really only applies to freelancers. In fact, there's been a noticeable increase in freelance outsourcing requests that would be hard to handle without AI, lots of short deadline gigs compared to before. And of course, that makes it harder to charge appropriately.
For teams, on the other hand, you still need things like code reviews and team decision making.
As an individual, I've practically become someone who just writes up a gate, lets AI handle the code, checks that the core domain doesn't break, watches the gate's rules, and pulls the lever.
The reason team work slows down is mainly because Agile methodologies and code review processes are still human centric and consensus driven, and human cognitive speed itself becomes the bottleneck.
So I can understand a lot of the arguments that come up in the comments. The important thing is that most people tend to only see their own situation and their own context, which makes it hard for them to understand others.
Bros "discuss on hacker news" link takes you to submit the article here. that really rustles my jimmies. its unfortunate that bro couldnt csrf the submit link thanks to submit tokens. I have no doubt he would have tried that too.
I have certainly noticed my stress skyrocket in this new mode of working. I was used to getting a lot done very quickly, with intense pockets of work followed downtime. Now it feels more like a steady stream of medium stress, and there is no opportunity to stop or drop the thread.
I must admit, if this is the new way of doing software development (eg: not actually programming but working with LLMs) I am not going to stick around for that long. It's not what I fell on love with, it's not what I trained for etc. I may as well do a job I don't enjoy that lets me rest my brain for later.
One idea to consider might be going into safety critical embedded work (e.g. brake controllers, critical systems for airplanes/trains, medical devices, some industrial systems, ...). AI hasn't penetrated much here yet. It isn't at all clear how or if you would be able to certify the process for example.
That might change with time, but for now, all I see AI used for is additional code review and side scripts/tooling that don't need to be safety rated.
Of course, that might mean entirely switching language (C, C++ or increasingly but still in minority Rust), learning entirely different skills (control system theory, real time systems, possibly formal verification but usually not), etc.
Safety critical embedded just doesn’t need as many lines of code. Your typical embedded codebase is small and long-lived, and if you’re spending a fortune to do verification and validation on a piece of code, the bottleneck is not the programmer.
A code change at my role recently, the diff was 6 lines, and that took at least 10 hours of combined writing documentation, figuring out which tests to run and then running them, pre-work for me, to propose the change and describe the behavior of the SW. So AI helps in all these processes, but having the agent write the code vs having me write the code makes no difference at all. I think most safety critical systems are like that.
The problem is that everyone is having that idea at the same time! Posts on /r/embedded asking a related question keep being shut down because there are so many web developers now asking daily how they can get into embedded systems because of a perceived lack of LLM penetration.
No such thing! Companies that aren't already actively using AI for embedded development are looking closely at it and experimenting with procedures to incorporate into their workflow. Why anyone would think that a company would ignore a potential improvement to their bottom line is beyond me.
Yeah, it might take a while, but it will happen faster than you think.
Indeed. GPT 5.4 was perfectly happy to help me write some 8051 assembly and integrate it into a weird vendor-specific Eclipse/Keil C51 build system. I would never have had the time or patience to figure it out. Embedded isn’t ready for full vibe coding to the extent that web development is, but it’s certainly not going to be an escape from AI.
The issue with AI isn't that it can't write embedded code (though it is noticeably worse at it), the issue is specifically with the safety certification of code the AI produced. There is a lot of paper trail to show that you followed all relevant standards, a lot of which pertains to your development process.
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.
Cant they just implement all the papertrail-generating and checkbox-checking and ass-covering into its instructions or harness?
There's plenty of embedded code in consumer products that doesn't need to meet any special standards like MISRA.
Well sure, but that isn't what my original comment that you were replying downthread of said. I specifically recommended safety critical embedded. :)
"Switch to a field that involves many people dying if you write a bug" doesn't sound like the less stressful alternative to me.
Especially for developers of server, desktop, or web software. Experience in those fields will be more a hindrance than an advantage if you want to enter embedded development. Embedded is a whole different beast and you’d have to unlearn a lot of bad habits and expectations that your former field instilled in you. No hiring manager will give you the time for that.
So maybe try the weapons industry? If you write a bug, it will probably miss the target, and people won't die.
> going into safety critical embedded work
The move-fast-break-things crowd is going to come after these as well, along with medical and defense software where lives are fully on the line. Sure, there will be failures and needless deaths and bombings of elementary schools, but that's just the price of being on the bandwagon.
Yeah, same thoughts. And this industry is becoming so volatile, I'm not sure what will happen tomorrow. I mean it's highly unlikely that AI will replace developers at least in the next 10 years, but I'm not sure what will "software developer" become. Certain people love to work with details. If AI is taking away this joy, I'll rather retire as early as possible from this volatile industry.
Maybe we just aren't far enough in the vibe coding side of things and there are still too many people in the industry who still pay attention to details, so no major catastrophes haven't happened yet because of vibe coding. So the people who pay attention to details are still carrying their organizations, but I do wonder how long it is going to be sustainable.
When it comes to joy killers because of AI, then it is dismal how plagiarism (going by the definition of "presenting someone else's work without attribution") suddenly became widely accepted. When I see long lists of bullet points with interspersed bold text, I know that it is something the sender did not write or bother reviewing. Absolute cherry on top when in the end of that text you see the typical LLM suggestion that you can ask for more information, which the sender didn't even bother removing.
> major catastrophes haven't happened yet because of vibe coding
Didn't Azure, AWS and Cloudflare crash a few times in the second half of 2025 because of vibe coding?
They crashed yes, but not for too long and they did recover. And was it ever confirmed it was because of vibe coding? Not sure how much if any it even impacted their stock.
It was confirmed each was because of vibe coding.
Can you share some links?
Asking for myself, some friends and HN community at large.
Catastrophies would be we vibe coded a nuclear plant or space rocket system and we blew up thousands of people due to a vibe coding error.
I can confirm that nuclear power plant software has much higher quality level than normal commercial software and extremly extensive testing. In addition, lot of nuclear safety is checked below the software level on hardware level.
Developement of nuclear power plant software is very conservative, it will use LLMs maybe in 10-15 years.
Bringing most of the western world economy to a standstill isn't one? When I say AWS was down I mean AWS was down.
> Bringing most of the western world economy to a standstill
That’s a huge exaggeration.
True, it was Crowdstrike that did that, and that one wasn't AI.
programmers were always against "software patents" - the idea of copyrighting algorithms and implementations
implementations are already copyright
I’m trying to get a bit away from the business stakeholders, into more technically required roles. Eventually my goal is to get into a system programming role.
The issue with roles close to business is that it doesn’t provide the right soil for good engineering . Your stakeholders have no concept of engineering and wants everything ASAP; Your manager is just a yes man who takes all tickets, and want you to use AI for everything because it’s so easy and quick; Your VP thinks your team is not moving quickly enough; Your VP puts speed before quality literally.
The thing is, I believe that some roles and some industries just don’t care about good engineering. If you want to be a good engineer, you have to stay away from them, even if they are high paying, and get yourself into a system programming role, in a company that fails you if you do not have good engineering practices. The only way to be a good engineer is to put yourself in such an environment that you will almost surely fail if you are not a good one. There is a cool-aid and many engineers drink that the most important thing is "business value", and I politely vomit that all out a while ago. The new rule is to become an engineer that they are still willing to pay you even if you spit on their faces.
Those roles and companies can die and I don’t give a fuck about those business clowns.
In my company it's a bit more complicated, but I have the spirit of your thoughts. I think business software (such as the ERP-like software I work on) is often an entropy magnet from the complexity point of view. It doesn't strive to be simple and elegant because business / finance world is messy. Whether all the complexity and messiness of the financial world is accidental or justified, this is irrelevant for me because I don't care about their business problems. It will be soul sucking anyway.
Yeah I agree. And sometimes it is not really the complexity. For example, kernel or compilers are very complicated in certain way, too, but whichever company makes those products probably is way more stringent about the quality comparing to other companies that are happy to move forward with tons of bugs and tech debts.
>> For example, kernel or compilers are very complicated in certain way, too, but whichever company makes those products probably is way more stringent about the quality comparing to other companies that are happy to move forward with tons of bugs and tech debts.
IMHO, the complexity of kernel and compilers is usually more justified and less accidental. At least non technical people are rarely the cause.
Yeah I’d rather fight with concurrency or obscure language features than fight with ever changing and ambiguous business rules.
It’s not just that. Working with multiple agents and tasks switching will increase cognitive load significantly leading to both poor decision making and increased stress.
https://pmc.ncbi.nlm.nih.gov/articles/PMC7075496/ https://pmc.ncbi.nlm.nih.gov/articles/PMC7614709/
10 years is a long time. 10 years ago the Transformer architecture didn't exist. I would call it moderately unlikely at best. At the very least, I would say it's likely that development will require an entirely different skillet 10 years from now.
That sounds dangerously like your organization has overcommitted to AI, is hemorrhaging money and is squeezing their human engineers to make up the difference.
it was impossible to write code for 8 hours straight, you naturally had to stop
but you can prompt for 8 hours more or less
like running versus cycling - you can cover more distance by cycling and it's less intensive (I'm talking casual running/cycling, not racing)
agents are a bicycle for the mind
Why is prompting for 8 hours easier than coding for 8 hours?
Is it because the prompts matter less?
I find the opposite to be true. I'm much less in control when prompting than programming. So I can be much more in the flow during programming and 8h (well stopping to lunch) can be no issue. I feel bad prompting 2h straight.
I don’t know how any engineer can claim this. Is this guy even reviewing his “output”?
You have to take a lot of these comments on this site with a grain of salt. These guys are not pushing out stuff they are professionally liable for.
The point was they trained to be a runner, not a cyclist.
But the metaphorical goal is to cover distance not get fit or to make the best use of what you trained for. A trained runner on a bike is faster than a trained runner.
At least if the metaphor is about coding as a means to creating usefully functional code as efficiently as possible. Careful coding by hand may eventually be a hobby activity.
Personally, while I do get some satisfaction in coding by hand it was always the production of something useful that I found most rewarding. I was never someone who wrote code for a hobby. With LLM's I'm more productive. And I find that very satisfying.
> A trained runner on a bike is faster than a trained runner.
Not true if they kept going the wrong direction.
Not sound harsh but that the people who solved problems with code just because they love coding disappears from problem-solving environments does sounds like a win-win for everyone involved. I've both been in situations where I loved coding the solution more than I want the problem solved, and I got in the way of people who just wanted the solution, and vice-versa where architect-astronauts are more interested in coding then solving things so they get in the way. If these could be better separated, that feels like the right direction, in both cases.
Loving code does not necessarily mean being an architecture astronaut.
The people I'm talking about literally like coding for the sake of coding (many have shared comments here on HN about it in the past too), which I think is the same group who now are loosing their "passion for software engineering" as the LLM takes over the typing/coding part, but still leaves the design/intention to the human. But yes I agree, one does not equal the other, but if one person has one of those characteristics they tend to also have a bit of the other, at least in my experience.
Agreed, I see a lot of the type of people you're describing on here.
That type are called "engineers". I used to interview them and I didn't care if they knew anything about the business.
Large codebases are the most complex things we have ever worked on and can easily become unmaintainable. I wanted people who really cared about code quality and consistency in order to offset this.
I think that it would be even more important to hire people like that now and even though we will need less programmers there were never enough of that type to go around anyway.
If you have ever endured the pain of bad code and cumbersome architecture when trying to fix a bug or implementing a feature, you start to be adverse to anything that increase the likelihood of it happening.
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.
This isn't the worst article, and it's triggered a decent amount of discussion (despite being very short). However, I really dislike "What you're doing wrong/failing to do" titles. They are intended to trigger anxiety, which is manipulative and (in this case) precisely contradicts the concern the author is purporting to have for the rest of us.
On the subject: some people find meditation very helpful, others find it a net negative, or useless, or impossible to do. So a categorical "you should do this" isn't correct or particularly helpful. Try it, if it works for you, great; but don't put it about that people who aren't doing it are being negligent in some way.
> On the subject: some people find meditation very helpful, others find it a net negative, or useless, or impossible to do. So a categorical "you should do this" isn't correct or particularly helpful. Try it, if it works for you, great; but don't put it about that people who aren't doing it are being negligent in some way
Absolutely. I've tried mediation in many situations and some classes but it's just not for me. My ADHD brain doesn't work that way. It's painfully boring and not relaxing at all. What does work for me is a walk through nature after a stressful day. There's another thing that works even better but too fringey and a bit nsfw to go into detail :) But anyway mediation definitely does not.
You need to find what works for you.
It being boring is part of the point - normally your brain is constantly stimulated so it does indeed feel strange and uncomfortable when that stimulus is taken away.
Pushing through that is what leads to progress.
Meditation is like physical exercise, it's not exactly "fun" at the time, you sort of have to learn to enjoy it, but it's never easy. Like exercise the real reward is backloaded
This is exactly what the OP and I argue against, people insisting that it must be good for everyone. By the way the 'painful' part does more heaviy lifting there, not the boring.
I've really tried a LOT during therapy and in some other situations. And it just doesn't work for me.
Same with traditional exercise by the way. I can't do exercise in a gym (too empty) or have those 'gamification' goals, it must be more natural. I'm extremely anticompetitive and antiauthoritarian so some watch telling me I'm doing great just generates irritation.
That’s all reasonable, and everyone is different , but I do think your original comment needed pushback, because meditation is often portrayed as enjoyable and easy at least in certain kinds of media. And I do think a lot of people give up when they find it boring and painful on their first practice.
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.
You should include the same advice that is given for exercise, it can and should occasionally be a bit painful but you have to discover your safe limits and only push yourself a little past them each time. You don't want to rack weights in 45lbs increments until you tear a muscle, you do it in 2.5lbs or 5lbs increments and practice for several sessions of work/rest at the same level for a while before making another small increment. People often quit both exercise and meditation because they just try to push through the pain and often end up with negative results due to injury or emotional and cognitive strain in the case of meditation.
It's all exertion, for both "meditation" and exercise.
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 eventually worked for you - great. That doesn't prove that it will eventually work for everyone.
At some point, when something is not working, you have to write off the sunk cost. In many cases, there's no obvious threshold as to when you make that decision, and it's easy to think that maybe, if you'd just held out a little longer, been a bit more determined, you could have made it work. But you have to make a call, without knowing for certain either way. And it can be the right call, even if, with perfect information, you'd have made the other choice.
So, while I'm sure lots of the people saying "you should just have tried harder" are doing so with complete good will, it's not helpful. You don't know, for another random person on the internet:
* how much work they put in
* what other burdens they were carrying
* what other needs and responsibilities they could use that time and energy on
* how their mind is different to your mind
etc, etc. In short, you don't have most of the information needed to make that decision for them, and you don't have any call to judge them for it.
I'll be honest, both these things are true:
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
Relaxation isn't really a goal of meditation. When you do it you cultivate a kind of meta-cognition, an awareness of - and control over - the kind of invasive thinking that usually dominates our awareness.
As a fellow ADHD person I didn't get out the first few times I tried, but now find it quite helpful.
This. It's like you end up growing your own PAUSE button for the rest of your day and you can break your own fourth wall.
For me it just doesn't work but everyone is different, that's my point. And the relaxation is a prerequisite for having control.
> It's painfully boring and not relaxing at all.
It is a common misconception that the purpose of meditation is to relax. My experience is that meditation is very difficult but has worthwhile benefits for those around me after I meditate.
At the risk of you hating this answer, because I hated this answer, but to me that sounds like you are holding it wrong. I have adhd and found it dumb and boring and possibly not even real / placebo or new agey until during one attempt I hit the phase change and had the holy shit this is amazing moment where it worked for like 3 seconds. The quiet relaxation felt like idk a euphoria in every part of my body just to not be anxiously mentally bouncing around for half a second.
Maybe but I've just not been able to make it work. I get that in other ways though.
Meditation - «getting used to»
A most elementary form of meditation, is getting used to placing your attention on a sensation and keeping it anchored there - even when other sensations or thoughts arise.
Following the breath- place your awareness, your attention, on the sensation of air passing through your nostrils. Count one inbreath and outbreath cycle as «1», and count until 10 or 21. Decide before you start, how many repetitions of 10 or 21 you will do.
If at any point your attention has drifted to a different sensation - seeing, hearing etc, or thinking, visual imagery etc, then congratulate yourself for noticing, and restart from «1».
I recommend «The attention revolution» by Alan B. Wallace
So attention is all we need?
.
Thank you. I like the comparison of "meditation" with "sport": it is not all the same, even if there are commonalities between some disciplines.
It is rare to see laypeople discuss some of the different types and which one may be best suited for a particular goal.
If the goal is simply relieving stress, performing some sport outdoors —especially team sports— is probably more effective than any meditation, for most people.
So you can place your attention on a single session of Claude Code, count to 21, and switch to another? :)
Why 21?
No idea, but the five tibetan rites were also recommended to me with 21 repetitions. Perhaps it's an Eastern thing.
Because is half of 42
thanks
>> I’m clearly much more productive now. I’m doing five things at once very effectively, switching between multiple agent sessions from morning to night.
Joel Spolsky disagrees here: https://www.joelonsoftware.com/2001/02/12/human-task-switche...
I feel like it depends on the task, and that's why people seem to disagree on this. Think about a manager managing 5 devs. If he is working on planning and managing work for his dev team, we don't say he is task switching, he's just taking a management role where he takes a high level view of the task at hand and then delegates the deep dive. Where it differs for devs is that we could in theory run multiple agents concurrently, but frequently, currently, we have to dive in and give the agents significant steers and this pulls us in to the detail. The same will happen for managers. The variables are the complexity of the task, the capability of the agent and the number of tasks. There are lots of scenarios where devs can run multiple tasks without too much mental overload, but I think what is hard is that we don't know when an agent will underperform on a task and we will get pulled back into developer mode. Maybe it's a case of running for as long as you can in manager mode and then accept that when one agent needs help, you have to single task with that agent (I think this is what makes us feel like we are the bottleneck, and that's where the feeling of stress creeps in). I thought about this a lot while working on https://www.agentkanban.io which I use to help me partition agent chats by task, run separate worktrees etc
>> I feel like it depends on the task, and that's why people seem to disagree on this. Think about a manager managing 5 devs. If he is working on planning and managing work for his dev team, we don't say he is task switching, he's just taking a management role where he takes a high level view of the task at hand and then delegates the deep dive.
This is assuming you fully trust AI code. AI is still not perfect and sometimes might produce code with insufficient quality even when it works. For example, it can fix a bug in a wrong way, such as removing the symptoms instead of fixing the root cause. And so on. Also, I still have to review and test that generated code, especially in complex systems. Yes, AI reduces coding time, but at the expense of increasing the review / testing time, and review is not something all developers enjoy (both as reviewer and someone who is reviewed). This still doesn't seem to be something that has negligible cost of context switching. Also, AI tends to make you more lazy and care less about understanding the requirements. I'll prefer manual coding with some AI assistance for boring / repetitive tasks and finding potential mistakes for software that I care.
Uh, I am an EM, and you have to treat context switching as the enemy or nothing gets done.
There’s a bunch of different tactics for this. Some people hold office hours. I block off 9am for code review any only do it once per day.
The programs we call agents are nothing like people.
Does Joel still disagree today?
Worth noting that this article is 25 years old. The world was very very different back then, especially when it comes to software engineering.
Context switching is a problem when the cost of switching contexts is non-negligible -- but in the age of agentic development is that still really true? Surely yes for some problems, but for many others I would argue it no longer is.
A personal anecdote for you:
At my company we have a local development CLI our devX team built, it allows for agents to interact with standing up, tearing down and managing local stacks for our software suite. When I receive customer feedback about a broken button, or a poor UX experience, I simply start up a prompt:
/metal user X reported an issue on the trial balance page, they encountered a blank page when using the inception to date filter. We need to investigate the root cause, spin up a new stack, and resolve the bug.
Then off to the next task, maybe some few hours later I'll check back in on the session and I'll see:
> PR created: https://github.com/company/repo/pull/12758295 > QA URL: http://localhost:8400/<url> > Summary of root cause and fix: lorem ipsum lorem ipsum
After a quick QA session I validate the fix, confirm that our claude reviewer has approved the PR and merge the PR to deploy. The mental burden of switching to this task is quite low, orders of magnitude lower than it would be 25 years ago.
What is also lower is your understanding of the change. So yes, if you are now essentially only doing the final mile of paper pushing for the LLM, then the mental burden is lower but so is the assurance of what has just transpired.
Whether this mode of working is going to be long-term viable is going to depend on how important it is for you to be aware of what has happened for the system in question, how viable the economics are for the LLM usage at this level of assurance and how much ownership you exert over the LLM used or another similarly powered one (because otherwise the LLM can be taken away from you, leaving you at the mercy of a third party with goals that do not align with your own).
Both very fair observations.
> Whether this mode of working is going to be long-term viable is going to depend on how important it is for you to be aware of what has happened for the system in question
This is the million dollar we'll see answered in our lifetime. Software engineering exists to automate work, are we arrogant to think we are not destined to the same fate? Is this truly a job befitting of a human over an agent?
Ever since I discovered my dad's C++ book in highschool I've absolutely loved coding, but i'm not convinced I have a long stable career ahead of me in SWE -- I'm 30 now and have already seen so much change in the industry during my professional career.
> how viable the economics are for the LLM usage at this level of assurance and how much ownership you exert over the LLM used or another similarly powered one
This piece scares me the most, a world where the next generation models are capped behind capital infeasible for the common person to access, further separating the ultra wealthy from what little remains of the middle class.
My hope is that open source models will fill the moat all of these AI companies so desperately want to dig, aready models like Qwen and Kimi are unfathomably better than what we had just a year or two ago.
> This is the million dollar we'll see answered in our lifetime. Software engineering exists to automate work, are we arrogant to think we are not destined to the same fate? Is this truly a job befitting of a human over an agent?
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.
This behavior is how you get:
> user X reported an issue on the trial balance page, they encountered a blank page when using the inception to date filter.
It’s whack-a-mole with bugs.
That was 2001 today Joel seems to think this is the future: https://hash.ai/
I rate Joel immensely, however, that post is 25 years old.
Also neuroscience disagrees.
This really isn’t a debate. OP is wrong.
I've been doing this for 25 years professionally and let's just say I'm more the 3 coffees, 1 redbull, headphones and bassdrive kind of programmer.
So no, I will not be "meditating". My meditative states tend to be beard stroking and occasional F bomb.
Regarding the multi-tasking induced by this new way of working (agentic coding), I've moved from quick and short iterations to a longer ideally one-shot prompt, optimizing for less reviewing and less context switching.
I used to send a prompt as early as possible, meaning that'd really just give the rough idea, barely a sentence, and see what the model would come up with, thinking that I'd save time if it got it right for the first time, and maybe I'd just need to correct what it got wrong (it's faster at typing than me). That means a lot of multitasking at a rather high pace, which takes its toll if you do it for too long.
I've recently switched to writing longer prompts (doing part of the planning myself), hoping to get better results and to have less to review: I'm realizing I'd rather write more and read less, past a certain threshold. I don't really want to iterate with an agent; I want to tell it, maybe in somewhat verbose terms, what I want, I want a quick confirmation that it'll indeed work, and I want the final output (e.g. a commit), that's it.
That's probably what some users have been doing since the beginning, but with all the hype around this tech, maybe I got caught by this idea that with just a few words, I can get stuff done. In my experience, it's indeed just a few words, but for useless units of work (iterations with a model) rather than what I really want (commit) which itself will often require non-trivial amount of input. In this case, I'd rather give it all in one go, in a somewhat focused state.
For anyone interested in Vipasanna mediation in the tradition of Mahasi Sayadaw: https://sirimangalo.org/text/how-to-meditate/
As someone brought up in a Hindu household (with Brahmin orthodoxy at that and all the casteism that came with it) and having learnt to shun all of that culture, and the religious indoctrination, here's the essence of mindfulness meditation that I was taught that I still practice and find useful.
1. Sit somewhere comfortable. Sitting "cross legged" or with your "back straight" as the guide linked to above advocates is not necessary. A comfortable chair/couch is fine.
2. The room should preferably be quiet. Though if you have the privilege of access to an outdoor courtyard that's quiet other than birdsong and chirp of insects, you'll probably enjoy it more. But a quiet room is good enough.
3. Phase 1: Set a timer on your watch/phone for 5 mins. Close your eyes. And let your mind wander. Doesn't matter what your mind drifts towards.
4. Phase 2: Restart the 5 min timer. Now, try quieten your mind of thoughts and focus instead on just your breathing. Be gentle with yourself. Your mind will wander again and that's fine. Just gently nudge it back to your breathing.
That's pretty much it. Slowly, over months try and increase Phase 2 from 5 to 10 mins.
When I described this to my partner, I used the analogy of treating your mind like a curious eager pup. In the first phase, cutting of external stimulus of sight by closing your eyes is like having the pup with you in a closed room.
In phase 2, you gently hold the puppy near you and get it to quiet down and stay still.
She mentioned that this analogy helped her a lot.
Honestly, this is pretty much the gist of it. I suspect that you will likely get most of the benefits of advanced meditative techniques with just the 2 simple steps from above. YMMV.
Be patient though. Getting to a fully calm state of mind takes months of practice.
The Mahasi method is quite different. You don't try to calm or control your mind. You observe and note your experiences as they're happening. Over time the calmness comes (and goes) but its not the goal. The goal is to see reality clearly. This clear seeing (which is where the word Vipassana comes from) leads to a change in the habit patterns that cause our stress and suffering.
You're right. This is a different technique. This is my simplification of the TM technique along with "japa" (repetition of a phrase) as is typically taught in the Brahmin scripture school mileu.
Since the OP was about achieving flow state and focus, I thought this was relevant.
Programmers need to stop listening to obnoxious people who are proudly destroying our industry while simulataneously farming our anxiety for attention and validation.
Software enegineering is not the kind of field that should require adoption of some universal coping mechanism. The fact that you're suddenly bing told to adapt to something harming you should raise all kind of qustions and red flags.
I noticed how relaxing and meditative programming can be. It might sound that after day job basically solving other people pronlems I sit down late at noght to just write code for hours on end. But I really enjoy it. Using LLM’s to generate the code ruins it.
I have also done meditation, but I struggle to keep it up for long. I think you should really do it consistently to get majority of effects. Coding, exercising, drawing has always been an easier form of meditation for me.
My favorite metaphor for programming is playing chess. Your opponent in programming is the complexity, you don't see its moves before the coding and design progress, before you make your choices/moves. You solve a problem by writing some code but that causes new problems down the line you didn't know existed before you made your choice of writing some specific code. or choosing a specific design.
Chess-players too are in a very "meditative" state when they play, and they enjoy it, I assume because it let's them focus on the game and forget about everything else.
I think the more stressful part is the management expectation that things will speed up more, especially when you can generate plausible looking frontends relatively quickly. And if you have out of touch control-freak management without any technical experience, you waste more life time arguing with them.
Of course you also might exhaust yourself to some degree, as your own expectation might be that you can develop multiple things in parallel, while also having to review a lot of code where you might not have context, so in a way you have to hold more high level context in your brain state, what might be somewhat stressful. However, when you have been tech lead once, all of that is somewhat familiar.
No. What they need is to stop being told "ok this is good enough now we need you to implement this other highly-necessary half-assed feature using ai as fast as possible."
I don't think this is a constructive way to look at life. You can't control what others say and do, what you can do is choose how you react and act on it.
Although I do meditate, I do not think this is the answer to our career's stress. That answer lies in learning how to generate a climate, a culture of open communications. Communications that include asking why, without triggering expectation that the questions are a lead up to blame, or anything other than understanding. Programmers need to learn communications, because BELIEVE IT OR NOT a software engineer's career is almost entirely some communications situation one after another. That is literally what we do: we translate communications between systems that cannot communicate on their own. That is literally the purpose of software. But this is probably news to a lot of you, and many of you will argue that it is not. That's why this career is in such stress, it does not even realize what it does. Sure we write software, which is an act of translating actions and behaviors into another language and environment which we understand and others outside of our field do not. We're communications professionals with a non-human entity.
I can’t agree that meditation and flow are very equal. In fact they are rather the opposite: while being in the flow (of programming) means been absorbed by your thoughts and you are most likely not be aware of being aware or or being thinking. In most meditation practices the goal is to be aware of your thoughts and inner processes
Meditation is great, but there might also be other options available when it comes to dealing with the effects of context switching.
For me, I find the Pomodoro technique really effective, but there's a key caveat, which is that you try to focus on one thing at a time (which flies in the face of using multiple AI agents working on x number of things at the same time).
Another angle to explore is how much of the process of software development that we do manually can we automate, particularly the parts that still require human input (like code reviews). That may also help with reducing the cognitive load.
>Another angle to explore is how much of the process of software development that we do manually can we automate, particularly the parts that still require human input (like code reviews). That may also help with reducing the cognitive load.
Get your vibe coded software with zero human reviewers away from the public infrastructure.
Meditation can also hype up your anxiety depending on individual circumstances and personality. And it is by no means easy, you have to invest much effort to get results. It's like refactoring your code base (mind).
well, gurus are supposed to meditate, once in a while.
per https://en.wikipedia.org/wiki/Guru_Meditation
There is also a simpler approach: just stop using AI.
And if you can't, THAT should be a big red warning sign for you.
that's like "stop using a car, you can walk between cities and its healthier"
So far I see it more like "you buy a car to take you between cities, but you end up routinely driving even just 1 km to a store, +50 kg overweight and then prematurely dead due to a heart attack."
But sure, if the most important thing is to mass produce tons of shitty code, it's your life - just don't give people dumb advice on what they NEED to do. :)
(putting aside the negative impact of the data centers on the planet, which is not "your life" anymore)
Perhaps: "If you find yourself re-arranging your life into a [car|AI|...]-dependent life, stop before it's too late?"
I guess my experience is better described as "stop trying to drive a car into your destination"
On the contrary, many still need to learn how to say no.
I try not to context switch when doing agentic programming. Instead, I use a single agent thread (in pi) and pay extra for faster inference (GLM 5.2 from fireworks.ai, currently; around 100 tokens per second). I rarely spend more than $25 per working week, which is a fraction of a percent of my own fee (I’m a specialist consultant). I also keep an Anthropic subscription and use that for longer research and design tasks.
I’m sure many people produce more than me, but I retain my sanity as well as a high level of understanding of the code that I produce, which in my domain I feel is still important. I’ve tried ultracode-style subagent workflows and find that they rapidly produce reams of slop that I don’t have the patience or energy to properly review.
I also meditate quite a bit.
Just wanted stop here to say that I find myself lucky to be able to retain employment as a gamedev engineer without using any AI or agent in my daily process. I work remote, so I don't know what the experience of my collegues entails. Am I really slipping into antiquity?
If you use zero AI, I would say yes
If he uses zero AI, he's better off than someone who hasn't looked at their own code in months.
You say programming used to be a meditative activity.
Then why get overwhelmed by LLMs and meditate to calm down, when you can just write the code yourself at a healthier pace? Tools are supposed to be designed around humans, it’s not the human that has to adapt to the machine.
In any case, meditating with an end to destress or to reach higher levels of productivity is missing the point of meditation.
> Tools are supposed to be designed around humans
This is a common thing to say, but when during the development of human civilization has this actually been the case? Is agriculture designed around humans more than hunting/gathering? Is industrialized work more designed around humans than agrarian society?
I don't mean to sound pessimistic or technocratic; quite the contrary. But I think we shouldn't project our desire for equanimity onto romantized versions of civilization.
It's fine for your pet projects. But for most of professional programming it's no longer feasible as you'll be at a small fraction of your machine assisted performance.
My performance in writing code was never once the problem. I don’t get why I should increase the amount of output by depending on a third party tool to do my thinking to whom I have to explain my very abstract thought process in words.
The point of being an experienced programmer is thinking in data structures and transformations, not in prose. Why would I introduce all that friction?
If you think performance relates to speed and amount of code per unit of time yes. If you're more grounded with the reality of software engineering then no
I have in fact masters in SE and three decades experience of commercial programming. Loved every minute of it (well except the burnout episode) and still do my hobby projects. So I would say no, you are wrong. The models decimate not just the coding (the best and the most fun part of development) but all the pseudo-engineering roles like architects or product managers too. Simply because there's less need for communication in the team as the surface of work for each dev is now quite enormous.
Well and my experience of 2 years working full time with AI (and 15 others of engineering) on safety critical adjacent products tells me you're full of it and wrong.
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 have tried to research what "meditation" really means. I discovered that its meaning is somewhere between "doing nothing" and "processing ceremony". Now it easier for me to analyze those articles with such an optics.
Unionizing. The word you’re looking for is unionizing.
I don’t think this article is suggesting really going for it in terms of meditation. But, as a warning to people, there is evidence that meditation can be dangerous for some people.
You don't already? I thought that's what every programmer has been doing.
I’ve started doing mornings without any llm assisted work, and keeping it only for after 11. I find it gives me back the joy of designing my systems in a highly focused state, while keeping the later part of the day for persisting those well thought out ideas into code.
Honestly, just go for walks or do something else physical that doesn’t involve a screen. Don’t listen to a podcast. Just take in the scenery or focus on what you’re doing.
I was so stressed at work a few years ago. Burnt out. Exhausted. I started meditating. Shared with my manager that I started, and it’s been helping me process all the chaos at work.
He told me that wasn’t normal, and I shouldn’t have to meditate just to function at work :’)
What a strange opinion. If it helps you do better at work, why wouldn't it be something to encourage?
Was he a judgmental person in general? Or do you think he had an aversion to meditating?
I do have to say, if you were encouraging him to ALSO start meditating, I'd hate that too.
He was a smartass, but also very blunt - unsparingly.
I did not encourage him to, this was just during a weekly 1:1 where I was sharing with him how I’ve been coping with the amount of workload and chaos happening among the team/myself.
He was wanting to empathize me that it’s not normal to have to do that to be functional at work, acknowledging how rough things were at the time.
I kept doing it, but fell out of practice. Also left and no longer work there, due to stress and poor support. Shocker.
> I’m clearly much more productive now. I’m doing five things at once very effectively, switching between multiple agent sessions from morning to night. After working full-time like this for ~8 months, one thing I’m sure of is that this way of working involves much less time spent in a flow state.
What an utter piece of BS. AI goons really like to smell their own crap
“I’m doing five things at once very effectively”
…sure you are buddy, sure you are…
Note to self: book appointment with Optometrist ASAP to correct how far my eyes have rolled back into my head.
hehe
I was discussing Buddhism with a few Buddhist friends this past weekend, and I randomly had an enlightenment. It was a very odd experience, I felt like I understood all the weird things I'd heard from them, and I suddenly became very calm and accepting of everything. I also had a sense of sort of "watching" what I was experiencing through my own eyes.
I'm generally hyper rationalist, so this was a very interesting experience, and it happened because a random thing one of my friends said about meditation made something "click" in me.
It lasted about a day, I can't say I have any lasting effects from it now. It'd be interesting to see if I can make it happen again, but when I was in that state, I thought that trying to make it happen would defeat the purpose.
What was the thing that made you click?
I asked my friend "is the purpose of meditation just to feel existence?" and he said "yes, and also taking your fears, insecurities, etc and throwing them away", and something just clicked.
Personally, I feel that as an individual, it's the right time to complete a program, but as a team, it's become harder.
It's true that the proportion of founders has increased both in the US and in my country, Korea.
And unlike the old days, it feels like what's needed now isn't so much deep, concentrated programming knowledge in one area, but rather broad knowledge across many fields. The claim that "productivity has increased" really only applies to freelancers. In fact, there's been a noticeable increase in freelance outsourcing requests that would be hard to handle without AI, lots of short deadline gigs compared to before. And of course, that makes it harder to charge appropriately.
For teams, on the other hand, you still need things like code reviews and team decision making.
As an individual, I've practically become someone who just writes up a gate, lets AI handle the code, checks that the core domain doesn't break, watches the gate's rules, and pulls the lever.
The reason team work slows down is mainly because Agile methodologies and code review processes are still human centric and consensus driven, and human cognitive speed itself becomes the bottleneck.
So I can understand a lot of the arguments that come up in the comments. The important thing is that most people tend to only see their own situation and their own context, which makes it hard for them to understand others.
Reeks of SanFran in here...
When the state of the industry is so bad that people need to start recommended mindfulness to unfuck your brain, then it's time to get the fuck out.
You need to ____
You should ____
Everyone is full of advice for others lmao
Bros "discuss on hacker news" link takes you to submit the article here. that really rustles my jimmies. its unfortunate that bro couldnt csrf the submit link thanks to submit tokens. I have no doubt he would have tried that too.