In my time as a professor I've read hundreds of draft papers from students. Students tend to make the same errors in the early period of their development. Some students make the same errors repeatedly. Old habits die hard.
The most fundamental challenge is to organize and linearize a complex thought process and a lengthy research process into text that seems simple and straightforward to a reader. Students often seem to resist it, because deep down they feel that all the hard work they have done couldn't possibly distill down to a simple paper. Resist the temptation to make things sound more complicated than they are. Simplicity and elegance always win in the end.
A good technique for organizing is to start with what is essential. The intro for any paper must be short, but it must communicate essential information to the reader:
The intro should never contain technical details: push them back and craft your intro around the essentials. For the rest of the paper, each detail has a rightful place in a logical progression of sections. The exact structure might be domain-specific, but for systems papers the classic structure is:
Essential "big picture" details should show up in the overview, along with enough related work to set your work in context, but not so much as to define your work in terms of others. Define categories of related work in the overview, cite the relevant papers in lists, and forward reference a related work section that discusses them in more detail in the back.
A key purpose of the overview is to define terms. Pick terms carefully, define them clearly, and use them consistently. Finding the right terminology makes all the difference. Language shapes thought.
At the end of your overview (3 pages), your readers should understand why they should read the rest of the paper, or why they should recommend its acceptance. They should know what the rest of the paper says, why it is important, and how it builds on the state of the art. All the rest is execution. Execution is critical, but it is worthless unless the context is clearly established and accepted. The execution may be incoherent without the right structure to hang the details on. Context is essential.
Any detail that is not essential to establish context has some rightful place in the DIE sections. Design should be broad enough to encompass a range of instantiations of the key ideas, not necessarily limited to what you actually implemented and evaluated. Don't mix implementation details into design.
Depending on the work, the heart of the paper is either design or evaluation. Structure appropriately. Do your ideas propose a new architecture, a new way to think about or approach some set of goals? Or does it propose a better way to achieve some particular goal?
Evaluation begins with methodology. A reader who does not understand and accept the methodology will not read the results. Every figure includes a caption that tells the reader what to conclude from the figure. It should be possible to understand the entire performance section by reading the figures and their captions.
When I mark up papers, I use a few custom notations for common errors: