Stepping Back and Letting a JR Train a SR

At the end of 2024, my team hired a new SR developer. Soon after hiring the new SR, we started a new initiative to enhance our automated test coverage. My team in particular while having a good amount of coverage with unit tests, didn’t have key UI modules instrumented to use MockServer. We did have a pattern that the JR developer on my team developed with collaboration from the our Software Engineers in Test (SEIT). With all of this in mind, it seemed clear that we had two opportunities: 1) we can have the new SR on board into more of our UI components by instrumenting those modules for MockServer, and 2) we can have the JR engineer train the SR on a previous implementation to strengthen the skills of our JR engineer.

The pattern that the JR developer and the SEIT’s put together works something like the following:

1. An integration test calls MockServer to set expectations for the API the page calls.
2. The integration test launches a web browser through Selenium WebDriver.
3. The integration test configures headers for the web browser via an extension to trigger the MockServer instrumentation in the System Under Test (SUT).
4. The integration test loads the appropriate page in the SUT.
5. The SUT detects the headers that indicate that the MockServer should be called instead of the underlying API.
   1. If MockServer is able to meet the expectation, then the mocked result is returned.
   2. Otherwise, the MockServer acts as a proxy and forwards the request to the appropriate API.
6. Once the SUT has received the data from the MockServer, it is either rendered into the page or returned to the page via XHR/Fetch.
7. The integration test then tests assertions against the page or takes actions that may repeat some of the above steps.

I observed that the JR and SR were coordinating their time well. They were having meetings, break out conversations, and calls to try and coordinate the effort of supporting this logic in new UI modules. After a few days, during some of our developer review sessions the SR presented what he had learned so far and showed a preview of what he had as well as took the time to ask some questions. There were somethings that were spotted by our manager and through questioning were corrected. However, I spotted something that I thought it would be best to leave alone for a while.

I saw that the SR developer had set the wrong API results in the expectations. The page calls an API via fetch where the SUT has an API that calls at least one API that we want to mock. We don’t want to mock any APIs in the SUT itself; we want to mock the APIs that are a dependency for the SUT. The SR developer was attempting to mock the API calls for the SUT and not it’s dependencies.

The reason I didn’t speak up during the review session is that I thought that this would be a good learning opportunity for the JR developer. Being able to spot that someone is looking in the wrong place, and helping them figure that out as well as get them on the right track is an incredibly valuable skill for a software engineer. I didn’t want to deprive him of this practice. I also figured that since I spotted this problem already, if they got stuck, then I should hopefully be able to step in and help them. Finally, I also have been working more on not stepping in. I have a tendency to jump in everywhere and try to fight all of the fires. Doing that deprives other team members of opportunities, and burns me out.

I kept an eye on this situation and it seemed like the JR and SR were working through various problems. Then after some progress in other areas the SR said during stand up that he hit a blocker in not getting the right expectation from MockServer, and that he would pull the JR aside during the afternoon to help him troubleshoot the problem. I ended up hearing that afternoon exchange from my desk and heard the JR help diagnose the problem. I was proud of him, and sent him a note telling him that he did a good job.