

Don't be a Codemonkey - blackhole
http://blackhole12.blogspot.com/2012/02/dont-be-codemonkey.html

======
reuser
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.

------
scriby
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.

------
tikhonj
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.

------
drivebyacct2
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?

