Now we’ll talk about some starting points for building healthy datasets—and nursing deficient datasets to health as much as possible. It’s important to note that these starting points apply chiefly to datasets obtained via human data entry—generally via a form.
Does hiring women or people of color affect a tech company’s bottom line?
But so what?
Numbers like these are uplifting, but they don’t convince companies to change.
So why not?
Let’s talk about two reasons:
- We don’t definitively know why diverse leadership improves a company’s financial performance. So we can’t draw a causal link that captures leadership’s attention.
- Metrics for overall company financial performance don’t motivate lower level managers and directors. Those lower-level positions, more than the C-Suite, influence the office practices that affect company diversity numbers. But those positions don’t get individual rewards when the whole company does well.
Let’s talk about both of these.
Then we’ll talk about a more focused metric that you can use to argue for, and measure the effectiveness of, inclusion-related efforts at your company.
Bonus: our new metric will help office leadership focus on retention of women and people of color, rather than only lamenting the pipeline problem.
Today at lunch at Pivotal Labs, our designer Andy Detskas talked with us about some of the things he has learned about material design for Android Marshmallow.
If you’d like to see more details on the presentation than the rundown provided here, or if you’d like to follow some links to useful resources on designing for Android, you can see the slides right here.
For the past four months, I have worked on a project in which I needed to pair program remotely with developers in other states, other countries, and other time zones.
Remote pairing feels different from pairing with someone in person: you lose the benefits of colocation for asking each other questions and reading each others’ moods and body language. That said, I have learned some practices that work better than others for pairing remotely, and I’d like to share them so that you can make your remote pairing experiences go as smoothly as possible.
I have noticed a troubling tendency for programmers to put one another down. I’ve noticed it at work, and at conferences, and on the internet.
What does it take to create an excellent user experience?
A designer’s work revolves around this question, and the answer differs from project to project.
I want to share my recent experience with answering this question for a particular project.
I work as a software consultant at a company that does almost 100% pair programming. I have also performed improv comedy, in classes and onstage. I’ve realized that the skills needed to improvise with other people can also help us pair program better with pairs of all kinds.
Here in Chicago, Second City is famous for its comedy theater and its school of improvisation. However, the business also consults for Fortune 500 companies on developing better teamwork. Two of its executives, Kelly Leonard and Tom Yorton, have published a book on the subject: Yes, And: How Improvisation Reverses “No, But” Thinking and Improves Creativity and Collaboration–Lessons from The Second City. The book discusses the business value of improvisational skills, and it also prescribes exercises to develop those skills.
From this book I’ve identified some relevant improv tenets for pair programming and some improv exercises that might make us better at pairing.
Steve Krug’s book Don’t Make Me Think, Revisited: A Common Sense Approach to Web (and Mobile) Usability takes an 80-20 approach to user experience design.
Though it does not serve as a textbook for UX design, I would recommend it to any developer who wanted to improve the usability of their products with relatively little effort.
In it, Krug goes over how to organize the material on a web page, how to display links to be most helpful to the user, and how to adjust one’s approach to usability for a mobile device. These are all fantastic things for programmers to understand. Many of the concepts seem obvious (and the author warns readers about this right from the get-go), but the book helps to clarify why we do those things the way we do them.
I want to emphasize three astute points from the book that I suspect could be easily missed. These points merit reiteration for a crowd of programmers: