A repository for helping new developers/engineers to quickly start up improving their skills.
Your systematic approach to troubleshooting should involve five basic steps;
- Information Gathering
- Analysis and Planning
- Implementation of a solution
- Assessment of the effectiveness of the solution
- Documentation of the incident
Below we will address these steps individually.
Information Gathering Before we can determine how to address a problem--or even assess what the problem is--we must gather information. Gathering information can be particularly challenging when the problem manifests itself at the client side. You might have to formulate your questions carefully in order to get meaningful information. Log files contain great information you should consult during the data-gathering stage. Try to avoid assumptions. If you reach the end of analysis and can not find the issue re-visit the information you have and look for where an assumption has been made. This is a great opportunity to slow down and carefully read documentation and logs, do not skim them.
Analysis Once we have gathered the data (including attempting to reproduce the problem), it's time to analyze the data. The primary task in this phase is to look for patterns. An important part of the analysis phase involves prioritizing. This includes prioritizing the problems, if there are multiple problems. Performance problems are generally less urgent than access problems.
Solution Implementation Although there could be several possible solutions to a problem, you should always implement one change at a time. Assess the results of that change before trying something else. This will save you time in the long run. Start with the most obvious or most impactful change first, if they are all not obvious or may not be impactful, go with the easiest to validate.
Assessment It is vital that you assess the results of your actions and determine whether the "fix" worked, whether it was a temporary work around, or whether it caused additional problems.
Documentation After completing your assessment, you should develop a summarization of the problem, which should include the reported and observed symptoms, the corrective actions taken, and the results of those actions.
Adapted from The Five Steps of Troubleshooting
As an engineer you will eventually hit things you just don't know and your google-fu is failing you.
How to ask questions is a critical skills
Standards are great and help make a project flow better. If you are starting a fresh project try to follow all of the best practices and get them in place before a lot of code is there. It's much hard to follow best practices after the fact. The caveat to this is when working on an existing project do not, try to change to some new standard. Follow the existing set of principles in place and get to know the project and it's developers before trying to enfore some new "standard" on them.
- Makefile, one standard when working on open source repositories is common conventions. Common make targets also flow over to other systems such as ruby, python. Though perl chose a different standard with
make testinstead ofmake check. Generally follow these standard targets unless you need to disregard them.
- Sed
- jq
- grep
- find
- man
- vim
- Yes there's a lot more to vim, start slow.
- Cheat Sheet
- awk
- GNU Tools
- Task runner
- git - the simple guide
- Git 101 — Introduction to Git for Newbies
- Git Documentation
- Writing Git Commit Messages
- How to Write Better Git Commit Messages – A Step-By-Step Guide
- Art of writing a good commit message
- Getting Git Right
- Automate the Boring Stuff with Python by Al Sweigart
- Real Python Tutorials
- Al Sweigart Twitch
- Learn Python Reddit
- Python Reddit
- r/python discord
- Introduction to Python
- Koans Part 1
- Koans Part 2
- The Modern JavaScript Tutorial
- The TypeScript Handbook
- JavaScript Algorithms and Data Structures
- JavaScript Naming Conventions
- Better Jasmine Tests With this
- Koans
- Reflection