14 answers
Xavier
Student
Glendale, Arizona
1
Question
Updated
843 views
What are an engineer's first thoughts when dealing with a problem?
I am a freshman whose dream job is to be an engineer and I want to know what I should look for when faced with fixing a problem.
14 answers
Donald Martin
Information Technology
4
Answers
Belleville, Michigan
Updated
Donald’s Answer
This may be a repeat from some of the other responses but the biggest thing I have learned is to break the system down into known parts. Once you can view a system in its smaller parts you can break down what part has a good input with a bad output and focus your efforts there. Try not to assume you know the issue and jump into the weeds too quickly.
Once you can isolate it to a part of the system it will help you in finding and resolving the issue.
Once you can isolate it to a part of the system it will help you in finding and resolving the issue.
HIMABINDU KANDUKURI
Software Engineer
5
Answers
San Jose, California
Updated
HIMABINDU’s Answer
When engineers face a problem, their first thoughts typically include:
• Understanding the problem: what exactly is the issue? Gather all the relevant information
• Breaking it down: divide the problem into smaller manageable parts
• Identifying constraints: what limitations or requirements must be considered?
• Exploring solutions: brainstorm and evaluate potential solutions.
• Testing: test solutions to see what works best.
• Iterating: refine and improve the chosen solution
Look forward to being curious, methodical, and creative and solving problems
• Understanding the problem: what exactly is the issue? Gather all the relevant information
• Breaking it down: divide the problem into smaller manageable parts
• Identifying constraints: what limitations or requirements must be considered?
• Exploring solutions: brainstorm and evaluate potential solutions.
• Testing: test solutions to see what works best.
• Iterating: refine and improve the chosen solution
Look forward to being curious, methodical, and creative and solving problems
Varun Nagaraja
Software Engineering
3
Answers
DeBary, Florida
Updated
Varun’s Answer
As a seasoned software engineer, here's my uplifting approach to tackling any problem that comes my way:
1. Grasp the essence of the issue at hand.
2. Evaluate the immediate and long-term consequences if the issue isn't addressed.
3. Collect clues and traces that could lead to the root cause.
4. Assess the impact based on the root cause analysis, which wasn't considered in the initial evaluation.
5. Craft a plan and strive to prevent the same issue from recurring in the future.
6. Rectify any complications that the issue has previously caused.
Remember, a problem isn't always a setback. It's an opportunity for growth and a chance to learn from past mistakes and oversights.
Here's to joyful problem solving!
1. Grasp the essence of the issue at hand.
2. Evaluate the immediate and long-term consequences if the issue isn't addressed.
3. Collect clues and traces that could lead to the root cause.
4. Assess the impact based on the root cause analysis, which wasn't considered in the initial evaluation.
5. Craft a plan and strive to prevent the same issue from recurring in the future.
6. Rectify any complications that the issue has previously caused.
Remember, a problem isn't always a setback. It's an opportunity for growth and a chance to learn from past mistakes and oversights.
Here's to joyful problem solving!
Anna Casto
Chemist
28
Answers
Saint Paul, Minnesota
Updated
Anna’s Answer
As others have mentioned, "why" is an important question. If something breaks or isn't working, ask "why?" Then when you have an answer, ask "why?" again. Going several "why"'s deep will help you get to the root of the problem and solve it long term.
For example: The tractor broke down.
Why? There are some holes in the metal - maybe something broke and got jammed in the moving parts.
Why? The floorboard looks rusty - maybe it was weakened by corrosion.
Why? The paint job looks uneven - maybe it didn't get painted all the way.
Why? Check with the paint manufacturers or painters and make sure all new tractors are getting painted correctly.
Of course, you would also want to solve the problem on the current tractor by cleaning out any broken parts, replacing or repairing the floorboard, etc.
For example: The tractor broke down.
Why? There are some holes in the metal - maybe something broke and got jammed in the moving parts.
Why? The floorboard looks rusty - maybe it was weakened by corrosion.
Why? The paint job looks uneven - maybe it didn't get painted all the way.
Why? Check with the paint manufacturers or painters and make sure all new tractors are getting painted correctly.
Of course, you would also want to solve the problem on the current tractor by cleaning out any broken parts, replacing or repairing the floorboard, etc.
Bryan Kalkhoff
Engineer
19
Answers
Rochester, Minnesota
Updated
Bryan’s Answer
Hello!
This is a great question. When I'm given a problem what I usually do is write down the question/problem in a way that works for me. My goal is to make sure I understand what the problem is and it allows me to start thinking of the different parts. Breaking down the parts would be the next step. Engineering problems are sometimes large and complex and if you try to tackle it all at once it can be very overwhelming.
I'm a very visual person so I often will make sure I have this list somewhere easy to access and look at.
Problems given to you will generally be rather specific, but if they aren't you'll need to ask questions. I would generally break down my list more and more until it's to a point where it's manageable.
At this point you can solve these little problems while keeping in mind requirements elsewhere (you can't one part too big if it'll impact other parts).
As you do this more and more you get better at being able to solve problems which allows you to not have to break down the requirements so much.
I'd also write down any information you learn while solving the problem. That way if you see something similar in the future, you can look back at what you did and see if that'll work again.
This is what I do when given a task and it works for me. The biggest thing I would suggest is break up the problem to be more manageable. That way you don't overwhelm yourself.
I hope this helps a little!
This is a great question. When I'm given a problem what I usually do is write down the question/problem in a way that works for me. My goal is to make sure I understand what the problem is and it allows me to start thinking of the different parts. Breaking down the parts would be the next step. Engineering problems are sometimes large and complex and if you try to tackle it all at once it can be very overwhelming.
I'm a very visual person so I often will make sure I have this list somewhere easy to access and look at.
Problems given to you will generally be rather specific, but if they aren't you'll need to ask questions. I would generally break down my list more and more until it's to a point where it's manageable.
At this point you can solve these little problems while keeping in mind requirements elsewhere (you can't one part too big if it'll impact other parts).
As you do this more and more you get better at being able to solve problems which allows you to not have to break down the requirements so much.
I'd also write down any information you learn while solving the problem. That way if you see something similar in the future, you can look back at what you did and see if that'll work again.
This is what I do when given a task and it works for me. The biggest thing I would suggest is break up the problem to be more manageable. That way you don't overwhelm yourself.
I hope this helps a little!
Steven Davis
Business Owner
5
Answers
Iowa City, Iowa
Updated
Steven’s Answer
Bryan's answer is spot on. The engineering "problem solving mindset" certainly includes the concept of breaking down a problem to its components.
I would add that it is important to understand how the thing you are solving is supposed to work as well. You cannot always treat components like a black box as there occasionally are side effects and other situations that allow those components to interact. It is always in an engineers best interest to develop components of a system that minimize these side effects but hard to ensure they are always completely removed. So as you are breaking the problem down, just make sure you know how the components work together and keep an eye out for any of those side effects.
To take it a step further, you can always try to understand the "why" for the problem. Why does this system act the way it does? What was its purpose and what problem was this system built to solve. That big picture thinking can help you in identifying alternative solutions or even perhaps improving the original design of the system while you are fixing it for the specific scenario that is currently breaking it. Also, this may help you build more resilient systems as you can think about the situations that haven't yet occurred and how the system should respond to those possibilities.
Good luck with your journey! Starting with this level of curiosity of an engineering mindset is surely an indicator that you have a bright future ahead.
I would add that it is important to understand how the thing you are solving is supposed to work as well. You cannot always treat components like a black box as there occasionally are side effects and other situations that allow those components to interact. It is always in an engineers best interest to develop components of a system that minimize these side effects but hard to ensure they are always completely removed. So as you are breaking the problem down, just make sure you know how the components work together and keep an eye out for any of those side effects.
To take it a step further, you can always try to understand the "why" for the problem. Why does this system act the way it does? What was its purpose and what problem was this system built to solve. That big picture thinking can help you in identifying alternative solutions or even perhaps improving the original design of the system while you are fixing it for the specific scenario that is currently breaking it. Also, this may help you build more resilient systems as you can think about the situations that haven't yet occurred and how the system should respond to those possibilities.
Good luck with your journey! Starting with this level of curiosity of an engineering mindset is surely an indicator that you have a bright future ahead.
Trent Buck
Manager
13
Answers
Boca Raton
Updated
Trent’s Answer
I will provide an answer from a different angle.
In the field an engineer might receive a report that there is a problem, this could come from a different department. So as an engineer, you might ask yourself if it is indeed an actual problem. Maybe the product works as designed but maybe not how an end-user is trying to use this product. So I would start by identifying if the reported issue is not working as expected. You would also attempt to reproduce the problem to verify the problem describe exists, it could be a bad report. From a software side of things, the problem might only be tied to a PC vs a MAC, or one browser vs another browser, or it could only be a problem for a user based on many other settings. Therefore you must attempt to duplicate the problem before attempting to fix it.
In the field an engineer might receive a report that there is a problem, this could come from a different department. So as an engineer, you might ask yourself if it is indeed an actual problem. Maybe the product works as designed but maybe not how an end-user is trying to use this product. So I would start by identifying if the reported issue is not working as expected. You would also attempt to reproduce the problem to verify the problem describe exists, it could be a bad report. From a software side of things, the problem might only be tied to a PC vs a MAC, or one browser vs another browser, or it could only be a problem for a user based on many other settings. Therefore you must attempt to duplicate the problem before attempting to fix it.
William Deich
Software Engineer
10
Answers
Sanford, North Carolina
Updated
William’s Answer
What I do is to think like a detective. I did not write the buggy code or install the malfunctioning software. So start by gathering information. Try to reproduce the problem. Is it happening on every computer where the software is installed? If it is a website & working in the User Acceptance Testing environment & not in the Integration Testing environment, then look at code changes between UAT deployment & INT deployment. Run the website from your local development computer & debug that part of the code. If it is not a website, but an end user program, like Office, then check if it is working on some people's computers but not others. Look for setting differences between the computers and check if the license is activated correctly.
Swathi Ravalcol
Software
3
Answers
Austin, Texas
Updated
Swathi’s Answer
Great question.
1. Understand the problem and breakdown: First understand the problem, which you are dealing and breakdown it to simple tasks
2. Understand the whole context of the problem: Some of the times solution might vary based on the whole context. Always try to understand the whole context/application where the problem exists and what are the implications
3. Solve step by step: provide solution step by step by performing unit tests at each step
4. Best practices: Follow best practices in order to make sure reviewers understand the logic/solution implemented
5. Regression: Once the problem is solved try to perform end to end testing for the context to make sure there no other regressions.
6. Review: Send for code review and address the feedback
1. Understand the problem and breakdown: First understand the problem, which you are dealing and breakdown it to simple tasks
2. Understand the whole context of the problem: Some of the times solution might vary based on the whole context. Always try to understand the whole context/application where the problem exists and what are the implications
3. Solve step by step: provide solution step by step by performing unit tests at each step
4. Best practices: Follow best practices in order to make sure reviewers understand the logic/solution implemented
5. Regression: Once the problem is solved try to perform end to end testing for the context to make sure there no other regressions.
6. Review: Send for code review and address the feedback
Natalie Kotsovska
Sr QA Engineer
6
Answers
New York, New York
Updated
Natalie’s Answer
Hey there,! It's awesome that you're already thinking about problem-solving. When faced with a problem, here are some informal thoughts that might run through an engineer's mind:
Assess the Situation: First things first, take a step back and assess the problem. What's going on? What are the symptoms? Understanding the scope and nature of the problem is key to finding a solution.
Gather Information: Next, gather as much information as you can. What are the relevant factors? Are there any constraints or limitations? The more you know about the problem, the better equipped you'll be to solve it.
Brainstorm Solutions: Get those creative juices flowing! Think outside the box and consider all possible solutions, no matter how wild they might seem. Sometimes the craziest ideas turn out to be the most brilliant.
Evaluate Options: Once you've got a list of potential solutions, it's time to weigh the pros and cons. Which option is the most feasible? Which one best addresses the root cause of the problem? Consider factors like cost, time, and effectiveness.
Make a Decision: After careful consideration, it's decision time. Pick the solution that you believe is the best fit for the problem at hand. Trust your instincts and go with your gut.
Take Action: Now it's time to roll up your sleeves and get to work! Implement your chosen solution and monitor its progress. Be flexible and ready to adjust course if needed.
Reflect and Learn: Once the problem is solved, take some time to reflect on the process. What worked well? What could have been done differently? Every problem is an opportunity to learn and grow as an engineer.
Remember, problem-solving is at the heart of engineering. Embrace the challenge, stay curious, and never stop tinkering. You're well on your way to becoming a rockstar engineer!
Assess the Situation: First things first, take a step back and assess the problem. What's going on? What are the symptoms? Understanding the scope and nature of the problem is key to finding a solution.
Gather Information: Next, gather as much information as you can. What are the relevant factors? Are there any constraints or limitations? The more you know about the problem, the better equipped you'll be to solve it.
Brainstorm Solutions: Get those creative juices flowing! Think outside the box and consider all possible solutions, no matter how wild they might seem. Sometimes the craziest ideas turn out to be the most brilliant.
Evaluate Options: Once you've got a list of potential solutions, it's time to weigh the pros and cons. Which option is the most feasible? Which one best addresses the root cause of the problem? Consider factors like cost, time, and effectiveness.
Make a Decision: After careful consideration, it's decision time. Pick the solution that you believe is the best fit for the problem at hand. Trust your instincts and go with your gut.
Take Action: Now it's time to roll up your sleeves and get to work! Implement your chosen solution and monitor its progress. Be flexible and ready to adjust course if needed.
Reflect and Learn: Once the problem is solved, take some time to reflect on the process. What worked well? What could have been done differently? Every problem is an opportunity to learn and grow as an engineer.
Remember, problem-solving is at the heart of engineering. Embrace the challenge, stay curious, and never stop tinkering. You're well on your way to becoming a rockstar engineer!
Raj Adepu
IT consultant
2
Answers
Seattle, Washington
Updated
Raj’s Answer
"Oh no. Not when I am on call".
Your 'Spidey Sense' need to be fine-tuned to zero in on the few areas that require your attention. It's not efficient to spend countless hours sifting through code, documents, or logs in an irrelevant component. So, our first response is usually to pinpoint the area that needs our focus. Engage with those who built the system (if they're still available) or delve into relevant documentation or past issues to see if this problem has been encountered and solved before.
If this isn't the case, don't hesitate to recreate the problem in a secure environment. Rule out all the elements that don't need your attention. Remember, like Reacher advises, don't make assumptions. They can lead you in wrong path when you're trying to solve a problem. Dismiss a scenario yourself and keep progressing. Increase your efficiency in completing checklists, dismissing irrelevant concerns/pathways.
Begin to dig into the logs and code. If you can recreate the issue and pinpoint the specific area that requires your attention, you will eventually resolve it in the end.
Solve gaming puzzles, sudoku or any other puzzles that interest you. Engineering problems are just large scale puzzles.
Your 'Spidey Sense' need to be fine-tuned to zero in on the few areas that require your attention. It's not efficient to spend countless hours sifting through code, documents, or logs in an irrelevant component. So, our first response is usually to pinpoint the area that needs our focus. Engage with those who built the system (if they're still available) or delve into relevant documentation or past issues to see if this problem has been encountered and solved before.
If this isn't the case, don't hesitate to recreate the problem in a secure environment. Rule out all the elements that don't need your attention. Remember, like Reacher advises, don't make assumptions. They can lead you in wrong path when you're trying to solve a problem. Dismiss a scenario yourself and keep progressing. Increase your efficiency in completing checklists, dismissing irrelevant concerns/pathways.
Begin to dig into the logs and code. If you can recreate the issue and pinpoint the specific area that requires your attention, you will eventually resolve it in the end.
Raj recommends the following next steps:
Dawn Cottone
Consultant
11
Answers
Gilbert, Arizona
Updated
Dawn’s Answer
Hello Xavier. Excellent question! I reached out to my husband who is a successful mechanical/aerospace engineer who had practical advice: 1) ask yourself the most cost-effective way(s) to solve the problem; and 2) make sure that your solution NEVER compromises safety. Best of luck in your career in engineering.
Lincoln Stewart
Software Developer
3
Answers
Mesa, Arizona
Updated
Lincoln’s Answer
Break down the problem and think about how many steps it could take to solve the problem.
Before you code anything you need to be able to say to yourself what you want the code you are about to write to do. You will save so much time once you do this instead of just jumping right in and coding.
Always solve in chunks and you'll reach the full working solution over time.
Before you code anything you need to be able to say to yourself what you want the code you are about to write to do. You will save so much time once you do this instead of just jumping right in and coding.
Always solve in chunks and you'll reach the full working solution over time.
Rabi Gartaula
Software Architect
2
Answers
Inver Grove Heights, Minnesota
Updated
Rabi’s Answer
Here is how I would look at any problem in general. By asking these 6 questions:
1. What exactly is the problem?
2. How did we get here?
3. What is the impact?
4. What would be a short-term solution (if needed)
5. What would be a long-term solution
6. How do we go about avoiding the situation in future.
1. What exactly is the problem?
2. How did we get here?
3. What is the impact?
4. What would be a short-term solution (if needed)
5. What would be a long-term solution
6. How do we go about avoiding the situation in future.
Delete Comment
Flag Comment