What painting a shed can teach us about writing software

What can we learn from painting

With the world being on lockdown I recently had time to finally get around to painting my garden shed. It’s a job that I kept putting off because I wanted to do other things (like playing Ghost Recon Breakpoint).

Anyway, I finally started to paint my shed and as I worked away on painting the shed, I thought to myself how we approach something like painting a shed can be job could be applied to software development.

Thinking about it there are five rules that you need to apply to paint that also applies to software development. These rules are:

  1. Always prep before starting
  2. Have the right tools
  3. Plan before starting work
  4. Don’t move on to working on a new section until you’ve finished what you started
  5. Practice makes perfect, well better

Always prep before starting

Before starting any project you have to prep. For painting a shed, you have to make sure the shed has been swept, removing all dust and dirt. Then you have to smooth down any splinters or rough edges and then make sure you have planned how you are going to tackle the work ahead.

Have the right tools

If you start trying to paint a shed with a small paintbrush, one that you’d use for painting a small picture. That would take you ages, and after a while, the brush would be useless through it not being the right tool for the job ahead.

The same can be said for the tools you use to build your software. In the Angular world we have tools like the Angular CLI, Karma for tests, WebStorm for writing your code. You can write an Angular application using Notepad, by why would you. Use tools that not only help you write code, but enable you to write the best code you can.

Plan before starting work

I’m not the best painter in the world so I need to spend a bit of time before throwing paint at a shed I need to make sure I’ve spent a bit of time planning what I was going to do.

So Ive learnt of the last few attempts at decorating that it I need to put in some planning before getting started. This involves working out what part of the shed I was going to paint, where I was going to start and what section of the wall I was going to paint.

Having a good plan for what I was going to do before getting started helped me do a better job this time than I had before.

This planning before you get started on a piece of work should be applied to development as well. Whenever you’re about to start a new feature or implement a new section of an application, spending a bit of time planning what you’re going to do before diving straight into the work is always recommend.

This planning , even spending a few short minutes thinking about how you’re going to tackle the problem in front of you, will save you so much time and probably lead to better written code.

Don’t move on to working on a new section until you’ve finished what you started

One thing I decided to do this time was to paint the shed section by section. This way I could keep track of where I’ve painted and move from section to section once a section had been completed.

Again this approach can be applied to development as well. When building a new application, it can be easy to start on one part of the application then quickly move on to the next, just to get the basics of the app setup. To give you the impression that you’ve got a lot of the application up and running, but this is not a great idea. Say you have a target of having 80% of unit test coverage for your app, but you’ve gone off creating screens, adding services and setting up routes. You’ve done all this work and no tests. Now you have to go back to where you started and try adding tests. But in your rush to get a lot ‘done’ you’ve written code that is hard to test!! So now what do you do, spend more time trying to work out how to write tests for code that is hard to test. All that time you think you’ve saved get all these sections done, now you have to spend more time trying to setup tests.

So it’s worth making sure that you have the section your working on completed before going on to the next feature. Yes, from a project perspective it can look like you’re getting a lot done. Your sprint tickets are being moved into In Progress and Done really quickly, but is the quality of the work you’ve done that good? Making sure you’ve finished to a decent level a section or feature of the app before moving on to the next will save time in the long run and the quality of the work you do as a developer is more impressive than moving tickets on a sprint board.

Practice makes perfect, well better

Finally, the thing I did learn while painting my shed was, while I don’t paint sheds as a living I did notice that this time I was doing a better job than the last time. Each time I had to do some decorating at home, it was a perfect opportunity to practice my painting skills and the more times I did this the better I got.

Now I admit my painting skills are not great, but that shouldn’t stop me from trying. The more times I try, the more times I could practice and through this I was getting better.

The same can be applied to web development, the first website or web application you build won’t be perfect, but only through trying over and over will you get better at writing good quality apps. It’s better to keep practicing and trying this leads you to learning new and better ways of tackling problems. Leading to better apps for your users.

A great book on this idea of practising and getting through this barrier of thinking that you’re working isn’t good enough is Steven Pressfield’s book The War of Art where he talks about the resistance we feel putting our work out there, but through getting through this resistance and keep putting work out will we get better at our work.

So while I’m not a great painter and decorator, though taking my time, working bit by bit, using the right tools for the job and not putting off getting the work done. I’ve managed to do a decent job on my shed. Taking this approach can also lead to good quality code, leading to good quality applications.