Since you have to state every tiny detail, the coding process easily becomes a series of tedious and monotonous tasks. Therefore, making the code you once built be in a reusable form comes to be very important in order to avoid monotonous tasks as much as possible.
Then how should we write reusable code? You can achieve it by following the big rule that one logic (logical flow) should be stated only once in the code. For instance, suppose there is the code that performs the function of buying an apple and the code for purchasing a bunch of grapes. the series of actions required in the process of 'purchasing a product' - such as comparing prices in the market, selecting one, paying the price, and receiving the product - should be the same regardless of whether the product is an apple or a bunch of grapes. Since the two processes share the same logic, they can be implemented by the same code upon abstraction of an apple and a bunch of grapes into a 'product.' If you write the code for the same logic of purchasing a product separately for two products, that task will be boring and unnecessarily take your time. Moreover, if you find there is something wrong with your logic for buying a product, you have to modify two (or possibly pretty many) different parts of code for one modification of the logic. It severly increases your chance of making mistakes without a doubt. To write proper code that fits our big rule, we can use Top-Down or Buttom-Up approach.
Top-Down approach is to group and separate the parts of the logic that is likely to be re-used before starting to write code. Although it has an advantage that you can establish a well-defined structure of the code, this can lead to unnecessarily complex code structure because actually even any tiny part of a logic can be grouped and reused. That's why I don't recommend this approach.
Bottom-Up approach is first to write code that performs the desired task without extracting any sub-logics from the logic you are about to implement, and then adjust the code when needed. To be specific, in Bottom-Up approach, when you come to have to write similar code that shares some part of the logic used previously, you will separate that intersecting sub-logic into a form such as a function, a class, or etc. Let's assume that you have written the code for purchasing a bunch of grapes. In Bottom-Up approach, when you need to write the code for buying an apple later, you will extract the code for purchasing a 'product' from the previously written code for buying a bunch of grapes. Then in the code for purchasing a bunch of grapes you will replace the whole code with the code of setting a bunch of grapes as a 'product,' and calling the function (or the code) for purchasing a product, and you will do the same for the code for purchasing an apple except that you will put in the new code the element of code that sets an apple as the 'product.'
I prefer Bottom-Up approach to Top-Down one. Top-Down approach contributes to unnecessarily complex code, and thus to the code which is hard to understand (or hard to debug). On the other hand, Bottom-Up approach allows you to write the code for immediate neccesity without hesitation, and to conduct abstraction when it's actually needed. We call the process of extracting necessary elements for abstraction from the previous code as "Refactoring." There are several Refactoring tools that can be used in Visual Studio development environment, which is largely used for C++ and C# language based program development. Unfortunately, I couldn't find a Refactoring tool for VBA, which I'm currently using very much. However, I think you can use a Refactoring tool for VB.Net as a substitute.
In short, although coding can be a tedious and monotonous job, you can minimize such monotonic tasks by using abstraction technique properly. To achieve this, I recommend Bottom-Up type coding style and I suggest you use the Bottom-Up type programming support tools, which are available for several well-known programming environments.
