Process
The first step of troubleshooting is not finding someone to blame for the problem. It is also not Googling wildly and moaning about how no one has ever encountered your exact problem. Troubleshooting is not a gift or a talent, it is a learned technique, and anyone can learn it.
When you troubleshoot:
- Define the problem
- Isolate the problem
- Form a hypothesis
- Test your hypothesis
- Repeat until problem is solved, or proven unsolvable
The last point is very important. There are only 2 types of problems:
- Those you can solve
- Those you can’t
Long before you give up and declare a problem unsolvable, at least make sure you’ve tried everything you can think of. Google is not a replacement for the scientific method.
If you over specialize you will die a slow and painful death. No matter how much money you’re making being the soul living expert of a legacy system or technology, it will catch up to you when you inevitably have to switch jobs. The flip side is that if you over generalize, you won’t have any marketable skill, as no one will know what you’re good at and therefore how to use you. The best approach is to pick a specific area you’re passionate about, and become a generalist with a high degree of proficiency in all the relevant skills.
You can only propose a solution to a problem if you have knowledge of how to solve the problem. This is a indisputable fact. If you have lots of knowledge of how to solve a problem, you can propose lots of solutions. However, if your knowledge is limited…
I often get the feeling that quality would be higher if there were no QA people. My thought is that without QA, 100% of the accountability falls on the engineer to find and fix bugs. Additionally, since many engineers don’t or won’t manually test their work thoroughly, being accountable for finding and fixing their own bugs puts more pressure on the engineer to write automated tests.
This, of course, is dependent entirely on how much the engineer cares about there being bugs in the system. Most engineers don’t care, using the rational that bugs are simply a by-product of developing software, and having a certain number of bugs should be acceptable. Furthermore, some bugs are minor, and should be de-prioritized in favor of high priority bugs, so really there are some bugs that will never be fixed by virtue of responsible triage based on business priority.
These types of engineers are typically lazy bastards and are unaffected by the presence of QA – they will do whatever they feel like, largely because they can get away with it. If you work with these types of engineers just figure out what they did to get such a sweet deal, and get career tips from them.
The engineers who benefit most from not having QA are those who are not lazy bastards. These are engineers who take pride in their work, and don’t want any bugs in their system, but who make honest mistakes. Without QA, these engineers get better.
“Like” if you’d like me to write this article
“Like” if you’d like me to write this article
“Like” if you’d like me to write this article
“Like” if you’d like me to write this article
“Like” if you’d like me to write this article
“Like” if you’d like me to write this article