The Orphaned ID Bug from My First Job (And What It Taught Me About Being a Junior Dev)

try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 3610693) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } Bradley Matera Posted on Apr 28 The Orphaned ID Bug from My First Job (And What It Taught Me About Being a Junior Dev) #webdev #jquery #php #ajax About two weeks into my first web-dev job, I had a Trello card that said the LMS was sometimes leaving orphaned IDs behind when assigned trainings were finished or deleted. The app was a corporate LMS for a global manufacturer that made machine protection, chip and coolant management systems, and facility safety products. This was not a small internal team tool. It was the training system for the whole company, and they wanted every training assignment for anyone to go through this broken LMS. The frontend was simple: jQuery dialogs, table rows, and AJAX calls. The bug was not a dramatic React failure. It was a row-based edge case in a table view. Sometimes the AJAX response would arrive and the data would be missing. Sometimes the table would render, but an empty row would appear where an assignment should have been. That was enough for the card to hit the board and for me to start investigating. Why the bug was more than a blank row At first, it was easy to dismiss this as a rendering issue. Maybe the list component was failing to fill the template. Maybe the CSS was swallowing the text. Maybe the client was accidentally rendering an empty object. Then I opened the network tab. The API was returning assignment objects. Some of them had training_id, some of them had completed_at, and some of them had fields set to null or undefined. The client never filtered those out. It rendered every row it received. That meant the bug was not just on the page. It was in the data the page was given. What I was told When I asked my senior for more context, the answer was basically, “Figure it out without AI.” That line was a punch in the face, because this was the same team that had told me they liked that I understood AI. The same team that had hired me after I talked about how I used free tools to speed up small fixes and keep my commits focused. I was not being asked to build a feature. I was being asked to debug a failure in a system I did not own. I was not given: the schema for assigned_trainings the intended lifecycle of a completed assignment whether deletes were supposed to cascade whether completed_trainings was supposed to be a source of truth I was only given the symptom and an expectation. That is a very common junior-dev situation: the problem is clear, but the contract is not. It got worse after I was fired. The official reason was that I used AI too much. I had spent one month on the job, made forty small commits, and the only real problem I had found was one that was creating blank rows in the UI. The contradiction stung. They paid for the work, accepted the fixes, and then told me they did not want my process. It left me angry, confused, and more than a little ashamed. That was the context I brought to the bug: a team that liked the results but disliked the tool, a junior dev who felt stuck between expectations and execution. Following the data trail like a junior detective Once I stopped looking at the UI and started looking at the database, the problem became more concrete. The…

This excerpt is published under fair use for community discussion. Read the full article at DEV Community.