How do I stop making silly mistakes at work? [closed]

Question

I have been working as a software engineer at a small IT consulting firm for 3 years now. I try to do excellent work but very careless and silly mistakes creep into my work. For example, sending email to the wrong person, forgetting an important part of report, deploying the wrong build on live server, missing important bugs in code etc. No matter how much I try to avoid mistakes, I still make them. My manager remains angry and mad at me and says that he can't expect stupid things from an experienced professional. He has warned me that if I make any more mistakes he will suggest to the higher management to fire/replace me.

How can I become excellent at my work? What tools/methods can I use to eliminate mistakes forever?

Answer 1

Three things will help you to be more accurate:

• use checklists and procedures (write your own) and follow them. Include steps like 'double check which server you are targeting'. When the consequences of a mistake are high, actually print the list and check things off with a pen as you go.
• when technology helps you, take a moment to check. Say your email client fills in the To line after you type the first letter. Don't just type the letter and click Send. Stop and look and see what it filled in.
• whenever you make a mistake, ask yourself why. What step did you skip? What did you not look at? Why did the right thing and the wrong thing look so similar? How could it be easier to be sure you're doing it right? Update your procedure with what you just learned.

Over time, you will develop habits and processes that ensure you do things correctly. As a matter of fact, that's pretty much what experience is.

Answer 2

How do I stop making silly mistakes at work?

You have a work quality problem and need a system to discover errors in order to create appropriate feedback for improving/developing personal procedures and work habits. Quality improvement has to do with the development of mechanisms for discovering errors and the cause of them, then developing an action plan for correcting them.

Step 1: Recognize that the mistakes are not "silly" - they are serious. You may lose your job over them. I think a big indicator of your problem is that these seem like things that are easy to prevent, and yet you are still doing them. By not preventing them, however, you have a serious problem.

Step 2: Slow down. Too often "rock star" programmers and engineers are seen as the ones that move fast and furious - nothing stops them! The reality is that they are not like this. There are situations where this happens, but there are lots of situations where it is not true. Stop feeling rushed, take a breath and slow down.

Step 3: Before you "finish" something, stop and take a break, then return to it and review. Get coffee, read an email, or something not too distracting, to take your mind off of the task at hand so you will have a fresh perspective when you return to it. You may feel like this will slow you down or reduce your productivity. However, this approach allows you to notice mistakes early, which is important to being productive. So before you hit "send" - go read another email or check the status of a server or something. This is not just about writing code.

Step 4: When you find an error, don't just fix it. Take a moment to try to figure out why the error occurred. Where you rushing? Copy/paste error? Reliance on someone else's work or opinion? This will help you be more aware of the cause of errors at the time they occur. Finding out later is not very helpful, as you know.

Step 5: Track your progress. Pay attention to the utility of your new habits and practices. Keep a spreadsheet to count errors or issues you found after taking a break. Also, note if a discovery prevented something that would have angered your boss or been embarrassing. This develops your ability to self-assess the acceptability of your own work better and also to try to learn what habits are most effective.

Step 6: Develop procedures and checklists (or update existing ones) where you see patterns emerge from your observations above. You can't develop checklists or procedures for everything, so after a while (or even fairly quickly) you will find patterns of errors where you can create a reproducible method for preventing certain kinds of errors. This is only useful for frequent tasks that are complex. Otherwise you will be tempted to not check the list, not keep it current or you may make more lists and procedures than you can manage, making them obsolete and out of date - possibly leading to more errors.

Try different approaches to discovering where your errors are before they become problems. While a lot of the responses here focus on developing processes/procedures/checklists (especially around code development), the premise of "quality management" or "quality improvement" has to do with error detection as a means of feedback for process development and/or improvement. You can't develop a "better" process if you don't know the cause of the errors. Work on discovering the cause of the errors Most likely you are just rushing and not "double checking" your work. These are some tips for making a slower pace more productive.

Answer 3

Stop Working. That's the only way to stop making mistakes.

No, seriously: You're always going to make some number of errors. That's part of being human (which I feel is safe to assume you are). Any professional developer is going to produce work with some number of bugs, and that's OK. This is the reason that we have things like Test Driven Development, Unit Testing, and Quality Departments. If your manager is expecting Bug-Free software on the first pass, then you aren't dealing with reasonable expectations.

That said, we live in a world where we can't stop working just because mistakes happen, so we take steps to reduce the risk of error. I work in a Manufacturing shop, so the catchphrase is Poke-yoke (literally Japanese for Mistake-Proofing); which is an automated process designed to eliminate human error. This means automation. I definitely recommend moving to an automated build process for deploying software to production. This will require involvement from more than just a single developer, but it's worth pushing as far as you can.

Where you can't automate, take your time. Many errors can be prevented by taking time to review before committing an action. Take a minute to look over your code before committing changes. Spend the extra minute to review emails before pressing that fateful Send button.

Finally, don't be afraid to ask for help. As a developer, one of my first courses of action upon finding a bug is to ask a trusted coworker to take a look. A fresh set of eyes can see all sorts of problems that you have unconsciously filtered out. And if you don't have a trusted coworker, find a new job; it sounds like you're a junior/mid level developer, and you need a support system to grow as an Developer. Having other software developers to bounce ideas off of is not an optional part of your development as a Professional Software Developer.

In Short: Automate where possible, take your time when it isn't, and don't be afraid to ask for help.

Answer 4

You will of course never be perfect, but there are ways to improve accuracy. The best course I think is to introduce additional procedures that isn't just double checking your own work, as people are naturally prone to making little mistakes. You aren't very likely to catch these kinds of things just by "being more careful" or "double checking," so just trying that is setting yourself for failure. Some specific suggestions:

1. Unit tests. With proper unit tests, any time you make a change to the code, run the tests on everything, and that will double check for you whether you inadvertently introduced a bug.

2. Better deployment procedure. Deploy to a staging server first, using the exact commands you would use for prod, and verify there the deployment is correct, before going to production.

3. Barring unit tests, set aside time in every deployment, once you believe you are done, to go through your build and test as much of it as you can yourself again. Don't just test those areas you think you've changed.

Whenever you make a mistake, try to think of solutions along these lines, to set up safeguards against natural human error, and present these ideas to your boss.

Answer 5

No, you won't eliminate mistakes. But you might be able to catch the most important ones. It's important to be conscious of what you are doing and look for ways of doing it more safely.

Identify risky endeavours. You can't be on your guard every second of the day - but everyone makes tiny errors all day long. Most mistakes can be fixed effortlessly, so get better at noticing when something has the potential to go wrong in a way that can't be so easily fixed. Any communication with a client, any deployment to a site, any global change to a document, etc.

Question what you are doing. Do you understand what you are doing, why, and how? Can this be done more safely? Are you sure it is better to do it than not do it?

Pause before going ahead with risky endeavours. Don't send an email without checking recipients, subject, content, and attachments. One by one. Take your time. Sending a quote for Client A to Client B could lose both clients. Better to spend a minute or so checking it through. Don't be tempted to rush, even in an 'emergency'.

Have a recovery plan. Know in advance what you will do if something goes wrong. Prepare so that if you do need to rectify your mistake, you can do it quickly - but without rushing. How will you know if you did something wrong? Is there a way to find out sooner?

Document anything that has many steps. If you have documentation, follow it like a checklist so you can tell if it's good enough or if it's outdated, incomplete, or faulty. Even if you only do it once - before you write your report, write a list of all the things that need to go in.

Track to-dos especially if forgetting is a problem. Anything you need to do and aren't doing right now should go in there. Track them all in once place and keep going back to your to-do list. Don't rely on post-it notes folded up and stashed in your back pocket.

Automate wherever possible. If you have a list of five things to type in, can you write a programme to do those five things and then you only have one thing to get wrong? If you are making software, can you run automated tests to pick up when you introduce bugs? Do you aim for 100% coverage? Do you test with the goal of breaking your code? Do you have continuous integration so you don't have to worry about forgetting to run tests?

Ask for a second opinion if you are doing something risky that you can't verify and can't easily recover from. It's a common practice for software that code is always tested by someone else before being accepted.

Learn. Every mistake made is an opportunity to revise the process.

Take care of yourself. Find time during the day to clear your mind and have a few minutes of silence or relaxation. Before work, after work, lunch breaks, etc. Get enough sleep. Eat regularly and healthily.

Answer 6

I've worked as an software engineer/architect for over 10 years, and I can say for certain that you'll never eliminate all mistakes. The best advice that I can give you is to determine which tasks are highest risk and take steps to mitigate that risk.

1. Most of the time, sending an email to the wrong person isn't a big deal. I couldn't tell you how many times I've received an email meant for one of the other Jennings' that work here. But if you're sending an email that may contain sensitive information, always take time to double check the recipients and the content.
2. If you're writing an important document, write an checklist/outline of what needs to be in it and double check the content before submitting.
3. For deploying builds, always use an automated process and deploy to secondary server first if possible. My team deploys our Ruby services to a secondary server, tests, and then flips the secondary server to primary. If there is any problems at that point, we can always just flip back to the old server. If neither of these things are possible, this carries a much higher risk, so my advice is to spend extra time and attention to the task. Double and triple check everything for each step that carries a high level of risk.
4. For bugs in code, ensure that you are writing good unit/integration tests that cover normal workflows and edge cases. It is a good idea to make sure that the project as a whole has as high unit test coverage as possible to ensure that if you change something that breaks something else, a unit test will fail and you'll catch the bug early. This won't catch all mistakes, but is a good start. Once the code is ready for blackbox testing, don't just test the workflow your code touches, analyze what other portions of the project your code may have impacted and test those workflows as well. Blackbox testing should also cover both normal and edge cases.

Outside of this, I would just say to spend more time and attention to higher risk tasks than you normally would for day to day tasks.

Answer 7

How well documented are the processes you have? For example, deploying the wrong build on the live server sounds like it could be a major error that should be minimized by having redundant checks in place to ensure build X goes to server Y while software may well have bugs in the code as things may not be caught that easily. I'd be tempted to create solutions and propose them to the boss so that some mistakes can be avoided in the future. Be aware of what you may want to check a few times over and what may not be that great to do a bunch of checks against.

Unfortunately, you are human and thus mistakes will happen. Perfection is rarely attained as more than a few of the so-called greats in sports missed the game winning shot like Michael Jordan. If you want some therapies look into Cognitive Behaviour Therapy, Dialectal Behaviour Therapy, as well as Acceptance and Commitment Therapy that would be used to battle the negative thought pattern you have here of wanting to be perfect. Mistakes will happen, the key is to consider how do you respond to them and how good is your emotional intelligence as self-awareness and self-management could be something else to study if you want another idea.

---

For somewhat documented, I'd consider updating the documentation and adding more checks that may be useful for the important stuff. In a way this is similar to people that would suggest waiting a handful of seconds before proofreading an e-mail you want to send so that it doesn't have typos in it that can be a useful tip in some cases.

Answer 8

I'm in the same boat as you in some cases but I'm from a different background. When we push code live at my old job, we had automated processes in place. At the new job, we unfortunately cannot put in automated process. As such, I miss tiny details here and there which shouldn't be. My manager is much nicer about it, though but disappointed.

In any event I have improved myself by first making sure I write down steps on a notepad. I make sure I have the list of files I want to push up, and double check it before doing it. I also have a mental procedure of what I'm going to do prior to doing it. It helps. Just pretend like you're doing it before you do it to make sure you didn't forget anything.

I'd like to also add that you should get with your manager. A one on one and explain you like to improve and outline how you would like to do it. Explain you're missing some small details here and there and you'd like to improve. Perhaps he could give suggestions but I would say if he's threatening to fire you on small details then that is something you'll have to consider and prepare for.