Question Details

No question body available.

Tags

team teamwork teamleader

Answers (4)

February 14, 2025 Score: 16 Rep: 23,346 Quality: High Completeness: 20%

It is not your code. A company employs you, so the code is the company's code. Some companies delegate ownership of certain parts of a product to certain people or teams, but even that changes as people move around the organization or even come and go from the organization entirely. Broadly sharing ownership and reducing barriers to people delivering their work tends to be more effective than gating changes to parts of the software to specific individuals on the team.

The fundamental problem seems to be that you don't have an agreed-upon style guide. It's unclear if a linter could help with this or if it's a broader code organizational concern. Teams of a certain size typically benefit from having agreed-upon and enforced coding standards and, to the extent possible, using automated tools to enforce them. This would be a good conversation to have with the team, such as at a retrospective if you use that practice.

February 14, 2025 Score: 5 Rep: 12,140 Quality: Medium Completeness: 30%

Better communication is expected. But the protocols, not the people are expected to accomplish it.

Code review and Pull Requests? User stories, tickets, and sprints?

Ignoring any of the emotional items and ownership, you haven't mentioned any source control protocols.

The company owns the code, it is the company's to do with as it wishes. Getting worked up about it isn't helpful to your mental wellbeing.

Having a set of design patterns getting documented is pretty much standard these days. It helps people from going rogue.

Lack of source control protocol or code reviews that help communication and managing a dev team is the definition of "superuser".

Getting typical code review, pull requests, etc. in place would do a great deal to quash the mindset of "change what I want when I want and not tell anybody" that you are living with. If that is possible to accomplish at your company that is really the question.

Good luck

February 15, 2025 Score: 3 Rep: 26,280 Quality: Medium Completeness: 20%

Any tips on how other teams deal with this?

Does you company have a process called code review before committing the code changes ?

The people who review the code usually are experienced software engineers who are also very familiar or are experts on the code base. They have the authority to either approve the code changes or requests some explanations for the code changes from the programmers.

If your company does not have the code review process, then talk to the manager or the team lead to get that process in place.

I can't imagine a responsible and effective software development team that does not have the code review process.


Currently, how does the code development process work in your team ?

Can programmers just commit any code changes that they make without going through a code review process ? Hehehe....

February 14, 2025 Score: -2 Rep: 173,726 Quality: Medium Completeness: 30%

“It’s the company’s code” doesn’t answer the workplace question.

As far as the workplace is concerned, your boss is disrespectful and disruptive. He is liable to causing damage to his company. Quite possible that he vastly overestimates his abilities because the tooth fairy magically cleans up his messes.

Now legally if he is the sole owner then he has the right to damage his company. Doesn’t mean it’s not stupid.

What should you do? First you check how easy it is for you to find a new job with similar pay. Then you decide how much money you want to do your job as it is, not as it would be with a reasonable boss.

No, forget that. He’s not going to change. He’s not going to pay you more for putting ip with an . He’ll probably be insulted by having his unfailability questioned. So look for a new job, stop fixing ip his messes, and when you signed a new contract you give notice. And it’s a case where you would definitely not accept a counter offer.