Item — HN Reader

I think this has a lot to do with how OOP is taught. At uni, on the same semester we were introduced to C++ with classes, OOP, UML, and design patterns. This of course creates in the mind an association between all of these things -- a feel of 'if I'm doing OOP then I should also use these patterns'.

The thing is, during the class we understood what the patterns were. However, since the actual programming project was comparatively small we didn't actually understand what a need for following these patters looks like. We didn't see a case where the simple way just didn't cut it, we were simply told to use them because they are good. The effect of this is that, unless someone with experience then comes and mentors you, you will overengineer all of your solutions because you don't know any better. We were taught the patterns but didn't understand the reasons. And I suspect many other engineers have had similar experiences

2 comments

I wrote a bit of C recently, it's impressive how patternless it makes you think. At least not in the OOP way. You may think in patterns, but it's not encoded in source. It's implicit structure. It's also very different because every bit of help you allow in your source is carefully thought out, you want it to fit the fragile land of C and also now you're moving bytes somehow explicitely, you tend to think more about memory and cpu perf.. again less pattern envy.

ps: I also forgot to say, even though I'm a fp head these days, imperative C felt fun, that is if you carefully stay into state -> state mindset ;)

Unfortunately this means you wrote several copies of essentially the same code but with minor differences, and if you find and fix a bug in one the others are still wrong.

You need to learn them to be able to read the code that uses them - whether it is used the right way or not. E.g. if you encounter the word 'adapter' or 'decorator', it is easier if you know what it means (and that you should not use those words for things that are not patterns).

yep, especially when working on a large established code base, reading code written this way is an important skill set even if you don't write it.