During the courses, I learned all three paradigms in Python3, even though it is not that well suited for functional programming. If you'd like to learn functional programming in a nice environment, I would suggest Elixir, and if you'd like to learn a "purer" functional language (and inflict some emotional damage), you can always try Haskell.

Imperative

I'll explain as simply as possible how I understand imperative programming. To be honest, the course goes through a subset of imperative programming in the form of procedural programming, but they both satisfy these conditions:

• Use statements that change the program's state.

• The developer describes how the program should execute with code.

One of the most popular imperative paradigms is procedural. Procedural code follows a recipe-like flow and is popular for algorithmic programming. Hence, it is used a lot for machine learning applications (this is why Python and R are used in machine learning).

Object Oriented

The object-oriented paradigm works well in combination with other paradigms like imperative, procedural, and functional. I'm not sure if a pure object-oriented language exists since the imperative paradigm is almost required for object-oriented to work. Here are a couple of important aspects of the object-oriented paradigm:

• Objects consist of data (in the form of attributes) and code (in the form of methods/procedures). Objects interact with each other and can inherit behavior from each other.

• Side effects are built into the core design of objects.

• Many/most of the widely used languages today support object-oriented paradigms (Python, Java, C#, C++, TypeScript).

Functional

With its design firmly rooted in academia, functional programming has a special place for anyone with a mathematical background. This is the only declarative paradigm we are looking at here. It focuses more on describing the logic of the end result rather than defining the program step by step as in imperative programming. Functional paradigms have these attributes:

• Functions are first-class citizens (meaning they can be combined, passed around as arguments, and returned from other functions).

• Functions minimize or eliminate side effects.

• Focuses on composing smaller functions together to achieve complex data manipulation, which makes it very testable.

Conclusion

There really is no paradigm that can solve all your problems, which is why most languages are multi-paradigm. This should be a good indication that there is no one paradigm that can solve all your problems (well, technically you can, but only if you want more stress). Hopefully, this gives a nice overview with follow-up articles showing what kind of problems we can solve with these paradigms.

It's fun coding in Python

I hadn't touched Python code for about 7 years. The last serious Python code I wrote was in university while taking some algorithms courses. Even then, I never really wrote Object-Oriented Python code. It was mostly focused on imperative and some functional Python code, mainly smaller programs implementing specific algorithms. Suffice it to say, I've never used Python for any full solutions, and so far I'm enjoying seeing what it's capable of. I'm excited to build out a full backend. But before I get there, I took some fundamental courses in Git and the command line where I picked up some new learnings.

Command line tricks

Learning a couple of shortcuts for the command line has been the most rewarding part of the start of the course. From the start of my career, I've probably not spent enough time learning the intricacies of the command line. Mostly, I know enough to be dangerous and to write scripts that can automate repetitive tasks. A lot of command line functions have also been taken over by IDEs like Visual Studio Code, causing you to never really leave the IDE. Of course, working more in the operations space has forced me to learn more about multiple sets of command lines (none of them in great depth). Here are some things I learned during the course.

• A lot of the core shell programs are written to be very functional in a specific thing. Meaning that you can learn programs like grep, find, curl, head, and tail really well.

• Learn your own package manager well. On top of this, it is good to know apt as you will encounter it at some point.

• Command line tools are fast because they don't use a Graphical User Interface. You should leverage this when you can.

• You can spend your whole life configuring your perfect dotfiles, but most likely someone has a pretty good one you can use already.

• Shortcuts and aliases are nice, but be sure you know how to use the base tools. You won't always be using your own computer.

Gitting into it

I've used git since the start of my second job. At the beginning, I felt like I learned enough to be competent and understand the core concepts of git. Today, I have a working knowledge and know the core features and how it interacts with GitHub fairly well. I was surprised to learn some new things in the course nonetheless.

First, the course went into the details of the file structure in the .git folder and, more particularly, how git solves the issues of changes and multiple branches. In its design, git doesn't cater to large monorepos, which is why Facebook doesn't use it.

Second, I learned about the introduction of a safer command to switch between branches. I've always had to teach junior developers the pitfalls of using the checkout command and how it can do more than just switch branches. I won't go too much into the differences between switch and checkout because this article already does a good job. While checkout is not deprecated yet and switch is an experimental command, I'll enjoy using switch for now knowing that it does exactly what it says.

What's next?

Next, I'll be diving into two core programming paradigms that I've reviewed recently. While I'm familiar with both Object-Oriented and functional programming from before, it's good to review that knowledge and make sure that I can still program effectively in both paradigms.

But why?

I've been working as a software professional since early 2016, starting first as a software developer and transitioning to DevOps/Platform officially in 2020. I did so mainly because I realized I care more about developer experience than user experience. In doing this, I moved away from development completely and have started to miss that side of the process. So mainly, I want to do this for fun and to learn more about backend development specifically. Not only because it's fun, but also because it will help me become a more well-rounded software professional.

How?

This seems like the easiest part to get to but has been painful to start. I found that the sheer number of courses available makes it difficult to choose which path to take. The first one that has consistently worked for me has been boot.dev. I think this comes down to the motivations of the people who started boot.dev. I've found that the content is really engaging and challenging enough for beginners as well as experienced developers. Hence, I'm looking forward to doing more courses and learning things in more depth. On top of this, I'll be looking into completing 1-2 longer-term projects that I have been wanting to do to supplement other learning goals.

Starting off, I'm not following any specific study plan or allocating a set amount of time per week to any topic or course. When I have some free time, I will work on it as long as I can. For this, boot.dev has already been a good choice with small chunks that can be completed in about 10 minutes. Outside of the main courses, I will dedicate some time to YouTube videos and general documentation reviews. I'm relying on these articles to keep me accountable and maintain steady progress. What has worked well at the start is picking up some tasks when I find myself feeling bored outside of work hours. In short, I'm trying to keep it casual.

What's next?

I'm documenting the process. It might take 1-2 years in total, but I'm hoping to complete the core boot.dev courses within 12 months. By documenting this journey, I aim to reflect on what works for me and learn more. Maybe I can even help others find processes that work for them too. With the added bonus of sharpening up my writing skills. Any thoughts, constructive criticism, or requests for more details are most welcome.