Lecture 6: Socially Responsible Programming

Today

• When to ask questions? Listening. Reading. Appreciating the work of peers.

• JSON vs IDE’s silly restrictions on .json files; files vs standard I/O

• What’s the last step of the design recipe? Test. As the book says, this applies in “real life” too. So when it says “deliver on the Linux platform,” do ssh into some VM or login-student and validate our steps:

  • run make, if you have a Makefile;

  • run ./x-foo-bar, once it’s created; if it fails, check the x bit of the file and others;

  • running it also ensures that all other files have been committed and pushed; and

  • it ensures you got all dependencies.

Lecture

Young people love to talk up social responsibility. But it’s always in general terms, often combined with arguments for debunked ideas (because they don’t know history).

Truly socially responsible people start with their“neighbors.” What it means is that you care about people that are directly affected by your (in)actions. Don’t talk about some indirect effect down the line. It doesn’t matter whether you know this “neighbor” or whether he’s a friend or not. If an (in)action affects this person in your context, think twice about what you (don’t) do.

So, how do we all start acting in a socially responsible manner?

You might be surprised but it starts with you. You need to act in an egoless manner; you need to become reflective; and you need to set up partnerships to practice “socially responsible” development.

Egoless Programming

Creators put their egos into the artifacts they come up with. Negative feedback of the artifact is therefore often confused with criticism of the creator’s ego. By nature, many of us reject negative feedback and react in a negative way to it. Most criticism, however, contains a kernel of truth (and sometimes more) and we should look for it and act on it.

So, egoless programming is about extracting positive gains from negative feedback:

• accept negative feedback;

• embrace as it as the best and only way to improve your artifact; and

• solicit negative feedback, because if you don’t get it, people are in all likelihood holding back.

Additionally, you need to learn to differentiate actionable pieces of feedback from non-actionable and both of them from false negative feedback.

The Rare Worker Who Thrives on Negative Feedback

Reflective Programming

As little kids, you’re taught “stop, drop, and roll” for fire drills.

In this course, we provide three different contexts on how to practice egoless reactions to feedback and providing feedback in such a context: pair programming, peer presentations, and panel reviews.

Homework D: Show and Tell

1. Explain the homework problem.

   Many programs involve geometric, topological, and graphical concepts. Visualizing these concepts helps with many different software development tasks: testing, debugging, understanding, documenting, and graphical user interfaces. Indeed, this statement holds even if the overall software system does not involve any graphical user interface.

   The purpose of this GUI exploration is to explore the basic rendering capabilities of your chosen language. Graphs—as in collections of nodes and edges—are a typical example, and so the homework requests that you visualize graphs. The word “visualize” implies that there is a non-visual representation, and yes there is: a JSON object.

   Like xhead and xjson, it consumes its input from STDIN. Concretely, it expects one JSON object, which specifies a set of nodes and the size of a square canvas. The assumption is that all nodes are connected with all nodes. Given such a JSON object, xgui displays a rendering of this graph in a separate window. The window remains open until a user shuts it down.

   So here is how xgui works:

   $ cat graph1.json

   {

   "nodes": [[20,30],[100,20],[70,40]],

   "size": 100

   }

   $ ./xgui < graph1.json

   The given JSON specifies a triangle with three nodes—and the displayed window shows it.

2. Explain Racket solution.