Writing software is all about communication.
Code is a way of conveying the meaning of natural language requirements in an exact manner so that computers can make sense of the intentions of our fickle human minds and the often ambiguous ways we tend to express ourselves in.
So, in that respect software development amounts to translating human concepts and notions into a language machines can understand.
However, communicating with machines is only one, more technical aspect, of writing software. The by far more important facet of code as a means of communication is communicating with other human beings. Unlike common belief, software development is a highly communicative trade: Business requirements have to be clarified; problems and impediments need to be discussed; progress (or lack thereof) must be announced to the team; both released products and internal APIs have to be documented to be useful.
By writing code, not only do you tell a machine how to deal with data inputs and workflows but you’re entering a conversation with other developers as well, including your future self! Who hasn’t experienced a WTF moment after looking over one’s own code after a few weeks and being at a complete loss as to the original intention of that code segment? This is also why personally I’m averse towards code comments (especially those mandatory ones enforced by code style guides):
If you need to comment your code you haven’t been communicating clearly enough in the actual code in the first place and your code likely can be improved upon! So, instead of wasting time commenting your code, try to improve the code itself to make it more comprehensible.
In this regard, web developer Christian Mackeprang wrote an interesting blog post about writing good code and how to reduce the cognitive load of your code. Christian mentions several good habits for writing readable, understandable code such as dividing code into small, digestible parts.
These habits are a good way to start becoming a better communicator through code.