My Journey as a Software Developer

Part 0: Origin Story

I've been interested in programming since I was a pre-teenager. When I was 12, my family purchased a Gateway P60 (Pentium 60MHz) desktop system with 8MB RAM, 3.5" floppy disk drive, CD-ROM and a 14.4Kbps dialup. I tinkered endlessly with the available freeware and shareware on Windows 3.1, played The Neverhood from CD, read Microsoft Encarta articles, and explored command line MS-DOS to navigate the file system.

After playing a few games and exploring the web through AOL's free online trial, my curiosity piqued and I wanted to learn how all of this stuff worked.

This curiosity led me down countless rabbit holes, into endless challenges and combing the software topic bookshelves at local libraries. I became acquainted with BASIC, HTML (before CSS was a thing), C/C++, and some other older languages like Pascal and Fortran. JavaScript and PHP was recently created, and VBScript was a new contender.

While I segued away from programming in my late teens through mid-20s to explore other things such as art, design and music production, ultimately I circled back and pursued a career in software development.

Part I: Internal Growth

My first role in tech was ironically not as a software developer. My first title was "Junior Graphic Designer" in a small company of about 40 people. My first job there was to convert paper-printed curriculum into highly visual and engaging PDF designs for music and film school programs.

Within 6 years my role grew to "Lead Developer / Designer" and I eventually left the company after 8 years for a fullstack developer role elsewhere.

In order to grow internally at the first company and prepare to make an eventual jump for a more fulfilling role, I had to learn new things to increase my value.

I'll outline some key values and specific decisions which led to steady internal growth in my first position. These are steps which took me outside of my comfort zone and pushed my limit. I believe these steps are universal in nature and can be applied to many careers, but are especially relevant to software engineering.

1. Push Boundaries

All websites and applications, no matter how impressive, have something in common: people built them. People no different from you or me. People who worked hard, tried new things, and maybe had a bit of luck along the way.

Everything can be created.

"I can't build that" is not a valid excuse. There's an incredible amount of open source projects, tutorials, and blog posts at our disposal to learn from. Nothing is impossible to create, and breakthroughs happen every day. With time and dedication to learning, much can be accomplished.

If I limited myself to what I already knew, or what I'd already tried and had success with, I would not have grown at all. I had to push myself.

Personal Case Study: Pushing Boundaries

Early in my tenure with RRFC, I noticed an internal software development need. The company was relying on a 3rd-party start-up vendor for their learning management software to teach students online and in hybrid learning scenarios.

This software was a no-code solution. It ran smoothly, but having little control of it made me uncomfortable. I felt that the company and offerings to students could grow if we had the freedom and ability to expand our own platform, crafting it to fit our specific needs.

Some questions that ran through my mind as I realized this need:

What if the 3rd-party company went under? How would we quickly recover?
What if they suddenly became very popular and raised their prices?
What did they offer which we couldn't replicate in-house?
How can we add our own features needed to improve student experience and meet strict state licensing requirements?

The Action

I drafted up an email pitch to upper management. I outlined the opportunity I saw to expand the company's digital footprint and improve their offering using a new software which could be developed in-house. Something that they could own.

The email was well-received, and I was given the priviledge to spearhead this project! The work ended up spanning two years, and I was the sole developer and designer for the majority of the work. The company was so enamored with the project after its launch that they felt they could secure patents on the product and I was a part of helping them put together the patent application.

This was an opportunity to grow my development skills while providing new value. Important note: I did not know how I was going to build this! I only knew that it could be done.

This faith in myself and understanding that all technical things are possible with time and learning was the launchpad for the next phase of my career. This work became a milestone on my resume, but it took a lot of dedication.

2. Network

This may go without saying for many people, but it's still important enough to reiterate here. For my first few years as a developer (this might sound silly), I did not know there was an actual developer community out there!

I went to community college and made a few acquaintances, but most of us in class were flying solo. There were no real collaborative dev projects like you would find in the real world. This experience was not an accurate reflection of common software development, where team integration is a critical piece.

I stumbled on the developer community by accident.

There are a myriad of podcasts and highly-visible software developers out there; find your preferred technology and then search for relevant podcasts. There's a fit for everyone!

X (formerly Twitter) and LinkedIn can be an exceptional place to connect and interact with other professional developers - many of whom have worked on or created the very libraries and packages you use every day. Following people who have made significant contributions to technology is rewarding and very accessible.

Personal Case Study: Staying Informed

I stumbled across the syntax.fm Podcast and my life as a developer was changed. Listening to Wes Bos and Scott Tolinski discuss web development trends and technology really struck a chord with me — and it provided a productive way to pass time during a commute!

At this point in my career I was working mostly remote, however I had to commute to the city once a week to meet with the execs in the office. It was typically a 1 to 2-hour drive each way, and listening to the Syntax podcast during the drive not only made it bearable — it made it fun.

I'd listen to their interviews and guests, and noted names and different new technologies that I wanted to test out. I would start Googling and researching them as soon as I could open up my laptop at the office.

What made this podcast really cool? The hosts, although quite popular and deep in the trenches of cutting-edge web development, are really open with their social media presence! They're down to earth, easy to find online, and you can follow them on Twitter. This was like a peek into how top-tier software developers interact online.

Additional Suggestion: Listen to AudioBooks

I also capitalized on the commute time by listening to various audio books, some of which include:

These topics helped prepare me to advance within the company, and to navigate some challenging decisions and conversations.

3. Automate Yourself: Work Differently

I've come across the notion that some developers feel the need to keep themselves employed by overcomplicating their work. The thought is that if they make their work so overly complex, nobody else can take it over and their tenure with the company is guaranteed.

The truth is that there are countless developers out there who not only can take it over, but they will gladly do so. Over-complicating your work for job security only makes their onboarding a bit more challenging.

I've found the opposite effort to be true: automate yourself.

If you find opportunity to automate yourself out of a task, do it. Don't hang on to doing something just because it keeps you busy or it keeps the company dependent on you. There's more exciting work around the corner to focus on.

Personal Case Study: Self-Automation

At RRFC, there was a regular need to update a particular set of webpages for state compliance, or to update forms to track various promotions or lead-gen efforts.

These updates would span across several WordPress websites, and were a repetitive — but essential — task.

After performing a styling and content update task for the dozenth time, I realized there must be a better way to manage these updates.

The Solution: A Custom Plugin & API

I wrote a custom self-hosted WordPress plugin which could be activated within each site. This plugin would parse WordPress Shortcodes representing various data or components. This data or component would be served from a custom API endpoint — this allowed me to write code and content once, from one location, and share it across multiple websites.

The plugin was housed in a GitHub repository, and WordPress websites would fetch the plugin updates directly from GitHub — so updating the plugin was a breeze.

Each website would serve content served by a separate WordPress API in the style and functionality of the particular destination website, however the core data and content would be fetched from one universal location. Write once, share everywhere.

The initial setup for this process took a little bit of extra time to get off the ground, but once it was up and running it greatly freed up my time to allow me to focus on higher priority — and more fun — tasks.

Part II: Preparing to Jump

After several years within the same company, I realized I hit a ceiling for growth. There was nowhere to grow internally, and my compensation was not going to improve.

At this point, I realized I needed to make a jump. But how? I developed software alone. How could I level up my skills to work with a team?

Read on about some steps I took to help grow my skills and make myself more marketable to companies with engineering teams.

1. Testing Code

I would see posts online about TDD (Test-Driven Development). I'd ask myself: "Do I have time to write this extra code? Do I have to ask permission from upper management to allocate some of my time to do this?"

As I learned more about it, I decided not to ask permission, but rather to take the risk of having to ask for forgiveness.

I never had to ask for forgiveness.

Personal Case Study: Payment Portal

I inherited an undocumented project that was critical to the company: a credit card processing payment portal. The majority of company's sales deals were processed through this portal, but the code was messy, logic was unclear, and nothing was documented.

For a while after the previous senior developer left, I just prayed this payment portal service would continue functioning as expected.

Then I was tasked with making a minor update to it, and I knew it was time to tidy up.

Long story short: I rewrote the codebase, and wrote an accompanying automated test suite with Cypress to fully test all expected functionality. The process took me about a week longer than it would have taken without writing the tests - however, I was able to demonstrate the tests to upper management when it was completed, and I'm happy to report that I did not need to ask forgiveness; it was deemed time well spent. Furthermore, I was able to demonstrate how these tests helped save us from issues in the future by catching errors.

2. Act as If

Using version control software is a non-negotiable requirement in modern software development. Learning to leverage git was a critical stepping stone for growth.

git software is typically leveraged by teams to allow developers to work on the same codebase simultaneously without much friction.

Within the context of the company I worked for, git's primary purpose was to track the commit history to verify which work was done; to save a historical record of progress.

I read up a bit on team development, and learned more about branching, releasing, and what the pull-request (PR) process should look like. I learned about continuous integration (CI) and continuous deployment (CD). I realized that these were practices that I could learn and practice on my own — even without a team!

Personal Case Study: Continuous Integration and Pull Requests

Earlier in my career, a typical deployment process involved SFTP, rsync, WordPress Duplicator, or similar. While studying continuous integration, I learned that the deployment process could be automated via GitHub Actions.

When I first set up CI, I used rsync under the hood — however it was used in the context of a GitHub Actions workflow.

I set this up to reduce the amount of time and manual work that a deployment would require. But still... something was missing.

Pull Requests

The GitHub Actions workflow was set up, but how would I use it effectively?

At first, I triggered it manually. Then I learned about how to leverage automation within a PR process. Once I figured out how to do this, I'd have this deployment workflow run whenever code was merged successfully into main, and it passed linting and tests.

By "Act as If," I'm referring to acting as if I was working with a team. I would open a PR for code that I wrote, write a relevant description and list notable changes, and include notes on how to test it. I knew these descriptive PRs would not only help my future self, but they could potentially help whoever was going to take over my role in the future.

So, I acted as if I was in a collaborative environment by tracking my steps, automating my deployments, and logging enough information to help the next person.

In Closing

At the end of the day, it's all about self-improvement and progression. When I found myself working repetitively, or stagnant, I became restless. The solution was typically to get outside my comfort zone, try new things, and learn.

The beauty of a software development career is that it's never stale. New technology and techniques are available nearly every day. There is no shortage of innovation and ideas.

The best software engineers continue to learn and grow, remain humble, and never settle for the routine for too long.

Enjoy the journey!