Describe a time you had to work under a team coding convention you disagreed with.

This was my second engagement at an agency, on a backend team building an integrations service. The program was running about eleven days behind by week seven, so patience for debate was thin. The team had a rule I thought was silly: no abbreviations in any identifier, ever. We spelled out configuration, repository and authorisation in full, and some lines wrapped badly because of it. I raised it once, in the team channel, with three examples of lines I thought were harder to read under the rule rather than easier. Two people explained the history. Our client's own engineers would inherit this code at handover, and abbreviations invented by an earlier team of ours had genuinely confused them on a previous project. That was a reason I simply did not have, so I stopped. I said in the thread that I was convinced, which turned out to matter more than I expected. The reviewer who had answered me told me later it saved him wondering whether every future review would reopen it. Then I did the part I am actually pleased about. Rather than leaving reviewers to catch the rule by hand, I added the naming check to the linter so it fails in the pipeline. My own changes had been picking up around six naming comments each, and after that they picked up none. I still think the rule is imperfect for internal code. It is also not mine to decide alone.

On a later client program I owned two of the four backend services. The team standard was that every outbound call went through a hand-written client wrapper, even for a single endpoint. To me that was ceremony, roughly forty lines of boilerplate per integration, and we were about a fortnight behind at the midpoint of the schedule. Instead of arguing it in review threads, I asked for an afternoon to test my own claim. I pulled the review history from the previous three sprints. Thirty-four comments across nine changes were about the wrapper, which supported me, but I also found two production defects the wrappers had genuinely caught in retry handling, which did not. So the rule was earning something, just not everywhere. I took that to the standards discussion and asked for a narrow exception rather than a repeal: wrappers stay wherever we retry or authenticate, and become optional for read-only internal calls. We agreed the narrower half of what I asked for and wrote it down with a date to revisit at the end of the program. I said plainly in the room that I had wanted more and was fine with the outcome, then implemented the standard as written everywhere it still applied, including in the code I disliked. For my two services, deploys went from four a week to nine. What I took from it is to bring the count rather than the complaint, including the part of the count that argues against me.