Lecture 6: Socially Responsible Programming



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:

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.

As adults, you must practice:
  • stop, as in, stop what you’re doing;

  • drop, yes, drop everything and get to a peaceful place; so that you can

    (Many people have a hard time with dropping everything, especially their continuous connectivity to e-friends on 1-1 connections or social media. My conjecture is that they confuse inactivity with being alone and thus loneliness.)

  • think.

    Your thinking must address two primary “ultimate” questions:

    • Do I react properly to negative feedback?

    • Do I provide proper negative feedback?

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.