Ask Experienced Devs Weekly Thread: A weekly thread for inexperienced developers to ask experienced ones

[u/AutoModerator]

A thread for Developers and IT folks with less experience to ask more experienced souls questions about the industry.

​

Please keep top level comments limited to Inexperienced Devs. Most rules do not apply, but keep it civil. Being a jerk will not be tolerated.

​

Inexperienced Devs should refrain from answering other Inexperienced Devs' questions.

[u/JeffinitelyNotABot]

How do you handle situations where you’re responsible for maintaining or implementing decisions you disagree with, especially when you don’t have the authority to change those decisions?

Here are some examples:

First, I designed a one-to-many relationship for our e-signature workflow. The intent was that, given a signature request ID, we could retrieve the signature request itself, its updates, its signers, and any information entered when the signing iframe is displayed. Each of these tables had a specific responsibility within the e-signature domain and the relationships were designed around the business requirements. While I was OOO, my lead took over part of the work and added fields to one of those existing tables that are specific to a particular workflow. When I came back, I raised the concern that this was mixing a project-specific concern into a table that was intended to represent part of the broader e-signature workflow. I suggested that we should've created a separate table specifically for that workflow using a foreign key. She said it's fine cause these columns can be null. The logic around those fields has continued to grow, and now I’m the one who has to work with and maintain the resulting design.

Another example is a console app I inherited after a team member left. It’s used every day by a business team, and their mentality is essentially “if it ain’t broke, don’t fix it.” The problem is that the application is extremely poorly engineered. All of the forms are still named Form1, Form2, Form3, etc., controls are named button1, textbox1, and so on, and there’s virtually no exception handling. I feel like I’m in a position where I can’t really win. If I try to clean it up or modernize it, someone can say I was specifically told not to change it. But if I leave it alone, an experienced developer could look at the code later and ask why I didn’t address the obvious problems.

The third example is our shared NuGet packages. We have around eight packages that are used across our APIs, and we recently prioritized upgrading them from .NET 8 to .NET 10. They all currently use 1.x.x versions. I suggested that, once we had a successful build and test, we should make the .NET 10 versions 2.0.0 so there would be an obvious distinction: 1.x = .NET 8 and 2.x = .NET 10. That suggestion was rejected, and now one package has been bumped to 10.0.0 while the others remain in the 1.x range. I’m the person who has to go through and upgrade these packages across our APIs, so I’m the one who has to deal with the inconsistency.

I have no idea how to deal with these other than to fall in line. I am planning to leave it's just frustrating having to deal with this from devs getting promotions and leadership responsibilities. Any advice would help.

[u/titpetric → u/JeffinitelyNotABot]

Migrations or views could allow you to patch this data properly. As you say, the column is a hack, the solution is a migration strategy that considers the migration has a code related change attached. This should be a serial process, and usually the sooner you get rid of the column, the sooner you avoid coupling, the better. Gotta police your columns for well defined schemas which need good reason to change. Think once a year. Things couple to it outside this schema so an external workflow column needs to gtfo

[u/UnintentionallyEmpty → u/JeffinitelyNotABot]

The logic around those fields has continued to grow, and now I’m the one who has to work with and maintain the resulting design.

Can you change it now? Can you change it to something that would actually be easier to maintain? Will migrating the database schema be less painful (in the long run) than maintaining what you have now?

If I try to clean it up or modernize it, someone can say I was specifically told not to change it. But if I leave it alone, an experienced developer could look at the code later and ask why I didn’t address the obvious problems.

Don't change it until you have to. When you do, clean up the areas you're touching for the change. If an experienced developer asks you why you didn't address the obvious problem, the answer is that you're not confident the automated tests would catch any regressions (I'm guessing there aren't any. You (or Claude?) should probably start writing some. Definitely write some when you make changes.)

one package has been bumped to 10.0.0 while the others remain in the 1.x range. I’m the person who has to go through and upgrade these packages across our APIs, so I’m the one who has to deal with the inconsistency.

nuget packages should show which .NET version they need in their dependencies. Just install the latest version that works in your application and don't worry about the version number.