Hacker News Reader

Comment by jordanlev | Hacker News Reader

> attack things with their limited experience and knowledge and fail to understand things fully before heading in

Over the years I gradually came to this core truth of programming: solving problems is easy, it's understanding what the problem is that's hard.

Kinda sorta similar to "it's not about coding, it's about modelling": http://www.chris-granger.com/2015/01/26/coding-is-not-the-ne...

View on HN

I found a quote recently by G.K. Chesterton about this that I really like.

"In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."[1]

[1] http://www.chesterton.org/taking-a-fence-down/

That used a lot of words to say very little.

It appears to be less true now than in days past, but humans are -first and foremost- storytellers. we like to tell stories, we like to listen to stories, and we -often- better remember lessons imparted in the form of a story.

Moreover, if you're trying to alter someone's opinion about the truth of a matter, you almost always need bolster your core argument with supplemental material. You often don't know much about your listener's background, you probably don't know what motivates him, and he may very well be opposed to your core argument for entirely unreasonable reasons. It's often best to surround your core argument with a large, somewhat varied structure, so that many folks will find some way to latch on to it.

Sounds like a great way to start a fight with a monkey in a cage.

Nobody builds a fence for no reason. Keep in mind that he isn't implying that it was a good reason, just that there's a reason why it's there and you should understand that reason before taking it down.

I can't get to completely agree with it, but the completely opposite idea that you should just not care is stupid.

Also, understanding which problems are worth solving is hard as well. That's where the "charge in like a bull" approach can be handy: a number of problems are worth solving that people shy away from, either because they're viewed as too inconsequential or because they're viewed as too difficult, and they don't get resources devoted to them until somebody has paved the way with a quick & dirty solution.

> solving problems is easy, it's understanding what the problem is that's hard

Great way to lay it out. How many hours have I spent debugging just to come to the conclusion that the code does everything according to the requirements — it's the requirements which are buggy.

> solving problems is easy, it's understanding what the problem is that's hard.

I completely agree. These days, I work as a sysadmin/helpdesk monkey, and I am having this experience pretty much all the time - once I understand what is wrong, the solution becomes pretty obvious. Finding out what is wrong, though, can be really tricky. (More so on Windows - troubleshooting on Windows often enough ends in "Let's just reboot and hope it works next time")

Reply on news.ycombinator.com