let myDataModel = DataModel()I know I should be using some kind of dependency injection, but I'm not clear on how to implement it. I didn't even know what a singleton was until after I'd developed this and later learned what it was called. At the very least I should encapsulate my data model more clearly in more descriptive objects that are based on the real-world concepts that more closely relate to the data it holds. When I was writing it, it all made sense: the data model was a new idea that had an almost physical reality. For the particular app though, it's fine, just like the fact it's a singleton. It gets me to the point where I can see the inefficiencies; to where I can see how wrong it could all go; and best of all, to where I can see that maybe there's a better way. And when I read forums and the Slack threads, it's a constant drumbeat of "you're doing it wrong". It's not even directed at me but it feels so personal. Developers are an opinionated bunch, and we seem to write as if we're all suffering from post-traumatic stress -- one might imagine -- in the insistence that there is only one true way to engineer software: the way we are doing it right now, on this particular project. I fully believe that some day I'll be as jaded, grizzled, and grumbling about the hot new design pattern as I am today about the horrors of copying and pasting code. I've done it, and I've suffered the inevitable searching through multiple copies of the same code, trying to remember what it was that I changed in the other file that I need to now change in this one. It's horrific, and I'd do anything to spare you the same trouble.
You don't need to know everything to get started, you only need to know enough to keep yourself interested in learning more.
But I can't save you and you can't save me. I have to make my own mistakes, so I can learn those painful lessons. I'm ever so jealous of people who can learn from other people's mistakes, and I guess occasionally I can do so myself but more often I need to fall off my own skateboard and sprain my own wrist before I realize the correct way to fall is not to throw my hand out to stop it. Eventually, after many painful trials, with sore hips and shoulders, and a skateboard that ended up being crushed by a bus, I learned how to stick the ollie and to stop falling. At least, how to stop falling as often. And someday I'll learn how to turn my singleton into a dependency injection in my app that's been engineered from scratch as a model-view-viewmodel-controller, not because that's the hip new way all the hipsters are hipping up their hip code, but because that's the best way to engineer my well-designed idea. Until then, I'll suffer the sidelong glances of my betters, who beseech the ghosts of Kernighan, Ritchie, and Stroustrup to visit me in the night so that I might mend my ways and join them in the holy land, where they never make mistakes and have nothing left to learn. And code just writes and maintains itself, and we never grow old and we never die. This is my journey and I get to choose my own path. I'm not good at spending years in a university setting, gathering knowledge that I may or may not use, getting lost in the theories of computer science and software engineering. Those things don't hold my interest. I'm not an engineer, I'm a hack. My code will never be as efficient as yours. My algorithms will never be as elegant as yours. My comments will always include movie quotes, and inside jokes, and certainly won't be as helpful as yours. But my software will be a unique expression of myself. At some point, writing code stopped being a purely academic exercise (if it ever was that, and I personally don't believe it ever was, except in the imaginations of those who wished it would be) and it became another medium regular folks use to express ourselves. That's a wonderful thing, it truly is. It means there will be messy, spaghetti-fied code that's unreadable and inefficient and may not ever be fully understood even by the folks who write it, but that has always been the case. Code has always been messy, which is why there has been so much energy spent on teaching people how to write clearer and cleaner code. One of the main goals of objected oriented design patterns was to create code that humans can understand more easily. If code was always clean, we'd still be programming in assembly. We are going from code that was created to solve problems to writing code to create new problems. That's the next step forward and we need minds who are excited about going places they're not supposed to go. The wonderful outcome is that the barrier to entry has been lowered enough that we can start teaching an entire generation of kids how to write code. It's still an ongoing process but writing code is going to become as ubiquitous as writing a blog or posting on Facebook. While some may decry the current generation as being Snapchat-obsessed and only capable of communicating in Twitter-sized chunks, they are at the same time, capable of writing their own scripts and self-automating their workflow, in any vocation, from accounting to zoology. They are absolute geniuses compared the previous generation that grew up only having one computer to share among a whole class, or none at all. If you're an old timer who's been there, made those mistakes, and has the scars to prove it, keep sharing your wisdom, it's essential. If you're just starting to write software for your own personal reasons: come on in, the water's fine. The first thing to learn is that you can't learn everything at once and you don't need to know everything to get started. You only need to know enough to keep yourself interested in learning more. That's all anyone else did.