Comment by remeq | Hacker News Reader

Comment by remeq | Hacker News Reader

Parent Full thread

I despise this kind of mentality which tries to demonize someone's passion to actually write a beautiful code. This kind of mentality takes away "the human factor" from the working environments turning IT jobs into delivery driven factories. I for one need to enjoy my work to actually be productive. And don't get me wrong - I understand that product people need to deliver products and they enjoy doing their diagrams and presentations but I am an engineer, and I like myself and my life and as a result I just want to do and be surrounded by beautiful things so I honestly don't give a shit if some product will not be delivered on time because product managers did include only business requirements and ignored requirement of my engineering team that we need to be able to sign our name under the code we write and be surrounded be beautiful things in our work life. Sorry, but engineers are part of the team, part of the product, if you ignored that at the beginning, it is not our fault.

Also, ability to write beautiful code implies the ability to deliver code much more then vice versa because there is a good chance that someone who actually is capable of writing beautiful code had to get to that level by actually also delivering stuff to production in the past.

So yes, in my world, someone who writes a beautiful code (meaning - correct, performant, maintainable, understandable, clever and so on) is a pretty good candidate to be a role model.

> meaning - correct, performant, maintainable, understandable, clever and so on

The only little nit-pick I have here is the use of the word "clever". Maybe you and I define clever differently in a software engineering context, but to me, "clever" is a dirty word in programming.

For me, "clever" means undefined behavior, one-off hack, difficult to parse, shortcut, etc. The difference between "clever" code and "bad" code is that "clever" code is written by someone with a lot of knowledge and experience. Their knowledge and experience has allowed them to work with the undefined/undocumented behavior of languages, libs, etc in order to come up with a solution that has the least lines of code/uses the least memory, etc. Not to say that those things are unworthy metrics, but "clever" code doesn't seem to consider maintainability or stability.

I think a better descriptor to strive for is "elegant", defined in my opinion by code that is beautiful in it's own simplicity, succinctness, reliability, and correctness.

For me clever is when someone is facing some problem and comes up with clever solution. Something that for example reduces complexity from O(n^2) to O(n) due to some smart idea. But I agree that elegant is another quality which can be added to the list :)

> meaning - correct, performant, maintainable, understandable, clever and so on

My favourite part of this is how often these criteria are essentially at odds.

    - Understandable *and* performant?  
    - Clever *and* maintainable?

But, you know, I'm also bad at all this so maybe it's just me :p

Yeah, I didn't really mean everything at once, I just wanted to make clear that "the beautiful" can be disaggregated into some engineering qualities.

Yeah, it was more a comment on the natural compromises that come about from trying to be all of the best things in your code. Perfect being enemy of good etc.

Agree entirely that they're all things that contribute to "good"

IME it's you (but /Pace/, no criticism intended, it may be that my area of databases + business dev allows this more easily than yours).

Part of it is using the tools others aren't aware of, so simple things become simple (counterexample on codinghorror, someone not knowing that XML has libraries to parse it, and started parsing it manually with regeps. From my own experience taking over a web-scraping project, I used XSLT where they previously used regexps). I have plenty of other examples of people doing things the hard way because they didn't read the docs.

Part of understandability is recognising a simple solution exists instead of a tangled ball. The simple SQL solutions are often most efficient, with tweaking, and the most understandable (which does NOT get you out of writing comments, BTW!)

Performant? The easiest code to optimise is that which is well written and nominally 'less than efficient'. This separation of layers allows me to put in new layers easily as I can see what's going on. Example: for an SQL + pascal product I got a minimum 10X speedup on the GUI, which really made a huge difference to the users, by sliding in a 3rd layer between 2 existing layers. It was simple and quick to do (3 days).

Other example: if someone had thought for a moment about creative use of SQL indexes they'd not have written another complex - and slooooooow - feature in the product I just mentioned.

So IME understandable = clever = performant = maintainable surprisingly often.

(disclaimer: I'm no coding god, I make plenty of mistakes too).

Reply on news.ycombinator.com