This usually happens when the programmer at fault is really smart but still hasn't learned that at some point in the future, someone needs to come along and understand the code he/she wrote.

Maybe we need editors?

It would be nice to have the senior folk guide the developer as opposed to handing off a blueprint and getting out of the way. (Not that its like that everywhere, just some places I've been)

Linus has deputized a few people to commit without his review, I believe.. but this is after years of working with them.

*professional means good quality balanced with maintenance and time available during development.

Just putting this out there, besides the undoubtedly negative sentiment it will bring. Try pairing. You don't have to do it all the time, but if you are working on something that you have to think about, bring another developer over. The best way to ensure what you are writing is good is to get another set of eyes on it. Preferable a set that will actually need to do something with the code at some point.

Besides, you could always send a message to the author and ask if you're interested.

1) Every check in required a code review by a peer. In your commit statement, you specify who reviewed your code.

2) If a senior programmer wrote code for a feature that wasn't too complex he would get a code review from a junior programmer. The junior programmer doing the code review, learned what good code looks likes and second learned how to give feedback in a constructive manner as he was talking to someone with more experience than him/her.

If you're writing something totally new, you usually throw ideas and mocks (either UI or code-structure) until you decide on a solution that works.

I've found this to be pretty good at helping newer engineers write good (and idiomatic) code without hindering development speed much.

On the other hand having the Architect act as editor after the code is written not only provides the "code review" function, but it provides the additional benefit of providing the Architect with feedback on the original design, and how the abstract design ideas are translated during the construction phase.

I think it would improve communication on both sides (Architect and programmer) as well as overall quality...very nice...

It is not in the interest of the programmer to allow others to understand his code. That would make him easily replaceable. I know quite a few consultants who write like that on purpose and secure their jobs this way.

Programmers are also not rewarded for clean code. They are rewarded for quickly delivered code. Beautiful code that is delivered two weeks too late is usually a bad idea. This is business logic.

It is easy to measure, how long it takes a programmer to develop code. It is much harder to measure, how much time is wasted to maintain badly written code.

Much speaks against writing clean code, little is in favour. The only persons interested in this are later maintainers and academics.

Lets face it: whats wrong with code that is a bit messy but does its job correct and quick? If the author himself has to edit it and does not understand it anymore, then he/she will refactor. If there is no need to touch this code because it does its job, who cares? If the original author is already gone and there was no time to make someone else familiar with his code and style, think about how people are treated in your company and refactor management instead of code.

Also, we practice code review at our work. That is definitely a way of fulfilling the role of being editors.

    - didn't have a frickin' clue what the code was supposed to do

Being open to refining your idea or pivoting as you go is a horse of a different color.

But trying to write code without a clear purpose in mind is the equivalent of monkeys banging away at typewriters, to return to our "writing" metaphor.

I wonder what the average startup codebase looks like?

Code gets complex as hell very quickly. If it was building a house, it would be built in a week and architected on the fly. The person mixing the concrete, who has to know the concrete grade and drying time, also has to know that the upstairs has just shifted and now the load is too much on the center beam.

The reality is that, unless your dealing with tiny apps, that "bad programmer"? It's you.

That said, there are programmers who are legitimately lacking both in basic skills and desire to attain those skills. It's orthogonal to the problem you're talking about, but these people do exist, and they're not as uncommon as one might hope. I can teach the difference between pointers and references; I can't teach you to care.

Needless to say, it failed. The guy was irreparably lazy, and trying to get him excited about building the things we are fortunate enough to get paid to build only made him try to put me under a bus when he got the chance. I had to let him go, and have slept better ever since.

For the most part the Django codebase has clean code, and its rapidly understandable. Where that's not true is the original SQL db, and the Forms library. Elsewhere its a dream to hack with.

I'd also praise the codebase of SQLite, and Lighttpd---these two are very clean.

teams reacting to changing or poorly-understood requirements (think enterprise and defense software contracts) have a much harder task. nobody has solved the problem before, nobody understands the problem, and project managagement is typically forced into waterfall in order to make sales, so its not like there's time to redo things that get duct-taped together, if the duct-tape holds.

The worst writing I've seen:

* is ungrammatical to the point of incoherency

* loses its train of thought mid-sentence and talks about something unrelated

* is full of irrelevant details

* simply ignores everything above the sentence level, producing mere text, no argument, story or whatever it was supposed to be

Not really the same failure modes.

Really? Because except for the first one (which we have compilers to thank for), your three remaining points apply equally well to a lot of code I've seen.

Who has not seen a piece of code that is so bad they don't even understand how it can compile, coming out of a newbie?

Doing strange undefined things in C comes to mind as a usual case where this happens.

"How do I do what I want here? Aha, someone already wrote ExactlyWhatIWantHere.... WTF, it doesn't even compile? But how is anyone using it? Oh, it's not being used anywhere? How the heck did it get here? Ugh..."