

Code, Picasso, and Simplicity - nathanh
http://blog.nahurst.com/effort-to-simplicity-code-design-art

======
lubutu
What I find interesting about The Bull is how Picasso's initial breakthrough
is to reduce the prominent head to a small insignificant shape. Only with that
done can he go on to reduce the rest of the body to such a degree. To me that
demonstrates how attacking a problem from an unusual angle can yield an
unexpected development, when trying to reduce the more obvious components
first would probably result in something more like a bull and less like a work
of art.

cf. <http://synthcode.com/blog/2009/06/Small_is_Beautiful>

~~~
akg
A lot of creativity comes from the most unexpected of sources. When you are
not thinking about a problem or thinking about something unrelated, some
neuron fires and makes connections with some subconscious notion of your
original problem. Looking at things from new and unexpected angles also seems
to trigger creative neurosis. You just have to turn off that filter and start
to look at things where you normally would not.

------
patrickyeon
Fred Brooks says to plan to throw one away. It won't directly help you keep
your final product simple, but if you don't worry about making your first pass
beautiful, you can get through it faster and learn all the details about your
solution sooner. From there you can simplify. (I'm talking at the level of
writing a function or two at a time, then simplifying)

I like to throw together my first try however feels easiest. Special cases,
multiple loops, wrong data abstractions, whatever. Once it works, I look at
the big picture: where are my data abstractions hurting me? Where can loops be
combined? what macro-scale blocks of code could be re-shuffled to be clearer.
Then I recursively look at subsections until I've gone as far as removing the
superfluous variables and ensured everything is named sensibly. _Then_ I push
the commit (not earlier, or it's too likely to be interpreted as 'done')

As far as anti-patterns that lead to unnecessary complexity:

* Is anything un-idiomatic (Python especially)?

* Is the same information stored/handled in more than one place?

* Is any variable being asked to do double-duty?

* Are errors being detected/signaled/handled too early? Too late?

* Can the data be re-organized to provide a more natural problem?

* Are there un-necessary branches? (Where applicable, develop an algorithm that works for all inputs, instead of seperate algorithms for different classes of input)

* Has anything been added because it's "basically free"?

------
agentultra
I think the impulse to simplicity and the ability to recognize complexity
comes from experience.

I'm sure Picasso wasn't "just" Picasso from day one. He probably spent most of
his early days absorbing as much as he could as we all do when we are young
and without experience. When we cannot absorb any more some of us, like
Picasso, begin to find ways to simplify our understanding of the structures
that beget such complexity so that we can find the intellectual room required
to reflect and absorb more.

As with code and mathematics -- we may come to understand our problems and
meet them with complex solutions. Yet only experience will reveal the
underlying structures. After you've written the same kinds of programs a
hundred different ways will you begin to see commonalities and short-cuts.

And personally I find that experience outside of programming also helps to
find that elusive simple elegance we all desire our code to have. I study
mathematics, fine art, literature, music all because I've found that ideas in
one often reveal through lateral thinking -- solutions to problems in the
other. That's why I love programming so much.

------
blktiger
I find that both when writing code and when writing papers I usually just try
to get my ideas typed out first. Then I start over (often from scratch) and
refine the ideas. I keep doing this, but re-using more and more of the ideas
until I come to my final solution.

