Tag: programming

Nostalgia, friction, and read/write literacy 

I probably need to revisit this (and the references) but I really enjoyed reading Silvio Lorusso’s essay on computer agency and behaviour.

Alan Kay’s pioneering work on interfaces was guided by the idea that the computer should be a medium rather than a vehicle, its function not pre-established (like that of the car or the television) but reformulable by the user (like in the case of paper and clay). For Kay, the computer had to be a general-purpose device. He also elaborated a notion of computer literacy which would include the ability to read the content of a medium (the tools and materials generated by others) but also the ability to write in a medium. Writing on the computer medium would not only include the production of materials, but also of tools. That is for Kay authentic computer literacy: “In print writing, the tools you generate are rhetorical; they demonstrate and convince. In computer writing, the tools you generate are processes; they simulate and decide.”

Source: The User Condition, Silvio Lorusso

Why NASA is better than Facebook at writing software

Facebook’s motto, until recently, was “move fast and break things”. This chimed with a wider Silicon Valley brogrammer mentality of “f*ck it, ship it”.

NASA’s approach, as this (long-ish) Fast Company article explains, couldn’t be more different to the Silicon Valley narrative. The author, Charles Fishman, explains that the group who write the software for space shuttles are exceptional at what they do. And they don’t even start writing code until they’ve got a complete plan in place.

This software is the work of 260 women and men based in an anonymous office building across the street from the Johnson Space Center in Clear Lake, Texas, southeast of Houston. They work for the “on-board shuttle group,” a branch of Lockheed Martin Corps space mission systems division, and their prowess is world renowned: the shuttle software group is one of just four outfits in the world to win the coveted Level 5 ranking of the federal governments Software Engineering Institute (SEI) a measure of the sophistication and reliability of the way they do their work. In fact, the SEI based it standards in part from watching the on-board shuttle group do its work.

There’s an obvious impact, both in terms of financial and human cost, if something goes wrong with a shuttle. Imagine if we had these kinds of standards for the impact of social networks on the psychological health of citizens and democratic health of nations!

NASA knows how good the software has to be. Before every flight, Ted Keller, the senior technical manager of the on-board shuttle group, flies to Florida where he signs a document certifying that the software will not endanger the shuttle. If Keller can’t go, a formal line of succession dictates who can sign in his place.

Bill Pate, who’s worked on the space flight software over the last 22 years, [/url]says the group understands the stakes: “If the software isn’t perfect, some of the people we go to meetings with might die.

Software powers everything. It’s in your watch, your television, and your car. Yet the quality of most software is pretty poor.

“It’s like pre-Sumerian civilization,” says Brad Cox, who wrote the software for Steve Jobs NeXT computer and is a professor at George Mason University. “The way we build software is in the hunter-gatherer stage.”

John Munson, a software engineer and professor of computer science at the University of Idaho, is not quite so generous. “Cave art,” he says. “It’s primitive. We supposedly teach computer science. There’s no science here at all.”

The NASA team can sum-up their process in four propositions:

  1. The product is only as good as the plan for the product.
  2. The best teamwork is a healthy rivalry.
  3. The database is the software base.
  4. Don’t just fix the mistakes — fix whatever permitted the mistake in the first place.

They don’t pull all-nighters. They don’t switch to the latest JavaScript library because it’s all over Hacker News. Everything is documented, and genealogy of the whole code is available to everyone working on it.

The most important things the shuttle group does — carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code — are not expensive. The process isn’t even rocket science. Its standard practice in almost every engineering discipline except software engineering.

I’m going to be bearing this in mind as we build MoodleNet. We’ll have to be a bit more agile than NASA, of course. But planning and process is important stuff.

 

Source: Fast Company

Teaching kids about computers and coding

Not only is Hacker News a great place to find the latest news about tech-related stuff, it’s also got some interesting ‘Ask HN’ threads sourcing recommendations from the community.

This particular one starts with a user posing the question:

Ask HN: How do you teach you kids about computers and coding?

Please share what tools & approaches you use – it may Scratch, Python, any kids specific like Linux distros, Raspberry Pi or recent products like Lego Boost… Or your experiences with them.. thanks.

Like sites such as Reddit and Stack Overflow, responses are voted up based on their usefulness. The most-upvoted response was this one:

My daughter is almost 5 and she picked up Scratch Jr in ten minutes. I am writing my suggestions mostly from the context of a younger child.

I approached it this way, I bought a book on Scratch Jr so I could get up to speed on it. I walked her through a few of the basics, and then I just let her take over after that.

One other programming related activity we have done is the Learning Resources Code & Go Robot Mouse Activity. She has a lot of fun with this as you have a small mouse you program with simple directions to navigate a maze to find the cheese. It uses a set of cards to help then grasp the steps needed. I switch to not using the cards after a while. We now just step the mouse through the maze manually adding steps as we go.

One other activity to consider is the robot turtles board game. This teaches some basic logic concepts needed in programming.

For an older child, I did help my nephew to learn programming in Python when he was a freshman in high school. I took the approach of having him type in games from the free Python book. I have always though this was a good approach for older kids to get the familiar with the syntax.

Something else I would consider would be a robot that can be programmer with Scratch. While I have not done this yet, I think for kid seeing the physical results of programming via a robot is a powerful way to capture interest.

But I think my favourite response is this one:

What age range are we talking about? For most kids aged 6-12 writing code is too abstract to start with. For my kids, I started making really simple projects with a Makey Makey. After that, I taught them the basics with Scratch, since there are tons of fun tutorials for kids. Right now, I’m building a Raspberry Pi-powered robot with my 10yo (basically it’s a poor man’s Lego Mindstorm).

The key is fun. The focus is much more on ‘building something together’ than ‘I’ll learn you how to code’. I’m pretty sure that if I were to press them into learning how to code it will only put them off. Sometimes we go for weeks without building on the robot, and all of the sudden she will ask me to work on it with her again.

My son is sailing through his Computer Science classes at school because of some webmaking and ‘coding’ stuff we did when he was younger. He’s seldom interested, however, if I want to break out the Raspberry Pi and have a play.

At the end of the day, it’s meeting them where they’re at. If they show an interest, run with it!

Source: Hacker News