After receiving a formal diagnosis of ADHD as an adult, it was recommended that I try mindful meditation. Initially, I was skeptical, but I soon learned that meditation has been scientifically shown to help with anxiety, depression, clear thinking, and overall health. What I did not expect was how useful it would be in programming. Software development is full of distractions and challenges, and even determining what we are trying to achieve can sometimes be a struggle.
Over the past few years, I’ve been developing what I call “Programming Meditation,” and I’m excited to share it. The foundation of this practice is regular mindful meditation. This involves sitting quietly and focusing on your breath and body to achieve a state of peace. Thoughts will inevitably arise, but the key is to acknowledge them, let them go, and return to your breath. For beginners, I highly recommend using a guided meditation app like Headspace or Calm and practicing daily.
Bringing Meditation into Programming
Programming Meditation integrates mindfulness directly into a coding session. Here’s how you can practice it:
Set Up Your Environment:
Sit at your computer with your development environment and code fully loaded in full-screen mode.
Close any potentially distracting applications (e.g., email, Slack, Teams).
Meditate with Your Code:
Spend at least 10 minutes meditating with the computer and code as part of your environment, no different from the floor beneath your feet or the chair you are sitting on.
Towards the end of your session, open your eyes and transition directly into reading the code.
Steps for Mindful Coding
Before writing any code, take the following steps:
Orient Yourself:
Become aware of where you are in the code. Imagine the code as a vast garden; take time to explore it and orient yourself without getting bogged down in details. Approach it with curiosity.
Understand the Code:
If your task involves modifying an existing file, read through the entire file to orient yourself. Consider what the code does and why it was written that way. Assume the original authors had reasons for every line. Do those reasons still apply?
Code Intentionally:
Write code in small, incremental, and intentional steps. Coding should feel natural and unlabored, much like healthy breathing.
Incorporate TDD (Optional):
Test-driven development (TDD) pairs well with meditation as it encourages small, deliberate steps. Even without TDD, keep changes minimal, commit often, and remain mindful of each change.
Benefits of Programming Meditation
Using this technique, I’ve found that I can induce a state of flow (distinct from hyperfocusing, which can be unhealthy). This practice has improved the quality of my code, making it easier to read and understand later. More importantly, it has enhanced my overall experience with programming, helping me feel better about my work and its outcomes.
Programming Meditation is a powerful tool for improving focus and cultivating a mindful approach to coding. I encourage you to give it a try and see how it transforms your development process.
I'm going to attempt a small 🧵 to explain ADHD in computer terms. Imagine your brain is a computer; you have working memory (RAM), long term memory (hard drive), processors (frontal cortex) and an operating system.
The operating system has a process manager which takes care of all the things. Some are daemons and run constantly on dedicated chips like breathing and sensory processing. Others need to be managed to interact with the CPU (the frontal cortex) to be active.
Most humans perform a type of preemptive multitasking where processes can interrupted and scheduled based on I/O waits, CPU needs, and timeslices. You can work on something until you have to go to the bathroom, or you need to eat, or just because it's time to stop.
In ADHD brains the interrupt mechanism is different. It wants to do something, anything really, and when it sees CPU and I/O dipping it assumes a new process needs to be spawned and given priority. It also will randomly terminate processes.
Most computers will defer to the user for what process has priority, the ADHD manager attempts to round robin task switch across all the processes without regard for what the user wants or needs.
Imaging you're using a email app and suddenly out of nowhere minesweeper opens and moves to the front. You didn't ask for it, but here it is, then as soon as you finish one level it opens a new browser tab and navigates to the wikipedia article about the Ottoman Empire.
There are also times when the interrupt mechanism will hand all priority to a single process and refuse to send scheduled processes to the CPU, need to eat? pee? sleep? No! Link can't save Zelda on his own, he needs me!
This style of processing isn't broken, it's just a different pattern. There are times when this task switching is beneficial as not all tasks really need to be given priority. Which is why ADHD folk tend to thrive in chaotic environments that stress out others.
Let me start by saying that I don’t hate mocking frameworks. They can be incredibly useful, and from an intellectual standpoint they’re some of the most amazing and interesting code you can look at. If you want a masters class on reflection and runtime manipulation go dig around in them.
What I do dislike is how they’re misused. I consider myself a classicist or a member of the Chicago/Detroit school of mocking. That means I don’t mock often, and when I do I prefer to use hand rolled mocks because I find they’re better at letting me test state as opposed to interactions. Still, sometimes mocking frameworks can be damn handy and I’m not above using them. More often they’re part of an existing application that I’m working on. The main problem I see with them is when developers don’t stay SRY with their mocking. Every time you mock a method that’s a little dab of glue making it harder to change that method. I get sad when I come into a test and see a chunk of mocking repeated over and over in every test.
User user = mock(User.class);
when(session.getUser()).thenReturn(user);
when(result.getName()).thenReturn(“Stacy”);
You will often find that these same lines are repeated throughout the system in many different tests, sometimes many times the number of invocations in the production code. If you want to change getUser() or getName() you may find that difficult, not due to the prod code but due to the mocker. I've litterally spent days refactoring tests and mocking statements so I could change some method automatically.
We can get around this the same way we stay DRY in our production code, through encapsulation and creating common utilities. In the above example, if this happens in one test we can easily extract a method for it. If it’s in many tests we can do the same but put it outside. I sometimes end up with a set of utilities for common methods. Something like this:
public class SessionExpects {
public static User currentUser(UserRepo userRepo, String name){
User user = mock(User.class);
when(session.getUser()).thenReturn(user);
when(result.getName()).thenReturn(name);
return user;
}
}
Now we can have only one place where these methods are called and if we need to change them it should be a lot easier. We also maintain the existing tests and other usages of the mocking framework. So it’s really low risk, low change, all we are doing is not repeating ourselves, which seems simple, and yet, maybe not obvious.
I had the honor of appearing on 'Software Engineering Daily' podcast to talk about practices at John Deere. Topics of discussion include autonomous vehicles, team autonomy and devops overload
