Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×
Programming Education

Overcoming Intuition In Programming (amasad.me) 237

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."

This discussion has been archived. No new comments can be posted.

Overcoming Intuition In Programming

Comments Filter:
  • Too Late (Score:5, Insightful)

    by chill ( 34294 ) on Monday January 04, 2016 @02:21PM (#51236199) Journal

    "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."

    That is the management view of programming and a major corporate goal. This way it reduces the skills needed to complete the task, and hence you can pay less for the less skilled laborers.

    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..."

    • If MS made their software easy enough to use that a low skilled person can do it, isn't that a good thing?
      • This is a prime example of 'all of the power, none of the responsibility.' type of thinking.
        • No it's an example of a question being asked.
          • Actually, it's both and the post you were replying to is an example of a valid explanation of the problem.
            • I don;t think the post I was replying to is a good explanation because it seems to suggest that making things easier (require less skilled labor) is bad because it leads to lower pay for those jobs. I disagree with this assertion, but I am not even sure if he is making it, which is why I was asking.
      • Re:Too Late (Score:4, Informative)

        by TemporalBeing ( 803363 ) <bm_witness@nosPam.yahoo.com> on Monday January 04, 2016 @03:25PM (#51236725) Homepage Journal

        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.

        • Well it seems that the scenario you are talking about is the one where the software doesn't allow a low-skilled person to do the job.
      • Re:Too Late (Score:5, Insightful)

        by gstoddart ( 321705 ) on Monday January 04, 2016 @03:29PM (#51236755) Homepage

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

        And then you can quickly get into uncharted territory which requires much more understanding.

        Sure, that low skilled person can do "some", "many", or possibly even "most" of the tasks. And they can also drive you off a cliff through lack of understanding.

        Anybody who has ever dealt with outsourced admins who can follow a script can tell you that when those people go outside of the script they will become utterly useless, if not outright dangerous.

        And at that point, you're deeply screwed if there's not someone around who actually understands the rest of the stuff. It's not pretty to watch some noob with a little knowledge completely screw up a corporate environment.

        • by Nidi62 ( 1525137 )

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

          And then you can quickly get into uncharted territory which requires much more understanding.

          Sure, that low skilled person can do "some", "many", or possibly even "most" of the tasks.

          If your entire shop is full of low skill people you are screwed anyway. If your daily work is simple enough that low skill employees can do most of the work, then that's why you keep senior employees around. Their job, besides doing daily work, is to jump in when the newer, less skilled employees run into problems they can't solve and also to train said lower skilled employees when those situations arise.

        • Re:Too Late (Score:4, Interesting)

          by TsuruchiBrian ( 2731979 ) on Monday January 04, 2016 @08:33PM (#51238835)

          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.

      • There tends to be a perception amongst the Linux crowd that things like email and web browsing should be easy (to foster greater Linux adoption) while things like system administration *should* be hard (to discourage newbs / the uneducated, and to forgive clunky, inconsistent, and poorly documented tools).
        • by epyT-R ( 613989 )

          There tends to be a perception amongst the windows/mac and web 3.0/mobile crowd that complex things be made simple at any cost, even if the result is only the appearance of simplicity, just to give newbs the impression they understand more than they actually do.

        • Re: (Score:3, Interesting)

          by aix tom ( 902140 )

          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 Window

      • by mwvdlee ( 775178 )

        Knives are very easy to use, but that doesn't mean I'll let some random bozo perform surgery on me.

        • In a world with relatively few people that are very highly skilled, I think it makes sense to have those skilled people doing things like surgery. I think I can live with a less skilled windows IT admin.
          • I'm one of those highly skilled people, would you like me to perform that difficult (even for a skilled surgeon) surgery even though my skills lie in the realm of computing? Simply being "highly skilled" does not make one highly skilled at everything, so I sure hope you answer is "no", for your own sake.
            • I guess what I am asking is for you to think about what I am saying in a more meaningful way rather than the trivially incoherent way that you have decided to interpret what I said.

              If I asked "What came first, the chicken or the egg?". An answer one might give is "Obviously the egg came first because lots of prehistoric animals had eggs before chickens ever existed". I am asking you not to give this answer.

              • Oh, no, I get what you're trying to say, I'm just subtly pointing out the fallacy of your reasoning. You see, for various reasons, I am not well suited to be a surgeon or a chemist, or most other highly-skilled professions that you might deem worthy; knowledge is the least of those reasons. You certainly wouldn't want my shaky hands cutting you open or digging around inside you, nor mixing chemicals to form an unstable but important solution, so it would certainly be worthless for me to pursue those fields.
                • You seem to be making a lot of very narrow assumptions interpreting what I said. I am not going to go into all the logical fallacies you are probably making with your reasoning, because I don't feel it's worth my time, and I don't like make assumptions about what people are thinking.

                  But I'll offer up a few hints...

                  1. The fact that not every high skilled person is high skilled in every possible skill, does not imply that every high skilled person is/ can be only skilled at one thing.

                  2. The skills that "peop

                  • It was your third point that made me realize the point you were trying to make, which is actually complimentary to the point I was making. It was your tone that made me stop reading before I got that far and go do something else; I only read so far as my eyes grazed the screen when I came back to close this tab. That you chose that particular tone tells me that you still fail to see my point and think that I am arguing when I am not.
            • The Principle of Charity [wikipedia.org] is the first lecture in any decent university-level critical thinking course. It should be required knowledge for any Slashdot comment thread.

      • Their software can be easy enough to use, that's good, but the creation of the software should not necessarily be easy to do. The tieing together of complex parts does not create a complex product that's well designed. A turbo engine duct taped to a bicycle.

        • First of all I didn't say that MS's software is easy to use. I merely suggested that *if* MS software was easier to use (requiring less skill/effort for the same result), that that would be a good thing. Chill (the person I was responding to, seems to be suggesting the opposite is true (i.e. it's better if the software is harder to use).

          Second of all, I would say that the job of software is precisely to make hard things easy. If the goal was to create a jet powered bike, then good software would generat

    • Re:Too Late (Score:5, Interesting)

      by DigiShaman ( 671371 ) on Monday January 04, 2016 @03:15PM (#51236625) Homepage

      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:Too Late (Score:5, Insightful)

      by Anonymous Coward on Monday January 04, 2016 @04:18PM (#51237069)


      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.

    • "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."

      Too bad he hasn't told this to his colleagues at code.org.

    • by unimacs ( 597299 )
      In my experience it's usually the IT people that have religious fights over Linux vs Windows.

      Management wants stuff that works and costs to be low. They may want a Windows box or Mac on their desk, but they don't care what's running on the servers in the rack.
    • In my country both get payed the same, actually MS jockeys a bit more as they are rather rare. No one really wants to administrate such systems.

    • major corporate goal

      Is there a technical reason why this shouldn't be a goal? I've spent the better part of my software career in making systems "as easy as gluing things together." Granted, I have written myself out of a lot of jobs, but I work for interest in the system and making something, not to give myself a job.

  • Like this
      X 3 3÷9 Y DATA[DATA] A comment

    I really don't mourn APL's passing.

    It is nice to see that programming as a discipline has reached the point where it questions it's great successes.

    • I think that what they are trying to say is that if we all are presented with problems that we solve in assembler then we will develop a very good understanding of how to solve a large number of problems computationally as we will have a very good understanding of the underlying computer architecture. (How's that for a long sentence?)

      I've known a lot of brilliant assembler programmers and I have to admit, I've always admired them for their skills. Even so, I can get a whole lot more done than they can us

      • by chill ( 34294 )

        The key is once you get a good knowledge of assembler, you stop using assembler as a general purpose tool and only use it were it would benefit.

        Back in the day ham radio exams in parts of the world required building a functioning radio from supplied parts. You had to know how a radio worked, in the abstract.

        That doesn't mean that once you have that knowledge you forever build your own radios from unassembled kit.

      • Being proficient in different tools (e.g assembly, c++, python), doesn't give you more or less understanding, it just helps you understand different things. Being able to write good python code means you are probably good at abstracting solutions to problems, which is a very useful skill.
        • abstracting solutions to problems

          I work on real time control. The basic for of every piece of software follows the same pattern for the last 60 years.
          1 read (measure temperature, water level, etc)
          2 evaluate (f(13cm of water, at 90c) = valve opening angle = 17.7 degrees - through some set of complicated functions and lookup tables)
          3 output (writing 0x418d999a to location 0xFFBEAD408)
          4 wait for timer
          5 go to 1
          The solution has been abstracted out for about 50 years now. The hard part is knowing not to optimize out &0x418d999a = 0x

          • I don't think anyone is saying that you should have N levels of abstraction in software designed to control a single servo from an embedded computer. There is a time and a place to be abstract, and a time and place to be explicit.

            That said, there are benefits to software abstraction even in some low level code. Abstraction allows you to reuse logic that would otherwise be duplicated. All that duplicated logic needs to be tested and maintained.

            Rather than hard coding all this stuff you could do something

    • I really don't mourn APL's passing.

      Harumph! If that's the way you feel, so be it. But please turn in your type-ball to the TA.

  • by DarkOx ( 621550 ) on Monday January 04, 2016 @02:31PM (#51236261) Journal

    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.

    Paid for by the society of project managers and business software analysts.

  • Specialization (Score:4, Insightful)

    by Tony Isaac ( 1301187 ) on Monday January 04, 2016 @02:39PM (#51236343) Homepage

    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

    This is the wrong conclusion. Most of the time, we should give preference to tools and practices that have already become best practices, without necessarily questioning each one every time. Of course, there is room for challenging best practices and libraries, but that's for people who are interested more in the best practices and libraries, than for the people trying to use them to create something useful to end users.

    You don't need to know how to repair a car to drive one. The guy who repairs your car doesn't need to know how to build a motor or a transmission, only how to install them. The guy who assembles the motor doesn't need to know the finer points of metallurgy. The guy who refines the metals doesn't need to know the finer points of mining. Each of these stages of production can have their own issues that need to be resolved, but the guy driving the car needs to worry only about staying safe on the road and reaching his destination.

    Programming should be the same way. I shouldn't have to debug the IP stack to make my program connect to the Internet, nor should I have to reinvent build systems to produce a product.

    Specialize!

    • I agree with your general sentiment, but I would say that some amount of knowledge of levels just above and just below your own level is helpful or often necessary to do a job at a particular level.

      Using my own example of a computer system:

      • App developers generally need to know something about how the app framework or OS works.
      • Framework developers generally need to know how apps interact with their framework/services, and how to interact with the OS.
      • OS developers have to be very aware of the API and AB
    • by Ichijo ( 607641 )

      You don't need to know how to repair a car to drive one.

      Of the two, would you prefer to have a mechanic or a non-mechanic drive you to the other side of the country?

      • Clearly, you and I drive different kinds of cars. I never would even think to ask a potential travel companion of they knew how to fix a car! I would focus instead on ensuring that the car is in good running condition before the trip, and ride with the people I'm most interested in riding with.

        The analogy holds. If you choose good quality software components, you don't need to have someone on-site who understands their inner workings, just the interface.

        • by Ichijo ( 607641 )

          If you choose good quality software components, you don't need to have someone on-site who understands their inner workings, just the interface.

          If there are no leaky abstractions [c2.com].

    • I've noted that businesses that have historically shown high growth and apparent long term stability seem to be looking for "T-shaped" employees. These are employees who know a little about a lot (a wide horizontal) and a lot about a little (a narrow vertical). Specialization is good, but you have to know enough to be able to respecialize in anything else quickly, which means dabbling in a bit of everything so that it's at least familiar.

      Basically, a jack of all trades AND a master of one.

      To use your anal

      • I've noted that businesses that have historically shown high growth and apparent long term stability seem to be looking for "T-shaped" employees. These are employees who know a little about a lot (a wide horizontal) and a lot about a little (a narrow vertical). Specialization is good, but you have to know enough to be able to respecialize in anything else quickly

        Well said.

  • This is a consideration for students and other people involved in learning a new language or skill set. In that case, yes, it makes sense to make the student work somewhat harder (within reason) to figure it out

    On the other hand, in a business context, you're not trying to develop understanding; you're trying to accomplish a specific task as quickly, easily and cheaply as possible. In that case, intuitive presentation of the problem is desirable and fostering development of deep understanding may be neither

  • by Etcetera ( 14711 ) on Monday January 04, 2016 @02:58PM (#51236495) Homepage

    A better title might be "Why Hipster Coders Shouldn't Think Super-High-Level JS-Framework-of-the-Month Calls Mean You're a Good Programmer"

    It's hard not to extend this to a #kidstoday rant, and I'm by no means arguing to go back to assembly, but at some point forcing large amounts of programming to the lowered-barrier of entry just reduces the percentage of folks who actually know what they're doing and can critically analyze the situation.

    • Re:Odd title (Score:5, Informative)

      by gstoddart ( 321705 ) on Monday January 04, 2016 @03:15PM (#51236619) Homepage

      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:Odd title (Score:4, Interesting)

        by Ed Tice ( 3732157 ) on Monday January 04, 2016 @04:55PM (#51237325)
        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.
      • 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've sometimes been accused of doing something similar. Good abstractions allow one to be productive by not having to micro

    • My problem is with the strongly opinionated frameworks. You know, the ones where you use framework 'X' and now you have a 'X'-website or 'X' application? Where the framework's author makes the majority of architectural and project organization decisions. Sure, they make 80% of the common usage patterns easy, but that almost always results in making 10% of what's left hard and the remaining 10% near-if-not impossible.

      In a world where the programmer makes the rules, this is fine - they can find some awkwar

    • I think what the author meant to say is that novices who get access to a battery powered, laser-aimed, gyro-stabilised screwdriver will frequently spend hours thinking about how to hammer nails with it.
  • Gluing things together is how programming works. You start by gluing the small bits together to make bigger bits and so on and so on. Eventually you come to realize that when you need to use "Super Glue" to hold the bits together it's probably broken. Usually you glue bits together at discrete places, if you have to work on bits that have had the glue brushed on in large amounts, that's call accretion, avoid those bits, maybe put a layer of wax around them with tiny spots for glue.
  • >> we should be careful to not enable the belief that programming should be as easy as gluing things together

    I just helped my daughter do the princess-themed exercises on code.org. Code.org is ALL about "gluing things together" and issuing a "computer science" certificate at the end. Is this post Facebook's dig against code.org or this just one random guy?

  • I think the main problem is that by "intuitive", a lot of people mean "sloppily glossing over distinctions as if they don't matter". Sometimes people try to simplify problems by treating new or difficult ideas or operations as if they're like other more common things, but this leads to problems insofar as those things actually differ. Intuition is hugely important and valuable in problem solving, but your intuition doesn't tell you the truth if you've trained it by thinking of things as being something ot

  • ... you don't become good at doing it.

    Wow, news at 11, guys.

  • There are a couple outcomes of this that I don't think they quite understand correctly:

    1) I'm not sure whether we're really using a different part of our brain here but just having to dig deeper into the problem. The more time you have to spend figuring out how the code works to then find how it is not working the more you will understand that code. That's not a leap of imagination there it's straight cause and effect. As it is this inherently works its way into a new developer's role in a new company. Your

  • I've heard it argued that perl programmer's tend to understand object-oriented programming better than programmer's from other languages, because they have to think about it harder... there are a lot of different ways of doing perl objects with different pluses and minuses, and you have to decide what aspects of OOP you really care about.
  • by EmperorOfCanada ( 1332175 ) on Monday January 04, 2016 @05:15PM (#51237451)
    If something is made hard enough then only the most capable will survive the selection process. Can you imagine the quality of programmer that would exist if we only did everything in ASM? While the understanding that ASM programming might induce would be beneficial the reality is that maybe only 1 programmer in 20 would continue the process. Also productivity would be shot in the face.

    For instance I really hate APIs where you have to have this huge pile of boilerplate with all kinds of factory classes pooping out this and that that you assemble into something that every other person using the API will do. Maybe it gives you a better peek into the internals but I would rather some kind of Init or Create function that gives me the end product that I and every other programmer wants. All that boilerplate might make my code look intimidating and keep the weak minded away but it didn't make me a better programmer by any amount to be worth the wasted time.
  • 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.

    Right, be tough on them, makes them perform better. Except, maybe just in a statistical significant manner. And maybe a lot less people solved it if you made it deliberately hard. And maybe they understood it better because they spent more time on it.

  • If you need a port, hire me to write it for your different CPU because it's already in my head as I had to have a deep understanding of the problem before I could write a solution in assembler.

  • I do find that easy interpreted languages that mostly do right thing tend to make you lazy in understanding.
    Try for example the following two in python

    a=[1,2]; b=a; b=b+b; print a,b
    vs
    a=[1,2]; b=a; b+=b; print a,b

    Results are actually different, even if they should "intuitively" be the same. I found that after spending 3 years of hard coding in C++ made me appreciate what exactly is going on under the hood much better, even for python.

The beer-cooled computer does not harm the ozone layer. -- John M. Ford, a.k.a. Dr. Mike

Working...