All code is written to be read. The end result of all that writing is for a computer to read and execute that code. A computer is a machine that will execute the code exactly as it is written with no ambiguity or complaint. So do we care about writing code for a computer? I would argue, No! We should be writing code for the people who will read it later.
Why should we care about readable code? As developers we spend most of time reading existing code. The easier it is for you to read that code the faster and more accurately you understand it. Even if you are the only person working on code it is very likely that at some point you will have to come back and update the code later and you will not remember all the details.
Flow is a necessity of readable code. By writing code that flows in a linear fashion you make it easier to read. Keeping variables defined just before they are used and related operations close together helps the flow stay linear. If you have to jump around the code to find out about something that happened earlier then it becomes harder to keep track of what is going on.
One of the best ways to write readable code that flows is to keep it simple. Simple code is easy to understand and the intent should be obvious at a glance. Complicated operations, references to variables set outside the current scope, and multiple levels of nesting are all enemies to simple code.
Naming of variables and functions can either be a help or a hindrance. Poorly named functions and variables will require looking up those values to determine their purpose. Well named functions and variables add to the meaning of the code and can help with flow by conveying extra information to the reader. Well named functions are also a great way to move complicated code and express it in a meaningful way.
Consistency is another great aspect of readable code. If some of the code uses different whitespace formatting, different styles of naming variables, or other possibilities then the reader has to adjust and work harder to understand those differences. Having consistency allows the reader to focus on intent of the code without being distracted by unrelated differences. This is where coding standards is a good thing. Pick a coding standard and stick to it.
Comments in code, like function names and variables, can either help or hurt. Comments should be sparse and add to the flow or understanding of code. Comments that reiterate what the code is doing are probably not helping and will, over time, become incorrect. If the comment is describing what code is doing because it is not obvious then you may need to rewrite the code to be more understandable. A comment should tell the reader why something is being done, or add information that the code itself does not convey.
The goal is to make the code as easy to read and understand as possible. Take your time writing the code with a good flow and following the standards and styles for your project will go a long way. Think about other people reading your code. Seek out other developers to peer review your code and ask them if the code is easy to understand.