How can I avoid critical mistakes in a new code environment?

Question

I've been a developer for over 3 years now and I have built up confidence of my programming abilities within my team. Recently my team has been employed under a company owned by our venture capitalists which we have integrated within and now work on.

I have no experience of Java and while I know how to code in C# etc and I am familiar with APIs, I recently created a huge issue when checking in my code to our source repository.

I was thrown into the deep-end and asked to make changes to an existing API (my team is aware of my exposure and abilities). After understanding the changes and checking the solution environment for references to the API itself, I made the changes, tested it with unit tests and Postman for the response etc.

All seemed fine. However my knowledge of the solution overall and other things is not as good as the other back-end developers on this project; I'm the only full-stack developer, doing both front and back end. The problem was that the API is referenced in a BPMN workflow file which didn't show up when I searched for the references or API name as text in the IDE.

This caused a 4 day problem with between 2-4 back-end developers looking into why the build was failing at any given time during the working day. While I own up to my mistake and fully accept the responsibility for making such a big problem, I now feel very disappointed in myself and more so doubt that I should continue to develop the back-end with such little knowledge of Java and the solution structure. I also can't help but feel guilty for wasting so much time and money on what was a mistake and took a long time find.

While I'd like to be able to spend time and sit down with some back-end developers to go through and understand it fully, they simply don't have the time right now. What else can I do to help ensure I don't make or am far less likely to make mistakes, let alone such costly ones, in the future?

I should add I also had my change code reviewed by one the back-end developers, who I'm sure asked if the API is referenced anywhere else. As my search and check didn't show anything in the IDE as it doesn't check BPMN files, I replied no.

What more and what else should I do to minimize the risk of making similar mistakes in the future?

Additional notes in response to the comments and answers:

Code reviews: I will always sit with the developer and talk through and understand the code with them, explaining as we go.

We do daily scrums. I mentioned this when I was working on it but no concerns were raised, though I'm sure we will discuss it in tomorrows scrum or the next retrospective.

I should clarify that the issue was the build was failing and I understand that I should probably pull all changes into my branch and build and do a final test before committing, this I didn't do.

Answer 1

With multiple developers committing changes to the same code base (and not always being up-to-date with each other), these things will happen. I'm a developer myself; it's nothing to get hung up on, it will happen to all of us at least once. There are a couple of things you can do however to reduce the risk of it happening again.

From the context, it seems as if you tested everything locally and it worked fine. It was only later that something went wrong. This suggests that either your own code base was slightly outdated and/or someone else had outdated code when they committed their own changes. The best thing you can do, just before committing your code, is to pull any recent changes from your repository (or whatever you call it) so you can be confident your changes work with the most up-to-date code. If all your tests pass, then you can commit with a clear conscience.

I would also suggest being a bit more vocal with your colleagues. If you're making changes to a critical system, mention it to them. Even if it's a simple request like "I'm about to change this important bit, do you have time for a code review?". This way, your team won't spend days finding the problem, if there is one, and you can rest easy knowing that you AND your colleagues are confident with the changes. Some development teams do daily stand-ups where they voice what they're working on; it helps the team be more aware of what you're working on and if there's a risk of your changes clashing with anyone else's.

You'll learn by doing. If you are well-versed with languages like C#, you might pick up Java quicker than you think!

Answer 2

This situation happens from time to time - you do something that has unforeseen knock-on effects to something else that you didn't know about before.

The fact that you weren't sacked immediately or put onto a PIP means that the company recognizes that mistakes happen, they get sorted out, and life accordingly moves on.

What can you do about it? Learn about this consequence and see if there's anything else related that you should have taken into account or any other team you should have asked about knock-on effects of you changing an API.

It's all part of building up experience and it shouldn't discourage you going forwards.

Answer 3

The way to avoid this problem also provides you with an opportunity to significantly contribute to your new company: the root of this problem is inadequate testing, not you (unless you were negligent in a way that doesn't appear in your post).

In all development environments, it should be possible to figure out if the change you've made is going to cause a major failure before checking in as well as figure out if the code is going to break the build. While it is definitely embarrassing to be the one to find such a gaping whole in the company's process, you now can be a leader in trying to establish such a process at your new company.

You can propose that the team begin writing unit tests and begin setting up a continuous integration environment which would re-build the project and execute the unit tests each time code is checked in, and where the tests can be run individually prior to checking in. The unit tests will take commitment from the team, but a basic CI environment can be set up fairly quickly from open source projects out there as long as you can dedicate a VM or server to it.

Edit: code reviews are another good programming practice that can minimize these kinds of mistakes, and is also fairly easy to get going.

TL;DR use this embarrassing opportunity to modernize your company's development processes. You'll come out smelling like roses.

Answer 4

The problem arises that the API is referenced in a BPMN workflow file which didnt show when i searched for the references or API name as text in the IDE.

What did the teams retrospective regarding this incident surface? What department procedures could be put into place so there this is not repeated? What does the team believe is necessary when on-boarding new developers? And what new on-boarding procedures are to developed?

P.S. Being proactive in the above is a great way to learn and lead.

Answer 5

Where were the BPMN files stored that they weren't visible when you were searching for any other API consumers?

The issue sounds like it was that you didn't know about/have access to all of the API consumers.

If they're not part of your standard development working set and for some reason can't be added to it, any APIs that are consumed by then need to be documented as doing so in method call header comments of equivalent. Depending on how formal your review process is explicitly verifying that they're not impacted might be a valid process change.

The issue of your not knowing about everything outside the codebase you're working on that needs to be checked needs brought up at your next standup/retrospective by you if your coworkers don't. Something like that should have been covered as part of your on boarding to the project.

Answer 6

You have to shift your mindset.

You did not make a "critical mistake". You worked to the best of your abilities; you were open to working in an unknown environment; you were transparent about your knowledge and everything else, before and after; you worked together with the other guys to fix the issue, you presumably did not throw a tantrum in the office. After the debacle, you are coming out here and trying to improve even more.

In short: I would lick my fingers to have more employees like you.

To answer your question:

1. You personally cannot avoid such things, in general. The technical error was completely out of your scope. If you would like to be 100% sure, you would grind to a standstill. You cannot check about parts of a system which you know nothing about.
2. Systems (including computers and humans) cannot be built to avoid such things, either, as soon as they get complex enough.
3. One way to approach this is the DevOps/Agile approach of inviting failure, and failing hard and fast. This is what all the CI and expecially CD stuff is about. You deploy so frequently and fast, that you will fail very often; and each time you fix the particular reason with utmost priority (using the usual techniques - automated and manual tests, painless rollback of small commits, blue-green-deploys with snap-of-the-finger rollback-switchover etc.). This logically results in making the whole process more robust very quickly. Ideally you do that from day 0. Easy? No. Can be improved piece-by-piece? Yes.

Answer 7

Regardless of what you or anyone does to minimize mistakes, mistakes will happen.

There are, of course, technical "best-practices" that will help and yes, there's all the platitudes about learning from one's mistakes. But you got all that, it seems. Yet you still feel bad enough about the incident that you've taken the time to write it up on workplace.stackexchange.com?

I think there is something tangible that you can do that will help you and the others feel better about this whole thing.

The best thing you can do is to take note of kindness and generosity that was shown to you and express some gratitude for that.

Instead of apologizing even more profusely and making soon-to-be-forgotten "never-again" promises, take the time to personally THANK the folks that helped resolve the problem and those that you've inconvenienced. If it's appropriate bring a box of doughnuts (for example) to the office and complement your coworkers.

And then, the next time something happens and someone else makes a mistake, be nice to them, help them out and return the kindness that was given to you. That's it. You'll be a better team because of things like that.

Answer 8

Make your commits as small as possible, and if you can build from the build server after every push. (If it doesn't build often, you may want to build before your push, too!)

This won't help you not make mistakes, but it will make them much less critical. If you know what commit/group of commits caused the build to break it is trivial to revert it while you work on the problem, and if commits are as small as possible then it is easier to locate the source of the problem.

If you are using git, there is even a command to help with this: git-bisect , which will let you do a binary search through a group of commits to find the one causing the problem.