Loading ...
Sorry, an error occurred while loading the content.


Expand Messages
  • Sean Gilbertson
    In the past year or so, I have become more a believer in back-to-basics, more considered, integrated and focused education in the Computer Science curriculum.
    Message 1 of 207 , Nov 24, 2004
      In the past year or so, I have become more a believer in back-to-basics, more considered, integrated and focused education in the Computer Science curriculum. Specifically, I believe that care and consideration should be strongly emphasized, and we should teach from "electricity-up." In my experience, Computer Science is presented more as a trade, perhaps to be studied, but not necessarily as a serious science or engineering pursuit. High-level concepts and languages are introduced before students even know how it all works; history and invention/innovation is not taught, and if it is, it's wedged into programming courses; and discipline (and the ownership of responsibility and knowledge that makes it real) is not developed. The result is a graduating class of students who for example, unless they supplemented their education for their own benefit, are afraid and disdainful of assembly language, and generally have no idea how a computer works.

      Courses are very segregated. Assembly is separate from architecture; design is separate from testing; language courses are separated from everything else. I believe that students should understand how a computer works, what their code does, and that what they produce is incredibly powerful, and not a toy. Additionally, I believe that design processes should not necessarily be taught to undergraduate students. Instead, I believe that students should be mentored and tracked as they create software, and shown where they have made poor choices, and why. The principles used to teach a student thusly would be based on common sense and critical thinking, and would be simple. For example, they may include beliefs about code duplication, and established named principles, like the LSP. From wisdom and knowledge, and self-reliance, the students will be able to make good decisions about code and design.

      I looked to the curriculum for a B.S. in Architecture at the U of MN as a baseline for comparison:
      Preparation for the Major (33 cr)

      Required General Education Courses (13 cr)
      EngC 1011—University Writing and Critical Reading (4 cr)
      Math 1142—Short Calculus (4 cr)
      or Math 1271—Calculus I (4 cr)
      Phys 1101—Fundamental Physics I (4 cr)
      or Phys 1201—General Physics I (5 cr)
      Architecture Courses (18 cr)
      Representation (6 cr)
      Arch 1301—Introduction to Drawing in Architecture and Landscape Architecture (3
      Arch 3301—Drawing for Design in Architecture (3 cr)
      History and Theory (12 cr)
      Arch 1401—The Designed Environment (3 cr)
      Arch 3401W—Environmental Design and the Sociocultural Context (3 cr)
      Arch 3411—Architectural History to 1750 (3 cr)
      Arch 3412—Architectural History since 1750 (3 cr)
      Technology (3 cr)
      LA 3501—Environmental Design and Its Biological and Physical Context (3 cr)

      Architecture Major Requirements (53 cr)

      Design (22 cr)
      Arch 5281—Undergraduate Architecture Studio I (6 cr)
      Arch 5282—Undergraduate Architecture Studio II (6 cr)
      Arch 5283—Undergraduate Architecture Studio III (6 cr)
      Arch 5284—Undergraduate Architecture Studio IV (4 cr)
      History (3 cr)
      Arch 54xx—History (3 cr)
      Technology (10 cr)
      Arch 5501—Environmental and Material Forces in Architecture (4 cr)
      Arch 4511—Building Systems (3 cr)
      Arch 4571—Architectural Structures (3 cr)

      Additional upper division courses
      Select 9 to 12 credits of 3xxx-5xxx architecture electives
      Select 9 credits of 3xxx-5xxx electives outside the major
      reference: http://www.cala.umn.edu/student_services/BSdegreereq.html

      The science of architecture probably isn't perfectly harmonious with computer science, but I think it may be pretty close. It may be especially close to embedded software, but perhaps you know better than I. Anyway, you can see that the basics are covered first, and then four studio courses are required. I know in C.S. we had senior projects, but at least at my University they were illegitimate. They didn't emphasize or require any approach at all; they just wanted you to turn in something that compiled and seemed to work. I think that is a poor method of teaching, and learning.

      "Okay class, by the end of the semester, I want you to build a house with four rooms. Ready, go!"

      "Wait wait wait, can we back up four years? I missed something."

      Sean Gilbertson
      IT Systems/Software Developer
    • Dale Emery
      Hi Alistair, A few months ago you referred to Virginia Satir s phrase, People ... My initial reaction, reading this two months ago, was that it doesn t
      Message 207 of 207 , Jan 15, 2005
        Hi Alistair,

        A few months ago you referred to Virginia Satir's phrase, "People
        prefer familiarity to comfort." You wrote:

        > I don't know about you, but that phrase, besides ringing true,
        > frightens the bejeebers out of me. I think that's the biggest
        > thing we're up against.

        My initial reaction, reading this two months ago, was that it
        doesn't frighten me at all. Given that I'm always advocating one
        change or another, I wasn't sure why it didn't frighten me. So
        I've been pondering.

        I think it doesn't frighten me because my persuasion style
        (developed over many years and still evolving) includes to make
        change familiar to people. I never thought about the things I do
        in those terms until I read your message, but as I look at how I
        nudge people toward change, some of it is about making the
        unfamiliar familiar.

        Here's an example of one of my nudges:

        I wasn't advocating any particular change in that situation, but
        my questions had the effect, I think, of framing Susan's problem
        so that it was suddenly very familiar to her, and then she knew
        exactly how to solve it.

        Another example:

        As I look at that story now, I think that Paul's epiphany at the
        end was largely about suddenly reframing his customer relations
        issue in a familiar light. And he knew what to do.

        Another example: What finally convinced me to try TDD and simple
        design myself was watching Alan Shalloway demonstrate how the
        rules of simple design can (sometimes) generate well-known design
        patterns. I had a little familiarity with design patterns, so
        Alan's brilliant demonstration had the effect of making something
        strange (designs can /emerge/?!) into something familiar.

        Another example of something I do often: find safe ways for
        people to try whatever I'm advocating. A small demonstration,
        maybe, or a "toy" situation to practice on, where failure doesn't
        matter. Making it safe for people to try the new idea in a small
        way nudges them to get a teeny tiny bit of experience, from which
        the new idea becomes a teeny tiny bit more familiar. Stories
        (like the ones I linked to above) can make new ideas more familiar.

        You're a pretty effective change artist, so I'll bet that a lot
        of what you do is also about helping people to find something
        familiar in something new. How have you persuaded people
        effectively in the past? Did any of that have anything to do
        with making change more familiar?

        So this idea is now in the back of my mind: If we attend
        purposefully to the idea that familiarity matters, what new ideas
        might that give us for how to encourage change?



        Dale Emery, Consultant
        Inspiring Leadership for Software People
        Web: http://www.dhemery.com
        Weblog: http://www.dhemery.com/cwd

        One half the troubles of this life can be traced to saying "yes"
        too quick, and not saying "no" soon enough. --Josh Billings
      Your message has been successfully submitted and would be delivered to recipients shortly.