Overcoming Intuition In Programming (amasad.me)

An anonymous reader writes: Amjad Masad, a programmer who works at Facebook, has put up a post about intuition and programming. It's based on a series of experiments (PDF) into how the presentation of a problem affects the learning involved in solving it. Researchers found that if they made a test deliberately hard to understand, those taking the test would exhibit greater understanding after solving it than those who were presented with a more intuitive wording of the same problem. Masad discusses how the research applies to software engineering: "Programming is an intellectually challenging task, but luckily we invent tools to make it manageable. I find that up to a certain point, the intuitive and easy properties of a given language, framework, or library might start to have negative effects.

From personal experience and from mentoring beginners I noticed that when using tools that allow us to reason within our intuition, anytime we're faced with some difficulty we feel that we've done something wrong. And although we might have the necessary skills to overcome the difficulty, we often start questioning and revising our work." He concludes, "Code reuse, libraries, sharing, and open-source are very important to software engineering, but we should be careful to not enable the belief that programming should be as easy as gluing things together."

Comments

Re:Odd title

[gstoddart]

Yeah, I always found coding (and especially debugging) required a level of intuition ... precisely because it was more than just gluing pieces together.

I understand you don't want to rely too much on intuition, because it's hard to sound like anything other than voodoo, but sometimes the voodoo is still a real thing.

I worked with someone years ago who liked to go on about how everything should be abstracted and pretty/elegant according to whatever was popular that month. He read the books and magazines incessantly, and wouldn't shut up about them.

The problem is he often wrote shit code he couldn't maintain or debug because he'd abstracted things so much it was impossible for him to follow his own code, or know where to look when things went wrong. A small enhancement request left him squealing how the code wasn't designed to do that and he'd have to rebuild it. Meanwhile the rest of us went "so, all of that is in here, and if I just nudge this a little it's all done".

I'm sure he got better over time, but for someone who was so loudly a proponent of the latest language theories and methodologies, he never seemed to understand how his neat intellectual model in no way translated into maintainable, readable, or sometimes even useful code. But his insistence on following all of these things usually had the result of him making absolutely terrible design choices.

These frameworks and methodologies sound awesome on paper, but you can still use them to write complete garbage code which is brittle, inflexible, and often completely wrong for what you're trying to use it for.

Whereas the guys who learned to program and debug without the syntactic sugar and frameworks to build upon, those guys tended to have a bigger picture view of the pieces. Which means you can zero in on where you think it likely went sideways instead of staring blankly wondering why your monument to methodology is now a teetering mess you have no idea where to begin with when there's a problem.

Re:Too Late

[TemporalBeing]

If MS made their software easy enough to use that a low skilled person can do it, isn't that a good thing?

Only for Microsoft and their Partner when stuff breaks and you have to bring in experts because it's really foobar'd up the wazoo, so much so that only hands-on work by MS can solve the problem - on and it comes at really high billing rates too.

Re:Glueing things together is how I teach OO desig

[mrchaotica]

If your C code leaks memory, you don't know WTF you're doing -- which is exactly why a department of CS professors who don't use C is so damn scary.

And I don't give a shit if you think you don't need to use pointers; that's fine. You still need to understand them so that -- if for no other reason -- you understand why in Java or C# not every IEnumerable should be a List.

Also, if you think a high-level language will save you from remote code exploits, I've got a bridge to sell you.