In the End, It's All Communication
From Programmer 97-things
Programming is often looked upon as a solitary and uncommunicative craft. In truth, it is the exact opposite.
Programming. That's you trying to communicate with the machine, telling it what to do. The machine will always do what you tell it to do, but not necessarily what you want it to do. There is huge potential for miscommunication.
Programming. That's you trying to communicate with other members of your team. You and your peers need to decide how your system will work, fleshing out different modules of your system and keeping them in sync. Failure to do so will inevitably lead to your system malfunctioning. Therefore, make sure the communication between the members of the team as high bandwidth as possible, favoring face-to-face conversation over email. Where possible, avoid remote working and have the entire team seated together.
Programming. That's you trying to communicate with other stakeholders of the project. It might be the IT department that will be in charge of the production environment. It might be the end users, providing you with information on how they actually use your system. It might be the decision maker who wants the system to carry out a specific part of their business process. Failure to communicate will inevitably make sure your system is unusable, unfit for production, or simply not the right tool for the job. Therefore:
- Even though you are a team, don't shut the other stakeholders of the product out.
- Work with usability as early as possible.
- Practice putting the system into production.
- Develop a common language for communicating the properties of your product with the stakeholders (in Domain-Driven Design this is referred to as the ubiquitous language).
Programming. That's you actually communicating with the programmers that read your code long after you've written it. If you fail to communicate the intent of your module, in time someone may misunderstand you. If that person writes code based upon the misunderstanding there will be a defect. Therefore:
- Write your modules to have high cohesion and low coupling.
- Document your intent by adding unit tests.
- Make sure your code uses the ubiquitous language of your problem domain.
Thus, in order to be a successful programmer, you need to be a great communicator. Don't be a mole, only poking your head above ground every few weeks with a new piece of functionality. Instead, get out there. Talk to users. Show your results as often as possible to the stakeholders. Employ daily stand-ups with your fellow team members.
Last but not least, seek out your peers and get involved in a user group. That way you're constantly improving your communication skills.
This work is licensed under a Creative Commons Attribution 3