How I Learned to Code

I've been a software developer for over 8 years. I feel very confident and comfortable in Javascript ecosystems, especially ReactJS. But I've also worked in many more frameworks and languages, including Python, Ruby on Rails, C++, C#, PHP, WordPress, and straight up HTML and CSS. I've deployed and administrated servers using Heroku, Digital Ocean, and AWS. I've created and maintained loads of websites over the years.

However in many ways I feel I'm just scratching the surface. The more I learn about software, the more I learn there is to learn.

But today I want to press rewind and reflect on some of the things that helped me get to where I am today, and hopefully provide some useful tips if you're trying to get a job as a developer.

Chapter 1: Curiosity of a Kid

I've always loved tinkering and messing with computers. Growing up, I loved making computers do all sorts of things, like pranking my uncle so that fart noises played when minimizing a window, to creating a simple word-guessing game in Q-Basic, to programming Snake in Visual Basic, to coding a graphical Russian Roulette game on the TI-86 calculator.

I majored in computer science in Community College, where I mainly learned Object Oriented programming in Java.

Then, I switched my focus to study music. I'm a pianist, and music is still a strong passion of mine. But ultimately, I missed the thrill of making the computer respond to my whims.

My friend Ricardo bought a book on HTML and CSS and started learning how to do web development. I followed in a similar vein, and made my first god-awful website to showcase my music. I still have the original codebase, and it's... pretty bad.

Chapter 2: The Labs - early days

Eric, Ricardo, Chiedo (Founder), and Don - developers at Chiedo Labs

Having made my own website, I approached my friend who had just started his own web development business, and asked matter-of-factly, "what do I need to do to work for you?" He pointed me towards a load of YouTube tutorials on HTML, CSS, Javascript, JQuery, PHP, and WordPress. So I got to work learning.

While the YouTube videos were helpful, I wanted to digest the information a little better. So I started going through tutorials on CodeCademy, which I highly, highly recommend. It's such an awesome resource. On CodeCademy, I learned JavaScript and PHP mainly. The knowledge I gained was rudimentary and pretty basic, but it gave me enough to get hired and start working on actual websites using more than static HTML/CSS.

I felt I had a leg up, though, having had CS background, albeit a 2-year degree. But I had a strong grasp on basic data structures and all of the fundamentals of programming, such as variables, loops, conditionals, and functions. I simply learned how these same principles applied to web development.

My first projects were small jobs, like tweaking CSS on websites, slightly altering the order of items on a product catalogue, or changing website copy. Pretty basic stuff. I remember very clearly my first noob mistake of not making a CSS style specific enough, and inadvertendly messed up the styling on a different page on the website. OOPS.

I quickly learned some of the nuances of CSS like z-index and relative/absolute positioning, and the tenets of fluid responsive design, avoiding explicit widths, etc. I started to form opinions for how I liked to structure my CSS classes and file structure.

We developed custom WordPress themes, and this was my first foray into serious full-stack development. WordPress incorporated everything: front-end presentation, a database, a server/controller of sorts, scripting, HTTP endpoints, and my introduction to the painful/exciting world of AJAX. (AJAX was how you got things to update dynamically on a website without refreshing the page before the days of React and the virtual DOM).

I owe a lot of my webdev experience to WordPress, and the many headaches that ensued trying to troubleshoot and debug issues. Because it's a full-stack framework, a bug could be in the GUI content, or the PHP code itself, or one of the many plugins that inevitably accumulate in a WordPress website. As a result, I got really good at problem solving and developed an intuition for debugging. I learned how to decipher error messages and what terms to search for when Googling the problem. As painful as it was, debugging WordPress made me the developer I am today.

Chapter 3: Ahead of the Curve

Don and Ricardo hard at work (making dank memes, and some programming too)

As a small start-up, we were really nimble and trying to keep our thumb on the pulse of the tech industry to see where things were headed. We developed apps in lots of different frameworks, like Drupal, Flask, Django, and Ruby on Rails. We were always trying to find the sweet spot of a framework to develop in, and also finding excuses to try out that shiny new technology.

We landed on Ruby on Rails as a solid architecture for more complex and nuanced apps, where WordPress just didn't cut it anymore. I tried my hand at learning Ruby on Rails, but didn't get very far as I simply didn't care for the "magic" of the framework - how it abstracted functionality away from you.

But before too long, our founder discovered React, a new framework that boasted a Virtual DOM, unidirectional data flow, and the concept of components, and everything changed for me. React fit my brain like a glove, and I found my go-to presentation framework.

We got into React in the early days, when it was still in beta. We had to hand-roll everything ourselves using Webpack and Babel to transpile the code into usuable Javascript. Around the same time, ES6 also came out, and we felt we were living in the glory days of the web. Indeed we were. A lot of us went to the NationJS conference in 2015 and soaked in the new terminology - spread operators, destructuring, const and let, JSX, etc. We marvelled at the idea of EverythingJS, where the entire stack could be written using a single language for ease of cross-development for the entire team. This felt like a new frontier for the web.

Quickly we landed on our preferred stack: Ruby on Rails on the back end, and React on the front-end. This setup seemed to work really well. I learned about REST architecture and HTTP methods, and wrapped my brain around the nuances of Redux in order to manage my app's complex state. "Separation of concerns" became my mantra.

Chapter 4: Mistakes Were Made

Every software engineer that you talk to, at least any good one, should be able to tell you a mistake they made, or some design that, looking back, they would definitely have done differently.

Because of my success with React and how comfortable I was getting with the nuances of JavaScript, I pushed for my company to develop our own server-side framework using NodeJS. It was highly ambitious, but I had worked on several apps by that point and had a pretty good handle on the major components that needed to be implemented. Data models, controllers, JSON responses, error handling; those things couldn't be that hard, right? So we set off to build our own framework. We added user authentication, mailers, and PDF generation. We added ElasticSearch for fulltext fuzzy search. We added a CLI to help build out some of the burdensome boilerplate. We had documentation specifying how the app's filesystem was to be structured. Yes, it was an opinionated framework.

But it took so much damn time to build. And we were constantly working under a budget. And our clients expected deliverables within agreed-upon timelines. But the codebase was ours, and we could add new features to it as time passed. However, we were also laden with the technical debt of maintaining this monstrosity. The burden of that task fell on me, since I was the one who principally designed and coded the architecture. However, a codebase that only one person really understands is a surefire way to impede a team's productivity and sap its morale.

Looking back, a much better decision would have been to use an existing framework like Ruby on Rails, where the non-critical architectural decisions were already made. It might have been annoying (at least to me), but it would have greatly reduced the amount of work that we had to do. Models, controllers, error handling, mailers, authentication - all of that came (mostly) for free, out of the box.

Now, building that custom NodeJS framework is an experience that I wouldn't trade even if I had the chance. I learned so much about architecture and system design, as well as the horrors of circular dependencies, concepts and lessons learned that I use to this day. I even look back on those days of crunching into late hours of the night with a sort of fondness. Even if we were over-engineering our own solution, this was something that we were doing for ourselves. We had a young pride and foolish tenacity in those days. We got here, myself and my teammates, by teaching ourselves how to code. It was a long and arduous journey, full of pitfalls along the way (and lots of curse words), but that moment when things finally work is a thrill that never seems to lose its edge. It never gets old. The lightbulb moment, when you finally figure out a tough problem, when the tests finally pass, or the UI actually animates how you intend - these small wins are the things I live for, and why I wanted to become a software dev in the first place.

Chapter 5: Epilogue

Chiedo Labs - Obligatory Business Stock Photo

So that's how I learned to code, or more generally, how I learned to become a professional problem solver. It really was just taking one day and one problem at a time. After solving loads of difficult problems, you don't feel so afraid when a new one comes. You know from experience that with time, you'll figure this one out, too. Because that's how it always works. Either you'll come across a solution on Stack Overflow, or you'll check your premises, or you'll think of a way to bypass the problem entirely. But one way or another, you will be the badass dev who figures things out. This job keeps you sharp and nimble; it keeps you on your toes for sure.

My journey does not end here; I'm a lifelong learner and want to keep growing, especially in the area of game dev. But how about you? Are you interested in getting into software development? My advice would be to learn everywhere you can: YouTube tutorials, Codecademy, Scrimba, Egghead.io, Udemy, whatever you think you need to learn to code, do it. But even more important: apply it. Get a job where you can start applying these skills to real-life scenarios. I know the market is super saturated for junior developers. It's a tough, competitive environment. In the meantime, you can apply your skills by working on coding projects, and building up a portfolio of demos. Create a GitHub profile where you can show off your accomplishments. But lastly, foster a love for learning. Stay curious. Never lose the love for that thrill when your code makes the computer bow to your will. It feels like raw power, and it's a rush of adrenaline.

Go out there, and code the universe. Peace!