DEV Community

Cover image for The Art of Balancing Learning and Building
Daniel Rendox
Daniel Rendox

Posted on

The Art of Balancing Learning and Building

I'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 ⬇️

✂️ Take it easy when learning programming - YouTube

52 seconds · Clipped by Daniel Rendox · Original video "Freelance Android Developer, Donn Felker" by CodingWithMitch

favicon youtube.com

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!

Top comments (4)

Collapse
 
montyharper profile image
Monty Harper

Hi Daniel,
I like your approach. I'm doing the same thing, making the same mistakes. I'm learning both SwiftUI and UIKit in order to make iOS apps. It helps that I have a particular app in mind that I'm highly motivated to create, plus several others I'm working on conceptually.
I will say that I'm following two curriculums, one free, and the other paid. I'm finding that they both help direct my learning in absolutely useful directions. I haven't hit a lesson yet that I can't apply to help make progress on my apps.
I have hit some rabbit holes, though, where the lesson went too deep into a topic I wasn't feeling the need for, so knowing when to skip ahead is a good skill to have.
Still, we shouldn't beat ourselves up too much for "time wasted" learning something we can't apply yet. For one, the very act of learning is a muscle and we are exercising it. Two, you never know when that thing may come up again, and you'll have at least some familiarity with it when it does.
Finally, reading your article made me think about the same balancing act applied to songwriting. I've invested much of my life in learning and teaching how to write songs. While students of coding may be likely to focus too much on learning, not enough on creating, I think in songwriting (or maybe any kind of creative writing) it can be the opposite problem; students want to write the perfect song out of the box without studying techniques or theory at all! The tendency is to try to learn entirely by doing, and students will ignore the need to study some techniques and concepts that could easily up their game.
The same balancing act likely applies to any domain of learning and the answer is almost certainly always to walk the middle path!

Collapse
 
danielrendox profile image
Daniel Rendox

You're absolutely right, Monty!

I want to deliver one thing — people tend to feel frustrated about some ridiculous stuff. I managed to somehow end my frustration and tried to share the clues to how I made it.

In fact, everything beyond what's said in the podcast is too much of a personal preference. I just shared my own interpretation of the given advice. Initially, I actually wanted to write about my favorite learning approach.

And now I think what's ideal is indeed the middle path. A person who focuses too much on building will reinvent the wheel and make unscalable apps, whereas a person who focuses too much on learning, will have theoretical knowledge and not have the real-world skills. Both would benefit from shifting their focus towards the middle ground.

But in the end, I learned to never regret anything in life. And if you like what you're doing and are really passionate about it. Whatever approach you used, whatever mistakes you made, this is a win from the outset.

Collapse
 
montyharper profile image
Monty Harper

Yes, indeed!

Collapse
 
carloscarvallo profile image
Carlos Carvallo

Great content Daniel