Typical Programmer

It is often the case that the simplest solutions require the greatest skill in achieving. Thus, I agree immensely with avoiding unnecessary complexity whenever possible, but not "We should endeavor to write code that a novice programmer can easily understand without explanation or that a maintainer can understand without significant time investment." --- which tends to lead to extremely verbose, inefficient, and dumbed-down code.

In other words, if you only ever use the very simplest features of the language, you are effectively reducing micro complexity but increasing macro complexity. One of the best examples of this is the classic arguments over the use of the ternary/conditional (?:) operator --- those against say it's hard to read and should always be replaced with if/else, while those for say it simplifies the code by removing redundancy and should always be used in place of an if/else with a single assignment statement with the same LHS in both clauses.

Similarly, if you believe programmers are almost completely incapable of understanding operator precedence, or that it "makes code hard to read" and restrict expressions to only one operator (and mandate that variables be created for all intermediate results), then you will get code with all the verbosity of Asm but none of the benefits.

In other words, good code may not be immediately obvious; but your reaction when you do understand it should be one of pleasant enlightenment, and not "I can think of a simpler way…

I wasn't able to figure out how to post a comment/reply on Blogger, sorry.

Thanks for pointing me to your article from the HN flame war about MongoDB. If only there were more useful articles like this and less flaming.

You wrote "...in MySQL, the application is king and the db a humble servant." That is exactly my experience, and it leads not only to terrible databases but to piles of awful code written around terrible databases. In 1974 Kernighan and Plauger wrote "Choose a data representation that makes your program simple" (Elements of Programming Style). Other esteemed programmers have said the same thing. A well-designed and normalized database schema with validations and access rules implemented in the database will reduce the amount of application code needed.

I've written about keeping data management code in the database where it belongs (http://typicalprogrammer.com/?p=101), but you make a much clearer argument with real examples. A few years ago the Ruby on Rails people championed the idea of "application databases" and writing HTTP+XML APIs, which probably seemed like a great idea given that few, if any, Rails applications ever had databases that other applications needed to access. Now the NoSQL folks have taken this even further, eliminating structure from the data and all ACID compliance, separating the data from integrity enforcement, all in the name of scalability problems their app might have if they get as big as Google.

I am stuck with MySQL most of…

"Surprisingly, left to themselves programmers don’t revert to cowboy coding—they adopt or create methodologies stricter and more filled with ritual than anything I experienced in 1980. In fact programmers today can be much more rigid and religious about their methodologies than they imagine a 1970s-era COBOL shop was. I now routinely get involved with projects developed by one or two people burdened with so much process and 'best practices' that almost nothing of real value is produced."

Sing it, brother! Can I get an "Amen"?

I know of one project with a technical lead who, to my knowledge, has never done anything other than support the vendor program the project is replacing; the team has developed a process built primarily around avoiding Subversion merges (which is not necessarily a bad thing given that they seem to actively resist learning anything about how to use Subversion) and secondarily around adopting anything anyone has ever described as a "best practice", including inventing a few new ones. So far, I do not know of anything their project actually does, although there is a great deal of it.

Oh, and their scrum meetings seem to involve the scrum master reading a fair amount of text from PowerPoint slides (which have far too much text on them).

[Edit] Apparently, I can. http://typicalprogrammer.com/why-dont-software-development-methodologies-work/#comment-4460

Having a separate team of "maintenance programmers"[1] who fix bugs is a decades-old idea, and I worked in an environment like that years ago.

I think it's much better for the original developers to have the responsibility for fixing their own bugs, since it gives them the incentive to be more careful when writing and testing their code. Not allowing them to write new code until their known bugs are fixed puts the brakes on impulsive developers who churn out unreliable, poorly-tested code quickly.

Also, people who fix bugs in other people's code tend to have a worse understanding of the code than the original authors. This pushes them into making microscopic fixes that address the symptoms of the currently-reported bug, but may introduce new bugs. In contrast, the original author might have the knowledge to rewrite a larger part of the code in a way that fixes many related bugs and makes the code more reliable.

[1] http://typicalprogrammer.com/the-joys-of-maintenance-programming

Some more quotes taken from http://typicalprogrammer.com/what-does-code-readability-mean that you might find interesting.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. – Martin Fowler

Just because people tell you it can’t be done, that doesn’t necessarily mean that it can’t be done. It just means that they can’t do it. – Anders Hejlsberg

The true test of intelligence is not how much we know how to do, but how to behave when we don’t know what to do. – John Holt

Controlling complexity is the essence of computer programming. – Brian W. Kernighan

The most important property of a program is whether it accomplishes the intention of its user. – C.A.R. Hoare

No one in the brief history of computing has ever written a piece of perfect software. It’s unlikely that you’ll be the first. – Andy Hunt

What if I'd done that 20 times around my code-base and then later I discover there's an off-by-one error in the original code that's maybe been inherited into all 20 copies?

If I could actually reuse code properly I'd only have to fix it once.

Without effective code reuse, I have to hunt down the copies, each of which may have slight modifications to make them better fit their use case (and might be hard to grep for as a result), figure out whether or not the bug exists in that copy (and whether it can actually be triggered), and fix it there.

The description of inheritance in http://typicalprogrammer.com/abject-oriented/ seems relevant here. (Edit: Derp, junke got there way before me!)