I also suggest consider your data. There are two main problems we face as programmers: managing complexity and transforming data. The former gets the majority o

I also suggest consider your data. There are two main problems we face as programmers: managing complexity and transforming data. The former gets the majority of the treatment in articles like this but I believe the latter is often more important. We must consider the shape of our data, the usage patterns of our data, and consider structuring our programs to accommodate such patterns and transformations. An example of where rules of thumb about abstractions turn into poorly designed code is when processing large arrays or vectors of data. It is common to model your data in some kind of product type like a struct or union and process each item using some method of iteration. However if the main usage pattern of our data is to perform this transformation over the vector within an outer loop we've shot ourselves in the foot from the get-go. Our caches are constantly swapping data. This is called, premature pessimization. So don't get trapped into thinking that our job is only about learning SOLID principles or various aphorisms and mnemonics. The other side of our job is transforming and moving data.