Conclusions in CS papers are generally worthless. The contribution of the work is typically not new knowledge, but a thing - a system, a technique, an algorithm, a language, a framework, etc. So the conclusions in CS papers tend to be "We presented a foo for a blah blah blah." I joke that conclusions in CS papers are mostly vestigial, and exist only because they're expected to exist. (Please note that this bothers me, and I try to include actual conclusions in my papers, which will take the form of general principles we can learn from this new technique or system that we're presenting. But such discussion is not needed, and is often cut due to space limitations.) So, skip the conclusions sections in CS papers.
The introduction can also usually be skipped, if it's an area that you are already familiar with. CS papers tend to have to tell a "story", and the introduction sets the scene for why the work is relevant and who cares about this sort of thing. These introductions can start out very broad and general, trying to motivate the work from larger trends in industry and society. (Yes, even CS systems papers will appeal to larger trends in society to motivate their work. There are a lot of CS systems papers which will appeal to the prevalence of, say, online social networks to motivate their work on the systems required to support such things. Such as graph processing or real time data management.)
If you are familiar with the field, you can typically skip all this. You already know it. Please note that introductions are great if it's a field you're not as familiar with.
A CS systems paper typically has the structure similar to: 1. Introduction; 2. Background; 3. Design; 4. Results; 5. Related Work; 6. Conclusions.
If I want to quickly assess if a CS paper is worth my time, I typically read the title, the abstract and then skim the Design section and skim the Results section. (Of course, if it's my field, I often can't resist just skipping to the Related Work to see if they cited me.)
If the paper passes my first look, then I'll typically start by reading the Design. If I hit any difficulty in understanding the Design section, then I'll jump back to the beginning to get the proper context. I don't bother reading the Results section until I understand what they did, and think it's reasonable. (If your Design section tells me how you implemented the best 3-wheel car in the world, I'm not going to bother reading your Results. I don't care to try to reason about the performance of your 3-wheel car, because 4-wheel cars exist - unless you can convince me of situations where 4-wheel cars are not an option. That's a hard sell, though.)