I don't know about you, but it's always been my nightmare to see something go terribly wrong, while also being the person responsible for it. It's one way to feel inferior, incompetent and ignorant.
There is also another way of looking at it.
It is important not to panic. There will be consequences, but ultimately, a mistake is just a problem that has to be solved. You can also try to identify the steps that lead to the mistake, so you can avoid it in the future.
Let's see one example! I was given the task to work on the internal administrative system (a code base which was in a far worse state than the actual website, which was open to the public). It was hard to get used to the way it worked, there was no structure, no directories, just 500 files next to one another, making it very hard to figure out how they were interconnected. Still, I managed, trying my best to maintain the old code, and write better quality features for it.
It was a lonely job, my fellow developers usually excluded me from the tasks and projects (as they worked on the website for the most part), and only scarcely tossed me an assignment that no one else was willing to take. I was obviously the "new kid on the block", and they didn't want to entrust me with even the smallest task. Not addressing this issue was my first mistake, I shouldn't have let this kind of workplace tension fester.
Until one day, the management came to me with an immediate request for adding a new coupon type. It was website-related, on which I was not supposed to work, however, there was no one else to do it at the time, every developer had his own work to worry about. According to our original agreement, every code I've written would have to be reviewed and approved by the lead dev before it could go to production - a very reasonable request, if you ask me.
I prepared a solution, it was no more than a few lines of code.
It introduced a new coupon type, which head its properties stored as a string, each individual property separated by a colon (they chose this way of storing information instead of using JSON, and it didn't seem like a good idea to change it around for just one coupon type). Exploding the string gave you the limit and the discount variables, the limit being the minimum required cart value, and the discount being the amount of discount given (as a fixed value and not a percentage), if someone has reached the minimum cart value. Next, you had to get the products from the cart, and check if they met certain requirements, in this case, they had to be in a certain category, and not in a certain subcategory to be eligible for the discount.
If the products in the cart met these requirements, their price (times the amount of similar products in the cart) was added to the total value, based on which this method returned ether the discount value, or zero.
This was the code the lead dev would have had to review, so I asked him to please look at it when he has the time.
After a week, I decided that it's probably not too impolite to remind him, that there is code waiting to be reviewed, and our colleagues from other departments have been waiting for this addition. He again said yes, and again, nothing happened for a week, after which he took one week of paid leave. It was the middle of the summer, it's perfectly normal for people to go on a holiday. On the third week, I decided to push the code to production without waiting for a review.
All this time, users were waiting for the feature. Their jobs could have been easier if it was implemented sooner. Don't get me wrong, code review is a helpful and good practice, and I encourage every team to use it. If done right, it only has benefits, especially if the entire team participates. Code review allows us to:
- see what others have been coding while we were working on our own task.
- help each other find mistakes and refactor the code.
- ask more experienced colleagues for their input.
- learn from the solutions other people presented to solve the problem.
- improve code and software quality.
But in the example above, this didn't work. What went wrong?
Communication, for one. In my opinion, people skills play almost as big part in being a good programmer, as actually writing consistent, readable and clever code. You have to be able to cooperate with your own team, and without a doubt, a team lead or project lead is also responsible for sufficient information exchange, and keeping the deadlines.
It was not only the lead dev at fault. If you agree to review code before it is implemented, then wait for the code to be reviewed. No matter how much an implementation is delayed, you should not act on your own, like I did. In many cases, you might even be blocked from merging your changes with the master branch, but here this wasn't the case. I shouldn't have made decisions on my own that I was not authorized to make, and that could have possibly caused more harm than good.
I wanted to deliver an implementation more than I wanted to adhere to our agreements with my team. But the road to hell is paved with good intentions, they say. I failed as a team member.
Respect your fellow developers, and don't jeopardize their work. If you act on your own devices in situations like this, you give yourself a bad name, and also your project lead, because he is also responsible for your cooperative and supportive behavior - and he is the one who will have to explain to the management, why something went wrong, if your actions ended up causing downtime, revenue loss or other issues.
Again, these advices might seem trivial, but it is fairly easy to lose grasp of what should be trivial, when you are working in a dysfunctional team. If no one else takes initiative, encourage communication, start a conversation. Convince your team to practice code review on a regular basis, create a schedule, which will help both you and your team adapt a good habit. An active discussion is a healthy part of a dev team.
I can only advise you to be proactive and cooperative. You can only learn and improve in a supportive environment, and you also have responsibility in creating it, so you can become a better developer.