
Write code like you just learned how to program - angrycoder
http://prog21.dadgum.com/87.html
======
dasil003
The author here is talking about the importance of plowing ahead with a
vision, but the title initially made me think of something else.

Now that I've been programming for over a decade professionally, I've
accumulated a lot of practical experience. On balance this makes me a better
programmer, but it also makes me worry more about everything: maintenance,
bugs, version upgrades, etc. Wrestling with all possible issues can be
paralyzing. Often it's better to just get something done, even if your future
self will claim how much better it have been if it was done "right" in the
first place.

~~~
1337p337
I think you hit what the author was talking about, which is cranking out code
so that it works (for whatever goal, in the case the author describes, user
experience), not necessarily so that the code is good.

I learned Japanese, but when speaking it, I'm often hesitant. I used to hang
out a lot with native speakers when I was younger, and there seems to be
nothing middle-aged Japanese guys love more than seeing young men drink. After
a few drinks, you stop second-guessing yourself, and so when speaking, words
just came out, and my coworkers began laughing when, after I had spent all day
stuttering and pausing, I would start spitting out fluid sentences. (A few
more and I became unintelligible again, but for different reasons than
hesitance; this was just as amusing to them.)

Coding is the same. Writing a small script, a prototype, or a little program
for fun (or on the peak of the "Ballmer curve"), you don't think so much about
structure and cleanliness, and you write the minimal amount that gets the job
done, even if it's a hairy mess, and leave the editing pass for later (if
ever). It's essentially the main tenet of Worse is Better camp and the Agile
methodology: make it work as soon as you can.

I've worked at startups and large companies, and at both types of place, I've
seen huge codebases, properly engineered and sometimes representing decades of
man-hours, get scrapped before launch because they were wrong. I've also seen
horrible code that ignored every good idea about building software that
survived years. Personally, I have a bunch of code that is embarassing to look
at, written as quick hacks, that has survived and done its job for years
because it didn't try to understand the problem, just solve it.

Not that structure is bad or that engineering is wrong, but it seems to be
independent of a program's survivability and its utility. In fact, Worse is
Better seems to produce code that is more adaptable because its structure
ignores edge cases that may turn out unimportant in the real world, so when
unanticipated but important edge cases come up, the code is less rigid and can
be adapted.

I think this lack of second guesses and of worrying about what doesn't matter
for the problem at hand is exactly what the author is talking about. In terms
of long-term maintenance, a prototype is cheap to build and easy to scrap; if
it doesn't get scrapped and replaced, well...there will always be a project
that junior programmers can cut their teeth on before subjecting a clean
codebase to a kid fresh out of school.

~~~
phillco
I aim for the best of both worlds - blast through the coding when you're at
the top of the world; then, once it all works, go back and clean it up and
make it pretty. IME, unless you're never ever going to see the code again,
it's well worth the time spent.

Of course, not everyone is willing to pay for #2. "It's already done, isn't
it?"

:(

~~~
1337p337
That's what my strategy is. "Get it working, then get it working right, then
get it working fast." The "get it working" part is where you start to be able
to tell whether or not you've solved the right problem.

------
edw519
_It's extremely difficult to be simultaneously concerned with the end-user
experience of whatever it is that you're building and the architecture of the
program that delivers that experience. Maybe impossible._

Layperson who's never seen it: "Impossible"

Practitioner who's becoming better: "Extremely difficult"

Expert: "We do this all the time. What's the big deal?"

 _I think the only way to pull it off is to simply not care about the latter.
Write comically straightforward code, as if you just learned to program, and
go out of your way avoid wearing any kind of software engineering hat--unless
what you really want to be is a software engineer, and not the designer of an
experience._

I know that OP meant well, but I think this is about the worst advice I've
ever seen here. A little background...

I have reviewed or maintained the code of thousands of other programmers, and
I've encountered maybe a couple dozen I'd actually hire and about 5 I'd
consider as technical co-founders. What's the biggest difference? Until today,
I wasn't sure how to verbalize, but now, I think a good description would be
those who appear to take OP's advice and those who know better...

AFAIC, there's is a close correlation between good code and user experience.
There's a close correlation between readable code and maintainable code.
There's a close correlation between expertise and precision to detail
_throughout_. And perhaps most of all, there's a close correlation between
something built properly to stand the test of time and _long term_ user
satisfaction.

If you want to learn a hobby, develop a passion, or really dig deep, by all
means, follow OP's advice and just code it. Sometimes that's simply the best
way to understand what goes on under the hood and learn what's possible once
you learn the right way to build things. _Once you learn the right way to
build things._

But, please, please, please, leave your experiments on your own hard disk
where they belong. You may have thought that those bleeding pixels were cool,
but your name will be cursed by the poor souls who forever have to maintain
your mess.

~~~
mathgladiator
> your name will be cursed by the poor souls who forever have to maintain your
> mess.

That's fine as long as it generated jobs.

~~~
necubi
This is the broken window fallacy [1]. If the company didn't have to pay
developers to maintain bad code, they could invest that money in something
more economically useful, like new products.

[1] <http://en.wikipedia.org/wiki/Broken_window_fallacy>

~~~
towelrod
Unless they went out of business while trying to perfect the code instead of
releasing any kind of product.

~~~
adrianN
There is a vast stretch of appropriate solutions between the maintainability
hell of "hardcode the coordinates of every pixelchange in your animation" and
perfect code.

~~~
billybob
Absolutely. Let's not fall into false dichotomies here.

Yes, we developers sometimes focus on making the code perfect, beyond the
point where there's an actual business case. So we need to be reminded that
the code serves the business, not vice versa.

But really. Bad enough code is a liability to the business. You can't add
features to make the customers happy, you get bugs you don't understand, it
runs really slowly, etc.

The real trick is determining, with an intelligent conversation between
developers and business people, what's good enough.

------
jellicle
In any creative endeavor, the largest barriers to completion are internal. The
creator gets tired, loses interest, and never completes the vision.

The author is saying that getting something out is better than having a
beautiful, difficult, half-completed and abandoned lump. It's really the same
admonition as the ones to build the minimum viable product, or not to worry
about premature optimization. Don't do work that isn't necessary! Every bit of
unnecessary work increases the chance of total failure.

In the early stages, your biggest obstacle is getting SOMETHING, ANYTHING, out
and working. We tell writers: sit down and write. We should tell programmers:
sit down and program. Well, stand, if you don't want your back to ache.

------
notmyname
Obviously, a new programmer's code will not be as good as an experienced
programmer's. I think the important lesson here is to "write code". "like you
just learned how to program" modifies "write", not the code.

I found myself in the same position as the author. As I was going through a CS
program, I thought back to my early years of writing code. Sure, those early
programs didn't have computationally optimal algorithms or the current {design
pattern|algorithm|language} of the week, but they were fun, and I got stuff
done.

Once I graduated, and now that I've been coding professionally for nearly 8
years, I find that the best way to keep that passion about code and not get
encumbered by "how it's supposed to be done" is to read other peoples' code
and work with really smart people who encourage you to be a better developer.

~~~
_delirium
Yeah, I definitely agree with this. Knowing a lot more about software than
when I was a middle-school/high-school kid makes me a better programmer, but
vastly increases the startup energy. When I wrote mIRC scripts to do something
I wanted my client to do, or some Perl scripts to maintain my Home Page, the
startup energy was nearly zero, and I didn't think about alternative
technologies, architectures, the "right" way to do things, APIs,
extensibility, etc. I just wrote some hackish thing, then when I couldn't
extend it any more, I rewrote parts to fix it. Ugly and unmaintainable, but
time-to-ship was like a day.

I guess the trick is combining some aspects of those approaches. I find it
hard to do: it's now so _obvious_ to me when I'm writing ugly and
unmaintainable code that's Not Doing It Right that it's almost painful to make
myself do it anyway.

------
Fluxx
Understanding that a "concise, fast, scalable and maintainable" code is not
always superior to "complex, slow, unscalable and unmaintainable" code is a
big learning for me over the years. There are tons of "web developers" out
there who know some PHP and are charging clients with real money to write
really, really bad code for their exotic plants website. They can write their
crappy code because they're the only developer and they're only working on
some random exotic plants website that gets 500 visitors a day and has 2
database tables with 50 rows. Not that big of a dal. At that point it doesn't
matter if they don't have indexes in their tables or know what indexes even
are. The single developer is cheap to hire and for the most part get the job
done. Clients are happy, developer is happy.

Where code like the skull dripping blood or the exotic plants website breaks
down is when you try to extend the codebase, scale it or handle more users.
It's going to fall flat on its face and you're likely going to have to start
over or refactor large portions of the code. That does happen sometimes, but
at that point you probably understand your problem domain enough to know what
the right features are and rewrite it anyways. So it's not always a bad thing.
But when you do the rewrite, you should hire the people who know what they're
doing and can write "concise, fast, scalable and maintainable" code.

~~~
raganwald
Complex, slow, unscalable and unmaintainable code in a shipping product beats
a concise, fast, scalable and maintainable unfinished design.

This is not a strict dichotomy, of course. But it's a dictum well worth
remembering.

------
ScottBurson
There's a major exception that needs to be stated here. If you're writing
anything with security implications -- anything that handles users' valuable
personal data, particularly financial -- you had damn well better know what
you're doing and think about it carefully. If your site gets hacked and credit
cards get stolen, your users will have a crappy experience, no matter how
spiffy your site is otherwise.

------
chrismealy
This is great advice. I often catch myself not writing bad code by not writing
any code at all. That's just being chicken.

~~~
wccrawford
There's no shame in that. It's called "fear" and can be overcome by research
or just forging ahead blindly. I prefer the research method. It's a lot
slower, but I feel much better about the results when I get there.

------
tmcneal
Sometimes when I'm in 'idea mode' I like to just plow ahead and get something
running even if the code is crappy. It gives me a chance to see the idea in
action. I then go back and re-implement the idea with the appropriate code
structure, unit tests, etc.

My first pass is really about proving out the idea, learning about the domain,
and finding any gotchas. The second pass is about using my experience from the
first pass to create a clean, maintainable base.. something that I can come
back to in a month and be able to maintain, enhance, and deploy without having
to relearn everything again.

------
marcos123
Whoa, I'm really glad I read that. I've always had this lingering worry that
my being completely new to coding, and my tendency to learn by doing instead
of reading a book... any book, would surely prevent me from finding success.
It's just really easy to get sucked into coding. The first thing anyone wants
to do is learn how to make text a certain color or size, and then from a
little CSS, everything is like a perfect stepping stone. HTML to PHP to
Python. And even then, it's possible to get by on only coding what you need
to, if you start with a good cms. So... I guess what I'm saying here is
although I am glad and it's great that coding "like you just learned how to
program" can be an asset, but if it's actually so easy to be one of those
people that just learned how to program˚, shouldn't everyone be a little more
worried about competition than they are? I know I feel a bit of a burning
sensation under my ass each time I manage to cobble something awesome
together, with 99% being someone else's freely available code and 1% being
mine.

˚and by program, I guess I just mean building stuff.

Merry Christmas!

------
motters
This sounds as if he's in favour of the skull programmer's output. I've seen
the skull methodology used in practice in businesses, and it invariably
results in disaster (i.e. angry bosses/employees and disappointed or fleeing
customers). If your code is unmaintainable it may be ok for a brief demo, but
beyond that it only causes grief.

------
danielrhodes
From reading some of these comments, it seems like a few people have missed
the point the author was trying to make.

The point was not to write better code or to write code fast, it was that a
'good' programmer is focused on writing better code, not on what the user ends
up seeing/experiencing (which at the end of the day is the important part). In
the author's case, he focused on the wrong thing and ended up with a
comparatively boring looking animation, despite having superior code.

------
juddlyon
Reminds me of the "Curse of Knowledge" written about in Built to Stick.

Example: while working on a client's app, I spent two hours cobbling together
a jQuery plugin to vertically align some dynamic navigation (sometimes the
labels were one line, other times two or three). The project manager walked up
and in five seconds said: "I made a website a while ago, I think you can
vertically align table cells." Three minutes later, the nested table worked
perfectly.

------
Autre
Well, i'm not sure about that. Aren't we expected to be professionals and act
like ones on any given job? Should we just eschew Knuth and express ourselves?
Don't think so.

OTOH, it seems like something is clearly wrong here since, we are having a
tough time being professional and working with the current crop of languages,
tools, technologies, etc and in the same time, fully expressing our vision
while enjoining our work.

~~~
Someone
IMO, the text is not about personal expression, but about "Le mieux est
l'ennemi du bien." ("the better is the enemy of the good"; Voltaire), aka
"real artists ship" (Jobs)

Most beginning programmers will see few, if any, bears on the road ahead of
them. That makes it easier for them to just move to the goal line.

Of course, good expert programmers will be able to see which bears actually
are on the road, and plan for evading them, and not any other bears.

------
cturner

        It's like having a song idea and learning to play an instrument so you can make it real.
    

This is a good analogy, perhaps better than the author realises. The way we
learn to program tends to be nothing like the way music is taught, but it
would be more effective if it were.

Just as it's important to be able to nail scales through repetition, it's
valuable to be able to type effortlessly, and to enter in patterns without
thinking. Think of programmers who - when confronted by a linked list scenario
- mindlessly hammer in what's needed.

Repetitive drilling of those patterns is a good mechanism for improving
programming skill. Yet we tend not to think about learning programming this
way. Think of that time recently where you struggled to get something working,
and now when you need the pattern you just copy-and-paste from there. How many
of us can reliably hammer out a socket server interface without it causing any
cognitive load?

~~~
adrianN
I don't think that would be a very effective way of teaching. The hard part of
programming is usually not writing things like linked lists, but the ability
to decompose a real world problem into sufficiently small parts that can be
solved by writing down some common patterns. Repetitive learning of patterns
won't help at all with developing this skill and may very well scare off
students because it becomes boring very quickly.

Unlike playing an instrument, programming is not dependend on muscle-memory
skills to produce adequate performances, hence repetition is of limited use
while studying.

------
markkat
This was nice to read. I am teaching myself to program at the moment, just so
I can build MVPs of some of the ideas I have.

I doubt I'll ever be a great programmer, but that's not really my goal anyway.
I only hope to build something that needs to be rebuilt due to scaling
problems. :)

------
coolgeek
Architecture is why we refactor.

Just build your vision - especially when you're stretching with unfamiliar
tools and languages.

Then go back and pay off your technical debt.

~~~
Confusion

      Architecture is why we refactor
    

I sincerely disagree with this point of view. To me, 'architecture' consist of
exactly all those aspects of an application that you can _not_ change by a
mere refactoring. There are parts of an application's design that are much
harder to change, after the fact, than others.

If you've built your Japanese pagoda from wood and rice-paper and you decide
afterwards you're really going to need a concrete foundation and some central
steel columns to tie your pagoda to it, you're basically going to have to
rebuild it.

------
marcamillion
This advice has been my experience building my app. I have a CS degree, but I
never did much programming after - I went more into product management.

However, now that I am building my own app, I have forced myself to learn the
entire stack (from Rails to JS and beyond).

I sometimes look at other people's code and compare what they did in 1 line,
to what I did in a block of 10 lines and wonder when I will be able to write
elegant code like that. But I have learned to console myself, that at the end
of the day, for this first release, it doesn't matter what the code looks
like. Just so long as it isn't slow and the user has a good experience (i.e.
things behave the way they expect it to), then I am doing a good job.

The perfectionist in me hates leaving it like that (I want to refactor every
chunk until it is completely optimized), but the realist in me knows that I
only have X amount of time to complete.

Thanks for posting this, because now I don't feel like I am doing a major
disservice to my users by programming like the n00b I am.

------
mks
I think what could be taken from article is: write simple code. However it
does not entitle you to write sloppy code.

Often naive algorithms and shortcut solutions work great. But make them so
that when you actually need to replace them you just unplug them and replace
with something better.

------
DanielRibeiro
Kent Beck, the creator of XP, mentioned something really similar a couple of
months ago on his "Flight of a startup" posts:

<http://www.threeriversinstitute.org/blog/?p=252>

<http://www.threeriversinstitute.org/blog/?p=251>

------
Shorel
The classic paper 'Worse is better' by Richard P. Gabriel explains this point
in a deeper way than this blog entrance.

