triple_r wrote:
> Assuming you fit into the professional programmer category, are you rewarded for
> producing fast, effective results that meet requirements, or for well-written
> code?

Both.

If I can produce fast results that aren't ugly, I do so. Otherwise, 
generally speaking, I produce fast ugly rather than eventually clean. 
But that's because I work for start-up companies that are much more 
interested in getting customers so they can get money instead of large 
established companies that can afford to take more time.

Were I working for Amazon, for example, I'd expect I'd write prettier 
code. When I'm coding for myself, I write prettier code. When I'm coding 
example code, I write prettier code.

The two problems are these:

(1) You don't always know it's ugly when you write it. You may not 
realize this bit you're creating here and passing to there is going to 
wind up being needed all over the place, so you don't at first make a 
specialized data structure for it. Or you may have the same code in 
three or four places before you realize it really should be a library 
function. In other words, in exploring the requirements and implementing 
them, you learn what parts can be made more meta and hence less ugly. Of 
course, if the requirements are poor, this happens way more often. This 
includes if the program is evolving quickly, such as is common in startups.

(2) Ugliness depends on both program size and complexity and the number 
of people working on the code. If I have a 20-line program to read a CSV 
file, extract three of the columns, and output the SQL required to 
populate the database table it represents, trying to use metaprogramming 
to select those three columns instead of just having three identical 
lines cut-and-pasted with the column name changed is probably more more 
ugly. If I'm the only person working on the code and I'm smart, there 
can be a whole boatload of ugly in there that doesn't interfere with me 
improving it because I can remember it all.

> Not that they're mutually exclusive, but this ugly code has to come from
> somewhere, and I can't imagine you're told to fix every mess you come across.  I
> can see pressure from above promoting very poor practices that produce short
> term gains and long term losses.

Indeed. Generally, I wind up fixing ugly when it gets to be more effort 
to work around the ugly than it does to fix the ugly. I had one 
situation (long, long ago) where the report generation code was so ugly 
I told the boss it would take 2 weeks to rewrite it as a data-driven 
routine and three to move the last column to be the first column.

Sometimes you fix ugly incrementally. The third or fourth time you 
copy-paste a few lines of code, you figure out if it makes sense to turn 
it into a subroutine somewhere. When you have the same routine in 
several programs, you move it from the program-specific library to the 
general library. Etc.

Of course, the best way is to never write the ugly code in the first 
place. With enough experience and je ne sais quoi, you eventually learn 
where the ugly is going to creep in if you don't do it right here. You 
learn that you should (for example) always take the time to create a 
business-object layer[1] and to always use templates[2] for output. 
Other ugliness is harder to catch.


[1] Business-object layer: a layer of code between the raw database rows 
and the application that implements an OO-like layer that talks database 
on the bottom end and application-logic on the top end. Not to be 
confused with DAO or "active records". For example, a set of routines to 
access "the product catalog", even if that's stored in multiple tables 
and has different properties for different objects in the catalog.

[2] Never let the UI people edit your code. Even if it's PHP.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message