3 posts tagged with "100daysofcode"

Draft from November 2021.

And that, I think, is the real shift in thinking: When you shift from being a learner to a problem-solver.

I realized that once you've finished a course, learned the basics, and started working on actual projects, you rarely go back and re-watch an entire section of the course just because it happens to be related to whatever issue you're troubleshooting.

Instead, you usually do one of two things.

You either:

a. Go through your own notes or documentation to see if you've encountered the problem before, assuming you trust your documentation enough, or

b. Take the much easier and quicker route and Google it, search Stack Overflow, or look for a similar use case on YouTube.

So I think structured courses are really useful during the discovery stage.

They introduce you to the technology, explain the terminology, show you how things are connected, and give you some idea of what you're actually dealing with.

But once you're trying to use that technology to solve your own problems, things become different.

At that point, instinct usually kicks in.

You Google the error and hope somebody has already asked the exact same question on Stack Overflow.

Or maybe someone uploaded a 12-minute YouTube video three years ago that somehow solves your exact problem.

Another thing I've noticed is that courses can become outdated pretty quickly, especially when technologies move at a really, really fast pace.

AWS Cloud computing examples come to mind (you can skip the list below if you don't care about the details):

1. One day, EC2 limits are described in terms of a fixed number of instances per region.
2. Later, the limits are based on the number of vCPUs you're allowed to run.
3. One day, ZooKeeper is an important piece of the architecture you're studying.
4. Later, newer versions of the technology start moving away from it entirely.

Sometimes the change is significant.

Sometimes it's just a button that moved somewhere else in the UI.

But when you add all those small changes together with everything else you're already trying to learn, they start becoming pretty significant.

One day, you might have several weeks to play around with this fascinating new technology you've just discovered.

Then tomorrow, someone tells you that you have two weeks to understand it and come up with a bare-minimum usable solution.

So yeah.

Things change pretty quickly.

I guess my point is that it took me almost four years, and honestly I'm still working on it, to shift away from the structured, college-style way of learning and adapt more to how knowledge is acquired in the actual industry.

When I say college-style learning, I mean the kind where you have a clear outline of what you're supposed to follow.

You start with the baby steps.

Maybe you fire up your first terminal.

Then you learn the commands.

Then the concepts get progressively harder.

Eventually, you reach the more complicated parts.

You usually know what you're trying to learn, what the problem is, and what you're expected to accomplish before moving on to the next lesson.

The actual industry doesn't always work like that.

Sometimes you're simply given a list of requirements.

And that's it.

Nobody gives you a neat list of all the technologies you need to learn beforehand.

It's up to you to figure out what tools you need.

Sometimes you aren't even given a clearly defined technical problem.

You have to figure out what questions need to be asked first.

Then you start searching for the answers.

I guess this falls under what people call ill-defined problems, where there isn't always one perfect or unique solution.

During my time at my previous job and now in my current one, I've learned a lot about how solutions are actually pieced together.

You might have help from a vendor.

You might have external professional services working with you.

You might have documentation, architects, engineers, and other teams involved.

But eventually you realize that solving problems isn't always as straightforward as it looks from the outside.

Some tasks suddenly become more important than others.

Something from the business side might come up halfway through the sprint.

A requirement changes.

A deadline moves.

A dependency suddenly appears.

And now you have to rethink which of the ten questions sitting in front of you actually needs to be answered first.

So the industry's way of learning can get pretty messy.

You search for whatever you need at that moment.

You try it immediately in your test environment.

If it works, great.

Maybe you start incorporating it piece by piece into your code or configuration.

Then you test it again.

Check the logs.

Run your unit tests.

Run OAT or whatever other validation process you have.

If everything looks good and nothing starts screaming in the logs, maybe it eventually finds its way into production.

Oh, and here's the fun part:

You need to have all of this done in four sprints or less.

No pressure.

Now, situations like this can introduce what we call technical debt.

This usually happens when you choose a quicker or easier solution today, knowing that you'll probably have to revisit or improve it later.

Is technical debt bad?

Yes.

No.

I don't know.

I guess the real answer is: It depends.

Sometimes you simply can't make something perfect.

Your solution might depend on a platform managed by another team.

A new version might change how your code behaves.

Another system could be updated.

Requirements could change again.

There will always be factors outside your control.

And sometimes getting a working solution out there lets you learn something that you would've never discovered by spending another month trying to make everything perfect.

The faster something fails in a controlled environment, the faster you can understand why it failed and improve it.

So in a strange way, we're constantly trying to find ways to break things safely so we can figure out how to make them better.

Wait. Where was I?​

Oh, right.

A shift in thinking.

I guess I've spent all this time trying to explain how structured learning differs from learning when you're already trying to solve a real problem.

So, should I stop taking courses and just focus on projects?​

No.

If something is completely new to you, you still need some sort of foundation.

And that's what courses are really good at.

They give you the basic tools that you might need later.

They show you what's possible.

They introduce you to the terminology.

They give you enough knowledge to at least know what to search for when everything eventually breaks.

Then, somewhere along the way, you start using those tools to answer your own questions.

Sometimes you'll keep using them.

Sometimes you'll realize that the tool you learned isn't actually the best one for the problem sitting in front of you.

So you drop it and learn another one.

And that's fine.

I am still confused​

Well, you're not alone.

I still haven't figured all of this out either.

I still have a ridiculous number of courses sitting on my laptop that I haven't finished yet.

And since time is a limited commodity, I've slowly developed my own strategy for learning things and actually applying them.

If my goal is to take a certification exam, I usually go through the course, do the labs, write down notes, and then prepare using practice exams.

Once I pass the exam?

I delete the course.

Yep.

No hesitation.

At that point, I know I'm probably not going to sit down and re-watch the whole thing again.

If I eventually need to use the technology for a project and I run into an issue, chances are I'll just search for the exact problem anyway.

And honestly, I like it better that way.

Instead of going back through hours of videos, I can search for exactly what I need.

Kind of like picking apples.

You grab the ones you need and leave the rest of the tree alone.

The important part is that during the discovery and review stage, I used the course to build some sort of foundation.

I learned enough to know the terminology.

I learned enough to understand the basic concepts.

And hopefully, I learned enough to recognize what I don't know.

Then comes the application stage.

That's when I start relying more on my own tools.

My notes.

Documentation.

Experiments.

And, of course, my Google-fu.

Currently, I'm preparing to take the RHCSA next year.

So by then, I'm expecting most of the RHEL-related courses sitting on my hard drive to be completely gone.

By deleting them, I'm also forcing myself to think on my own instead of constantly going back and copying the exact steps an instructor followed.

If I want to remember how I did a lab, I check my notes.

If it's not in my notes, there's a good chance it's somewhere in the official documentation.

And if it's not there?

Well.

Google probably knows somebody who knows.

Okay, I think I got it.​

If you did, then you're probably already one step ahead of me.

Again, I don't have all the answers.

Half the time, I don't even know what the right questions are yet.

But I expect to figure out more as I keep going.

I'll do more labs.

I'll break more code.

I'll tail more logs.

I'll try solutions that don't work.

I'll eventually find ones that do.

Then I'll document what happened so maybe I don't have to suffer through the exact same problem twice.

And somewhere along that process, something changes.

You stop just asking: "What should I learn next?"

And you start asking: "What do I need to solve this?"

That, I think, is the real shift in thinking.

When you shift from being a learner to being a problem-solver.

And maybe, after you've solved enough problems, you eventually move into another kind of learning altogether:

Passing what you've learned on to someone else.

DAY 1 - Where to start?

The #100DaysOfCode challenge has been one of those goals that I've pushed back several times in the past, either because of time constraints or some looming workload I had to deal with.

There were actually a few times when I started the challenge, only to stop after a week because, well, I simply didn't know enough yet.

What I mean is that my way of learning was never really structured. Instead of going through the fundamentals of a skill, I would usually jump straight into whatever was necessary to solve the problem in front of me.

And sure, that's an efficient way to get things working quickly. But it's not really sustainable. Eventually, the lack of foundation catches up with you.

You might manage to solve one problem, but once something breaks again, you suddenly realize you don't fully understand why the solution worked in the first place.

You just cannot skip the process​

Another thing that has always gotten in the way is my own thought process.

I was younger then, with little experience but a lot of excitement and tenacity to jump into challenges without first going over what was actually needed.

I'm telling you, as a kid, it was fun to just tackle whatever the world threw at you because, well, that's how kids deal with things. No BS. No need to complicate things. Just plain fun.

But as an adult (or at least a 20-something adult) you can't always just grab a problem and try to solve it without examining it carefully first. For one thing, there are consequences to our actions.

No matter how small we think an effect might be, the real problem starts when those effects begin to cascade and roll downhill like a snowball on a steep mountain.

One day, you think you don't need to learn data structures and algorithms because you've already managed to put together a script patched from several sources on the internet.

Then the next day, you come face-to-face with a problem that nobody has asked on Stack Overflow yet.

You just cannot skip the process.

It might feel like it takes more time to properly learn something, but hey, you don't move mountains using brute force. Instead, you break Everest into its smallest pieces and move it one stone at a time.

Moving places​

I've hopped into positions where I was either only partially qualified or, honestly, not qualified at all.

I guess it was the eagerness and tenacity that helped me get those jobs, but I've learned that the basics always come back eventually. You'll be troubleshooting some issue, and suddenly you're back on the internet searching for the fundamentals again.

Alright, maybe I'm exaggerating a little when I say that I never bothered learning the fundamentals of anything.

I did start from the very basics of networking when I re-learned everything while studying for my CCNA last year. It was actually a fulfilling experience to properly understand subnetting, how networks work, and how routing allows data to reach its destination.

But I also know that networking is just one of the foundations an IT professional should have.

And as I discover more about the world of DevOps, I've come to accept that networking alone isn't enough if I really want to succeed as a DevOps or cloud engineer.

Which is why I started learning Linux last February.

That turned out to be pretty useful when I moved to my current job, where I handle some of our network management systems. Those NMS tools are all hosted on Red Hat 7 Linux servers, which I've been lucky enough to play around with.

Well, mostly on the lab servers.

Practicing on production servers is obviously a BIG NO.

Alright, I guess that's enough of the story, and the memes.

I've already spent about an hour researching what I'll focus on for this challenge and, of course, looking for the awesome memes I'll put in here.

So far, I've narrowed my checklist down to this:

1. Standardize my naming conventions - Yeah, I know this sounds like a pretty trivial thing, but I think it'll help in the long run, especially if I ever come back and look through my earlier files.

2. Linux - I still consider myself relatively new to Linux, but I'm definitely more comfortable working on Linux servers and my Linux VMs now. It's only been a couple of months since I first really dove into Linux, so there's still a lot to learn.

   Another good playground for Linux is KodeKloud. Head over to www.kodekloud-engineer.com, set up an account, and try completing your first System Admin task.

3. Git - I already have a Git account, and I've learned how to work with my local repositories, but what I don't really know yet is how to properly work with GitHub.

   So yeah, Day 1 is for Git and GitHub.

   For this, I'll be using a Coursera Guided Project called Git for Developers Using GitHub, which you can find here:

   https://www.coursera.org/learn/git-for-developers-using-github/

4. Python - With so many languages to choose from, I decided to lock myself into Python for, I guess, the first 50 days.

   This will include solving problems on HackerRank and actually working on projects.

   Python is a language that's pretty close to me because I've had this on-and-off relationship with it for a while now. There are periods when I'll focus intensely on doing Python stuff, and then suddenly stop because there's another workload I need to deal with or because I'm preparing for another certification exam.

   This time, I want to be more consistent.

   I'll be using the Google IT Automation with Python Professional Certificate on Coursera:

   https://www.coursera.org/professional-certificates/google-it-automation

Google IT Automation with Python Professional​

To start re-learning Python the proper way, I'm beginning with the Google IT Automation with Python Professional Certificate on Coursera, which is composed of six courses.

The site suggests that it can be completed within eight months if you spend around four hours per week studying.

Since I plan to work on this every day, including weekends, and because I normally watch the videos at 2x speed, I'm aiming to finish the entire professional certificate in around two months.

What I really want to spend more time on, though, are the practice challenges.

Now, this is still a rough plan.

If you've read the Python section above, this is only what I'm planning for the first half of the 100 days.

For the second half, I intend to work on web development stuff.

You might say that 50 days is too short to finish that course.

And yeah, you're probably right.

I'll just finish whatever I can between Day 50 and Day 100. Whatever is left, I'll continue during my next #100DaysOfCode.

To sum it all up, I guess this #100DaysOfCode challenge is really more of a consistency challenge for me.

I'd like to fully commit myself to something and keep going until I reach some level of mastery.

Of course, it'll take way more than 100 days to become an expert at something. But I think these 100 days can at least put me on the right path.

Also, I'm still not really sure where I'll be posting all of this since I only recently started Twitter and Instagram accounts.

I guess I'll use both.

The problem with Twitter is the character limit, so I might have to break the posts into parts, maybe post the first half as the main tweet and continue the rest in replies.

Or I could just cross-post everything to dev.to or Hashnode.

My only concern is whether all the images I put here will display properly when I post on those platforms.

As for Instagram...

Yeah, I haven't really figured that one out yet.

And one last thing: my succeeding posts or tweets will probably be a lot shorter than this one. They'll mostly just be updates on how the challenge went that day.

Then maybe at the end of every month, I'll create a longer summary as a checkpoint and post it on dev.to, Hashnode, or freeCodeCamp.

Alright.

So, Day 1. Where to start?

Yeah.

Git.

My take on how I approach the idea of programming. I've also included some of the core concepts that I think everyone should know when they're starting to dive into coding.

To start with, I want to say that you made the right choice opening this post.

You might be someone who's been dabbling with code since you were little, or maybe you're someone who just wandered through a bunch of interesting links on Google and somehow found yourself craving more nuggets about programming.

Either way, there's probably still one thought, or rather one question, sitting somewhere in your mind:

Is programming really easy?

Well, let's try to answer that question once and for all.

Programming is relatively easy.

Say it with me.

Yes, for the most part, programming is basically putting together keywords and instructions into lines that the computer can understand, then moving on to the next line.

Kind of like forming a sentence.

But is it really just that?

Think about how you form a sentence in English. There are certain rules you have to follow. You have to think about which tense to use, whose point of view you're writing from, where words should go, and which punctuation mark should end the sentence.

Programming works in a similar way.

You have a set of rules, a vocabulary, and a structure that you need to follow.

Of course, there are a few other core concepts you should understand before you start building your own programs.

What's the word?​

When you're first learning a new language, let's say Nihongo, you might have this reaction the first time you come across Kanji:

Looks complicated, must be complicated.

But it's really not that difficult once you take the first few steps and start learning the basics.

Everything can be confusing and frustrating when you're doing it for the first time. But once you start breaking down the individual pieces and understanding how they work together, things slowly begin to make sense.

And eventually, it becomes easy peasy.

What came before​

Regardless of which programming language you're trying to learn, you'll notice that many of them share similar ideas.

Programming languages are usually created to solve certain problems, introduce new ways of doing things, or improve on limitations found in languages that came before them.

Because of that, newer languages often borrow concepts, techniques, and even syntax from older languages.

They won't all work exactly the same way, of course, but once you've learned the fundamentals of one language, you'll probably recognize a lot of familiar concepts when you move on to another.

So I guess you could say that programming languages speak differently, but many of them think in similar ways.

At their core​

As I've mentioned, many programming languages share the same basic concepts. The main difference is often how those concepts are written or implemented.

Here are some of the things you'll encounter almost everywhere.

• Syntax

  Remember that every language has its own rules.

  These rules might be influenced by earlier languages, but each language will still have its own way of writing instructions.

  

  When you first read the title of this post, you might have had this tiny feeling that something was a little off about how it was written.

  If you did, then congratulations. You already understand the basic idea of syntax.

  Syntax is basically the set of rules that tells you how something should be written.

  Now, programming is indeed easy, isn't it? 😄

• Variables

  The main idea behind variables is associating a value with a name.

  Think of a variable as a labeled container where you can store information and use it later.

  These values can be changed, passed around, compared, calculated, printed, and used throughout your program.

  For example, instead of repeatedly writing a person's age as 25, you could assign that value to a variable called age.

  From that point on, your program can simply refer to age whenever it needs that value.

  

• Printing

  Printing is basically telling your program to display something as output.

  This could be the result of a calculation, the value stored in a variable, a message, or pretty much anything you want the user or programmer to see.

  You might hear programmers say something like:

  "The code returned this value."

  What they usually mean is that after the program processed its instructions, it produced some sort of result.

  But programs don't always display those results automatically.

  Sometimes the calculation is happening quietly in the background, and if you want to see the result, you need to explicitly tell the program to print or display it.

  You've probably already seen a glimpse of this in the example for variables above.

  

• Comments

  Comments are notes that programmers leave inside their code.

  Their purpose is to explain what a certain section does, why something was written in a particular way, what a variable represents, or anything else that might be useful to someone reading the code later.

  And yes, that someone could very well be you six months from now wondering:

  "Why the hell did I write this?"

  Comments aren't processed as instructions by the program.

  Different programming languages have different ways of marking comments.

  In Python, for example, you can put a # at the beginning of a line to tell Python that the line is a comment and should not be executed.

  

• Strings

  Earlier, we talked about comments and how Python recognizes a line beginning with # as something that shouldn't be executed.

  But what if you actually want your program to work with words or sentences?

  That's where strings come in.

  A string is basically text stored as data.

  

  When you assign text to a variable, you'll normally wrap it in quotation marks so the programming language knows that it's dealing with text rather than another instruction.

  You can also combine strings with other values through formatting.

  For example, if you have a variable containing someone's name, you can insert that value into a sentence rather than writing the name manually every time.

• Arrays

  An array is basically a collection of values grouped together.

  Instead of creating a separate variable for every single piece of information, you can store several related values in one collection.

  Depending on the programming language, collections like these can contain numbers, strings, objects, or even other collections.

  Python, for example, commonly uses something called a list for this purpose.

  

  Another important thing to understand is that values inside these collections have positions.

  So if you only want one particular value, you don't necessarily have to retrieve everything. You can refer to its position, usually through something called an index.

  For example, if you have a list containing five names and you only need the first one, you can access that specific item directly.

  And here's one thing that might feel strange at first:

  In many programming languages, counting starts at 0 instead of 1.

  Welcome to programming.

Wait, there's more​

At this point, hopefully you have a better idea of why I say programming is relatively easy.

A lot of people focus immediately on the question:

Which programming language should I learn first?

And that's perfectly fine.

But I think what's more important is understanding the concepts that programming languages have in common.

Once you understand ideas like variables, syntax, strings, collections, conditions, loops, and functions, moving between languages becomes much less intimidating.

The syntax might change.

The keywords might change.

But the general ideas are often still there.

If you'd like to learn more about some of the things you can explore before diving fully into programming, you can check out Evan Kimbrell's Udemy course, Pre-Programming: Everything you need to know before you code.

You can absolutely jump straight into whatever programming language you're interested in.

But if you're someone who's non-technical and you've only recently developed an interest in programming, I think learning some of these basic ideas first can make the whole thing feel a lot less overwhelming.

Because programming itself isn't really the scary part.

The difficult part is usually figuring out what you want the computer to do and breaking that problem down into instructions it can understand.

Once you get used to doing that, the code starts making a lot more sense.

As always, happy learning!