Ask HN: I can't get my code reviewed. Now what?
The company doesn't have many people that can review my code changes (infrastructure-related, terraform, Go, Ansible, etc). They are focused on PHP and Node.js.
However, there's a formal rule that whoever submits a change, cannot merge it. It has to be reviewed byt someone else and merged.
My changes sometimes languish for 2 months at times. It's making me depressed and management doesn't seem to care.
I'm thinking about jumping ship but I was wondering if the HN crowd has better suggestions. Maybe merge my own changes and see who complains? In some repositories they don't even give commit access to most people so that would be tricky/impossible to do for 40% of the code base.
5 comments
[ 3.7 ms ] story [ 27.7 ms ] threadIt depends what field you're in and what the company is like I suppose, it sounds like the management has other priorities at the moment, I'd just keep raising it with them, discuss it openly, if nothing is done about it and it bothers you then either suck it up, or find alternative employment would be my guess.
I used to suffer from a similar situation. In GitHub, one can be a code owner of a directory in the repository, in my company you cannot merge pull requests without explicit code review and approval of the code owner or the repository owner (CTO in my company)
Problem was that whenever I used to raise a pull request for changes in the directory I myself was the code owner.. no one was there to approve the pull request as one cannot review the PR one raised itself. I would just ask someone else to raise the pull request and approve it myself and merge it ;) Didn't want to wait for my CTOs approval and dictate my working pace. I was always going to be accountable anyway my repositories.
Now, I'm not saying that you should go the same route, rather trying to influence you to not feel depressed and try and find a solution to work around the policy.
Firstly, do the obvious and keep poking who ever is incharge about your situation.
To me, this is a bad idea because it has no upside. If changes can wait for two months, then they may be important but are not urgent. But unless you always write bug free code, something will go wrong and you will be singularly irresponsible. To put it another way, it sounds like your organization has adopted a sound engineering practice -- that's what code review is. That makes going around code review bad engineering at a higher level than code quality. Engineering is creating things fit for purpose and here the purpose is the business operations of a particular business.
If you're unhappy at your job, more conventional steps such as talking to supervisors or looking for a new job are often more appropriate than going cowboy. Trying to see the role of your code in the larger engineering context or even the complete business operation might lend a useful perspective. ....gaining an understanding of why the company is both willing to pay you to produce the code but is not rushing it into production will probably give you a sense of what drives the organization's culture. Even if you leave, such knowledge will provide intuition for evaluating opportunities throughout your career because there are patterns.
Good luck.