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

When i was taking freshman CS classes, this was a running joke with my classmates. Wed take to google for helping fixing an error, and 90-95% of C++ 101 questions have at least one answer in the form: "why are you trying to do this? Unless you know what you're doing (which by your question you probably dont), you should by using different methods entirely."

Friend having a coding problem? Give 'em the SO special: "Have you tried using vectors?"




My favorite anecdote, and the one I trot out every time this comes up, was the time I was asking for help in golang-nuts and on the IRC figuring out a few things about unsafe/uintptr. I was participating in a code competition with performance as a primary metric and learning Go at the same time. Trying to get somebody to answer very straightforward questions about casting was worse than pulling teeth; everyone wanted to work their way into a back-seat architect role on my "real goal".

"Hey, here is this task/problem I'm solving. Is this solution okay or is there a better solution?" is a very different question than "I'm trying to cast this pointer back to this slice of types but I'm seeing this error; what am I missing?".

A somewhat related pet-peeve of mine is when software authors bake assumptions about how somebody "should" be doing something into their projects at a low level causing it to become unnecessarily inflexible and often time inconsistent with what you would expect. I've run into this with a lot of Gradle and gradle plugins.. My first big experience was perhaps trying to convince NTFS3G to allow the user to clear or override the dirty bit for certain resize operations. It can take a lot of convincing to get people to expand their concept of a "valid use case" and create escape hatches and flexibility for those atypical situations.


> ...unnecessarily inflexible...

Opinionated frameworks are much, much easier to write. Abstraction and generalization are hard, and a lot to ask of people who are likely creating something for free. The fact that a framework doesn't make the choices you would have made doesn't make it wrong, or unnecessarily inflexible. They're necessarily inflexible to keep the burden on maintainers and new contributors as low as possible. Just because one person has an edge case isn't a good reason to write a bunch of new code.

See also, yagni.


Never mind the people who think you shouldn't do something, it seems like most of the time when I look up something on SO these days, the solution is terrible or everybody agrees there is no solution, and after spending maybe 20 minutes more searching, it turns out that, yes, there is a way to do it that is infinitely better.

One of the most important things that is needed for finding a solution to any problem is a sense of what a good solution would look like, and a certainty that it exists even before you have seen it, and even if you can't invent it yourself. Not knowing when to settle is the reason people usually go with terrible approaches to a problem.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: