The Skill That Always Pays Off

When it comes to software delivery there are numerous skills required in order to be successful. From understanding the language you use and knowing architectural patterns to writing user requirements and planning work. It can be overwhelming at times to decide what to get better at.

My opinion is that the number one skill you can learn is to take smaller steps. Once you learn to take smaller steps then take even smaller steps than that. While all the other skills will pay dividends in various contexts this is one of the skills that applies in nearly every context. It will pay off constantly.

Here are some examples in various software delivery contexts:

1. Writing new code

2. Refactoring

3. Project/Sprint planning

   
   

Writing new code

It’s easy to think that you can take a new project or feature and just slap the code together and end up with a feature exactly as the user expected. After all, we’re smart people and we know how to write code. Unfortunately, it just never works that way. If you’ve ever worked on a large chunk of code all at once, you’ll have had the experience of it not working and then having to debug this brand new code to find out where you went wrong. What happens? You end up spending large chunks of time hunting for the piece that’s wrong.

Take smaller steps.

As you write the code, write it in small, verifiable chunks. Find ways to verify a piece of code before the whole thing is done. Automated tests are one way. Writing small consumers that are unrelated to your app can help expose pieces of low level code and allow you to manually verify things without wiring up an entire feature. There are so many ways to step smaller when writing new code.

Refactoring

We all have to massage code into a different shape at some point. Sometimes these refactorings involve a fair amount of code. As with writing brand new code, if you bite off a large chunk at once you’re destined for the failure/debug cycle.

Take smaller steps.

Rename a variable and then commit it. Introduce a new parameter with a default value and commit it. Change 1 calling site to provide the new parameter and commit it. In each step it should be trivial to verify that you haven’t broken anything and, if you have, it’s just as trivial to back out of the change guilt free.

Project planning

The same principles apply at the project level too. Every customer or product owner has big visions for the product. When someone gets excited about the impact a new feature could have it’s very easy to try to estimate the whole thing and provide a projection for completion a few months down the line. What tends to happen in this case? Delivery is late and, in the end, it’s not what the customer actually wanted. Happens time and time again.

Take smaller steps.

Break it down. Learn how to take a feature and break it into smaller steps that can be demonstrated to the customer or customer representative. The smaller the better. The earlier you can discover that you’re on the wrong track the better off the project will be.

Conclusion

Taking smaller steps is a skill that needs to be developed like any other. Practice it in as many contexts as you can and you’ll learn new tricks in each one while reinforcing the higher level skill. If there’s something preventing you from taking a smaller step then ask yourself what you’d need to be true in order to take it. Is it possible to take a small step towards that ideal situation? It may not fully allow you to take a smaller step now but it may pave the way for smaller steps later.

Take smaller steps.