Building A Software Development Career: My Story (Part 2)

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?

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

1. Testing Code

I would see lots of posts on LinkedIn and Twitter about TDD (Test-Driven Development). I'd ask myself questions like "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.

Personal Case Study: The 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 (CI) and Pull Requests (PRs)

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.

Conclusion

I hope these tips are helpful. I'll revisit this article and update with more in the future. Happy (clean) coding!