[ad_1]
At some point, I lost the motivation to write about anything that would include too much code because of the amount of time it would take to:
- put a functioning solution together,
- architect it in such a way that’d fit with best practices (at least for OOP),
- explain the various features about OOP that the reader may not know,
- then explain the problem.
This is too complex.
I’m not saying that articles shouldn’t be written that explain the concepts of object-oriented programming or shouldn’t talk about certain rationale for why something was done.
But I am saying that not every article on programming has to be written in a way that includes code that’s in a namespace with several other classes, has subscribers, services, and that uses dependency injection and includes a GitHub repository just to demonstrate a single concept or solution.
Maybe I’m writing this for my own benefit, but maybe there’s also something to be said for those of us who enjoy blogging about what it is that we’re doing and are growing more concerned with showing how to solve a problem with the bare set of code to make it happen all the while leaving the architecting – or judgment from other readers on our abilities – to our day-to-day responsibilities.
To that end, don’t over architect your blog posts. Say what you need to say, demonstrate what you need in the code, and leave the rest for another post or another author.
[ad_2]
Source link