On ownership, or start to give a damn

On ownership, or start to give a damn

There are two types of software developers. Those who dig deep and those who don’t. The difference can be dramatic.

There was a time, back in college while learning to program, where I would try to fix things the easiest way. I was just trying to get things to work.

But that quickly went away. If I find myself debugging code, I have this drive to dig until I find the true root cause. This can have dramatic impacts with how I interact not only with code, but also with teams.

When you don’t know how to fix something, what do you do? Do you throw your arms up in the air and ask for help? When the problem is in another team’s codebase, do you just say, hey its not my problem? Or do you pick it apart, and try to isolate everything about that issue?

If you don’t take the path of deep investigation, you’re doing it wrong.

Don’t pass the buck

Often, people will tend to find a way to prove that something is not their fault. But this is the exact backwards attitude you should take. Assume its your fault.

Science the shit out of it

In Bob Martin’s newest book, Clean Architecture, he makes a statement about math and science. To paraphrase, he says that math works to prove things true (through proofs), and science works to prove things false. One of the great ways to treat software development is to adopt the scientific method. That is, form a hypothesis, and attempt to prove it false.

This is how you can treat ownership. Before passing work off to another team or person, do everything you can to attack the problem in every way. Make a hypothesis and test it until you are out of hypothesis.

Assume that it is in your locus of control to resolve the issue you are working on. Exhaust every opportunity before validating that you need assistance to resolve that.

Even the phrasing here is important. Once you determine you can’t resolve something on your own, work to resolve it with assistance. Don’t just make it someone else’s problem.

Asking good questions

That phrasing is the general key to the next step. If you truly cant resolve something without help, you need to know how to properly take the next action.

Too often I hear “X is broken, do you know how to fix it?” What good does that do for the person you’re trying to get help from? Remember, they are not really obligated to help you fix your problem.

First, make sure they have time for your request. You shouldn’t just expect them to give you their time, it is their most precious resource.

Collect your data, and present it. When I’m asking questions, I like to immediately present the problem, and then follow up with the background on it. I’ll be prepared to deliver a full background of all the hypothesis I tested, and the conclusions I arrived at.

This does two things for the other person. It shows the effort that you have put into the problem for the other person. Additionally, it relieves the other from having to retread your steps unknowingly.

Finally, don’t just dump it on them and hope to hear back. Work with them to resolve the issue. Assuming they have the key piece of knowledge that you didn’t, this is a perfect opportunity for cross pollination of knowledge.

A good corollary is to think about how not to ask questions. Your goal is to make it as easy as possible on the other person. Don’t ask a question by leading with a seemingly unrelated question. Almost everyone does this, be direct. Don’t make the other person peel off the onion layers to find out what you are trying to solve. Instead, lead with that. Don’t ask open ended questions, ask pointed questions, that show you put some effort into it. And don’t lead with your opinion. You’ll color the response and the answer you’ll get.

Make it easy on others

The main goal is just to make it easy on others. Not only are you unburdening your fellow coworkers, but you’re showing them the level of effort you’re willing to put in. What a good way to deliver value at the office.

The person who helps you in this way is also way more likely to do the same for you when the tables are turned. Maybe they’ll even learn this method from you.


You’re a craftsman, care for your tools

You’re a craftsman, care for your tools

Developers have a plethora of tools available to them. Maybe more so than any profession. New potential tools pop up monthly, perhaps daily.

Most developers I know are passionate about some of their tools. IDEs and editors tend to be a hot topic, filled with religious battles. But there are a lot of other tools we use on a daily basis that we may not think about as tools of the trade

As craftsman (yes, developers are craftsman, I’ll fill another blog post with some thoughts on that another time), we should take great care with our tools. You should be selective in the tools you use, weighing the trade offs of them versus the tools currently in your belt. You should freshen them up, keep them up to date and make sure to choose the correct versions. You should customize them, crafting configurations for them that serve your purpose. You should even create some tools, specifically for yourself but which may help others.

Choosing your tools

In Cal Newport’s “Deep Work”, the author recounts the story of a farmer outside of D.C. analyzing the value of a hay baler. It seems clear that there are obvious benefits to the hay baler for a farmer. With a hay baler, a farmer no longer has to purchase hay, and can instead produce it himself.


The farmer does an in-depth analysis. While the hay baler represents an opportunity, there are costs associated with it. Fuel, repairs, storage, to name a few. Additionally, there are opportunity costs the hay baler prevents the farmer from undertaking.

The point of referencing the story is to drive home the effort a traditional craftsman goes through in choosing his tools. Software developers should do the same.

Every tool we use comes with trade offs, and we shouldn’t take our choices in this realm lightly.

For a concrete example, let’s look at something obvious, IDEs. A classic debate in the Java world is IntelliJ vs Eclipse. I’m not going to enter that debate here, but instead use it as an example as to how you might evaluate tools.

It’s easy to go online and find comparisons of these two applications. Weighing the pros and cons of each. Software Development is a unique field in that the cost to try a tool is generally very low. I think it is worth giving each one a run through, and really exploring the pros and cons yourself. Additionally, where one tool may work for one person, that same may not be ideal for you.

Caring for your tools

I think its also important to care for our tools. That may seem an odd statement, but even computer tools need care.

There are obvious ways to do this. Updating your applications such as your editors, your programming languages, even your operating system. But there are likely less obvious ways.

Customization is an important trait of many good development tools. Many developers are passionate about their various customizations they apply to many different tools. Bashrc files, vimrc files, and others all play a prominent role.

I don’t know how everyone else uses these, but my rc (Run Commands) files and other customization files tend to pile up with stuff that I try out. I’m advocating here for a cleaning of these files.

A regular “check-up” of the health of these files should really help to streamline them. Making them publicly available will also force your to tidy these up a bit.

Plugins are another area that could use some cleaning. Any eclipse developer likely has oodles of plugins installed at any given time. They tend to hang around. Clean out the ones you aren’t using. This probably makes an even bigger difference than rc type config files. Loaded, unused plugins tend to slow an application down considerably.

Creating your own tools

You may have heard that if you ever do something three times, you should automate it. The type of automations this results in are perfect candidates for tools.

These can take a lot of forms. A great one is building your own CLI. If you have a series of common things you do in the terminal, craft your own CLI to execute these tools. Evolve it over time.

The before mentioned plugins are another great way to do this. Many developers create plugins to fix problems for themselves. It just happens that other developers have the same problem. In creating plugins to solve your own problem, you know you’re at least addressing a need.

The importance of tools

The tools you use to support your craft are easily overlooked. But they play a critical role. They are the conduit of producing valuable software. One thing I love about software development is that the output of our craft is typically tools for others in their own crafts. Sometimes its even tools for other developers!

I’ll leave you with one oft said thought. You’re only as good as your tools. Make them count.

If you liked this post, please like or share it on your social media platform of choice. I’d also love to hear your feedback. If you have time, drop a comment below.

A day full of outrage

A day full of outrage

I’ve blogged a lot about distractions and thinking lately. One thing I’ve noticed is just how distracted we are in our world today. You know what I’m talking about, the constant buzzing from our smartphones. I’ve also talked about how to deal with that. That part of it is on us. But today I want to turn our attention to the root cause of this.

Sure, in some regard, your phone is what you make of it. You can ignore notifications to some extent, and you can do things to reduce them. But that is definitely not the default mode. I was turned onto this idea when I first heard Tristan Harris.

Here’s his core idea. While we say technology is neutral, the reality is that the applications we install on our phones manipulate us. They trick us to open them. They trick us to spend more time on them. I was vaguely aware of this, but hadn’t heard it phrased in a way that the ideas became concrete.

The Concept

Behind every app is a team of people working to keep your attention. Experiments are run to find new ways to keep your attention. Decisions are made to grab your eyeballs. These decisions typically optimize for one thing, time on screen.

Working in software engineering gives a unique view into this. We can see these decisions. But here’s the thing, I’ve never considered these malicious. And I’m fairly certain the developers behind obvious offenders like Facebook and Snapchat are also not making malicious decisions. But when you’re measured on a metric, you tend to optimize for it.

Let’s take a concrete, but unrelated example. Code coverage can be a great metric for assessing unit tests on a project. It gives us insight into how well our unit tests are written. But it can easily be gamed. This is the outcome you’ll get once that metric is used to measure an individual’s performance. If you do this, you’ll end up with unit tests that cover every line of code, but don’t actually test for correctness. You’ve optimized for the metric.

Obviously it wasn’t malicious, just the natural outcome of weighting the metric too highly. This is exactly the situation we find ourselves in now. Attention and time on screen are weighted way too heavily in our apps. As a result, we optimize for it.

So how is that done? Notifications are one example. With a notification, an app grabs your attention and pulls you in. That’s step one. Now the goal is to keep you there. Tristan references something he calls a “variable scheduled reward”. This is the number of tweets you might have waiting for you in Twitter. This rewards you for entering the app, training you to check back in. The never ending feeds keep you engaged in the app way longer than you meant to be.

Is this how you want to spend your time? Probably not, you likely didn’t even mean to. This is unfortunate, because it means you didn’t intend to do this.

How about those feeds? Have you ever considered what gets put into those feeds? Let’s consider the algorithm behind those. We know that Facebook has removed its human curators, and it is conceivable other companies have as well.

Since the algorithm is going to maximize clicks and shares, it is going to end up favoring articles with a heavy emotional response. We can see this already in the fake news phenomenon.

Imagine the different responses that the feeds might give you. Things that cause outrage are likely to be shared. Will they benefit you? Likely not, but they’ll get clicks and shares. How about jealousy? See where this can go? Next thing you know, your feeds are all outrage.

How to spend our time the way we want

So let’s start with our own lives. How can we improve that? I don’t want to dig too deeply into this, as I already did with my distractions blog. But I do want to introduce a couple new ideas.

We work in sprints for our jobs, what if we worked in sprints for our individual tasks? That’s exactly what the Pomodoro technique is. The concept is to spend 25 minutes at a time on a single task. Don’t let interruptions stop you, just focus on that one task. In fact, I recommend tracking your interruptions. After those 25 minutes, take a five minute break. This is the key. You have a stop point, which allows you to focus singularly for those 25 minutes.

How do you know you’re spending your own time well? If you can’t measure it, you can’t improve it. If you’re on iOS, I recommend checking out Moment. This app allows you to use battery screenshots on the iPhone to track your usage of apps throughout the week. Then, at the end of the week, gives you a summary of which apps you spent time in and how long. You can then rate those apps as time well spent or not.

This really digs into the core of Tristan’s ideas. The manipulation techniques that our apps are using could be used for good, if their values aligned with ours. Its important to know which apps you actually want to be spending time in.

Improving the industry

Unfortunately, I’m not very hopeful for change in this area. The incentives are all currently misaligned, which will prevent this from really changing. Even if we make efforts on an individual level, the metrics for screen time and attention will force products to move towards  maximizing time on screen.

So what has to change? The advertising model certainly doesn’t help. The correlation between time in app and ad clicks is a big influencer into this metric. But it goes deeper. Companies on subscription models are essentially forced to maximize screen time as well. Netflix has found that losing screen time can result in lost subscriptions.

The big players here are the gatekeepers. Apple and Google, the owners of the app store, control which apps are surfaced. I don’t think top grossing or most popular are metrics that are benefiting users. I’m not sure what the answer here is, without asking the user too many questions. I don’t like the idea of rating your time in an app, so I’m sort of at a loss here.

Even though I’m not hopeful for making a large change via personal efforts without a system change, I still think it is worth the effort. As devs, we should speak up when we recognize less than ethical choices in apps. We should question if we’re serving our users in ways that they want. Are they really communicating positively with their clicks? What other metrics can we use to determine time well spent.

Next steps

The biggest first step is awareness. You’re less likely to fall prey to the manipulative tricks of these apps if you’re aware of it. Maybe you’d even be ok with some of these tricks if they align with your own goals. We also need to admit to ourselves that we’re all susceptible to these tricks. Everyone likes to think we’re not susceptible, but we are.

I wonder if we can start sending a message by prioritizing our time for ourselves. Perhaps if we are not falling prey to the manipulation, it will stop working. Maybe then we can realign the incentive system for the industry.

Once we can prioritize our own time, we can start to think about how to change the industry. Only then we can change the metrics.

If you liked this post, please like or share it on your social media platform of choice. I’d also love to hear your feedback. If you have time, drop a comment below.

You need to set aside time to think at work

You need to set aside time to think at work

Coding is a small part of the job of a developer. We spend a lot of time at whiteboards, drafting designs. We spend a lot of time reading code. And we spend a lot of time thinking.

We all think about code. A lot. But what about everything else? Are you thinking about the design? How about the decisions you’re making right now and the impact they’ll have on you, your team, and others now and down the line?

Mistakes tend to happen precisely at the moments we aren’t thinking. Sometimes we’re just on autopilot. Other times, we’re focused solely on the task at hand, forgetting about how it will impact other future decisions.


We need to start thinking clearly about the problems we’re solving. Decision impact is one of the big ones for sure. Too many decisions are made in a silo. How are the changes you’re making today affecting others?

What about months down the line? This is often one of the big differences between junior devs and senior devs. Senior devs tend to be thinking about the long term product strategy. Junior devs often miss this. Start thinking deeper about this if you want to advance your career.

Speaking of careers, we should be thinking about our own. This is something I missed early in my career. You know those questions you always hear, “where do you see yourself in five years?” You don’t have to think that far ahead, in fact that might be a bit foolish. Things tend to change a lot and hardly go the way you expect. But start thinking about what type of career you want to have. How can you align what you’re doing in your day job to further your career goals? Alignment between organization goals and personal goals is the best way to motivate.

How to do it

But how can we find this time? Often the demands of the job prove difficult to work in time to actually think. There are steps we can take to combat this.

Block off time on your calendar. People do not do this enough. Don’t be a slave to your calendar, make it work for you. Too often we allow our calendar to get populated by too many meetings. Step one is to just block off time so that meetings aren’t scheduled on specific times. On top of this, you have to make sure people respect that time.

That leads me to a follow up idea. Know when to say no. Decline meeting invites that overlap with time you’d like to spend thinking. Decline meetings where you won’t provide value. You don’t need to go to every meeting. I found it very liberating to start removing myself from many meetings where I didn’t think my presence really benefited myself or others. You’ll find people actually respect you more when you do this. It may be hard at first, as people may not expect it from you. But once a precedent is set, you’ll be much happier.

Find a quiet place. Its not good enough to be at your desk, there are too many distractions. See my last article. Finding a quiet area will prove hugely beneficial. This will really allow you to think and reflect.

Grab some tools. Tools like mind maps, brain dumps, and others improve your thinking. They get things out of your head and in front of you. This allows you to clear all the crud that’s in your head and focus on what’s important. It can also save you sometimes when your memory fails you.

Should you do it?

Hopefully I’ve convinced you that you need to make thinking time a priority in your own career. You’ll find that it can improve your coding without even touching a computer. You’ll improve your product by building a plan and thinking through the impacts. And most importantly, you’ll improve your career, by taking control of the direction you want to go, rather than letting others drive it. So I challenge you to set aside time at work and really think about all these things, and others.

The distracting world of software development

The distracting world of software development

On a typical work day, I get interrupted from what I’m working on about 9000 times, or about once every three seconds. At this point I’m a pro at getting interrupted.

Now, obviously, this is hyperbole, but the point is valid. As developers, there are a lot of different pulls on our attention. Of course this isn’t unique to developers. But as tech companies move to open floor plans, the need to be able to focus, despite those distractions, is growing.

I’ve focused a lot lately on the idea of mindfulness while coding, but it is easy to see how distractions can prevent that. Any interruption can snap you out of your focus, and suddenly you’re rabbit-holing down a path you never intended.

Preventing Distractions

Ideally, we can remove our distractions. I’ll touch on a number of ways I personally attempt to remove distractions from my work.

External Distractions

The first type of distraction we’ll need to deal with is external. This is interruptions coming at you from outside your control.

My number one way to attempt to block these interruptions is probably everyone’s most common. Headphones. You simply have to get yourself a decent pair of headphones as a developer. This is crucial even if you don’t listen to music! Other than drowning out background noise, headphones provide an immediate visual cue that you are in monk mode. They say, “Now is development time”.

Of course, they don’t always work. Not only will some people not respect the headphones, sometimes people just consider their thing the priority. Hopefully, your office provides you some side rooms. At my office, these are called “JITs”. Anyone can grab these rooms at any point and just work. If your office doesn’t provide these, I recommend getting cozy at Starbucks.

These strategies can help reduce the interruptions caused by drive-bys, but Slack and other applications can be just as annoying. I have two main strategies for dealing with these.

Number one, block off your calendar. Put time on your calendar for dedicated tasks. If you need to write that new feature, put a spot on your calendar specifically to work on that. This does two things. One, it prevents others from scheduling time there, and notifies them you are busy. You can also put up auto replies and go away on slack if that helps. But two, it sets aside mental space for you to work on that task.

Two, turn off notifications. This has a bigger effect than you might realize. I actually do this in most of my life, but at least temporarily disabling notifications on your laptop can be a big deal while trying to focus. Slack, especially, has a tendency to be distracting. On mac, use do not disturb mode.

Internal Distractions

For me, this is the harder one. Narrowing your focus to just the task at hand. I have multiple tricks I do to this end. In fact, turning off almost all notifications, which I mentioned previously, on both my phone and laptop all the time is something I do to help this.

Not everyone is willing to take that plunge though, so that’s where focus apps come in. There are a variety of these out there, but here is one: focus booster. These apps work by blocking access to a variety of typically distracting sites. Facebook, reddit, twitter, these sites aim to keep you locked in them. As a result, they are addicting, and sometimes we need help to stay off them. These apps help with that.

This next tip will probably be met with some resistance, but hear me out. Switch to a single monitor setup. Using one monitor keeps you focused on the one thing you’re working on. If you can’t do that, use two, but position one directly in front of you. I’ve seen many developers position the second monitor vertically, this also helps delineate which monitor is your focus. But nothing beats a single monitor for this.

To enhance the single monitor lifestyle, use full screen apps. This keeps you in the app your working on. Get good at alt-tabbing (on windows) or switching desktops (on mac). This has been one of the best hacks for my productivity. Not only does it make the app easier to use, it keeps you constrained in the app. No more checking Facebook on the side.

Dealing with distractions

As we all know, not all distractions can be prevented. Sometimes we just have to deal with them. This is where things get difficult. We may have to break social norms. We may have to attempt to dislodge the status quo.

The biggest single thing you can do is learn to say no. Often, when coworkers come to you with a request, it can be hard to turn them away. But when you’re really focusing, this can be the best way. Take a note of it, and move on (I mean a literal note). Follow up when you’re not focusing. Or don’t, because the likelihood is that it isn’t a priority for you.

This can be hard. We want to help others. But you have to know your boundaries. Deliberately setting those boundaries can go a long way to know when its ok to let yourself help someone.Those boundaries can also enable us. Use those boundaries to set expectations with others. Tell them your boundaries, and they will respect it. This can help remove the awkwardness of the no all together, you never even get to that stage.

Finally, mindfulness (you knew I’d come around to it eventually) can help us realize these moments. Oftentimes, when these interruptions come up, we react without even thinking about it. If we can slow down, and take the time to see what is happening, we’ll be better for it. Mindfulness can be the key that enables you to say “no”.

How do you remove distractions?

These are some of my techniques, but I’d love to here yours. For me, this is a constant learning process, and really no two people are the same. Some techniques work with some people, some with others. If you’d like to share, drop a note in the comments!

Know the problem you’re trying to solve

Know the problem you’re trying to solve

You sit down to start a new project. You start setting up the environment, maybe its a web service you're writing. As you're going along, you think, "what if I want to switch the database on the backend?" So you start to add in an abstraction layer there. You pack up for the night and promise to yourself to finish it tomorrow.

As tomorrow rolls around you think, "Gee, that DB abstraction is really boring to work on, so I think I'll work on something else." And this happens the next day, and the next…

Sound familiar? Maybe this happens to you at work too, you start designing a new service, and you make sure its scalable to 1000s of requests per second. But then your service is serving 10's of requests per day and you're already too late to the game.

This happens all the time, we get derailed with the technical details and totally miss focusing on the problem we were trying to fix in the first place. We take way too long to produce a solution, and end up either losing interest on a personal project, or bringing a work project to market way too late.

In my last blog, stop coding by coincidence, I detailed how we can bring the practice of mindfulness into coding. In this one, I'd like to dig into how mindfulness can help us with the problem of over engineering.

Over Engineering

Over the course of nearly a year, I worked on a team that developed software to allow a doctor to beam in to a room in a hospital and facilitate a consult. We were replacing a system that was supposedly not keeping up with the demands placed on it, while also being difficult to change.

The team worked tirelessly iterating on the new product we developed. We laid out new designs with a nice micro-service architecture. We used AWS auto scaling groups to scale the product for the future. We built the product to be extensible for future use cases, building a platform rather than just a product.

We built a great software product, technically, the final product was leaps and bounds better than its predecessor. And then we brought it to users… and they liked it!

But (you knew the but was coming) when traffic started hitting our servers, it was very slow. We thought it would grow quickly, but the business contracts that were to be supporting the product fell through.

We had built a technical success that wasn't being exercised enough to make the effort worth it. And you can probably guess what happened next. Although we executed quickly, we were up against too tight of timelines to roll it out to other lines. The project pivoted, and much of the work that had gone into building the product felt wasted.

It wasn't all bad though, the product was able to pivot and get reuse in a different area. It still isn't seeing the traffic to justify the scaling engineering that went into it. And had we spent more time focusing on what was truly wanted by the users, perhaps we could have rolled out a solution quicker and more focused on their needs.

So where does mindfulness come in?

The thing is, this story is hardly unique. Stories like this one is why the agile movement picked up so much steam. But we were practicing agile, we produced working software every two weeks that we put in front of users. So even with the best efforts, this can still happen.

But there were plenty of moments to right the ship, and that's where I can see mindfulness playing a role. Many hours were spent discussing designs on a whiteboard. Architecting out grand solutions. Many code reviews were had that suggested better and more performant ways of doing things. These small day to day interactions provide all the opportunity we need to refocus ourselves.

Mindfulness doesn't have to be exclusive to coding, we can practice it any time. Those times at the whiteboard, it is useful to think to yourself, what are we really doing here, are we solving the right problems? And the same with the code reviews, thinking, is it worth investing the extra effort here, is this the correct problem to be solving.

This can also happen directly coding. In my last blog, I referenced TDD and how it focuses you on the problem at hand. I want to reiterate that sentiment. TDD draws the boundaries for you, enabling you to solve just the problem you're trying to solve. It can help you think carefully about whether or not you need to solve a grander problem. It allows you to be mindful of the iterative steps you're taking to solving that problem, and how much work is left to meet the real requirements.

There's more to do

Over engineering and focusing on the wrong problem are mistakes that happen every day. They happen for a myriad of different reasons in many different situations.

Of course, mindfulness is just part of the equation. It is no silver bullet for the problem of over engineering. In fact, it is really just the catalyst to get you started down the path of thinking about how to prevent it.

If we can be mindful of the small decisions we make day to day on our projects and how they'll impact us down the line, we'll all be better off.

Stop coding by coincidence, start coding mindfully

Stop coding by coincidence, start coding mindfully

Dave Thomas and Andy Hunt coined a phrase I love in their book the Pragmatic Programmer. They refer to a process of “programming by coincidence”. They contrast this with “programming deliberately”. We can capture this idea with a more relevant phrase and repurpose it a bit as “mindful coding”. The names pretty accurately describe these ideas, but let’s dive a little deeper.

Programming by Coincidence

We’ve all been there. You write some code, it doesn’t work. “What’s happening, I was sure it would work”, you thought. “It’s late, let’s just flip the greater than sign to a less than sign in this expression… Holy shit it worked! Done!”

We all code like this from time to time, you might have even been guilty of this exact thing. I know I have been. But guess what, we both know this code is going to be hard to maintain. If by some miracle it is easy to maintain, it is pure coincidence.

So how did this happen? Developers work on a ton of different things. Our attention is pulled in a myriad of directions. Unfortunately, this causes things like this. You may not even remember writing a piece of code, you were so distracted while writing. How could you possibly guarantee its “correctness”.

This is something TDD was trying to solve. Break a problem into such small steps you can’t possibly mess it up. Even if you didn’t apply your full attention, you’ve made a guarantee that the code will do certain actions and things would be ok. You passed the unit tests before you could move on.

But TDD isn’t enough. This clearly doesn’t guarantee that your tests are even worthwhile. So what is the alternative?

Mindful Coding

This is where mindful coding comes in. Writing code deliberately that solves the problem you’re trying to solve.

This is clear when trying to debug why your code doesn’t work. Take a step back, think about what you’re trying to solve. Rather than just flipping that greater than sign, think about what criteria you’re trying to meet. What are you invariants?

Breaking the problem down helps a lot here too. Chunk it out, solve the smaller bits first. How do the pieces fit together? Don’t just mash them together, then we’re right back into our mindless coding.

I introduce the concept of mindful coding very deliberately. For me, it draws an obvious parallel to the mindfulness movement. If you aren’t aware of it, read up.

Mindfulness is about being present in the moment. Being aware of what you’re doing. You’re walking somewhere, but to do that, your legs are moving. You can feel the ground in your feet when you take a step, that kind of thing.

Let’s apply that same idea to coding. You’re writing your if statement. Why are you writing it? Oh yeah, we need to make a choice here. What are our two choices. Let’s wrap the choice in a function to make it more clear to the next reader.

See where I’m going with this? Mindful coding leads to code that someone else might be able to read because we’re constantly being attentive to what we’re putting on the screen.

How to code more mindfully

So how can we write code while being more mindful about what we’re writing? There are many techniques we can use to pull this off.

  • Understand the code you are modifying. This might sound self explanatory, but let me dive in further. Kent Beck discusses exploratory testing in his book TDD. This is exactly the type of thing we need to be doing to understand the code we’re working on better. Furthermore, code that doesn’t have unit tests could benefit from them, and so will your understanding in writing them. Write tests that explore how the code functions, why it functions that way, and where it functions unexpectedly.
  • Slow down. So many of us are in a race to finish what we’re doing. Of course we are, we’re all fighting tight deadlines, and its hard to predict the future. But the reality is that 9 times out of 10, slowing down will speed you up in the future. Slowing down, being aware of what you are writing, will pay off in spades when you come back to this same code tomorrow.
  • Have a plan. Do you know what the plan is going to be before you put code to screen? Take a look at this video, where google shows you how to do one of its interviews. Pay attention to how the interviewee describes his plan before writing it out. They look for this because it allows a developer to think through their intentions before writing out what they’re doing blindly.
  • Building on that… know your assumptions. If you have a plan, you must have built that plan on something. You might have already detailed these in unit tests, and I think this is one of the great insights that Beck was trying to get to with TDD. You’re literally testing your own assumptions in your unit tests, so think through them.

There are many other ways to remain mindful while coding, these are just a few from my own perspective.

We could all code a bit more mindfully

I’ll be the first to admit, I’m not always great at this. I sure try to be, but there are times I find myself lost in my own code. But that moment that you come to, you recognize your own ignorance, is a critical moment. Take note of those moments, they are the most important. It is mindfulness at work, and the key to a new feedback loop to help yourself be just a bit more mindful next time.