---
title: 'Take-Home Test Review: An Uncanny Rejection'
date: '2024-11-26'
updated: '2024-11-26'
tags: ['career', 'technical interviews']
featuredImage: blog/canny-rejection-email.png
summary: >
  This take-home coding assessment was a discouraging experience. Here's why, and how I believe
  companies can improve this process for candidates.
---

## Preface

I was laid off on August 5th, 2024. My position as a Senior Full Stack Developer was removed along
with a few other roles at
[The Real Deal](https://www.linkedin.com/company/therealdeal/posts/?feedView=all). As of the time of
this writing, I've been hunting for my next role and have applied to over 200 positions. The market
is rough right now.

## 0: Finally, an Interview!

I applied for a Senior Frontend Engineer position with
[canny.io](https://canny.io/?utm_campaign=please_provide_constructive_feedback_to_your_rejected_candidates)
in November, 2024. The
[job listing on LinkedIn](https://www.linkedin.com/jobs/search/?currentJobId=4064305528) didn't
include a salary range, but I took a chance on it anyway:

<Image
  src="/static/images/blog/canny-job-listing.png"
  width={1228}
  height={1934}
  alt="LinkedIn job listing for Canny Senior Frontend Developer position"
/>

By this point in time, I had gone for **nine straight weeks** and **_over 100 applications_** since
I had my last interview. I'd been applying for a variety of senior software engineering positions.

A couple of days later, I received a request to move forward with the next steps of the interview
process! I was ecstatic and excited - recharged after such a long drought.

<Image
  src="/static/images/blog/canny-invite.png"
  width={1286}
  height={888}
  alt="Invite to take the assessment"
/>

Stoked!!

<Image
  src="/static/images/blog/canny-michael-first-response.png"
  width={662}
  height={273}
  alt="My first response to the invite"
/>

Let's go! 🚀 🚀 🚀

---

## 1. Assessment time

The test was straightforward. Canny provided a link to download a zip file, which contained some
source code for a backend and frontend application using Node and React.

The candidate is supposed to spin up the frontend and backend, then work their way through four bugs
called "Customer Issues."

For each of the issues, I had to:

1. Find the problem.
1. Fix it.
1. Draft a brief response to each customer.

Below is what I submitted as my portion of the assessment:

<Aside>

### **Customer 1:** The page doesn't load, I see 'server error'.

There were a string of issues here, I'll list them out in the order I found them.

#### The Diagnosis

1. The string `"server error"` was returned to the client instead of providing more details about
   the underlying issue. I first modified the code to provide the specific error message:

   ```js
   // Original:
   error(error) {
    const data = JSON.stringify({
      error: 'server error',
    });
   }

   // Modified:
   error(error) {
    const data = JSON.stringify({
      error, // Return the actual error here instead of "server error"
    });
   }
   ```

1. In the `HTTPServer` class, a call to `authenticateUser()` was failing with `"unauthorized"` -
   however, this was misleading because the `catch()` block was catching the error and returning a
   hard-coded string `"unauthorized"` instead of a reference to `error.message`. Ater fixing this,
   the actual underlying error message is `"Missing name in user data"`:

   ```js
   // Original:
   try {
     await authenticateUser(request, data);
   } catch (error) {
     // ...
     request.error('unauthorized');
     return;
   }

   // Modified:
   try {
     await authenticateUser(request, data);
   } catch (error) {
     // ...
     request.error(error.message); // Return the actual error message here.
     return;
   }
   ```

   This led me to the root cause...

1. The actual error message buried in this thread of incorrectly-handled errors is
   `"Missing name in user data"`. The root cause was within the dummy data in `AJAX.js`, the
   `SSOToken` decoded has a `nayme` property (typo) instead of `name`. To find this, I used
   [jwt.io](https://jwt.io/) to paste in the original token and check the values.

   <Image
     src="/static/images/blog/canny-jwt.png"
     width={1198}
     height={454}
     alt="JWT.io screenshot"
   />

#### The Fix

To fix, I used [jwt.io](https://jwt.io/) to rename `nayme` to `name` in the payload, then used the
key value from `authenticateUser.js` to generate a new token.

#### Response to Customer

_"My apologies, it looks like we weren't passing the correct property name in the authorization
token, which caused the server to fail the request. This has been resolved, please let me know if
you run into this issue again. Thanks!"_

<HorizontalRule />

### **Customer 2:** When I select 'Old' or 'Top', the dropdown doesn't update.

#### The Diagnosis

This is a rendering issue, it looks like the component is not subscribed to changes to the `sort`
object's values. As a result, it doesn't know the values were changed, so it doesn't update. I
haven't used React Redux before, so I'm not familiar with this pattern.

#### The Fix

I fixed the issue by passing in the entire `sort` object to the `Selector` subcomponent. Then I
determined whether an option was meant to be in the `selected` state based on the current value of
`sort.name`. This seemed to do the trick in ensuring the component re-rendered.

```jsx
{
  /* Original: */
}
<Selector onSelect={changeSort} selected={sort.sort} />;

{
  /* Modified: */
}
<Selector onSelect={changeSort} sort={sort} />;
```

```js
// Then in the <Selector /> component, change the "selected" prop name to "sort"
// and update a couple of conditional references.

// Originals:
const className = 'option' + (option.name === selected ? ' selected' : '');
const option = Options.find((option) => option.name === selected);

// Modified:
const className = 'option' + (option.name === sort.sort ? ' selected' : '');
const option = Options.find((option) => option.name === sort.sort);
```

#### Response to Customer

_"Thank you for letting us know about this issue! There was a disconnect between the data and the
component that was supposed to display it - this has been patched and resolved. Please reach out if
you encounter anything else."_

<HorizontalRule />

### **Customer 3:** When I sort by 'Top', the posts aren't in order.

#### The Diagnosis

It looks like the sort method is using string comparison somewhere. String "28" ranks higher than
"180" because the initial character "2" in "28" comes after "1" in "180"

> Note: This was my first idea, however after looking at the code again, I see it's a flaw in the
> custom algorithm.

#### The Fix

I had a hard time unraveling the custom algorithm because I'm not familiar with it. So I used a
standard `.sort` method with a/b comparator function. This is not a great choice if there was a
performance implication in sorting the data on the server, however I believe that overhead could
potentially be offset with a more performant query on the database side -- or, I could spend more
time figuring out where to patch within the algo. Open for discussion!

```js
// Original (common merge sort with a flaw):
export default function sortBy(array, key, descending = false) {
  const length = array.length;
  if (length === 1) {
    return array;
  } else if (length === 2) {
    const aValue = array[0][key];
    const bValue = array[1][key];
    if (bValue > aValue) {
      return array;
    }
    return [array[0], array[1]];
  }

  const mid = Math.floor(length / 2);
  const firstHalf = array.slice(0, mid);
  const secondHalf = array.slice(mid, length);

  const arrayOne = sortBy(firstHalf, key);
  const arrayTwo = sortBy(secondHalf, key);

  const merged = [];
  while (arrayOne.length || arrayTwo.length) {
    if (!arrayOne.length) {
      merged.push(arrayTwo.shift());
      continue;
    }

    if (!arrayTwo.length) {
      merged.push(arrayOne.shift());
      continue;
    }

    const valueOne = arrayOne[0][key];
    const valueTwo = arrayTwo[0][key];
    if (valueOne <= valueTwo) {
      merged.push(arrayOne.shift());
    } else if (valueTwo < valueOne) {
      merged.push(arrayTwo.shift());
    }
  }

  return descending ? merged.reverse() : merged;
}

// Modified:
export default function sortBy(array, key, descending = false) {
  return array.sort((a, b) => {
    if (a[key] === b[key]) return 0; // The same value, no sorting needed.

    // The value of `descending` determines whether or not to reverse the sort.
    return (a[key] > b[key] ? 1 : -1) * (descending ? -1 : 1);
  });
}
```

#### Response to Customer

_"Thank you for catching this! It looks like our sorting algorithm had a bug. This has been fixed,
please let me know if all looks good on your end. Thank you!"_

<HorizontalRule />

### **Customer 4:** The vote counter in the top right of the page doesn't always update correctly.

#### The Diagnosis

This appears to be a render issues because the value of `votes` isn't changing, so the component
doesn't re-render.

#### The Fix

I removed the separate `recountVotes` logic and included it directly within the state updates in the
`PostsLoaded` reducer. This way, it's always updated on time and doesn't get delayed.

```js
    // Original:
    case PostsLoaded: {
      return {
        ...state,
        error: null,
        pages: action.pages,
        posts: action.posts,
      };
    }

    case RecountVotes: {
      // ...
    }

    // Modified:
    case PostsLoaded: {
      return {
        ...state,
        error: null,
        pages: action.pages,
        posts: action.posts,

        // Remove the RecountVotes case and place logic within PostsLoaded here.
        votes: action.posts.reduce((prev, post) => {
          return prev + post.votes;
        }, 0),
      };
    }
```

Then, in the `dispatch`:

```js
// Original:
(dispatch) => ({
  fetchPosts: (params) => {
    dispatch(fetchPosts(params));
    return dispatch(recountVotes());
  },
  // ...
})

// Modified:
(dispatch) => ({
  fetchPosts: (params) => {
    return dispatch(fetchPosts(params));
    // Removed the separate recountVotes dispatch.
  },
  // ...
})
```

#### Response to Customer

_"Thank you so much for letting us know about this issue. The underlying issue had to do with the
order in which data was being processed after being fetched. We've fixed this issue, please do let
us know if something else pops up!"_

<HorizontalRule />

### Notes on Solutions

This assessment took me much longer to complete than I anticipated. This largely had to do with two
areas:

1. I got lost in the weeds on the divide & conquer algorithm. I'm not familiar enough with this, and
   I spent too much time trying to fix what was in place rather than replacing it with something
   that worked. In a team environment, this may not be the best approach though, and I'd spend more
   time understanding the original code and fixing it in place if I felt it was better that way.
1. I've never used React Redux before outside of a brief tutorial years ago. So I had to take a bit
   of time to understand how the state was being handled. This ate up a bunch of time.

---

### Notes on My Assessment Experience

Thank you for putting this assessment together!

I found when troubleshooting and getting familiar with the code, I'd make some changes here and
there - however, without `git` tracking in place, it was difficult to stay on top of where changes
were made. For future test-takers, it would be much easier to be able to clone or fork a GitHub
repo, then open a PR with the fixes. This would help with transparency in reviewing the changes, as
well as during the dev/debugging process.

Thanks again for your consideration!

</Aside>

**Phew!** What a test!

This was supposed to take between _45 minutes_ and _2 hours_.... but I completed it in _just_ under
2.5:

<Image
  src="/static/images/blog/canny-assessment-completed.png"
  width={743}
  height={421}
  alt="Assessment completion screen"
/>

I followed up to let the recruiter know. This was on Monday, November 4th, 2024:

<Image
  src="/static/images/blog/canny-michael-second-response.png"
  width={812}
  height={267}
  alt="My second response follow up after submitting"
/>

## 2. The Rejection

Three days later, on Thursday 11/7, I received an email with the subject "Canny Assessment."

Could this be it? Am I moving forward? Will I have a chance to discuss my submission with somebody
from this company and learn more about the org?

<Image
  src="/static/images/blog/canny-rejection-email-full.png"
  width={600}
  height={361}
  alt="The big rejection email"
/>

I read _"Unfortunately, we've decided not to move forward at this time."_ and my heart sank.

However, this isn't the first rejection I've faced, so it didn't slow me down. This job just wasn't
for me, oh well...

I was truly curious, however, as to what drove this decision. The response was so canned and
vague...

- Was it my code?
- Did they not like my sort?
- Did I miss something in my debugging?
- Was I supposed to refactor to clean up the codebase (it was really messy)?

I had to ask.

<Image
  src="/static/images/blog/canny-michael-third-response.png"
  width={647}
  height={232}
  alt="My third response follow up after submitting"
/>

I didn't receive a response.

🦗 🦗 🦗

For days.

Until...

I shared my story on LinkedIn and
[my post went somewhat viral](https://www.linkedin.com/posts/michaeldinerstein_company-wont-tell-me-why-they-didnt-like-activity-7263100680138031104-Mlc5)
(at least viral _to me_, as it's the most engagement I've ever had to date on LinkedIn!)

Since Canny wasn't willing to provide feedback on my test, I decided to upload my test code to
GitHub with hopes of getting some eyes on it. Then, I opened a PR with all my changes and described
my thinking process and changes in comments. I received some feedback from comments on LinkedIn
about the code and the discouraging experience I shared.

Overall the feedback was quite uplifting and informative.

I also learned that a few other people in the comments have gone through the same experience with
the same company.

Then I received a response to my email **11 days later**:

<Image
  src="/static/images/blog/canny-takedown-request.png"
  width={1280}
  height={1049}
  alt="Code takedown request"
/>

At first I obliged, and left some feedback for them:

<Image
  src="/static/images/blog/canny-takedown-request-response.png"
  width={1494}
  height={848}
  alt="Code takedown request response"
/>

...however, after more consideration, I decided to republish it.

I felt like I was being punked when they spent time to request that I take down the repository and
provide all their excuses why I should take it down... when they couldn't respond to my simple
request for clarity on my assessment rejection.

A few days later, I received a
[DMCA copyright infringement notice](https://github.com/github/dmca/blob/master/2024/11/2024-11-22-canny.md)
from GitHub. It seems that Canny reported the repository and had it
[forcibly removed](https://github.com/missionmike/technical-assessment-review-canny).

Oh well!

## 3. Takeaways

### Candidate Feedback is Important

As a candidate, I was excited about the prospect of working for a new company that seems to tackle
some interesting challenges. I spent time researching the company's website, learning about their
product, and getting familiar with the team page. I wanted to be prepared to meet with them during
my first interview! Because surely after this assessment there's an interview, right?

Wrong (for me).

There was an interview for someone.. maybe. Just not me.

**And that's OK!**

**This is the part that I wasn't OK with:** _"Unfortunately, we've decided not to move forward at
this time."_

Why isn't this OK? **It provides zero context.** No information about WHY we're not moving forward.

- Did I fail the assessment?
- If I failed... why? Which part? Some? All?
- Did they even look at my code?
- Did they hire someone else already before they could meet with me?
- Did they close the role?

So many questions. No answers.

**I firmly believe that candidates should receive feedback from take-home assessments.** Even if
it's brief, candidates deserve information.

In this particular experience, Canny had the opportunity to provide feedback, especially after I
asked them directly. Instead, they chose to ignore me, just as they disregard who-knows-how-many
other candidates.

### This Isn't Unique

This situation isn't unique. I've gone through this with other companies before. It's rude and
disrespectful.

My Canny experience was a final straw and I decided to share my experience online. Normally I'd
bottle it up and move on... but that is unhealthy.

Sharing my story led to many conversation on LinkedIn, a DMCA takedown on GitHub, and finally this
blog post - where I plan to keep this experience documented for myself and others.

### Message to Companies and Hiring Managers

If you are sending candidates take-home assessments as part of your process, you should budget a
small amount of time to share reasons for rejection with those who don't move forward.

Why?

Because it's considerate and respectful.

Perhaps it's been a while since you've been in need of work or had to interview, and you've
forgotton all the stress and anxiety that goes along with that process. That's OK, it's easy to get
comfortable and forget.

However, now that you've been reminded - please make the hiring landscape a better place for all.

### Message to Candidates

Has this happened to you?

Share it. Talk about it.

It's not healthy to store up resentment. It's not OK for companies to treat us like this. Speak up
and decompress. I did, and I sure do feel a lot better - and I made some new friends and connections
along the way.

Onward!


This take-home coding assessment was a discouraging experience. Here's why, and how I believe companies can improve this process for candidates.


Take-Home Test Review: An Uncanny Rejection

---
title: 'My Journey as a Software Developer'
date: '2024-07-14'
updated: '2024-09-11'
tags: ['career']
featuredImage: blog/direction.jpg
summary: >
  Growing a career as a software developer is a challenging and rewarding effort. Here's some things
  that have proven to help me along my own journey. Perhaps they'll help you also.
---

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

<Aside>

### Personal Case Study: Pushing Boundaries

Early in my tenure with <a href="https://www.rrfedu.com/" target="_blank" rel="noopener">RRFC</a>, 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.

</Aside>

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

<Aside>

### Personal Case Study: Staying Informed

I stumbled across the [syntax.fm](https://syntax.fm/) Podcast and my life as a developer was
changed. Listening to [Wes Bos](https://wesbos.com/) and [Scott Tolinski](https://levelup.video/)
discuss web development trends and technology really struck a chord with me &mdash; 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 &mdash; 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:

- [Critical Business Skills for Success](https://www.amazon.com/dp/B00VSWXFB0/ref=kinw_myk_ro_title_ab_amzn)
- [Never Split the Difference: Negotiating as if Your Life Depended On It](https://www.amazon.com/dp/B01COR1GM2/ref=kinw_myk_ro_title_ab_amzn)
- [Algorithms to Live By: The Computer Science of Human Decisions](https://www.amazon.com/dp/B01D24NAL6/ref=kinw_myk_ro_title_ab_amzn)
- [Public Speaking for Success](https://www.amazon.com/dp/B01EGOQHBQ/ref=kinw_myk_ro_title_ab_amzn)

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

</Aside>

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

<Aside>

### 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 &mdash; but
essential &mdash; 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 &amp; API

I wrote a custom self-hosted WordPress plugin which could be activated within each site. This plugin
would parse [WordPress Shortcodes](https://codex.wordpress.org/Shortcode_API) representing various
data or components. This data or component would be served from a custom API endpoint &mdash; 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 &mdash; 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 &mdash;
and more fun &mdash; tasks.

</Aside>

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

<Aside>

### 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](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 and Pull Requests

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>

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


Growing a career as a software developer is a challenging and rewarding effort. Here's some things that have proven to help me along my own journey. Perhaps they'll help you also.


Tag: career

Take-Home Test Review: An Uncanny Rejection

My Journey as a Software Developer