At a meetup I was at recently, the speaker asked what we thought were the most important soft skills. My answer was English, or more generally, communication.
Programming can be thought of as communicating with the computer – telling the system what we want it to do – but software development is often just as much about communicating with other people.
- Before we code, we (sometimes) write a design that lays out exactly what the code should do.
- When coding, we (hopefully) name our methods and variables, and sometimes even comment, in such a manner as to make it clear to the future reader (whether that be ourselves or another programmer) exactly what’s going on.
- After the code is complete, we may write testing instructions that should be clear as to exactly what behavior is expected from the code.
These are all areas where many people get sloppy. The design doesn’t really explain what the new expected behavior is, the code is difficult to read, the testing instructions are essentially just “make sure it works.” Often much of this documentation fails to be complete sentences. The result is debate over whether or not the code is working correctly, because the stakeholders don’t have a shared understanding of what “working correctly” looks like.
For the QAer, clarity can be even more important: a bug report is much more useful when it specifies exactly what the problem is, what should be happening, and how to reproduce the issue. Specific, actionable bug reports tend to be acted on; vague notes that don’t explain how to reproduce the problem tend to sit in the bug tracking system for years until they eventually get closed as obsolete (or blow up).
Take the time to communicate clearly; it speeds things up in the long run.