
I am a terrible programmer - ScotterC
http://danshipper.com/i-am-a-terrible-programmer
======
edw519
My default response to any "good programmer, bad programmer" post:

A smart accountant once told me that the answer to "How much money did you
make?"  is always, "Who wants to know?"  If it's an investor, the answer is "A
lot."  If it's a customer, the answer is "A little."  If it's the IRS, the
answer is "None." 

Same thing here.  The answer to "Who is a good programmer?"  is always, "Who
wants to know?" 

To a project manager, the programmer who hits every deadline (regardless of
quality) is a good programmer. 

To a customer, the programmer who solves their problem quickest is a good
programmer. 

To a business owner, the programmer who makes them the most money is a good
programmer. 

To a PHB, the programmer who makes them look the best is a good programmer. 

To a journalist, the programmer who tells the best stories is a good
programmer. 

To a junior programmer, the best mentor is the good programmer. 

To another programmer, the programmer they are most likely to want to go into
battle with is a good programmer. 

To a blogger, the programmer who best fits the profile of the point he is
trying to make is a good programmer. 

~~~
hnriot
You're making the point that being competent at programming is in some way
relative to the perspective of the asker, but that's just not the case. 
Competence is absolute.  There are traits of a good programmer that are
immediately evident to any experienced programmer. 

~~~
siganakis
If competence is absolute, then there should be some way that you can
objectively measure it (otherwise how do you know its absolute?). 

What are the ways to objectively measure the competence of a programmer? 

If that was the case, then it would be much, much easier to hire and fairly
compensate programmers than it is in reality. 

~~~
nadam
In my opinion programmer competence is not absolute, but a little bit more
absolute than what ed's post suggest. :) 

A very rough measurement of programmer competence:

The programmer is given a product specification.  He creates the program in T
time using S size of code. 

1/(T * S * S)

is a very good approximation of how good the developer is. ( small size is more
important than the taken time, that's why I've taken S square.  We can tweak
the formula of course.  Maybe 1/(T * S * S * S) is even better in some cases.) 

TL;DR: the most common thing amongst good programmers in my opinion is that
they are masters of the DRY principle, but they do not overabstract; in
essence they write smaller code to problems (usually even faster) than not so
good programmers.  The bigger the system is, the more and more
architectural/design skill is needed to keep the code base small. 

~~~
EwanToo
I have to disagree sorry. 

If a piece of software is needed by the date of a major launch, and a
programmer doesn't ship, all because he wants to reduce the amount of code
involved, then he's an awful programmer as far as the business is concerned. 

Running over time can cost millions of $ of investment in other areas of the
business:

\- Press organised

\- Advertising purchased

\- 1000s of hours of staff training underway

\- Suppliers informed of increased demand / new supplies purchased

\- Customers told to expect delivery by date

Any one of these areas can cost 10x or more of the cost of developing the
code. 

If you're not writing code which would be affected by that kind of criteria
then cool, go for whatever metric you want to define. 

Time taken is almost always the number one criteria of any business
requirement, or to put it another way, small size of code means almost nothing
to anyone except the original developers. 

~~~
nadam
I said that it is a rough estimate, and we can tweak the formula.  My opinion
is that programmer competence is not absolute, but also not terribly relative. 
I mean John Carmack is kind of absolutely a better developer than let's say
junior average Joe. 

>small size of code means almost nothing to anyone except the original
developers. 

No.  Small size reflects the quality of the code: It reduces the time of future
developments (non DRY code keeps growing agreessively and becomes even more
non DRY and very time consuming to develop new features into).  It is an
investment in the future.  Now you are right: sometimes it is not worth it to
invest into the future, because maybe the code will be thrown away because it
will turn out that the startup/product is not viable.  Somtimes you know that
product has a stable growing market and you will have to develop tons of
features into it in the future.  Then investing in the future is very
important. 

~~~
mercurial
> Small size reflects the quality of the code. 

Not always.  Case in point: a week or two ago, I refactored some C# code.  It
was an installer generator, which was coded entirely in the controller.  Yeh
who want to add unit tests, abandon all hopes. 

So the code is now split into different pieces, according to responsibilities,
with dependency injection, and I/O in its own layer.  The result, in terms of
lines of code, is a net increase.  But according to your metric, I have
decreased the quality of the code. 

I agree that generally speaking, less code is better than more code, but more
code can mean reusable, more readable code. 

~~~
nadam
Ok, I accept this.  I have experience in refactoring really bad code. 
Refactoring these always led to smaller code: yes sometimes some of the
refactorings increased the code size, but there was enough redundancy because
of the bad (or no) abstractions and design mistakes in the original code which
compenstated for it. 

The bigger the system is, the more probable it is that you can make it better
while decreasing the code size.  Above 10.000 lines a bad code usually is not
DRY enough so much, that it is very easy to decrease its size while increasing
its modularity. 

Yes, code size is not a perfect indicator of quality.  But reducing code size
is a very central part of my design philosophy.  When you very conciously
refactor to smaller code size (using good design patterns) the code and the
abstractions in your head can become incredibily clear. 

For example I write a software which deals a lot with rectangles.  In the
beginning my rectangles had four properties: left, right, top, bottom.  After a
while I've found out that my code gets more and more redundant; I have to find
an abstraction which relies on the symmetries in the problems.  So now my
rectangle has this interface to get and set the 4 sides:

void setSide(bool vert, bool isEnd, int value)

int getSide(bool vert, bool isEnd)

Not only my code size reduced dramatically, but because of this new
abstraction I've understood the problem much better! 

------
jbail
This article presents a false dichotomy.  There is no reason why you need to
sacrifice code quality for the sake of speed of development. " Getting things
done" is a hugely valuable skill, but don't conflate having that skill with
meaning you are too busy to code clean.  Productivity and beautiful code are
not mutually exclusive. 

I write very nice, commented JavaScript that employs consistent whitespace and
indentation and validates in JSLint all day long.  That's just how I do it and
I'm way faster than the coworkers of mine who code things quick and dirty. 

You reach a certain level of expertise and your code will just naturally have
these qualities.  It will be both beautiful and will be developed quickly. 
Senior talent gets this.  Junior talent doesn't. 

This was a thought provoking article though.  The main takeaway is that
"getting things done" is the most important skill a programmer can have which
I completely agree with.  For the sake of other developer's sanity, clean code
is so important too.  Ugly, sloppy code takes longer to read, more effort to
maintain and is frankly demoralizing and tiresome to work with.  Clean code for
me is probably right underneath getting things done on a skills ranking. 
Ideally, good developers would have both...and my experience shows that good
developers do. 

~~~
Evbn
If I had a nickel for every lint-clean properly indented file of spaghetti
code I saw, I would have.... to be at my job, where we have tools and rules
for surface appearance, but no accounting for quality in depth. 

~~~
jbail
This is why peer reviews are so important.  Simply running code through JSLint
and then making sure its formatted correctly is only step one. 

------
huhtenberg
Right, right, right. 

Sorry, bud, I worked with a couple of guys like you before - very bright,
smart, self-confident, young, yet started coding before they started drinking,
but with not a lot of mileage in the industry - and the problem was that this
style of work is not compatible with other people.  It's great for prototyping. 
It's great when you work alone, but it's a _nightmare_ in a true team
environment and the resulting code is nothing but a headache in a long term. 

I'm sure you can ship, but that's hardly an achievement.  Everyone one can, but
shipped out _shit_ in a working condition is akin to all that Made in China
crap from Walmart.  Nothing to be proud of to put it mildly. 

> _So next time you’re working on a project, give some thought to what’s most
> important: speed or elegance._ 

It's "Fast, cheap, good - pick two" and "You get what you paid for". 

~~~
pnathan
Any tool can crap out code that serves a business need.  That's a "product",
fine.  But it takes someone with a bit finer sense of competence to produce
code that can work over a longer term and doesn't drag down the business in
years to come. 

~~~
mattdeboard
Yes.  The term "quick and dirty" and "bang something out real quick" make me
want to throw up in my hat.  It's not like it's not necessary to lower
standards a bit sometimes, but because people who use that phrase a lot tend
to, in my experience, use it as an excuse for churning out a lot of garbage. 

------
calinet6
I think there is some confusion over quality vs. quantity. 

You can ship all the code you want, but even if it's _lots_ of mediocre code,
it's still mediocre. 

Quality is independent of quantity or productivity.  You may choose to lower
your quality in favor of a higher rate of productivity, but you've still
lowered your quality. 

So you may be a productive programmer.  But that doesn't necessarily make you a
good one. 

There's also the matter of the quality of code that your'e capable of, versus
the quality you actually produce.  So you may be a very good programmer forced
into producing shitty code (time constraints often do this). 

But let me say this: a good programmer who consistently ships great, high
quality code regardless of the situation is still a _better_ programmer. 

~~~
xauronx
>But let me say this: a good programmer who consistently ships great, high
quality code regardless of the situation is still a better programmer. 

So, the perfect programmer is a better programmer?  That goes without saying.  I
think his post is more an issue of people who build things vs. people who can
code algorithms.  Personally, I'm the former and as such naturally think it's
superior.  Let's face it, we can't all be perfect programmers. 

There's the developer who can register a domain, set up a LAMP server, get a
web application up, create a good database schema and make it look nice and do
it all in a weekend.  Then there's the programmer who will come in and look at
one portion of a less-used paged and call you a shitty programmer because you
did it in O(n^2) when using THIS clever algorithm you could do it in O(n). 

It depends on what your focus is I suppose.  The question is whether or not I
(or the author of the article) would be able to optimize that chunk of code if
the user experienced slowness. 

~~~
calinet6
My point is that quality is an objective measure which does not depend on
situation, or reality, or getting things done, or time constraints, or
personal issues, or whether you do it in a weekend.  Better code is still
better regardless of all that. 

You have to have an objective notion of quality before you go trying to apply
it to reality.  And if you do, you might have a chance at improving it. 

~~~
xauronx
Well, you're simply incorrect.  I mean, we can agree what a perfect programmer
is.  But comparing the qualities of two imperfect programmers is absolutely
situational, just like any skill.  Who's the better athlete, Michael Jordan or
Michael Phelps * ?  They're both great athletes, but who's better?  I guess you
could have them perform in every olympic event, but that wouldn't really tell
you much. 

Ah, but I just noticed a small syntax difference in your argument.  You're
arguing about better CODE not better CODERS.  Still arguable, but _more_
objective.  You can easily gather a lot of metrics about code.  Still, if I'm
programming something for my graphic designer sister to work on later, I'm
going to program differently than if I was writing a compact and efficient
internal piece of code. 

*Using two of the only athletes I really know. 

~~~
calinet6
You're absolutely right, there are differences between situations.  I
absolutely, positively know that. 

But I'm saying, when you're measuring quality objectively, it just doesn't
matter.  What matters is the thing itself.  The created object.  The outcome. 

I'm not simply incorrect—I'm simply correct.  My argument has the constraint of
simplicity.  It is defining the basic existence of a thing which we know
exists, namely Quality.  When you add complexity, yes, the definition is no
longer sufficient to describe the entire process; but I'm not claiming that
perfect code and perfect coders are possible in reality.  I'm saying: start
with simple and true definitions so you understand what quality _is_ by
itself, so that once you add situations and reality to it you can still try to
achieve something close to "good."  It is a matter of scope. 

This isn't an argument.  Quality exists.  Defining it is hard, yes, but it's not
impossible to understand that one thing can be better than another by many
measures, and we say that thing has higher Quality. 

Read "Zen and the art of Motorcycle Maintenance," it'll twist your brain up
some more. 

What you're going to say next is of course that you're right and that
devolving into silly philosophical arguments doesn't mean anything to real-
world work, so yes, I guess I'll agree with that. 

------
grandalf
I wish more programmers/hackers had the courage to show off their ugly code
and admit to the early stages of the creative process. 

The Ruby community has a great emphasis on beautiful, elegant code, but how
many first commit trees on github are actually after hundreds of hours were
spent, a good percentage of which involved beautifying and organizing. 

I definitely prefer to read clean, well organized code, but I'd also like to
read the first attempts and the discarded approaches used by the hackers I
admire. 

~~~
jetti
I agree.  For the longest time my github had little in it except school
projects.  I finally decided to use it for personal stuff, or more like got
used to the idea that my code would be public.  I put up a few projects and
even then, I didn't do anything to even try to show them off.  This is because
of the fear of being judged and because in my mind I'm not nearly as good as
the people here or the people who post on /r/programming.  Eventually, I posted
my projects to a few sites and while the feedback wasn't "oh this is great",
it was feedback nonetheless and I was able to take it and improve my project
and myself. 

I guess where I'm going with this is that for those who are beginning or come
from a non-CS background, seeing all this polished code, even in initial
commits, being posted to sites like HN or reddit is very intimidating and
could be a drawback from people sharing their code. 

~~~
thisone
I do the same.  All my personal gh repos are public.  And I push as I work, I
don't wipe commit history. 

I'm no one special, and I seriously doubt anyone looks at my code, but, if
someone ever did, they'd see work in progress. 

Just like the code base at work.  Nothing's brilliant the first time out. 

------
stephengillie
This blog post reveals more about its authors insecurities than it provides in
insight to the rest of us. 

If you're good enough at what you do that you have time to blog your inner
debates about how good you are, you're good enough to need more important
things to do. 

~~~
PommeDeTerre
I'm still trying to figure out why so many Dan Shipper articles get submitted
here, and why they always end up near the top. 

They always come across as nothing but self-promotion thinly veiled under
buzzwords related to software development, rarely with any real substance. 

From what I can tell, he hasn't really done anything notable.  He's a college
student who has apparently been involved with some relatively unknown
startups, and otherwise does some pretty typical and unremarkable software
development. 

It just seems like he's usually trying to make a big deal out of stuff that's
pretty inconsequential, while continually dropping his name or that of some
startup he's involved with. 

~~~
JohnExley
Hey PommeDeTerre, I think it's because of two things primarily:

1) Dan is beyond his years in terms of articulating his thoughts on startups
and software development, and reminds some people of a young Jason Fried (co-
founder of 37Signals, author of "Rework", etc.) 

2) Dan is (much like Jason Fried) a bit of a contrarian.  He has shipped almost
two dozen apps/sites in the past couple years and is working night and day on
growing his current startup, but he isn't dropping out of university.  He also
isn't out raising venture capital and trying to scale scale scale -- instead
focusing on building a business that makes revenue and is profitable from
(almost) day one.  And lastly, because he is not chasing the "sexy", popular
consumer app space -- instead focusing his efforts on the 'less glamorous'
SaaS and B2B space. 

 __*

The combination of these factors make a lot of us in HN interested in where
Dan's career is headed, and thus interested in reading his posts and watching
him progress as a founder while still in school. 

That's why so many Dan Shipper articles get submitted here, and why they
always end up near the top.  He is the real deal. 

------
charlesju
[http://www.codinghorror.com/blog/2009/02/paying-down-your-
te...](http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-
debt.html)

I am surprised that no one has talked about technical debt yet.  This is a
classic case of taking technical debt for productivity.  Like all forms of
debt, some of it is good, it's leverage on your time (ie.  you spend less time
making it perfect, and more go to market faster), but you need to pay it back
at some point in the future. 

The key difference between what the author espouses and a good programmer, is
that the good programmer makes the conscious choice to accrue the debt in
favor of speed and creates an action plan to pay off the debt at a later time. 

I do not believe that you can become an a good programmer until you can
understand the distinction, make the proper trade-offs necessary to hit
project objectives and create an action plan along the way to pay off the debt
in the future. 

------
mgkimsal
The 'definition' aspect is key, but also the context or project. 

For startup/rev1 web products, no doubt Dan's abilities are paramount.  Would I
want that same "ship it now" hacker ethic at work on a flight system?  Or a
heart monitor?  Hell no. 

Context matters. 

~~~
greenyoda
It's not just life-critical systems that require good code.  Any large code
base that has multiple developers and a long lifetime will quickly degrade
into chaos unless the developers take the time to write understandable and
maintainable code and refactor it when necessary.  And after a few years, all
the original developers may have moved on, but people still depend on being
able to evolve the code to handle new business needs. 

It sounds like the author of the article has never had to deal with any of
these issues.  That doesn't make him a bad person, but it does mean that his
advice shouldn't carry a lot of weight. 

~~~
mgkimsal
The 'life-critical' was just an extreme example.  I agree with your point, but
also agree with the OP, sort of.  What needs to happen is that everyone
involved understands the tradeoffs inherent in 'ship it now' approaches.  Yes,
no one can predict the future entirely, but sometimes you can be pretty sure
that the 'fast and dirty' approach is actually OK to take. 

~~~
Draiken
This only applies to this new wave of "ship it" these days.  From what I've
seen, it's pretty much just in web/mobile development. 

I doubt Torvalds produces (or produced) quick dirty code to "make stuff
happen", and I also bet he's a hell of a programmer. 

As stated by someone before, shipping stuff fast makes you a good "product
builder", not a good programmer. 

------
debacle
I'm of the strong opinion that if your code is encapsulated, it's pretty okay
for it to be entirely shite as long as it works. 

If someone needs to maintain it, and that someone isn't you, it's very likely
they're going to understand your shite stream-of-consciousness code much more
easily than your beautiful, elegant code that has had all of the thought
process refactored out of it (but refactoring is a very important tool). 

~~~
gutnor
If your code is less clear after refactoring than before, you have gone a step
too far in refactoring. 

Your goals when refactoring is removing useless bit of code, make the code
understandable without comment and remove duplication. 

That is the last step that generally requires introducing additional
abstractions layers and where stuff go wrong.  Too often refactoring books or
articles give examples of how to use refactoring technique, but for the sake
of being readable, the examples rarely really require such refactoring in the
first place. 

But yeah, at the end of the day I also prefer a hackish piece of code that
solves the problem than the same "refactored" into conceptual art. 

------
ScotterC
This is what I loved about working with Dan in those early days of Artsicle. 
He cared about shipping more then anything else.  He was a rabid hacker who
pushed out code even if it was crappy but it got us to the understanding we
needed so we could move on to the next milestone. 

------
ssebro
Context is what matters here.  You're a terrible programmer for established
businesses building products they know people want (so it has to be rock solid
and easy to maintain/upgrade).  But you're great at churning out MVPs, which is
really all startups need.  The second a startup moves from an MVP, it no longer
is a startup - they've proven their business and are building things like
betas, where they know exactly what users want and are delivering on that. 

~~~
greenyoda
But if a startup wants to become a successful larger business (rather than
just get acqui-hired by Google), then the code quality _does_ matter.  Once
they've gotten paying customers, they can't afford to drop everything and
build a reliable and scalable system from scratch - it would be cheaper and
less risky to build on top of their original code. 

Also, depending on the business, the MVP may end up being a large and complex
code base that can't just be hacked together haphazardly.  Not all startups
build iPhone apps; some build on-line retail businesses or investment banks. 

~~~
Evbn
Your theory directly contradicts the actual history of Google, Amazon,
Facebook, etc. 

Larry and Sergey's first hires were for people to replace the crumbling hacks
they wrote to launch Google. 

------
S4M
<http://www.lambdassociates.org/blog/hackers.htm>

Mark Tarver compares "street programmers" (people like the OP before he
started to take some CS courses) and people who focus in Computer Science
without practical (industrial) coding. 

------
pharrington
Can someone point me to some examples of software that's non-trivial, stable,
performant and fairly bug-free, yet coded like trash because it was rushed out
the door as quickly as possible? 

~~~
Evbn
Verything written in the language of DNA.  It has some bugs, but generally not
system-fatal showstoppers. 

------
heelhook
I believe the mistake here is attempting to assert your skills in a single
continuum, bad or good.  Like you say, and others comment, bad-good are
relative terms that vary widely depending on context. 

I would like someone like you, with a quick turnaround on features for early
products and prototypes but such personæ wouldn't be my first pick for a
stable or mature product where quality is paramount to speed. 

Its all relative. 

FWIW, I believe you are too quick to dismiss sound theoretical background, and
I say that as a college drop out who had to fire PhD students from his team in
the past.  Theory _is_ important and, given the right context, I'll go with the
academic type, with slower turnaround that will take months to deliver a
single feature. 

> The answer is: a good coder knows when something should be quick and dirty,
> and when > something should be thorough and clean. 

From my experience, people tend to be better at one than the other, its not a
simple switch in your brain that you turn on and say "ok, now this part is
important so I'm going to be much more careful here".  From what I've seen, a
prototyper is, at the same level of competence, worse at being thorough with
documentation/well thought-out data models/corner case handling/etc. 

------
dpiers
I made games while I was in school.  Lots of games.  PC games, iOS/Android
games, and even some homebrew 360/PS3 games.  All of those games helped me get
the attention of technical directors at a couple of studios and got me my
first two internships and eventually a job as an engine programmer on a multi-
platform game engine. 

But the code in those games was crap.  Looking back on the early stuff, I am
amazed it even compiled.  It wasn't until I had to work on a +500k LOC codebase
with 30 other programmers for a year and a half that I learned the importance
of writing code that can be easily read, understood, and modified by other
programmers (or even myself) six months after it was written. 

Writing maintainable code is a skill that comes naturally to every good
developer after they have to work on the same code base for an extended period
of time.  Dan hasn't had time to do that because he's shipped 20 different apps
in the last 2 years, but now that he's working on his own startup (and will be
for the foreseeable future) it sounds like he's learning the value of elegant
code. 

------
albumedia
In Engineering we learn about a "black box" - a device that accepts an input
and return an output.  We couldn't careless about the parts/components inside
that black box. 

Sometimes we have to treat programming like a black box.  All we care about is
getting the desired output.  There will always be time to make the code
efficient later. 

The end user and manager only care about the output. 

~~~
splicer
If there's a bug, and you have to wade through 10K+ lines of utter shit to fix
it, WITHOUT causing a regression, you're screwed.  The "black box" mentality
works fine for prototyping, but once you've got a working prototype, you
should throw out the prototype and write a clean, MAINTAINABLE system from
scratch. 

~~~
Evbn
Ah yes, the second system.  To great effect.  See the Netscape 5 rewrite, a
great example. 

------
paupino_masano
Having been in a startup before: I'm not sure how I feel about this...

In regards to getting features out quickly: that's a great programmer.  Though
inevitably there comes a time when the code needs to be maintained - and if it
is unmaintainable then I'd put you in the bad programmer category. 

Now-a-days: I prefer clean code to a specific coding standard over the quick,
dirty features being implemented.  But, only because it usually causes more
pain in the long run.  I understand the "getting a feature out quickly to test
it even works" mentality, and to some degree I agree with it.  However, if it
DOES work then a clean code base is always better.  Inevitably it will need to
be maintained...

After writing this (sorry: could rewrite my comment but decided not to) I've
now realized that I'm now AGAINST the feature push mentality.  I'd much prefer
well written code and eat up the cost then rather than later on.  Worst case
scenario, it can then be reused...

------
dkoehler
I've seen quite a lot of debate with hard lines of what defines "good" code. 
In my admittedly limited experience, I've found that the definition of "good"
varies with the situation in which the code is written. " Good" in my opinion
is not something that has a concrete definition.  It's entirely dependent on
the requirements of the project, and how the developer meets them. 

-Sometimes this means a programmer can drop into the style already in use on a project, even if it's not the 'best' approach.  That way his changes are low-impact and can be easily understood by the people who have worked in the system for years. 

-Sometimes this means the programmer needs to architect a complex solution to a hard problem. ( Though I think this is an assumption we make far too frequently.) 

-Sometimes this means the programmer should spend some time understanding the constraints on the project, and express them in code.  If a constraint is acceptable at least until the next major version of a piece of software, then why not focus on making it simple to alter the assumption, rather than adding complexity to avoid the assumption completely? 

-And sometimes, this really does just mean "Ship that mess by next Friday", regardless of the cost.  Sometimes it's just more important to get a poorly architected version in the hands of users that just does what it says on the tin, especially if their input could drastically change your requirements. 

------
JonnieCache
All this talk of beauty and elegance is missing one key point: it's not just
an aesthetic matter.  Beautiful code is beautiful because it implements some
theoretical design concept that makes it easier to maintain and more
performant.  The fact that it happens to look nice when you do that is down to
the design of the language itself. 

~~~
Evbn
Beautiful performant code does not exist in a large system.  The languages just
don't exist to express it. 

------
matwood
When it comes to entrepreneurship, programming ability is secondary to
shipping a product.  Real Artists Ship. [ 1]

[1]
[http://www.folklore.org/StoryView.py?story=Real_Artists_Ship...](http://www.folklore.org/StoryView.py?story=Real_Artists_Ship.txt)

------
sgdesign
As a designer, I can certainly say there are tons of designers who ship ugly
designs.  Do those designs convert well?  Sure.  Is the client happy?  Yep.  Does
that make them good designers?  No, definitely not. 

~~~
kylec
I think programming's a bit different - with an ugly design, the customers see
it and know it's ugly.  If a software application works fast and flawlessly,
the customer sees that it just works, and it doesn't matter if the code has
been neatly organized and arranged underneath. 

------
lutusp
> In general, my priority since I started coding 10 years ago has been speed. 

Which meaning of speed?  You can write fast programs, and you can write
programs fast, but you can't write fast programs fast. 

------
alexkearns
I think some programmers focus on the code, while others focus on the end
product.  It is a philosophical difference.  The first make great employees.  The
latter make great start-up founders. 

~~~
Firehed
I don't think it's nearly that cut-and-dry.  The most elegant code in the world
is pointless if it doesn't solve a real problem (the end product), and the an
unmaintainable and unscalable mess of crap that actually shipped on time is
equally pointless if it's so broken that user's can't use the product or
developers can't improve upon it. 

Great people need to find a balance, and I don't think leaning towards one
side or another shows whether someone would be a great employee and/or
founder.  This "ship early/ship often" and "move fast and break stuff" attitude
is ok for immature products, but there's still a minimum level of quality you
need to reach, and as your userbase grows and your product matures, it's
almost certainly going to be important to raise the bar on quality. 

Shipping prototypes is fine, but you have to keep in mind that if it catches
on, your plan to rebuild a non-crap version (invariably you had this plan)
will fall through because something else came up. 

My rule of thumb for prototypes is to get the data models close to right, and
untangle the rest later.  Pulling apart spaghetti code isn't too bad as long as
there's reasonably sane intent behind it.  I can fix systems where people are
updating state from the views and writing to the db in all sorts of
unimaginable, horrible ways; however, if you're not storing the right info,
you're pretty screwed and have a hell of a migration process in your future. 

~~~
alexkearns
Just because you focus on the product does not mean you ship bad code.  Nor
does a focus on the code mean you ignore the product.  I see it more of a
philosophical thing - what excites you most?  Writing a highly efficient,
perfectly formed piece of code; or creating a product that others use. 

------
pharrington
A bit off topic, but this got me wondering: is there any field of study
dedicated to quantifying multidimensional, fairly subjective measures (like
one's quality as a programmer)?  Just intuitively it _seems_ like there's some
process in general to map out a subject's traits across multiple dimensions,
assess those in a variety of multidimensional contexts, and convey the results
in a natural-language way, but I've never seen this talked about in articles
like the OP's :\

~~~
mogrim
There's the field of empirical computer science (for example
<http://www.cs.jhu.edu/~nasmith/erm/>) - and I've seen a couple of articles
recently pushing for a more evidence-based approach to methodology.  No links,
I'm afraid - can't find any - but it is out there. 

Edit: the link I included is more to do with algorithms and the like, mea
culpa, but there are also studies cited in books like Code Complete that cover
what you mention.  How recent, or how good the research is, is another
matter...

~~~
pharrington
Thanks, it's a start. 

------
ukapu
Reminds me of the quote by one author (I think it was Stephen King but I'm not
sure). " I don't get paid to write books.  I get paid to finish them." 

------
richardlblair
I agree with the author here. 

A huge part of being a good programmer is knowing when to just solve a problem
quick and dirty, and when to really plan it out and implement a beautiful
design. 

Either way, if the programmer is making the right decision most of the time
they should feel good about the work they are doing. 

At the end of the day we provide value.  Provide value to the right people at
the right time and you will have a good career. 

------
Cieplak
_The answer is: a good coder knows when something should be quick and dirty,
and when something should be thorough and clean._ 

------
marcamillion
Thank you for this Dan.  You are very right. 

The subtitle for this should be:

"An ode to everyone that has gotten flamed on Stack Overflow or IRC for 'bad
code'". 

------
hcarvalhoalves
Truth be told, horrible JS tends to be the norm because people more often than
not just need to wing something in it. 

------
hobb0001
Having your code still work 20 months after you wrote it really isn't much to
boast about. 

~~~
Evbn
As the saying goes, bad code falls apart in 3 months.  Google code falls apart
in 6 months. 

------
joewee
Even terrible code written by terrible programmers can earn wonderful profits. 

------
Void_
Part of being a good programmer is writing bad code sometimes. 

~~~
lttlrck
Part of being a good programmer is knowing when you are writing bad code.  In
my mind its subtlety different, I never plan to write bad code, but sometimes
it just turns out that way because of a tiny initial bad decision. 

That is what sets good and bad programmers apart.  Bad programmer have no clue
that they are writing terrible code. 

------
desireco42
You and me together.