When I first started coding, both reading it and writing it, I found that a lot of people wrote code in an unnecessarily complex way. Then I would decide to co

When I first started coding, both reading it and writing it, I found that a lot of people wrote code in an unnecessarily complex way. Then I would decide to code it in the much simpler way I saw in my head. As I coded along, trying to add the features I needed, I would see a way to be even more flexible for only a little cost. Frequently I would go back and look at the "ridiculously complex" code, only to find that our implementations were similar after all. My understanding of the problem was much more sophisticated tho. This happened frequently, but in retrospect, as I practiced this more, I found that I was discovering the similarities between my solution and the already existing code much sooner. Eventually I learned to trust the other developers, that they had a more sophisticated understanding of the problem than I did. I also learned about refactoring and how that affects code shape (going through a similar process to that mentioned above). Other times when I find reading the code to be a problem, it is due to "future flexibility". Sometimes this is needed, others it is a waste. One thing to keep in mind tho, is that the "future" represented in the code may have already passed. I have some code I am frequently accused of "prematurely future-proofing", however in reality the changes the code was handled to design are now mostly incorporated. At the time the future-proofing was done however, life was hectic and "must do" changes were coming down the pipe daily and the flexibility paid off. Finally, there is the option that its crap code. I and most others have written plenty of that too. One thing that helps me in that case is to stop trying to figure out the code as a whole. Instead I refactor it as I go, since well factored code can lead to a big decrease in cognitive load. Best luck.