Study syntax and data structures of the programming
language you intend to use before you begin coding.
It'll allow you to use the language to your full
advantage and write better code overall.
Study grammar and style in depth before you begin
writing. Your grammar may already be pretty good,
but there are so many ways to structure a sentence
and so many stylistic techniques that don't come to
but there are so many ways to structure a sentence
and so many stylistic techniques that don't come to
mind right away that will allow you to express
yourself much better in words.
If your software requires long instructions, you
haven't designed it to be intuitive enough. The
user interface should speak for itself.
"Show, don't tell." If your descriptions ramble on
for ages, you aren't following one of the most
important rules of writing. Your descriptions should
be colourful enough to speak for themselves.
Knowing design patterns will prevent you from
wasting time re-writing code that has already
been written.
Knowing common plot patterns of your book's genre
will provide you with a good plot skeleton to build
from. It'll also help you prevent your plot from being
predictable, if you know what readers expect.
The requirements phase of the software development
life cycle is just as important as the rest of the phases.
Planning your story before you begin to write is key. If
you don't know where you're headed, you'll end up
with loopholes and you'll probably need to do
some rewriting in the end.
with loopholes and you'll probably need to do
some rewriting in the end.
That said, an agile approach usually works best for
customer satisfaction.
That said, your book will turn out better if you're
willing to re-work plot details and characters
as you go.
willing to re-work plot details and characters
as you go.
The first algorithm that comes to mind may not be
the best one - try it again and again until you find the
solution with the best complexity.
The first solution to a conflict that you come up with
is too obvious. Come up with a different one, again
and again until you find one with complexity.
and again until you find one with complexity.
A user interface should be smart with the use of
colour, patterns, shapes, boldness, etc., for
ease-of-use and a better user experience.
Descriptions should appeal to all the senses.
It draws readers into the world and engages
them more than a bland, objective description.
them more than a bland, objective description.
Software should have no mysterious behaviour.
Every possible user input, including error cases,
should be handled.
You should know your characters thoroughly and
describe them as such, so that their actions don't
come across as unexpected to the reader. There's
a big difference between an unpredictable plot twist
and an action that's just plain "out of character."
describe them as such, so that their actions don't
come across as unexpected to the reader. There's
a big difference between an unpredictable plot twist
and an action that's just plain "out of character."
When it comes to the testing phase, it's a good idea
to have someone else do it. It's harder to break your
own code, partly because you know how it works
so you end up overlooking some error cases.
When you're done your draft, it's a good idea to
have someone else read it over. It's harder for you
to find errors and plot holes than it is for someone
else who's reading it for the first time.
