Hacker News new | past | comments | ask | show | jobs | submit login

I think one reason why people like to write supposedly clever code especially on the realm of software development is due to lots of these developers want to get acknowledgement of what they produce. And hearing someone say "Oh, this is a very clever implementation" sort of fix that inherent need to be recognized. I haven't heard (particularly in corporate environments) where a praise in the line of - "wow, this was a very clear and simple implementation" trump what managers and people deem as superior when the term clever was attached to it.

I've challenged far quite a lot of implementations where understanding a piece of functionality has required for the developer to jump between more than 23 files across 8 different projects in implementing a very domain specific functionality. Splitting code into single independent parts introduces simplicity, only and if only you are reading that part by itself, but when you layer it overall to get the functionality it delivers and it becomes a web of tangled mess of code, then that clever solution was not really clever after all.




I have an intuition about library design that I’ve been slowly trying to formulate into a set of guidelines. I have extremely high standards in this area and not being able to state them concretely makes communicating them a struggle.

One of the ways I complain about particularly bad decomposition (the sort of practices that lead to parodies like Enterprise FizzBuzz) is the ridiculousness of stacktraces for errors in these systems.

We tell people to use delegation but many have trouble differentiating delegation from indirection. You know things have gotten particularly bad when you have traces with the same sequence of three or more functions appearing three times. Debugging this is a nightmare. It’s literally a maze of logic. This type of code has to be memorized to be understood, which further makes an existential threat of a saner person’s attempts to refactor it - moving things around to be discoverable and debuggable comes at a cost to the people who already memorized it.

There is also DAMP vs DRY and “desertification” of code, which is related to the good versus bad indirection problem.

When you get a prolific “clever” person who suffers from these problems, the whole team suffers with them (which is why I need a new job...).

Someone above mentioned flame graphs, which is a trace of every call in the system, typically for the purpose of visualizing where time is spent by the CPU. In thinking about this thread, I now want to look into using them as a measure of time spent by the reader.

My overall philosophy on code is that we should use our best days to protect ourselves from our worst days. I expend most of my clever on trying to make things look easy, which is a bit of a challenge come review time because one of the hallmarks of really clever reasoning is that people react by saying things like, “well of course it works that way”.




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: