Joining a story already in progress
My internship at Laxson Solutions Inc., from May to August 2026, introduced a clear difference from college projects: the application existed before I arrived. Conexgo already had components, conventions and users. Starting over whenever a section felt difficult to follow was not a useful way to contribute. I needed to understand what was there.
Reading can feel like standing still when you want to solve something. Yet tracing a value to its source or understanding why a component is shared belongs to the fix. Existing code reflects decisions whose constraints I may not know. Reconstructing enough context gives the next change a reason beyond my first impression.
Describe the problem before choosing a solution
I worked in Blazor and MudBlazor interfaces, including forms, filters, tables and reusable components. A visible defect does not necessarily identify the place to edit. An incorrect value might depend on incoming data, a display condition or an earlier step. Looking only at the final screen closes off possible explanations too quickly.
Consider a hypothetical filter that appears to return nothing. Before changing the table, I would want to check the submitted value, the available data and the role involved. Describing a problem this way separates observations from assumptions. It also helps avoid hiding a symptom while leaving the original cause in place.
Decide how much needs to change
The shortest fix is not always the clearest one. Adding a condition might handle the immediate case while making a component harder to understand. Reorganising a large section can create unnecessary verification work. The useful question is which responsibility actually needs to change and how the proposed edit relates to that responsibility.
Git diffs help me examine that scope by comparing the intention with the files and behaviours affected. Logs and Release builds provide other evidence about the result. These tools support the reasoning: they make assumptions easier to inspect and give me something more concrete than whether the screen looks right at first glance.
Repeat a workflow with enough context
With Playwright, I built role-based scenarios, reusable sessions, screenshots and traces. Their value goes beyond repeating clicks. A scenario needs to describe an identifiable situation: who is using the application, its starting state and the outcome that matters. Otherwise, a check can pass while answering a different question from the one behind the fix.
Roles, devices and screen sizes widen that discussion. Checking everything in the same way is not realistic; choosing relevant cases requires understanding the change. A trace or screenshot can then help explain a divergence. It becomes evidence about a workflow rather than simply a record of how an interface looked at one moment.
Leave a change the team can review
Someone else needs to understand why the work was necessary and what was checked. Saying that a form works leaves many questions open. Describing the expected behaviour, the original context and the cases examined gives a reviewer a clearer starting point. It also makes the reasoning easier to recover after the details are no longer fresh.
Since August, I have continued working with the team part-time. The internship left me with a different measure of a fix: how easily it can be explained, verified and built on by the next person. That responsibility starts well before the last line of code and continues through the way I present the work.