Dismissive Language

Dismissive language harks back to my post about microaggressions. It’s very easy to accidentally say something dismissive without realizing it. The most common examples of dismissive language I encounter are in descriptions of complex topics, often with the words “just” and “should”. For example, “All you need to do is just git rebase and everything should be fine” or “Just change this setting in your config and it should just work”. These constructions trivialize the listener’s problem and imply that they are stupid for not being able to figure it out on their own. (I’ve given technical examples here, but I imagine that this can happen in any context with complexity, like knitting or wet labs.)

I think it’s a good practice to try to completely remove the word “just” from your vocabulary, and watch your usage of the word “should” as well. At a fundamental level this is about putting yourself in someone else’s shoes, thinking about whether what you’re saying is appropriate given their level of experience, and making sure you’re not going to make them feel dumb by making something that’s actually hard/complex sound like you expect it to be obvious.

This is something we worry about a lot in Software Carpentry because we’re teaching complex computing topics to novice programmers. In fact, we recommend instructors completely avoid the word “just”. We discuss this a little in our instructor training materials:

Software Carpentry’s founder recently put together a short, 2.5 minute video giving examples of many of things you should not do when explaining complex topics to novices, such as using jargon and trivializing complexity. It’s worth a cringe-inducing watch:

The Recurse Center’s social rules also provide some great examples of things not to do: https://www.recurse.com/manual#sub-sec-social-rules

Note: This is based on a series of posts I’ve been putting together at work to educate coworkers on diversity and inclusion topics.

Dismissive Language

Unconscious Bias

This post came across my Twitter feed this week that talks about some of the spurious, meaningless reasons software engineering candidates are rejected. It’s challenging to evaluate candidates and we have a lot of productive discussions about how best to do that, but there some personal characteristics that we know are irrelevant to job performance: gender, race, age, sexual orientation, marital status, parental status, accent, where you grew up, etc. But even though we know those characteristics are irrelevant, they can still unconsciously affect how we evaluate and work with people through something called unconscious bias.

Unconscious bias manifests in some scary and surprising ways. For example, elementary school teachers give girls lower scores on math tests, unless they don’t know the gender of the students.

Another study examined gender bias in academic science. From the abstract: “In a randomized double-blind study (n = 127), science faculty from research- intensive universities rated the application materials of a student—who was randomly assigned either a male or female name—for a laboratory manager position. Faculty participants rated the male applicant as significantly more competent and hireable than the (identical) female applicant. These participants also selected a higher starting salary and offered more career mentoring to the male applicant. The gender of the faculty participants did not affect responses, such that female and male faculty were equally likely to exhibit bias against the female student.”

Bias can even have far reaching, unintended affects. Early marketing of personal computers targeted almost exclusively boys and that probably had an affect on the number of women seeking computer science degrees today.

One of the ways to combat unconscious bias is to learn more about it, which you can do with these resources:

If you’re evaluating a job candidate take a minute to think about how biases might be affecting your judgement. In fact, this can be a valuable thing to do in any interactions you have.

Note: This is based on a series of posts I’ve been putting together at work to educate coworkers on diversity and inclusion topics.

Unconscious Bias

Microaggressions

Microaggressions are small, often unintentional actions that can make others feel out of place. Examples can include asking where someone is from, acting surprised when someone doesn’t know something, or always expecting women to do office-keeping work. They can make people feel like they don’t belong and distract them from doing their actual jobs. “Micro”-aggressions might not sound so bad, but over time and many interactions they create an unwelcoming environment that can cause employees to leave or cause people to not want to attend events. As an example, a friend of mine almost swore off of all tech events after she went to a social event where everyone ignored her and talked to her lawyer husband instead.

It’s everyone’s job to make sure they’re actively creating a environment in which everyone feels that they fully belong. You can help by learning more about microaggressions and doing your best to avoid committing them (they hurt even when you don’t mean them to).

Here are a couple of good links that describe what migroaggressions are and the affect they have:

This post does a great job explaining how microagressions affect your life:

The Recurse Center’s social rules are very useful for helping you avoid committing microaggressions:

Note: This is based on a series of posts I’ve been putting together at work to educate coworkers on diversity and inclusion topics.

Microaggressions

Python 3 Universally

Frustration

A Python user is starting a project and thinks to themselves, “Yay, new code! I can use Python 3 for this!”. They install the latest Anaconda for Py3 and get to work. A few days and hundreds of lines of code later they find out that a particular library they need (maybe imposm.parser) only supports Python 2. Our well intentioned user sighs, re-installs Anaconda for Py2, and carries on. Maybe next time (or maybe not). (This is a semi-autobiographical story.)

Elsewhere, a Python library maintainer is excited about Py3’s new asyncio module and could put it to immediate use but doesn’t want to alienate users who are stuck on Py2.


There are many valid reasons to be using Py2 today: a dated dependency, the inertia of existing code, not wanting to break a working setup, not knowing how/why to switch, and lack of time.

There are also many valid reasons for wanting to develop exclusively for Py3: access to new features, reduced support burden, simplified maintenance, wanting to get ahead of the 2020 end-of-support for Py2, and lack of time. These tensions have the potential to create much frustration in the Python community, but I think with some intentional effort on the part of Python developers and leaders it will all be fine.  Continue reading “Python 3 Universally”

Python 3 Universally

C Extensions for Python 2 and 3

One of my upcoming tasks at work is converting Pandana to support both Python 2 and 3. The tricky bit is that Pandana has a C extension written in plain C using the Python 2 C-API, which is not compatible with Python 3.

It seems like the best way to have a C extension that supports both Python 2 and 3 is to not write the extension in C. These days there are a number of alternatives that allow you to write interfaces in Python or something like Python (Cython). I decided to make a sample project with some C functions to wrap so that I could try out CFFI, Cython, and the standard library ctypes module.

You can find the project with examples of all three and a longer writeup at https://github.com/jiffyclub/cext23. Pull requests are welcome on the repo with further examples!

C Extensions for Python 2 and 3

About Agile Work-flows

Note: I wrote this to describe agile/scrum development to my colleagues because on our team I have the most experience with it, but I’m not really expert on agile or scrum.

Developing a product involves a number of different roles that all need to coordinate with each other. There are designers, sales people, engineers, writers, managers, and much more. All those people need a way to track what they need to do and what other people are doing. Agile work-flow is a communications system that helps teams broadcast what needs doing and what is being done.  Continue reading “About Agile Work-flows”

About Agile Work-flows

What I Do at Autodesk, Aug. 2015

I work at Autodesk with a team that includes urban planners, architects, and software engineers. Our goal is to make tools for people in regional and urban planning. The tools include a desktop geographic data viewer, statistical modeling of real estate markets, data pipelines, and much more.

I work on all of our data related projects, which are almost entirely Python. The projects involve the standard scientific Python data tools, of course, but also web libraries when we work on web-based data services. It’s also not unusual for JavaScript, HTML, and CSS to come up for user interfaces. (We even have a node.js server in the works.) On a team this small it helps to be have diverse experience and a willingness to learn new things. (Our larger group is ~12 people, but I work closely/regularly with about three, all urban planners.)

The users and collaborators on our data projects are mostly scientists, which sets a high bar for library usability, documentation, and technical communication. With only me doing the bulk of coding and operations things can often take time, but my colleagues are committed to having well tested, well documented code that will work for a long time. (And I wouldn’t have it any other way.)

Day-to-day my brain power goes to things like:

  • Asking my colleagues questions about their needs and how they do things
  • Thinking about how to make a sensible API or UI
  • Thinking about how to actually solve a problem
  • Writing tests
  • Writing documentation
  • Writing code
  • Figuring out how to work with a given data source (researching libraries and learning the data format)
  • Reviewing code and projects
  • Training colleagues in Python and software engineering practices
  • Learning new stuff to apply to a task

We’ve got a lot of interesting work coming up, including building several automated data processing pipelines and online services. As always we’ll be working together as a team of diverse expertise to create usable, useful software that has real-world applications and meaningful impact on the citizens of cities around the world.

What I Do at Autodesk, Aug. 2015