Summary
- The answers to your bug or issue most likely is NOT in a textbook, blogpost, or article
- Pick a goal, a large goal, and stick to solving that problem to learn the most about development
Learn programming a better way
If I was to go back one year and tell myself one piece of advice, this is what it would be.
“Drop the book.”
Ok, ok! Maybe don’t drop the book immediately.
But, I would advise you to put it down for a day or two.
Next, come up with a large goal. One that you feel passionate about. One that if you had to stare at the goal for an entire year, you wouldn't consider throwing your computer against the wall if you stumble on reaching your final product.
The final goals of the project might have technologies that you have no idea how to use. The purpose for now is to turn nothing, into something. Get a minimally viable project/product (MVP) up and running.
An example of this is my current goal. I am building a web-crawler that opens links to certain world news articles. Later, I’ll store the contents, post the text of that story, and post it on a site. In the project I am going to use Node.js, Angular2, and RXJS.
Facebook does not get built overnight. Everyone has a "Hello, world" moment.
The hard way
The reason I wanted to write this article was to remind myself, and maybe others who happen across it, that the answers to your bugs or issues are most likely not written in a textbook or posted on someone else's blog.
Granted there are numerous tutorials out there that will guide you through a general case. But your case will be different. Thats when you have to venture out into the abyss and experiment. Get your head pounding, hands dirty, and Break stuff.
It has been more or less one year since I took on the challenge to teach myself A programming language. I will self-admittedly say that I am nowhere near having “learnt programming,” nevertheless having stuck to “A” language.
I knew this journey was going to take quite some time. But I will confidently say that I am getting closer every single day, to both building something substantial and something novel. And at the same time, loving every single day. Whether I fail miserably or commit something substantial, I know I am pushing the envelope.
Being the lead dev on a production scale project has taught me a ton about the development process. If you are building something new, there are NO instructions, textbooks, or blogposts.
The old way
The way I was taught for the past year or so, was to be given a goal in a textbook, for example “Build a Blog”. The author would then walk me through the steps.
Line-by-line, the code could be found in the book. I had one window with my text editor open and another with the textbook. Once all the typos, missed brackets, and/or missing gems had been added, the app would work exactly as expected.
I hate to break it to you, but this is not the way development is actually done.
The lesson
One of the hardest things to get over when developing something substantial, is that your work-flow is not going to be pretty at first. And this is my beef with the books and tutorials.
The books would have you believe that the entire structure of your project is thought out a head of time. That you will be able to develop these DRY methods and layouts from the get go.
False.
Your code structure will most likely fail one, two, maybe three times, requiring you to write it over and over again. You will probably have more than one copy of a function. And you will have to write out the
It is ok.
That is what refactoring is for.