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:Too Late

[DigiShaman]

Which is funny, because in the world of Windows Administration, either you're a complete idiot, or an experienced Windows sage that's very good at cleaning up other peoples mess, and running the network properly. There is no middle ground unless you've gained the experience under the wing of such a sage.

Re:Glueing things together is how I teach OO desig

[quietwalker]

That's my experience as well, at least, as of the middle 90's. Why use a mainstream, commercial language, when you could use a theoretically complete one? One where they recognize that features like "output" and "input" are dirty exceptions that spoil the purity of your program when you're trying to get a good hard proof using Hoare logic.

Better not clutter up the syntax either by using confusing, pre-existing symbols to form constructs, not when you can add whole new symbols requiring a special (APL) keyboard!

I remember having a TA once challenge me - I had written an algorithm to operate iteratively, rather than recursively, because I had noticed the program would run out of memory if I did it the other way when fed large data sets - because to him, recursion was theoretically perfect and not using it was a personal affront. The fact that my code worked and his crashed after 4-5 minutes didn't matter.

To paraphrase a professor of mine, "There's absolutely no reason for a computer scientist to use a computer."

This sort of attitude was pretty rampant all throughout my college career, fairly startling having already been employed in the industry for some years prior. No concept of real world usage at all, or worse, some strange bias against it.

Re:Glueing things together is how I teach OO desig

[Darinbob]

I knew someone in late 90s who was upset that we weren't using Java for a highly complex embedded system used for medical work, and instead used something archaic like C++ (seriously, he thought it was archaic in its heyday). We'd explain to him that we can't throw out all the work and start from scratch without spending years, that Java at the time was terribly slow, that there were no distinct advantages of changing or reductions in complexity, etc. But it was his first job after his master's. Later on he started a (tiny) company and gave a keynote address at a Java conference where I heard third hand that he had put down his former employer for being such a dinosaur. It wasn't even that this guy was an academic idealist but that he merely was caught up in fandom.

Re:Odd title

[edtice1559]

I don't doubt your story but the problems we are solving today are more complex than the ones of years ago. In the 1970s if you wrote a nifty way to solve the quadratic equation you might be considered a super star. (Okay that was somewhat of a dramatization) But today we are dealing with much more complex domains. In many cases we are trying to model human behavior. It's simply not possible to solve these problems if we didn't have building blocks. What we really need is a good understanding of the problem we are trying to solve and enough technical skills to turn that understanding into something working. Getting the problem description right is where the heavy lifting should be. If the implementation involves fussing with tools rather than working on the problem, the tools should improve.

Re:Glueing things together is how I teach OO desig

[mrchaotica]

There's a lot of things like this in C++ that can slip past a person for years before it actually bites them. Don't get me wrong, I love C++ and think C is a rather dangerous language (from a memory safety standpoint) that requires that its authors reinvent the wheel over and over again. But C++ does have some weirdness in places that can pose hazards.

C++ doesn't have "weirdness," C++ has bad design. Literally anything that you might think C++ would be good for is better solved by either C#, C, or a combination of both.

Re:Too Late

[aix tom]

I always like "update holidays" in our company.

The Windows Admins run around sweating, clicking this clicking that, checking there, trying thing a couple of time in the test environment, then switching to live, etc.....

I recline in my chair, open a terminal to run the update scripts I have tested beforehand, and a Media Player to watch some TV shows while they run. The thing is, the "little things" I have to install on the Windows machines are also scripted the same way, while the "Little things" the Windows Admins need to do on the Linux machines they also use some GUI Tool.

90% of "System Administration" is "knowing how things work" For example the technicalities on how IPs/Network-Masks/Gateways/routes, etc... work are absolutely identical in both Windows, Linux, IOs, whatever. There used to be a time when the only way to set them in Linux was the CLI, and the only way to set them in Windows was the GUI. That is no longer true. Now you can also use a CLI in Windows and GUI-Packages to manage them in Linux. The same way that most Cloud/Web/Whatever applications can be administered either via a GUI or a CLI.

So the difference is not really Linux/Windows any more, it's more of a GUI / CLI thing. So any admin might need to learn three things:

- How "Stuff" works.
- How do set up "Stuff" via the CLI.
- How do set up "Stuff" via the GUI.

It's interesting that even Microsoft (for example with SQLServer) only expose "the most commonly used" settings via the GUI (SQLServer Management Studio), while "all" are available via the sp_configure procedure that can be called from the CLI.

So in system administration I have either the option to:

- Learn "Stuff"
- Learn the GUI
- and then a few month later when I'm bored out of my skull by repetitive steps I need to do over and over in the GUI to learn the CLI to automate it maybe sometime later.

- Learn "Stuff"
- Learn the CLI
- go on learning new "Stuff" after the boring jobs have been automated.

Re:Too Late

[TsuruchiBrian]

Right up until you meet the limits of what a low skilled person can do.

There is always a limit to what a person of any skill level can do. All I am suggesting is that raising that limit is a good good thing, even if it means accomplishing a task pays less money.

For example I don't think it's a bad thing that any idiot can look at google maps and have a very accurate set of directions. I think it would be worse if getting good directions required a very highly skilled and well compensated cartographer.