When I started my career in programming, I was struggling to find the right books to learn from, the right language, reading about best language, fastest language, most popular language etc. I went so far that I was reading programming concepts that I did not understand almost at all at that time. All of this just get to the interview and be surprised with questions that I didn’t cover during my learning time. I was living the impression that only people with a born talent for programming are meant to pass those interviews and have the chance to work as developers. After I finally passed an interview I realized that actually normal people like me or you are working as developers.
I’ve been in a number of development teams, seen a number of projects, but when it was to fix a bug or write some code nobody handed me an algorithm, a design pattern and told me to implement that. They just said “fix that bug” or “make that work”. You sometimes land on a fresh project when you have to write the code from scratch and some other times the code is already there and you just have to fix bugs or add code. In those projects you have to interact with people, plan, attend to meetings, agree on things or get approved before you actually do the coding. From the books you’ve read, you learnt limited scenarios about how the particular code, principle or design pattern applies. There’s a small chance that what you learnt applies accurately to your particular task on your project. When your code has to get approved by peers or leads, it is rarely the right code. You can get a million reasons for your code to get rejected (read this as: work more on it): it can be too complex, too generic, doesn’t align the way the rest of the code is, not enough organized, not organized like the rest of the code, it has too many comments, it has no comments at all, has no test, doesn’t have enough tests, the tests don’t do what they should, and so on. Nobody cares if your code is written “by the book” if the rest of it is not really.
When you’re learning from a book, do it for you, do it so you understand the code and the logic behind it. Don’t take for granted what you read. Exercise, experiment various scenarios, write your own code, your own app, write it better, don’t settle. After you get to work on a real project you’ll have to deal with code that looks like written with the feets and you’ll want to forget as soon as possible, but you’ll still have to deal with it to get your salary. You’ll also have to deal with code that will stretch every link of your brain and you’ll think that it’s to much for you, but you’ll also have to deal with it so you can get your salary. Both of those situations will help you learn because there’s a high chance you’ll meet then several times along your career. This is the actual hands-on .