If you wanna consume this content in the form of a video here it is:

Alright, let's buckle up everyone. I watched dozens of YouTubers talking about how they would "learn programming again" if they had to start over.

I decided to review them, get the best parts, what I think works, and remove what I think is BS, and then add my twist on it.

First things first, if I was going to learn how to code again, I'd need a damn good reason to do so.

It's not easy. Anyone who's attempted it before knows how hard it can be.

So what were my reasons? I wanted to build games, build robots, and build a startup.

That was my context.

What is yours? If you don't know, I'd highly recommend you look up youtubers talking about their experience in front end, back end, game dev(randy), robotics, data science, machine learning so you have a glimpse of what the day to day life in that area is.

It's important to know at least where your interests lie, if you're like me and have multiple interests, I find it to be the best to approach one at a time, and give it time to see if you like it or not before moving over to the next thing.

You'll be doing this for a long time, and will need to put in a lot of effort, that's why finding your why is a great motivator for you to keep at it even when things get hard.

After you know your why then we can move over to the next stage.

First Things First

After you know your why, there's one great way I can get behind in learning programming, it's very simple and inspired by @levelsio:

Don't go for courses, mentors, or boot camps. The core is figuring things out for yourself. Try building your idea in whatever language you want. Is it a game? Download Unity and make some stuff up. Website? Try making it in HTML.

Google every single thing you don't know. "How to download Unity", "How to make an HTML page", then "How to create a scene in Unity" or "How to make colored text in HTML?" and keep going. Keep searching. You'll be surprised how far you can get, this is how me and many others have learned. Figure it out yourself.

Disclaimer: I've also learned programming from books and courses, mostly because I didn't think I would get far by just looking stuff up, and I gotta say, some books and courses are worth it. Feel free to try other methods as well, but do know that "looking stuff up as you need it" is an option.

With all that said, I'm going into more depth in the rest of the video on some key concepts that can help you out along the way.

How to Learn

Learning programming has been one of the best ways for me to train my "Learning muscle".

I came from a robotics environment so everything I did took me ages to see if it worked or not. With coding you get a much shorter feedback cycle, you click run and it gives out the errors, so that helps you with developing much faster than other environments.

As Steve Jobs once said, coding helps you think better.

And so how would my approach to it be?

There are 5 steps to optimal learning:

The Steps

1. Recall
   • If you spend too much time in between coding sessions, you will forget what you learned.
2. Test yourself regularly
   • There have been plenty of experiments on human forgetfulness, but one that stuck in my mind has been Ebbinghaus' Curve of Forgetting.
     • He tested himself on random three-letter combinations that were not real words.
     • He sat down to memorize 2300 of them.
     • He regularly tested himself. If he couldn't recall a word, he would write down how many days it had been since he had memorized it.
     • He discovered he forgot things very fast, within 20 minutes of memorizing, he'd forget 40% of it.
     • The rate of forgetfulness declined as time passed, and the ones he didn't forget were lodged in his memory.
     • the curve is here
3. Interleaving Problems
   • mix a bunch of problems that require critical thinking to solve, don't just keep doing coding tasks that you already know how to do. To learn and be comfortable with the technology, you must develop an eye for novel situations and an approach to solving them.
4. Taking regular breaks
   • The Pomodoro Technique was invented by a man called Francesco Cirillo when he was studying at college. He picked up a tomato kitchen timer(pomodoro is tomato in Italian), and he would work nonstop on a single task while the timer was on. After it rang, he would put in a smaller time to rest, and then go back to another session. After 4 sessions, he would take a longer rest. And then repeat.
     • Science has shown the power of resting for learning new challenging things, it's damn hard to keep at it 100% for more than 50 minutes at a time.
     • However, it's important to mention that resting is not made equal.
       • If you're working during a Pomodoro session and then just stop to watch Netflix or look at your phone, that has drastic changes to your attention. Grabbing a book, going on a short walk, or eating a snack might help you recover in between study sessions.
5. Sleeping well
   • Sleep is a huge topic all in itself, so I'll keep brief here.
   • Sleep is where our brains clean themselves up for the next day. It's the moment where the body decides on the type of information to keep vs to throw away. You can be the hardest worker during the day, if you have bad nights of sleep, you will lose a lot of your work.

Good Practices for Learning Programming

Now that we've seen some general tips on learning, let's go to some specific ones for programming.

Errors are Opportunities

You're meant to break things, so break things

Some of us have a lot of fear of messing things up when we are programming. However, you are not in "production", you're in your local machine, and there's very little you can do that would be irreversible.

In fact, most of us actually learn the most by messing things up, digging ourselves into a grave, only to have to think on our feet to get out of there.

Don't know what this function does? Comment it out and see what happens. If it breaks the code, surely commenting it back on will solve it. If it doesn't, you can keep digging. That's all there really is to programming. You keep digging to find an answer.

Learn - Apply - Learn - Apply cycle -> Avoiding Tutorial Hell

Lots of people when they decide to learn programming, go to YouTube and keep watching hours and hours of videos without ever touching one piece of code.

Let me rip this band-aid off, coding isn't "memorizing syntax" to solve a problem you've seen 10 times before by lots of people sharing their screens.

Coding is sitting down with a problem, and thinking your way through a solution. Now if you are able to find a solution that works for you in Stack Overflow or chatGPT or even some random Youtube video, great! But the problem comes first, and so does your understanding of it.

You can't search for a solution if you don't know what your problem is.

And all those YouTube videos won't be better at teaching you the basics than just sitting down with a coding problem and solving it your own way. People making their own mistakes and figuring out what they can do to improve will be leagues ahead of the ones who just watch YouTube videos, too afraid to actually do something meaningful to learn.

Disclaimer, I know this is a YouTube video, but it's not one where I will "teach you how to code", I'm laying down the framework and how you can approach this problem, and you can always who back here to remember something or see how far you've come in your journey.

Break down problems

Every big problem is a collection of small problems. Every great problem solver in history has upgraded their game by breaking down big problems into small, solvable problems.

And that's how you should approach programming too. Whenever stuck on a specific coding task, try making it smaller, solve 10% of it, then try for 20%, if that doesn't work, try finding similar problems that you have solved in the past. See the difference between them. Keep digging.

A great resource on this is the book [[How to Solve it]]. I'll leave it in the description below.

Read the Docs

Every great programmer has once tried saving a few minutes reading the documentation by spending days brute forcing their way into problems.

I did it, the devs I know did it, and you'll probably do it too at one point.

Just read the goddamn docs.

There are levels to this - Skip at your own risk

1 - Fundamentals

I'm just going to say some of the stuff that you'll learn in this level, and so you can kind of measure yourself against it to know if you're in this level or the next.

This is where you understand not only the fundamentals of coding but also how a computer works.

This is where you understand bits and bytes, how computers interpret electrical signals to transform the code you typed into your text editor gets transformed into executable code.

Of course, you won't have an in-depth understanding of this, but you at least know what a byte is and that your human-readable code becomes machine code for the computer to process.

And regarding programming in itself, this is when you know about:

• Control Flow -> conditionals
• Variables -> definitions (Name, phone number, etc)
• Data Structures -> organizing info in the code
• Functions -> separating parts of the code that do different things, reusability
• Basic Algorithms -> sorting algorithms, and conjunction of code that does one thing that is needed in most programs

Any course that claims to "teach you the basics" of any particular language will go over these concepts. I would highly recommend you do the basics in C. But if you're in a hurry, you can go to Python or JavaScript, they're more beginner-friendly.

2 - First Projects

Now that you understand the basics, let's begin with some projects. Let's see what you can do at this stage.

• Building CLI games,
• Program your own robot with Arduino using C
• CLI calculators,
• scripts to automatize your desktop in Python
  • Automate with Python book is great for ideas
• Venture in web dev -> You'll see that HTML and CSS aren't really programming languages the same way C, JavaScript, and the like are.

Don't forget to also save these projects in GitHub. You'll need it later!

3 - Fancy Object Oriented programming

Here's what you learn at this stage:

• initializers or constructors
• methods
• inheritance
• encapsulation
• polymorphism

So if you don't yet understand what each of these words means, and you want to find a book/course that will teach you it, those are the terms you need to look after.

I myself learned OOP by devouring Head First Java's book, I did it over a month when I was in recess in college. I did it because I was demotivated with my coding skills and wanted to learn something new. But what I didn't expect is to find a book that made me laugh out loud while learning new stuff.

If you're a book nerd like I am, I can't recommend the Head First series enough, the writers are hella funny, and you come out of it with a lot of understanding if you code along.

I got through the book in about 30 days, one chapter a day. It was pretty damn cool and I still remember stuff from it.

4 - Next Level Projects

Alright alright alright.

If you haven't been doing this by now, you should start hacking away. Building lots and lots of projects guided only by your curiosity, here's some stuff you should be able to pull off at this stage, but this is by far not a full list. Explore away.

• game dev in Unity with C#,
• Mobile apps on Android/Swift,
• APIs using Java.
• website to track expenses
• portfolio website in pure HTML/CSS JavaScript (or using a framework if you want)
• Whatever else your heart desires.

Again, put these on Git Hub, or publish some if they look cool.

5 - Design Patterns

This is the stage where you've seen multiple problems with object-oriented programming and probably had to use some boilerplate code to solve similar things in different projects.

This is where Design Patterns come in. When you learn repeatable algorithms and pieces of code that solve specific and common problems in software projects (especially enterprise ones).

The reason for those patterns is that no language or framework is perfect, but since people need to make the code work with fewer bugs, some common solutions appear.

6 - Network Concepts

Network concepts allow you to understand how computers work in a network and also how the network is built. That means you understand the OSI model of networking and how to navigate to and from computers using SSL. That means you're more savvy on security basic practices, how to share secrets for projects, and how VPNs work.

This is also the level where you understand how back-end systems communicate with front-end systems.

Other Useful Stuff to Learn

Dividing on most used projects to least used projects.

Most Used

Learning your terminal

Navigating between folders, installing libraries and packages, creating files, and editing text files using vim/nano/emacs. These are all things you can learn that will make your development faster.

Source Control - GIT

Source control is how software development is leagues ahead of other professions, we can have a powerful "Ctrl Z" functionality where we can go back in previous versions of a code with a lot of granularity. It's the equivalent of documenting the construction of a wardrobe, and at the end just go "Yeah I want 90% of this finished wardrobe, but keeping all doors and losing these specific screws".

Use it to your advantage and you really won't be able to go back to developing without git.

Agile Methodologies

This is more product-based, but it's something you'll have to deal with in most projects you work on. Be it full Scrum, just Kanban, or anything in between, agile is here to stay because it works very well to allow people from different areas to collaborate on a project.

Some take it so to heart(me included) that we organize our lives with Kanban boards and Scrum-like timelines. Hell, even estimating task difficulty.

This is another key skill that once you get it, you'll find very hard to stop using because it is so good.

Memory Management

Not every language has what's called "[[Garbage Collector]]s", which means you'll have to manually allocate memory to run operations, create variables, and the such. This is heavily used in C, C++, and Rust applications, but most newer languages come with [[Garbage Collector|garbage collectors]] so you'll have less to worry about.

Testing

Testing is basically surrounding key functionality in your code with other pieces of code that check if it's doing what it was supposed to do.

Think of it as a way to not have to double check everything yourself, we are programmers, and we like to automatize stuff that we find repetitive. What best way to automate that? Testing!

But there's another philosophical position on testing, the Go Horse one.

How can you know a piece of code is running as expected? If you're really good you just know, no need to test. And if it fails, it's because you need to GIT GUD.

[[Extreme Go Horse]] dictates that Testing is a Weakness, if you know what you're doing, tests are a waste of time.

CI/CD

Just like testing, programmers like to automate stuff they don't like doing manually. And this is where a CI/CD pipeline comes in. CI in Continuous Integration and CD as in Continuous Delivery.

These fancy words mean, automating the boring part of compiling, checking the code for build errors, and then deploying it if it passes all the tests you want it to pass.

Learn this to supercharge your local projects and to help out building error free deploys in your company. It's a pretty cool knowledge to have.

Databases

If you're working on backend applications, banking, or anything that takes in loads and loads of data, chances are, you'll need to deal with Databases. NoSQL, SQL databases, Graph based (fauna), Key:Value ones (Redis).

It's not used in every type of application, but knowing it can open doors to new opportunities.

Used in some

Parallelism, Threading, etc

This is very useful if you're dealing with optimizing systems, be network systems or even heavy data applications that need to distribute load in GPUs or CPUs.

Not every language is able to deal with parallel processing. Some, like Java, use the concept of Threads, which are parts of the code that run the most parallel possible, even though the environment isn't parallel in itself(it's not distributing load in CPUs or GPUs).

How to do Code Documentation

Writing is a challenge for many techy folks. However it is the best way to communicate asynchronously with the least amount of filler.

By documenting your code and design decisions either in the project itself or elsewhere, you help out loads of future developers that are gonna use your code.

That is if they READ the GOD DAMN DOCS.

Less Used

Type Safety

Not every language is a chad language like C, Rust and other production ready languages. Some are just Python and that is okay.

But if you want to work with languages that check errors while you're developing, instead of having the code crashing on a Friday night, that makes your boss ask for you to put out the fire, type-safe languages act as one barrier to such events.

It's better to have code breaking locally than at production. Of course, python boys don't know what production is.

Least Used

Mastering your Code editor (VIM/Emacs, JetBrains IDEs, VsCode, etc.)

We all know you can't be a real coder unless you use VIM.

Sorry, I meant to say Emacs.

Sorry, I meant to say bloated IDEs.

Poor man's vs code.

Hear me out!

The Ultimate Code editor, Google Docs.

By mastering your editor, you'll be able to code 10x as fast. And as Albert Einstein once said, "Fail fast, or die trying to get NeoVim working without random errors".

Paths and their Timelines

Alright, we've been through a lot already, and I wanted to end the video about 20 minutes ago, but here I am.

There are plenty of paths in the development of careers, here are some that my friends have gone through.

Take these timelines with a grain of salt though, these are just my personal anecdotes and friends' anecdotes on the time it took them to get a position in that area.

Front End

Takes about 2 years to get into a stable position, first year you'd be studying most of the fundamentals and doing smallish projects. If you focus wholeheartedly on it, you might get an internship at the first year and then you'll be growing professionally well into your second year.

You'll learn not only programming but also some design and UX along the way in your journey.

Back End

About the same as the front end, around 2 years, but somewhat heavier on the technical side.

You'll be more in touch with databases, CI/CD pipelines, and network fundamentals.

Robotics, System Engineering

Expect a long journey, and probably an engineering degree, 4 to 5 years just to get the basics and even so a long journey to follow.

Mobile

About the same timeline as front end and backend, I'd say 2 years on average to learn the basics and start applying to companies.

Data Science

This is very skewed as it's just people I know who went into Data Science, some started as front-end devs, but due to their college course, had a really strong statistics and Python programming background, and so found it easier to switch careers.

Took some 3 years, others 5 years.

Game Dev

This is kinda the one I have the least contacts in. Game Dev is harder to get into, you need lots of specializations, and you need a heavy technical background, especially if you're developing C++ in Unreal Engine or the like.

I'd say 4 to 5 years of really intense study.

Interview

This is the part where techy folks also suck the most. You can be the most technically perfect programmer (we all know that's not true but let's play this fantasy), if you can't talk about your work in a way others can understand, show past projects, and collaborate with others, you'll not get the job.

Interviews can consist of algorithmic problem-solving, behavior, and cultural fit.

Sometimes you won't even be asked to solve technical problems and instead only talk about your life and professional experience.

Every interview is different. But there are some ways to prepare for them.

To prepare for algorithmic problem-solving in real-time, you can practice Hackerrank or leetcode problems.

To prepare for other parts, you can get a books. I haven't read it, but lots have been talking about Cracking the Code Interview by Gayle Laakmann McDowell.

Or if you're like me you can just apply to a lot of companies and learn while doing the interviews.

I see it more as fishing, you throw some baits, some companies will be interested, some won't, but as long as you throw enough baits, some fish will come in.

And then you learn what interviews in that particular area ask for, some ask for general techy problems others ask you to do a project, others just behavior.

Some people apply for months without a response, so it helps to also have some friends in companies that can either help you polish your resume and LinkedIn profile, recommend you, or give you general tips.

Above and Beyond

AI is all the hype, will it replace engineers and developers?

Who knows? But there are some ways to future-proof yourself.

In the words of Naval Ravikant:

If you can be trained to do something, society can train others and you are replaceable.

So the most valuable knowledge is the one you can't be directly trained for, it's specific knowledge working in an industry, years working with a specific technology, and leveraging AI also is in this.

How can you leverage AI to upgrade your development experience? I plan on making a future video on this, but at this moment, you gotta be exposed to it, play with ChatGPT, see it's limitations, and use it however you can to speed up your learning and help you advance in your career.

Play around, and find out.

That's it for today, see you in the next post. Peace

😗 Enjoy my writing?

If you read more than 2 of my posts and loved them, we have an honor code, meaning I give you value and you hit that subscribe button.

Forward to a friend and let them know where they can subscribe (hint: it’s here).