When “Shit” happens, take responsibility

When “Shit” happens, take responsibility.
One of the things you need to learn early in your career as an aspiring software professional is the habit of taking responsibility for yourself and your actions.

It is never easy to take responsibility for your actions, especially when those actions have consequences. But rest assured, it is worth it.

To reach your potential as a software professional, you must continually improve yourself, and you may not do that if you do not consciously take responsibility for your actions and learn from your mistakes.

The truth is that you will face challenges that you are completely new to.

Despite thorough testing, good documentation, and solid automation, things still go wrong. Unforeseen technical problems come up.

These things happen, and we try to deal with them as professionally as we can.

You may work incredibly hard to make sure that no mistakes happen on the application you are working on. But sometimes, even under the most controlled environments, “shit” still happens. Your code could break things.

Something as small as forgetting to add a closing curly bracket on a code block could mess up your application branch or maybe you accidentally push a work-in-progress state to remote, the master may be potentially broken. This can significantly impact the behavior of the application.

When you do accept the responsibility for an outcome, you should expect to be held accountable for it. When you make a mistake (as we all do) or an error in your code, admit it honestly and try to offer a possible solution to resolving the error.

You don’t have to blame someone or something else or make up an excuse. Don’t blame all the problems on a particular library, framework, programming language, or your coworkers. Any of these may play a role, but it is up to you to provide solutions, not excuses.

Before you inform your Engineering Manager or your team members why something can’t be done, or is broken, stop and think if your excuse sounds reasonable.

Sometimes I find the sentence "It can't be done or it's not possible" as inappropriate to say as a software professional. Instead of excuses, provide options.

Don’t say it can’t be done; explain what can be done better to salvage the situation.

Does the code have to be refactored? let them know, and explain the value of refactoring. Do you need to spend more time prototyping to determine the best way to proceed?

Perhaps you need additional resources to complete the task. Or maybe it’s just you: do you need to learn some technique or technology in greater depth? Would a book or a course help? Don’t be afraid to ask, or to admit that you need help.

Stepping up and taking responsibility for your action is one of the most important things you will ever do in your journey to becoming a professional software developer.