Daniel RendoxI've been experimenting with my learning approach for a long time now, made dozens of mistakes, and I think I finally came to a conclusion. Eager to share the gained insights with you!
🐰 The rabbit hole is open
This summer, I had a lot of free time for programming. So, knowing a bit about Android, I quickly learned the basics of the new UI framework and started applying these things in my program that I think I have a good idea of. Having tried to write some simple stuff, I realized that there was a whole mountain of things that I didn’t know.
While creating some labels, buttons, and checkboxes is easy, making them actually work and doing some more complex stuff requires a lot more knowledge. Imagine, I want to create a functional screen. I need to first write business logic and UI. Then it would be good to add databases, which also requires knowledge of multithreading. And only then I can connect everything, and preferably, write tests to make sure everything works correctly. This is the whole bunch of stuff not even mentioning, interaction with remote API, dependency injection, and following best practices.
Then you actually try to figure all this stuff out and find other pitfalls which is really frustrating, especially when you don’t understand something. You don’t even know what you don’t know!
Here is the answer to why beginners feel very confused about how to cope with everything.
As you can guess, I fall right into that trap. But luckily, I regularly listen to some programming podcasts and I once found some great advice in one of them. I encourage you to watch this 50-second clip ⬇️
I obviously needed some time to digest it but when I did, it ended my frustration. Here is the breakdown.
🤯 #1 Have fun and experiment with stuff
When you encounter a problem that requires you to learn some new things, approach it with the right mindset — be excited that you’re gonna significantly increase your skills.
Of course, this podcast wasn’t the only thing that pointed me in the right direction. It’s usually a confluence of circumstances that causes people to rethink something.
I remember another Android dev who having found out that I was trying to learn Android and build my app, said to me smth like “You must be following a lot of Google codelabs and just experimenting with stuff”.
And this stuck to my mind. Just having fun and experimenting with stuff — that’s what I should do. One step at a time. Find an interesting guide for a topic, try to implement, and switch to another one.
🤯 #2 Build your program!
So I decided to savor learning and really enjoyed getting into these rabbit holes. However later on I realized another equally important thing.
I made some kind of a roadmap for myself that involved passing codelabs and making small programs to practice my knowledge and play around. This was pretty close to what Philipp Lackner recommends in his video — learning stuff and then making programs to apply this in practice. For example, you’ve learned a programming language and UI framework — now you can build a calculator, then you learn how to store data and build a to-do app, and so on.
Given that to make a scalable project, you need to consider lots of things from the beginning. E.g., for Andriod, it would be good to, first, care about dependency injection and architecture, it would be even better to make sure that your code is properly abstracted and tested. [source]. So as I just didn’t know all this stuff, I decided that I would learn it and then get back to my program.
And I ditched it for an unidentified period of time.
Fortunately for me, at some point, I had a little dispute about “the right learning way” with my dad who is a developer and had made all these mistakes either. He said that I was learning too much and should’ve focused on building instead. And I was like, that’s what I’m doing, I’m creating these learning projects to practice and they all involve the knowledge acquired previously so as not to forget anything.
But he told me that it’s very important to have an ending point. There is always gonna be other stuff to learn, and you’ll never be ready to continue working on your project. He’d fallen into that trap and eventually found himself knowing a lot but not having actual results.
Like when you spend a significant amount of time preparing yourself for the big venture and then your friends ask what you’ve accomplished so far, what you’re gonna respond? Alright, I can name a bunch of technical things to impress people, but what can I actually show?
What if we flip it upside down?
And then I realized that the best way of studying is not learning theory and then seeking the possibility to practice but on the contrary trying to make something, figuring out what’s needed, and learning that. Right away with the practical approach! 🙌
Learn only the stuff that you actually need
It’s crucial to learn only those things that you really need for building your program. When I started learning programming, it was my biggest mistake. I just learned things that indeed helped me understand concepts, the programming language, and the whole structure. But even though, I quickly forgot them, and could be so much better off not wasting time on those things and following the practical approach right away.
I still make these mistakes and this advice is also very to misinterpret. For you to understand, here are certain scenarios. ( ✔️ — correct approach, ❌ — incorrect approach, according to the described mindset)
To save your program’s data, you need to learn databases. But the prerequisite is that you should know concurrency first.
❌ Go find a course for mastering concurrency and after that, switch to databases.
✔️ Start with databases right away, and when you don’t understand something about concurrency, find a quick explanation on the web and go on. If you eventually feel that this concurrency knowledge is not enough, take that course.
Don’t run after new and shiny
You want to create a program and already know how to make a simple app, but a new shiny framework comes out, and you feel like you need to learn it.
❌ Learn the new framework. This will allow you to fill in the gaps, get more confidence, and see things from a different perspective.
✔️ Congrats! You are ready to start building your app. This will keep you motivated, you’ll retain your knowledge, and stay practical. In addition to that, you’ll eventually get all the benefits described above.
Even applicable to absolute beginners
You're just starting out and have an idea of an app you want to create. Before that, you certainly need to learn the programming language.
❌ Go find a crash course about that language.
✔️ Go find a course that will allow you to stay practical right away. For instance, here is one for Android development. If you can’t find one, learn the basics and jump to creating something yourself.
Don’t get overwhelmed with best practices and give up on your program
You find out that to make your app scalable from the outset, you need to know many things. You consider what to do next.
❌ Ditch your program, learn all these things, and only then get back to it.
✔️ Carry on with your program. Start small. First, write business logic, then add UI. Boom! Pre-MVP is ready. Then try and add data storage — MVP is ready. 🎉 And don’t really worry about making it scalable.
There is no point in being concerned that your code is not clean enough. It won’t ever be perfect. Trying to optimize every class you write and learn all the best practices at once will only take up your time and spoil your nerves.
It’s good to occasionally look into these things, but being overwhelmed with them is bad.
As you may guess, I made each of the mistakes above.
Adopting the mindset to build any app
If you rewatch that clip from the podcast, you’ll discover that the first piece of advice (🤯 #1) was actually produced by my imagination, while the thing the guys actually emphasize is exactly the importance of building your own stuff.
In the beginning, Mitch says: “It’s like what you said earlier.” And that earlier was at 1:02:00, where they answered one of the listener's question: “How can I get an attitude that I can make everything, that I can make any app?”
The answer is actually in developing such mentality that I described above. Being able to learn, and just carry on. Like Mitch says:
Get confortable with being uncomfortable.
My favorite learning approach is free
It’s one of the things that I love about it. You don’t need to pay for any books or courses. In fact, with all this information available for free, paid higher education seems to be nothing more than a scam either.
In the marketing world, salesmen put discounts to make us buy things that we don’t need. The business of making courses works in the same way. I’m not saying that it’s bad though. Products are good and we’re happy to buy them, the same thing with courses.
I love Philipp’s channel and benefited very much from all the knowledge he shares. But why would I pay ~100€ for a course on his website if everything is available on his YouTube channel? What these books and courses really offer is the information gathered and structured in a systematic way. They also artificially make you feel comfortable because you have support.
Then the question of whether to buy or not boils down to how willing I am to collect all this information and solve problems on my own. In my opinion, if this stuff is available legally and for free, buying a course is a way to spend money and get tutorial hell, whereas the project-based approach lets you adopt this very mindset.
Ending
Now that I’ve defined the most important things about learning programming, here is how I’m gonna change my approach. First, I’m going to make building my app the first area of focus and allot no less than 50% to it.
I think it’s imperative though to still embrace learning in parallel and dive into these lovely rabbit holes, but only for a limited time. This way, I can be sure that I stay on the right track and do not reinvent the wheel due to the lack of knowledge.
I’m still searching, so I’m curious to hear about your favorite way of learning. Advice and insights will be much appreciated!
