---
title: 'Building A Software Development Career: My Story (Part 2)'
date: '2023-01-18'
tags: ['career']
draft: false
featuredImage: blog/direction-inverted.jpg
summary: >
  Growing a career as a software developer is a challenging and rewarding effort. Here's some steps
  I took to help take my career to the next level. Perhaps they'll help you also.
---

## 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.

<Aside>

### 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](https://github.com/cypress-io/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.

</Aside>

## 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_ &mdash; even without a team!

<Aside>

### Personal Case Study: Continuous Integration (CI) and Pull Requests (PRs)

Earlier in my career, a typical deployment process involved SFTP,
[rsync](https://linux.die.net/man/1/rsync), WordPress
[Duplicator](https://wordpress.org/plugins/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 &mdash; however it was used in the context of
a [GitHub Actions workflow.](https://gist.github.com/missionmike/a21d92370e92dd129fb2be8bd4ab3015)

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.

</Aside>

## Conclusion

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


About Michael