- What issue(s) have been reported?
- What sort of abnormal behaviour have you noticed?
- What error(s) are you seeing?
Many problems a team encounters will have a direct impact on how people use your sites. It is very important to understand how your work will affect your customers before you decide on a solution to the problem. If you don't, it will be tempting to write code that "fixes" the immediate issue but does not really improve the system as a whole. Instead of making the system better, you will have introduced technical debt that will be paid back in the form of unexpected problems or reduced flexibility later.
Sometimes, you will find that a issue that appears simple on the surface is actually a symptom of a much deeper problem and will take longer than expected to fix. In these caes, it's essential that you let your manager and/or technical lead know so they can help you find the correct solution and allocate enough time for it to be implemented.
There are an inifinite number of things that might affect customers. Here are some things to think about but do not consider it a complete list.
- Activities a custamer cannot perform because of this problem
- e.g. not being able to find some kind of information or not being able to buy something
- A poor user experience
- e.g. Missing information, broken links, missing images, confusing error messages
Some problems may not directly affect your customer, but they still are important because they give a bad or unprofessional impression of your company.
Again, the list of possible impacts is infinite and overlaps with the user experience section above, but here are some examples of the sort of thing to consider
- Badly worded copy and spelling mistakes
- Styling and layout problems
- Inconsitencies between different areas of the site
- Slow responses
- 500 errors
- Tehcnical errors leaking through to the user
Every time you touch the code, you should leave it in a better state than you found it. Bad makes the system hard to work with and slows your team down. Examples include...
- Confusing and badly written code
- Bloated CSS
- Tangled and complex dependencies
- ... which are often caused by a lack of modularisation and/or poor abstractions
Sometimes you will run into a problem that does not have any effect on your customers but still needs to be resolved because it is slowing your team down.
As well as understanding the impact of a problem on the customer, you also need to understand the techical issue. A big part of this is taking a moment to step back from the immediate symptom of the problem and looking at the system as a whole to find out where the best place to solve it might be.
An "upstream" system is one that provides data or services you rely on. For example, if the problem occurs in a system that recieves a nightly dump of data from another system, the system that provides the data is upstream.
A "downstream" system is one that consumes data or uses a service your system provides. For example, if the problem occurs in a system that provides an API, then the systems that call the API are downstream.