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."
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."
Why do you think the average salary of a Windows Admin is lower than that of a Unix/Linux Admin? Because Microsoft pushed the "we've made it simple, just push the button" marketing drek and aimed it squarely at the management crowd -- who bought it hook, line and sinker.
"They made it easy, so I shouldn't have to pay you as much because anyone can do it. I'll just hire some kid with the latest MS cert..."
It's more complicated than that. Salaries are lower because there's a herd of "kids with the latest MS Cert" that also bought into the "it's easy" line of thinking. It's not, but it sure looks that way. Managers are always looking to save a dollar of course, and many of them don't have any ability to distinguish talent from dreck. Even after they hire the dreck, they might be forced to put up with it as the "new normal".
It stems from a mentality of measuring salaries, but not measuring consequences of fucking up. Let's say John knows what the hell he's doing, but is paid $120,000 a year and rarely screws things up. John managed to increase productivity and save $50,000 last year through some innovative thinking. Joel is paid $50,000, but is constantly fucking shit up. Just last week Joel took down the network through one of his changes, and cost the company $20,000 in lost productivity. Over the past year Joel has cost the company approximately $200,000 in lost productivity due to his own point/click mentality and a management team that encourages this rather than learning and risk management.
So John costs $70,000 a year, and Joel costs $250,000 if you add up all the costs and savings from each. Yet if you only look at salaries, it looks like John should be replaced with 2 Joels, at a cost savings of $20,000!
So part of the problem is not measuring employees true worth.