
Make it work. Make it pretty. Make it fast. - erikstarck
http://blog.opportunitycloud.com/2009/10/04/make-it-work-make-it-pretty-make-it-fast/
======
diN0bot
> "My education is software engineering (I have a masters degree) and when I
> was fresh out of school (which I was 10 years ago) I used to spend a lot of
> time drawing class diagrams and object interaction flows and lots of other
> paper stuff that didn’t take me anywhere closer to a working program."

i have a master's, too, and i can relate to the progression from wanting "well
designed code" to wanting "products that work and look pretty."

i don't see the goals as mutually exclusive. writing diagrams, and indeed
doing all sorts of on-paper design work, is often necessary for either better
programming or better teamwork.

i've worked with people who can keep crazy data structures and algorithms in
their head. that's cool. maybe i'm all modest and unhackerly, but i can
clearly see limitations in my mental space. i love loading problems and
solutions into my head, but the real problems and solutions are often bigger
than my head (elegance and the desire for simplicity aside...they'are awesome,
too).

the point is that it's impossible to work _with_ non-writers, unless the
"collaboration" is entirely modular. sometimes you need to hire a person to
write a library for you. seldom do you need to spend a day reading and poking
crazy code in order to understand the datastructures for a small tweak. look,
i love open source and i've gotten pretty damn good and groking code. it
doesn't matter. pictures can still display relationships better than code.
it's faster. diagrams as documentation rocks. just don't go overboard. do
exactly as much as is useful. just like simplifying, right?

for me, i'm a better programmer when i write things down. after a few months,
i'm happy when i can go back to an old section of code and see immediately
what's going on. it means my friction for getting started is close to 0. i
write down object models for all my databases because seeing a bunch of boxes
and arrows in a single glance is a lot faster than scrolling through code.

i wrote my own python script for converting django models into omnigraffle
diagrams, and vice versa. sometimes i need the diagrams before i even write
code, as i'm figuring things out. sometimes i need the diagrams later, when
i'm adding features.

i also used <http://www.websequencediagrams.com> for the first time a few
weeks ago to quickly draft up the complex interactions between a firefox
extension, server and Amazon's FPS. looking at that diagram i know i have the
logic right.

the code is almost boring to write once i have a diagram.

writing the _correct_ code _faster_ is a big win for me. i think some folks
are afraid to admit that because it seems "unhackerly" or "unbrilliant."
forget about that. being smart means doing exactly what you need to do to get
the job done right, whatever the constraints on _right_ are.

~~~
erikstarck
Thanks, good thoughts. Most of the coding I've done in the last 2-3 years have
been in my own projects, and it certainly helps when you're your own customer.

I've also done lots of typical web stuff and once you've coded 5-10
html/logic/SQL-projects you start seeing the similarities and it's easier to
go straight to code.

If there's anything I put any significant time into before coding that would
be the data model. It's hard to change built in restrictions.

