Forem: John Walter Munene Njeru

From JavaScript to React: Building Real Projects with The Odin Project

John Walter Munene Njeru — Sat, 04 Apr 2026 05:50:39 +0000

Originally published at Medium.

From JavaScript to React, I share how building real projects with The Odin Project helped me grow from learner to confident React developer.

I’ve recently finished The React Course at The Odin Project and I wanted to step back, reflect on my experience and progress in web development. When I started The Odin project, I had prior basic programming skills from my Electrical and Electronics Engineering classes with little to show of it for I couldn’t build anything working let alone the thoughts of production. Now that I have been hacking my way into programming through The Odin Project, I wanted to inform anyone about what they can expect and how my journey has been uniquely rewarding.

When I first finished the JavaScript course, I wrote a title named “From Beginner to Builder: My Journey Learning JavaScript with The Odin Project”, which has brought me many visitors and a small community here on Medium. I’m thankful to everyone who has been following me since, so this will be a follow up of my progress since then. While this article won’t cover all of my explicit challenges and “aha” moments, it should help you have a holistic overview of what a structured progression from writing JavaScript to React feels like. Let’s dive in!

Looking Back: From JavaScript to React

When I started to learn programming on a serious level, I only wanted to get how things work, and not feel left out in conversation about software development, although writing in the space was my main goal. I had a year’s toil understanding how JavaScript works under the hood, as in the syntax and the browser operation model (well explained if you have read about the journey in the linked article).

I had built a few applications using Vanilla JavaScript and was starting to feel proud of my progress as a programmer. Even though I hadn’t built any fancy or modern websites, I had a comprehensive suite under my belt. In the JavaScript course, I had built a few projects such as a Weather app, a battleship game, and even played around with some basic data structures and algorithms. The Battleship game was the ultimate project and with it, I had tinkered with Test Driven Development but I had no idea on how to test my UI, apart form running it myself with lost of hassle on the context of debugging, console log statements being the savior.

On finishing the Project I wanted to continue this learning so I didn’t halt at that checkpoint. Rather I extended my efforts and started learning ReactJS, the most popular library for building user interfaces to take my frontend skills to a whole new level.

Why React Felt Different

At first, React felt like I was fighting programming. This isn’t because of learning a new syntax for writing HTML and JavaScript in a single file is hard to grasp, but because it’s a complete shift into a new programming paradigm. My adventure began with an introduction to React, setting up a React environment, writing JSX, rendering techniques, the concept of keys in React and passing data between components. I the proceeded to state in programming, and then did a deep dive into it on the scope of managing it and adding interactivity.

The lessons on Odin give a good introduction on all of the above topics. Instead of just reading through the lessons, I went ahead to read through all of the linked resources into the React documentation. When I got to the CV application project, the first one in the curriculum, I had spent so much time reading all about state management, and my mentals on writing JSX and the preceding topics had sort of faded into the winds and so I redid the intro lessons once more, this time with a clean focus on the basics as I had done a deep dive. This was meant to bring step back and bring things into perspective as I was well equipped with what is down the state management rabbit hole.

To mention of a few things about state, your application could take any shape, and based on how you want the product to behave, and thus interactions are the ones dictating what shape your state takes. Note that this doesn’t come automatically as you’ll need to have spent some time with React to internalize the building model, and you’ll also need to understand the least changing data in your application as it goes without saying, it’s what gets tucked into state. Since, I struggled a lot in my first days, I kept close kin, the title “Thinking in React” which is a detailed guide on how to solve problems in React. This was an article I read many times whenever I was stuck or needed to touch an application I was writing. In this case it was my CV application.

Thinking in Components: The Shift That Changed Everything

After finishing my CV application, I went further to delve deeply into dealing with side effects in React, a way to synchronize your application (DOM) with external activities or procedures. Similar to the state bits, this was another interestingly deep rabbit hole with much to learn that in the end the documentation cautions on when to use state to handle interactions, the appropriate way to use effects, and a note of side effect events, and when to opt for either based on your needs. Things were a bit confusing but on taking note that they side effects are a way of React applications to interact with the outside world I was good to go. In fact, the best lesson learned on this was that I should explicitly separate application specific events in terms of user interaction in contrast with system specific events.

I wrapped up my effects lessons with a nice memory card project which too, in my development was influenced so much by the Thinking in React guidelines. It was not until I a completion of this project that I felt the state and effects click. By the end of this project, I had developed a good intuition on what a good effect looked like, and while at it I had made the use of the Giphy API SDKs, and had my state well structured. Being my second project and seeing it come to life filled me with much joy looking back that when I started programming, I really struggled with writing loops.

When I had a working model of the memory card game, I refactored my methods to move them from child elements to a parent to reduce the recreation for methods on every item. While this isn’t a worry for small applications, knowing when something should be defined in the parent rather than the child was something important that I learned. This is a concept that goes hand in hand with the worry about where state should live in your application. I had my friend Sam check my solutions for this project and he signaled that I was progressing relatively well. In the light of looking at lessons learned, this project helped me learn about managing state while working on a real game project. My first CV project was ugly, but my memory card game was better, both in terms of code and final output. Nevertheless, I had working applications.

Completing this project and seeing work came with a rejuvenation and the urge to proceed forward to learn more about React. Next-in-line was class-based components. While these are relatively used in older code bases, they helped give a different understanding of side effects and how to reason about them. This section was also about explicit handling of effects using classes and through a slightly different syntax even though the end results are the same. From the development learning point of view, these were meant to equip on handling older code bases suppose you met one along the programming journey.

So far, I was getting deep into the React ecosystem but I hadn’t felt like I was doing much. I had a simple flow of walkthrough through type checking with prototypes for better development, and to have an explicit alert when a function didn’t use the correct props. All this changed when I started using the React router and there were suddenly some extra things to pick on like defining routes, using outlets, exporting routes in their files, and organizing the code around routers.

While these weren’t really hard, they braced me to get further and I was now working on how to test React applications. Well, here came an interesting challenge where testing in React is slightly different from writing Jest logic tests yet the mental model around the testing of the syntax remained the same. Snapshot tests were now a new way to test modern codebases but the though of getting false positives and negatives had me steering away towards writing actual tests that asserted what I aimed out of the application.

The Odin Project had shallow details in regards to testing, and so I decided to supplement my knowledge on testing by looking at the React Testing lessons from Full stack Open. I finally got a solid idea and was now ready to work on my final React project, a working shopping cart, a project that challenged me the most but also stitched everything into context around how React works. I also ended up looking at styling React application methods and opted to use CSS modules on moving forward. I didn’t want to use Tailwind as Odin warns on early adoption of frameworks without solid and comprehensive knowledge of CSS. Other options like CSS-IN-JS looked appealing but I’m a lover of clean syntax, and so modules were my final choice, a step better than vanilla itself, with little or no difference from it, only by scoping as the new rule.

Shopping Cart: The Project That Stretched Me the Most

I had now been somehow deep into React and this project came at an appropriate time that I had to step back and put everything I had learned into practice. Because The Odin Project has a very good encouragement on taking final projects on a course seriously, I resolved to work on something worthwhile in terms of what my code and output would look like. Odin has well described steps or approaching a project and this was no different. The only exception was, I have to architecture my whole application from scratch making all the design decisions.

This time, I did not need to look at the Thinking in React as I had acquired my own ways of approaching applications. While the docs will talk about the top to bottom and bottom to top ways of building react applications, I have come to conclude that the best way is a dual mode where you think of the top as pages, but then fall back to the bottom and build gradually to the top. There’s now straight separation of the two. Instead, it’s a back and forth.

As usual, I adopted my application into three static pages, the home page, the shop page and the cart pages. I started by populating my home page, ensuring my shop page handles the errors, and loading states, correctly, move forward to the population with cards and thus wrote some effects, and then I proceeded to the cart page. Worthy of note is that the development of these pages came after writing my navigation bar which I had to refactor when writing shop and cart pages to include some extra information while at them.

An important thing to mention is that while working on these pages, you are also forced to think about the minimalistic changing data in the application (which is the state) and where to put it. I was forced to think about using outlets to render my home and carts but straight out realized that it’d be a bad practice if I’m handling conditional rendering in routes in the absence of things like authentication. I opted to define my state in the App.jsx component as well as the routes, passing state down and it’s updaters to the correct components. That way my application’s pages could be tested in isolation, and if in any case, when each page updated it’s parent state correctly, the other pages wouldn’t have to worry about them only consuming the updated state.

While working on the specifics of my shop and cart pages, I tried implementing methods both on children and parent components so that I could have a look at how each programming pattern would have an effect on how I’d approach my tests. On getting my tests to pass for all my components, and testing the UI with a skeleton on running build, I was sure that minimally my application was working and all I needed was to style it. Using CSS modules was really easy to style my app as there were no worries about conflicting rules even if there was a need to have clear layout defined at the component level. I this app I leverage the composition programming pattern, which I wasn’t aware of, yet it still adapted naturally to my coding style. This project really frustrated me.

Debugging, Deployment, and Testing Frustrations

Even if no one says it out, I found it tough to debug tests and to get them pass. Note that unlikt in jest where we assert logic, here we are actually testing the behavior of the UI by waiting for actions to be called and then testing the DOM changes for expectations. It’s not that testing is difficult, but there’s a learning curve to have your tests passing correctly. Again, some lessons aren’t taught during tutorials but can only be felt on hands on experience. I’ll give an example for context.

If you opt to write tests using query selectors for classes, it’s easy to get them working real quick. The only problem is that when you switch to using CSS modules, the class names are hashed and now unavailable in the tests. This means that some time had to be spent refactoring my project to pick elements using the right queries and some weird quirks had to be resolved. For example, the testing documentation doesn’t outrightly state that async operations using ‘forEach’ are a bit tricky and do not await callbacks forcing tests to fail. Instead, I had to use the ‘for…of’ or the regular ‘for’, or while loops for sequential operations. Again, if you have utility functions in your components, they’ll need to be called inside the tests to ensure congruence in results.

Another thing that I couldn’t fix was the fact that when I installed my router, the linter rules were now changed the propTypes stopped working. When I was writing tests for my router, to check that navigation clicks worked, I was forced to install a slightly different package and work with it — as in react-router for the app, and react-router-dom for testing with the React Testing Library. Again it is also worthy of note that testing the application had nearly an equal amount of code to that of the application itself.

Getting tests to pass was one thing, and now that my application was styled and working, the final bit was deployment. I chose to work with Vercel but had lots of trouble for some inconsistent naming of exports and imports. In this case, React is forgiving that when you run “npm run dev” it works well on local host but won’t build on pulling my repo to Vercel. To fix this, I read the Vercel docs that guided on making local builds (like with webpack) run is the right step to getting the application run and deploy of vercel. I struggled my way out by cleaning up the application naming, using some simple bash scripts to automate the figuring out of which parts differ. When my build worked, I run my tests once more before using Vercel deployment commands locally. In this case the command line was really a close tool to work with. I’ve finally deployed my shopping cart (no media queries as of this writing), and here is the source code. Here’s the look of the cart page.

What The Odin Project Gets Right About Learning React

Just like I said in my other article about how The Odin Project teaching how to program by equipping you with the necessary skills to tackle any problem, this has still been the format. I’m in love with the teaching method where you take on some lessons before projects and that they are well structured in incrementally increase the load. The only truth I have realized if you read through all the lessons and grasp all what is required no project will be impossible. The projects aren’t simple, but they are doable based on preceding knowledge.

If you’re still wondering if it’s the best way to learn React, then you’re at the right place. One, the learning is structured and self-paced so you don’t have any pressure, and you move at your own pace on the expectations that you’re self-aware of your learning goals. Second, The Odin Project teaches through following many unique tutorials, and finally combining them with a project so you can build with confidence. Nothing beats project exposure. Learning through tutorials feels productive as you are making steps, but working on a project tests all the learned concepts in a single sling that you have to make use of everything to create a working web application.

The final thing to keep in mind is that learning by documentation feels slow and deep but the benefits are crystal clear. The docs give in-depth guides around a topic and text is easily updated with the rolling out of new features, both in React and the JavaScript or Browser updates which are not easy to adapt into content if you’re on videos. This is not trashing videos as a way to learn but I have found videos more resourceful when taken to explore different examples and as a supplement to documentation. Would I still recommend Odin, a triple yes as usual. Give it a shot!

Lessons I Didn’t Expect to Learn

There are many lessons that I’ve picked up along the way like how programming is easy with React and how it gets you building projects faster and in an easy way. So far, I’d recommend learning React topics in this order: JSX, Rendering Techniques, Keys in React, Passing Data Between Components, state, side effects, class-based components, component life cycle methods, testing (spend some extra time on this one), react router, type checking, fetching data, and styling applications. With a good grasp of these, you can build nearly any project provided that you use each tool for what it’s meant for.

Again, React does a good job at testing your fundamentals of JavaScript. Had my understanding of JavaScript been shallow, I wouldn’t have made it through this course. I have also learned that getting a working project teaches more than any independent lesson in isolation. Where each tutorial is meant to hold your hand through solving a particular problem, a project forces you think about the whole application in terms of expected output, how you make your architecture suite the application and translating your thoughts into working code. Many people will tell you once you get the sytax you’ll be good to go but learning how to solve problems is equally important. And this, if I must stress on harder, can’t be taught by following blindly following tutorials, but rather by intentional learning.

In addition, a lot of resilience is needed to get through this course. I have also realized that I do not need lots of hand holding and I’m naturally knowing when to reach out for specific tools, and where to find them. My own code solutions for React were really ugly but they have also really improved by the third project and I can’t really wait to know what lies ahead of where I am at. A lot of research is also needed to make working solutions as there’s nearly a solution for every specific problem in JavaScript, but knowing how to stitch them to work together and correctly is the real labor around programming.

What’s Next in My Developer Journey

I’m writing this as I close the first phase of my development journey now that I can say at least the frontend is covered. Looking forward, I’m at a point where I can start reading about design patterns and architecture, and I’m now going to be confidently matching into backend development. I will only proceed further by learning better programming patterns on frontend development as I simultaneously hack my way into the backend.

My take is that it has not been easy but it has been a suitable and challenging journey with lots of learning and humility needed. When I shared my final project to a working full-stack developer for review, I’ve received lots of positive criticism that will force me to go back to my project and to make improvements. I can’t help but admit that following the comments I received, I have moved from wondering how to make it work to how best should this look and work alike. This means that we are talking of designs in the UI/UX and how they can be improved unlike how do I center a div or write my first program.

Not only has the journey been a little faster when I compare it to what it took to complete the JavaScript course. By the numbers React has taken me six months to have it flowing while JavaScript took me a whole year. This is by far the biggest indicator that I’m learning and my pace is taking quicker revolutions in terms of speed. I’m still on the path to becoming a full-stack developer and so I will be proceeding to Databases, and finally the Node.js course. I had started learning API documentation and I pause this to embark on it once I build my first API so this is something I’m hopeful I can do in the coming months.

That said, I happy to progress and call myself a frontend developer with hope that in due time, I will be a full stack developer writing about JavaScript while getting paid to learn in a role or at least building my own projects that actually translate to a better bank account. Till, then, I’ll keep Reacting to it in JavaScript, and hope to Node it down as well. If you’d like to chat me more or even offer an opportunity, I’m available on all social platforms.

Please send me an email, shoot me a DM on X (formerly Twitter), or even review my code on GitHub. Better still, if you’d like to collaborate, my LinkedIn is open to new networks. Cheers and happy coding! See you in the next article.

Originally published at Medium.

From Beginner to Builder: My Journey Learning JavaScript with The Odin Project

John Walter Munene Njeru — Sun, 30 Mar 2025 04:36:22 +0000

Originally published at Medium.

From beginner to JavaScript developer: My journey with The Odin Project, real-world projects, challenges, and key lessons learned.

I started my journey of becoming a programmer a few years back. This is my second time running into The Odin Project. But it was not my first attempt at becoming a programmer. When I was on campus, I couldn’t write loops in C and got supplementary in the second semester of my first year. I even lost hope when two of my laptops were stolen, each at its own time. As I write this article, thanks to The Odin Project, I’m happy to be active in the JavaScript developer community. I’m learning JavaScript to work on my dream projects and hopefully land a role in the top software development companies (Microsoft, Spotify, Pieces for Developers, and others…). I’ll talk about my projects in a future post.

Why did I choose The Odin Project?

When I started to learn programming, I read the book Python Crash Course by Eric Matthes and built a few projects, including Alien Invasion. Things couldn't add up When I started working with the Django framework. Not that I wasn’t familiar with the syntax, but I couldn’t solve problems. At the same time, I was doing the Odin project after being recommended to it by a stranger on LinkedIn. This was in the late months of 2022 and early 2023. After finishing the Python Crash Course, I started Intro to Python for Computer Science and Data Science. While halfway on it and stuck at the restaurant project, I realized I had learned a lot but couldn’t build meaningful things. So, in August 2023, I resolved to redo The Odin Project with lots of seriousness. I had admired its teaching style.

Learning the Fundamentals

My learning began with the core concepts: variables, arithmetic(s), data types, string methods, loops, functions, comparisons, objects, array methods, regular expressions, and understanding errors. In the introduction stages, you feel like there’s much to learn even before you can build anything meaningful. Of course, the above concepts come after a strong introduction that puts you in the right mindset and a solid foundation in HTML and CSS concepts.

In the closure of the foundation lessons, I learned about the art of writing clean code and problem-solving tactics. Down the rabbit hole further, I went and tackled the Intermediate HTML and CSS course, learned about advanced selectors, CSS Functions, CSS units, text styles, form validation, the Grid, Emmet, tables, positioning, return values, and more CSS properties. By the end of the course, I had built a fantastic dashboard using Gid!

I got into the JavaScript course. Wow, all is going nice and well. There was a warning about how we would slow down and take the understanding of foundation lessons to a deeper level. But I didn’t think it would be that heated… We started with how to organize JavaScript code, and I’m terrible at it! Proceeded to objects and object constructors, where leveraging all the preceding knowledge on DOM and other topics would be applied to build a little library project. Next was factory functions and the module pattern, after which I’d create a Tic Tac Toe game. I then learned about classes, refactored my library project to use classes, and committed my changes to GitHub, demonstrating branches in version control systems.

After learning about npm and Webpack, I comfortably redid the restaurant project this time. Here’s a link to the repo, where I deployed it from, and a live preview. Only after revisiting Webpack, playing with JSON, and learning object-oriented programming principles I worked on a real-world project, a ToDo List application.

Building Real-World Projects

The ToDo List project was one of the most hands-on projects I ever did. I’m happy because this is a project I can continuously iterate on, and the biggest benefit it had for me was that it challenged my problem-solving skills. Even though I didn’t work on an attractive UI, I was more concerned with the architecture of the workflow and making things work. I also had the chance to interact with browser APIs like local storage and cache (while doing my freelance writing gigs) in this project.

Fast forward, I’m learning about linting; dynamic user interfaces where I made dropdowns and image carousels, and form validation with JavaScript as recommended by the Web Accessibility guidelines (make sure to read about them later). I learned about ES6 Modules, writing asynchronous code using promises, working with APIs, and the async/await pattern. I’d then build a weather application to showcase my newly acquired skills.

It was now a chance to get started with computer science topics; that’s where things would get tough to pull through, but it was worth all the toil. I started my exploration with recursion. I have to be honest; I had to reread the available resources so many times before I could bring it all together with a project on recursive programming. Moving forward, I read about time and space complexity, which weren’t easy to grasp, not knowing that data structures and algorithms were quite ahead and ready to strike.

Cranking up my skills, I did a project about linked lists. I played with the HashMap data structure to eventually build a dynamic one that uses linked lists to handle collisions as an extra way to store data beyond growing the HashMap. Then, I’d later build binary search trees, where I had a better feel for recursive programming, and close up with a chess game project, Knight Travails, which I enjoyed, and came up with two solutions. Next in line was a deeper look at git, working with remotes and using git in the real world. I had lots of fun playing with Git, and how I think of Git as a large recursive software—I even had thoughts of building a simple version of it for fun.

At the end of the course, I did unit tests as part of test-driven development (TDD) using Jest. I closed off with the Battleships project, where I did the project using TDD. I have learned the core principles of JavaScript, understand why things work the way they do in the browser, and am ready to venture further in my path to becoming a full-stack software developer. So, what key lessons did I learn?

Key Lessons Learned

I cannot stress that learning the fundamentals and being patient while at it has been the core reason for where I am and how I am moving. At first, it didn't feel easy, but things have started feeling a little more natural as I continue to write more applications, see this slot machine I’m building. Among the key concepts I have discovered to be crucial are closures, promises, “this” in object-oriented programming, writing clean code, error handling, and debugging.

I have also learned that project-based learning solidifies your understanding of programming. Through projects, you use your freedom and knowledge about the tools you have learned and how creative and appropriate you should use them to build meaningful software. Here at The Odin Project, this is the route that I have followed (in a very supportive community), and I have been able to build problem-solving skills.

In my perspective, the part that makes you a programmer isn’t knowing the syntax but how well you understand the rules to build functional systems. This means using the right tools for the right task, which requires understanding what was created and why and, more so, how it should help you solve your problems.

Besides, you must also be good at research and open to reading other people’s code in StackOverflow. I was very impressed when I used maps and sets in my Knight travails while I only learned a little about them. I have also learned to break down a large problem into small pieces that work together as a unit when stitched together. Debugging skills are also another rock I have sedimented along the way. All in all, the most important skill I have picked is resilience, as this course has taken me nearly a whole year to complete. I’m happy about all the efforts put into bringing together such a helpful resource. Next are my thoughts about The Odin Project.

Reviewing The Odin Project

Many programming resources out there will get straight into teaching you all the syntax out there. And while you realize it, you’ll have lots of it stacked up in your mind, but with very poor problem-solving skills, if you’re lucky to acquire any. The Odin Project takes a strategic approach to teaching programming. First, the curriculum is self-paced, and you’re your only watcher. In my introduction, I started with a brush-up on how computers operate, how the web works, and how learning programming gives you an edge in leveraging technology. Second, the project ensures you build a strong mindset that will push you through from the beginning to the end. You’re probably wondering what worked so well for me…

If you head straight to any lesson in The Odin Project, it consists of lessons written by a large community of developers (experts and others learning like myself). In each lesson, you’ll have an overview of what topics you’re learning and their importance before diving into the technical stuff. Once you read through a lesson in Odin, there’s a section on assignments where you’re tasked with an exercise, linked to other resourceful articles, directed to video explanations, enticed with inspiration threads On X (formally Twitter), or a combination of all the aforementioned.

You’ve probably heard that software development is a beautiful mess. This can be attributed to the challenges you’ll face along the way. You’ll probably encounter difficult concepts or complicated bugs that won’t be easy to fix along the way, perhaps because you haven’t picked up all the skills needed to be good at them. In this case, The Odin Project has a vibrant community on Discord where you can ask questions, link your project repos for quick assistance, and even get tips on approaching a problem. Also, Odin does an excellent job teaching you where to find answers to whatever hurdles you encounter. Additionally, there are tons of projects from other learners to look at after completing your projects to expand your scope on how a single problem can be solved in many ways.

To touch on the areas that could be improved, I’d suggest that the maintainers make some additional efforts (if they see fit) to enhance the learning of topics like Webpack, writing asynchronous code, and recursion. As I say, we can’t rule out that these topics are probably a little challenging if you’re starting a programming journey, and the learning curve is always steep in knowledge acquisition no matter the domain you’re working on. Else, I was probably the one who struggled to put things together with them. All the same, there are plenty of projects ahead for you to work on, and that allows you to leverage these topics enough to become a guru at them. It doesn’t mean I’m the very best at them.

Would I recommend The Odin Project to others? Yes, yes, and time and again, it’s yes. On keenly walking through this curriculum, I have gained significant knowledge so far that I can probably build any UI that a designer hands me. I always wondered how my classmates wired up these pieces to make applications that I admired, and now, I can see myself building my future projects in the coming months. All projects you take on here will leverage all the preceding topics, with the chance to go ahead if you need to get something working. I’d crown The Odin Project as a number one resource for anybody seeking to learn how to write code. In fact, the knowledge about technology I have learned so far exceeds, and by far, all that I got out of an electrical and electronics degree on campus. If you have time, please give it a shot, and let me know how it goes!

What’s Next?

As of this writing, I just completed my JavaScript course yesterday and have a long learning path ahead. Well, I have to say that my GitHub profile is taking a nice shape with each new project I take on (so are my skills), and I also have a private repo that is my note-taking system since you only learn better by practice. I will continue with the curriculum now that I see the fruits of my efforts. As someone who started writing before programming, I can now write about more technical topics like APIs, security, and more. I always wanted to write content for software engineers (I’ve done it with so much research put in), and now things feel more intuitive as I have issues with learning complex topics.

In my heart lies my undying will to become a great software engineer and technical writer. Once I’m done with The Odin Project, I plan to get hands-on with interesting and more challenging computation roles in Platform Engineering and blockchain technology. I’m also hopeful that by the end, I can land myself a role in a leading software development company where I can sharpen my skills further before I branch off to build my dream projects. I may also start building my dream projects as part of my portfolio to land roles in the companies I’d love to work at. Whatever comes my way first, I’m happy to embrace my journey. I also want to contribute to open-source projects. As a writer, I’ll also be well-equipped to get my hands dirty with interesting stuff like API and SDK documentation.

Bringing it All Together

This post reflects my growth as a programmer and is meant to give insights to anyone who wants to become a computer scientist like me and does not have or feels no need to spend money getting a degree on campus. In fact, I’d have opted to take on The Odin Project instead of getting a degree. Nevertheless, I appreciate all my experiences, which have led me to where I am today. Up to now, I have created a portfolio in technical writing, covering topics around software development, cybersecurity, and blockchain technology. I’ll continue to uncover the goldmine that lies underneath these areas. I thank The Odin Project for being such a wonderful programming daddy.

As I put the pen down, I’d like to invite you to walk with me on my programming journey. If you’re starting out and need my help, I’m happy to offer it, having received it from strangers in plenty. If you are way ahead of me in the software development and technical writing fields, I’d appreciate it if we could link up and see how you can help me get a little better at what I do. If you’re right where I am, let’s join hands and explore the goldmine together.

I’d be happy if you could review my GitHub and let me know what areas I should improve on. If you like what you see and would like to collaborate on a project, shoot me a DM on X (where I share daily learnings, ideas, and discoveries), or drop me an email. If you’d like to learn more about my past work in Tech, here’s my LinkedIn wall. To continue reading from me, follow me on Medium. I love to write about what I learn.

Originally published at Medium.