DEV Community

Cover image for Declutter Your Coding
Alex Damian Negru
Alex Damian Negru

Posted on • Originally published at Medium

Declutter Your Coding

Imagine you walk up in a hoarder’s room. It is full of so many things: cups everywhere, boxes, a dead mouse, dust and all sorts of other stuff. Chances are you won’t be able to stay in that mess for too long: the outside chaos will seep its way inside your mind.

And yet, this very chaotic feeling might be exactly what one is carrying around when working.

Cluttered work brings about chaos in the workflow.

What are the downsides of clutter?

Clutter:

  • fills up the available working memory with irrelevant data for the problem at hand
  • spreads the attention span to multiple mental points
  • causes mental task-switching
  • which in turn may decrease productivity & cause stress.

Minimalism as an antidote for chaos

In the context of work, minimalism might be defined as follows:

the least possible amount of relevant work

What would cluttered software development look like?

Anything that violates the above definition may be defined as clutter:

  • adding, but not removing, breakpoints during debugging
  • editing code that is irrelevant to the problem at hand
  • pursuing to implement multiple pieces of functionality at the same time
  • having in your field of vision (e.g. in your IDE) more than is relevant for what you are trying to do

Be minimalistic…

…by following TDD

If we think about it, TDD (in a BDD way) is perfectly minimal. It forces the developer to think of an actual behaviour that is pending implementation, which then requires the minimal amount of code to make the behaviour actually exist, followed by a focused action of cleaning up said code.

…by writing up the desired behaviours as pending

context 'when the password is valid' do
  it('creates a session') { pending }
  it('responds with 201 Created') { pending }
end

context 'when the password is invalid' do
  it('does not create a session') { pending }
  it('responds with 422 Unprocessable Entity') { pending }
end
Enter fullscreen mode Exit fullscreen mode

This is how I like to write my specs in RSpec (Ruby): by starting up with the task of defining the desired behaviours of my task at hand. This frees me up from having to constantly return to the action of thinking of what other behaviours my solution needs to adopt. You write up your to-do list as pending tests, and then move on to implement them one by one. In RSpec, I prefer using the focus: true option to ensure only what is relevant to me is being tested.

…by making a commit after each passing test

Source-control commits can then snapshot this behaviour: a commit would encapsulate that single point of added value. Each snapshot would progressively build the final picture, and if at any point we need to travel back in time, we can be sure that each commit would actually contain a working version of the application, with the minimal amount of clean code required for implementing the behaviours up to that point.

…by closing up unnecessary views & compacting unnecessary code

it 'does this' do ... end

it 'does that' do ... end

it 'does not do Y' do
  # why see more than you care about?
end

context 'when X is true' do ... end
Enter fullscreen mode Exit fullscreen mode

Close up any file tabs which aren’t relevant to the task at hand. Debugging might make you jump through a dozen files, but in the end only two become relevant. Close the irrelevant ones so that you focus only on what you care about.

This applies for any other piece of code you might think of: classes, functions, tests, you name it. If right now you want to find out why a user cancelling their subscription fails, why would you care to see how their billing info would be fetched?

…by having only as many breakpoints at a time as you need

Breakpoints everywhere

Sometimes we want to dig further into the code to see what’s going on with the data. This may lead to adding an unnecessary amount of break points that may cause us to needlessly skip until we reach the location. Remove what you don’t need, so that you can focus on what you care about.

…by deleting emails you don’t want to keep around

Aside from development, a big part of today’s world is emails — and there sure are a lot of them. It’s easy to gather up a thousand emails in a day, but how many of them do we care to see?

Empty Outlook Inbox

Remember the hoarding image above? How would your room look like if your inbox were your room & the emails were actual letter laying around?

By deleting emails you no longer care about, you’ll go an extra step in seeing only what is of interest to you, saving yourself from being bombarded with irrelevant data. It’s the little things, but they add up.

…by focusing on one task at a time.

Task-switching

Illustrated in a great article by Elaine Meyer

Arguably, there’s no switch thing as multi-tasking, mentally speaking. It would rather be more correct to call it task-switching. A study describes how multi-tasking undermines efficiency, especially when dealing with tasks involving a high degree of complexity.

Do one thing, and finish it well before moving to the next task.

Conclusion

Besides software development, the principle of minimalism & decluttering can be extrapolated to life as well. Applying these principles has visibly increased my productivity, while simultaneously decreasing my level of stress, and I encourage you to give them a try and see if it does so for you as well.

Happy ordering!

Cover image illustration by Samsul Undangan @ Vecteezy

P.S. This is my first written article. If you enjoyed this it or have found it helpful, please do consider following/subscribing, as I plan to write on a regular basis.

Top comments (0)