Don't be a Codemonkey

If you are just writing for yourself, and you don't need tests, etc. then who cares what you do. Follow your bliss and more power to you. But if there is some chance I will have to fix or figure out your code - please DO try to make it maintainable. Useful code is useful even if it's dirty, but it's just polite to consider your audience. Surely this is not controversial?

Maybe the issue here is some disagreement about what "maintainable" means and in particular, in how and where it conflicts with "clever."

If "clever" means intentionally obfuscated, or doing something in a complex or unorthodox way just to show off, I don't think there is much controversy that this is unhelpful and not good unless you are just pleasing yourself. If "clever" means extreme conciseness beyond the point where it makes it very hard to read and understand, I would tend to look at that as more of the same.

Cleverness is often instituted to make code more maintainable, as in many cases of "Don't Repeat Yourself" using introspection. I tend to think that gratuitously huge amounts of mandatory boilerplate are very not-clever and actually decrease maintainability.

For example, I have seen dependency injection being heavily touted for 'maintainability', but making a religion out of this can lead to all kinds of tortured and unclear code (just like what you see from many people who have recently become infatuated with "patterns"). Code which is overly complex for the task, and hard to read, isn't that maintainable in my book.

Cleverness can also be done behind the scenes of an API, hidden behind a screen, to make life easier for the API's end users. Sometimes this is good, sometimes bad. Often it is worthwhile to get a clean implementation, just hard to do.

I don't think there is any clear definition of "code monkey" but I think such derogatory terms should be reserved for people who are really incompetent all around, not just people who do clean workmanlike jobs and worry about how their code reads and extends and so on. Those are good things to worry about; there are other things to worry about, but those are good things to worry about.

I have to disagree with this.

There's plenty of ways to be creative and still be disciplined.

I find myself spending a lot of cycles reducing solutions to their most simple form -- removing everything unnecessary until just what's required remains.

Or, designing large systems. Giving my input on UI layout / design / experience. Imaging use cases and how users will use the software -- what assumptions will they make?

Data structure selection, sync vs async, and a whole myriad of trade offs and judgment calls are all creative processes.

We're professionals after all. We're employed for the finished product -- let's make it as good as we can.

You can always code outside of work to flex your creative muscles if you find your work environment too restricting.

This is a blatantly false dichotomy--how fun and clever code is is not inversely proportional to how much fun it is.

If anything, I've found the opposite to be true: the code I have the most fun writing is also the code I find easiest to maintain. My latest side project--writing an interpreted language in Haskell--has been extremely fun and disconcertingly maintainable. Being able to add complicated features that I thought would take a while in a couple of lines of code is just eerie.

Coincidentally, this brings up my second point: writing maintainable code makes the latter 90% of programming (debugging and adding features after the fact) more fun. I think it's a win.

I don't see why you can't do both? Wrap "clever" things in well tested black boxes that can be used in maintainable systems.

I guess I don't get the article. "Clever" ideas for startups don't translate to "clever" solutions in code. Someone can have an idea of something "new" for a startup, but the patterns in code are often the same. In that sense having well designed code can be a plus and doesn't mean sacrifice of the uniqueness of the idea. Even if my startup requires a "clever" algorithm for speed or scale, that can be wrapped in a coherent black box that enables the code using it to be easily readable and maintainable.

Maybe I'm just misunderstanding, I'm not sure?