Something was bothering me about this whole thing. I think I found what it is: 1) This is an entirely self-centered approach. "These are the tools that I like,

Something was bothering me about this whole thing. I think I found what it is: 1) This is an entirely self-centered approach. "These are the tools that I like, and I code the way I'm productive, with the specific knowledge I've acquired, tailored to how I best work." That's a lot of "I" in there. The idea of programming this way really bothers me because as someone who's hired freelancers, the best interests of your clients are nowhere in your calculus. Now, if you gave them the choice between lower cost code and code that anyone else can work on, it's your client's decision. But you are making that decision for them. If your clients are non-tech people who don't understand the ramifications of each choice, then you are doing them a disservice. Nowhere in your article do you mention documentation or making your source easily understood by anyone else, so I rest my case. It looks like if you are ever hit by a train, your client is screwed, and you've not thought about that. 2) I know that we, as engineers, love to reinvent the wheel, but when you start implementing stuff readily available you introduce bugs and security weaknesses. Maybe you trust yourself not to do that, but do your clients know you're not using industry standard code? Anyway, your life, your choices. I'm not sure you've been on the client side inheriting code written like this that no new programmer can understand right away. Whoever inherits your code is going to have a lot of head scratching to do, and the only saving grace is that they will have your tests to validate any changes, and they will hope that your test coverage is appropriate. But from the point of view of your own interests, everything you wrote is very beneficial.