# Taking Responsibility for Your Actions

DevFeed: [Taking Responsibility for Your Actions](<https://devfeed.tech/articles/taking-responsibility-for-your-actions-24961.md>)

Original publisher: [Read original article](<https://codeahoy.com/2016/11/14/taking-responsibility-for-your-actions/>)

Author: umer

Published: 2016-11-14T00:00:00Z

Content type: opinion

Language: en

Sources: [Code Ahoy - Articles](<https://devfeed.tech/sources/code-ahoy-articles.md>)

Topics: [Programming](<https://devfeed.tech/topics/programming.md>), [Software](<https://devfeed.tech/topics/software.md>), [Testing](<https://devfeed.tech/topics/testing.md>)

Tags: [developers](<https://devfeed.tech/tags/developers.md>), [management](<https://devfeed.tech/tags/management.md>), [mistakes](<https://devfeed.tech/tags/mistakes.md>), [programming](<https://devfeed.tech/tags/programming.md>), [software](<https://devfeed.tech/tags/software.md>), [solutions](<https://devfeed.tech/tags/solutions.md>), [work](<https://devfeed.tech/tags/work.md>)

## AI overview

The article argues that software developers should actively accept responsibility for their careers, projects, and daily work. When mistakes occur, it recommends acknowledging them without deflecting blame and focusing on practical solutions, while recognizing that responsibility requires agreement and does not imply complete control.

## Source excerpt

I read Pragmatic Programmer whenever I get a chance. It's such a great book. I was skipping through the pages today and landed on the first chapter. After (re)reading it, I can say that it is arguably the best chapter in the book. All software developers must read it once and live by its philosophy: One of the cornerstones of the pragmatic philosophy is the idea of taking responsibility for yourself and your actions in terms of your career advancement, your project, and your day-to-day work. A Pragmatic Programmer takes charge of his or her own career, and isn't afraid to admit ignorance or error. It's not the most pleasant aspect of programming, to be sure, but it will happen--even on the best of projects. Despite thorough testing, good documentation, and solid automation, things go wrong. Deliveries are late. Unforeseen technical problems come up. In your career, you will make mistakes. They are inevitable. I can't count the number of times I have made mistakes. So when you do make a mistake for something you accepted responsibility for: Don't deflect responsibility. Don't blame another team member. Don't blame a vendor. Don't blame a library or a tool that you use. Don't blame management. Don't become defensive. Sure any of the above factors could have played a role in the failure. But deflecting responsibility by making excuses or blaming someone or something is the worst possible way to handle such situations. What you should do instead is own up and offer solutions. That's what your coworkers and management are interested in. I'm reminded of this email from Linus in which he gets furious at a kernel programmer for making up "lame excuses". (For the record, I strongly disagree with the language in the email.) Responsibility is a two-way street. It has to be both given and accepted. I have seen managers foolishly thinking that they can walk up to an employee say out loud "You are responsible for this" or "You own this" and walk away. If the employee doesn't accep