Diversity, Inclusion, and Money.

Does hiring women or people of color affect a tech company’s bottom line?

According to some data, yes.

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:

  1. 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.
  2. 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.

Continue reading “Diversity, Inclusion, and Money.”

Diagramming Data, Part 2: Reversible and Irreversible Data Issues

In Part 1 of Diagramming Data, I talked about the relationship between code simplicity and the underlying data. I touched on some of the issues that organizations face with their data. Now, we’ll categorize those issues according to how easily they can be fixed.

We can take a sampling of data-related issues and place them on a continuum from easily reversible to irreversible. Some data issues can be fixed with relative ease. Others cannot be fixed without re-collecting all the data. There are also cases in the middle where we can fix issues with the data by writing complex code.

Continue reading “Diagramming Data, Part 2: Reversible and Irreversible Data Issues”

Bias doesn’t start with skin color.

Look around your office.

If you’re in tech, I suspect I can predict what you see: lots of white faces.

We’ve known tech to be a sea of white faces for a long time. Big companies respond by sponsoring code education programs and hiring (usually white) Directors of Diversity. But the numbers aren’t changing: tech remains 95-98% white, just like it was before the Directors of Diversity got hired.

Continue reading “Bias doesn’t start with skin color.”

Android How-To: Card Flip Animation in API 23

Hello!

Lots of android devs are using this tutorial from the Google documentation to try to achieve a card flip animation, and they’re getting errors, including this one:

 05-22 11:32:34.706: E/AndroidRuntime(6801): java.lang.RuntimeException: Unknown animation name: objectAnimator

There does not appear to be a definitive answer that I can find as to how to get this to work. I got it. This is the relevant portion of my build file:

You’ll notice that I mention this library in the build. I downloaded it, rather than access it on bintray, to hedge against changes in its availability, and put it in the build/libs directory of my app.

When I go to flip in/out the child fragments, my parent fragment has this click listener on my flip button:

If you’re been banging your head against this (like I did at first), please pay it forward and share this with another Android dev who might like to know.

Test-Driven Android: Testing Multiple Cursor Loaders for One Activity/Fragment

I’ve found some favorite resources on writing Android apps. One of my favorites is Virgil Dobjanschi’s Google I/O Talk on Android apps as REST clients. This talk is relevant to every business-related app I’ve ever built, because most apps, on a general level, solve a lot of the same problems. Fetching data from an API and displaying it on the app is one of those problems. How many apps that I’ve built have demanded this functionality? All of them.

Virgil describes a couple of different levels of advancement for fetching and displaying data in an Android app. Lately, I have favored the most advanced one: making a call with a service, sticking the results in a database, and accessing them with a content provider and cursor loader to display on the UI.

Lots of tutorials will help you implement this pattern…on the simplest level. But what happens when, say, you have multiple tables, and you want to register updates for all of them on the same UI? If your LoaderCallbacks implementer is pulling from multiple databases, then your onLoadFinished() method has to distinguish between different CursorLoaders for each of your databases. And if the generic type for any of the CursorLoaders is the same, then you need to distinguish between them from within one onLoadFinished() method—because you can’t implement that method twice with the same signature.

Everyone on StackOverflow describes one of two solutions.

1) Implement two separate onLoadFinished methods and change one of the Loader’s generic types to not-a-cursor for the express purpose of loading them both in one activity/fragment. This works by adding a layer of indirection that can make the code confusing for developers who are unfamiliar with the pattern.

2) rely on the loader ID, which makes total sense, and works for the implementation code. The problem comes, as it frequently does with mobile development, when you try to unit test this approach. When we call onCreateLoader() from a test, the loader id does not get set. 

Seriously, take this code:

Print the loader.getId() for the loader that gets returned when you call onCreateLoader() in your tests. It will be zero in both cases, despite the fact that we expect the ids to be 1 and 2.

So what to do? I spelunked through the CursorLoader code a little and found a method that sets the id on the CursorLoader: registerListener(int id, OnLoadCompleteListener<Cursor> listener).

So when we add this call to our onCreateLoader() method, we get this:

and that sets the loader id!

So now you can have a clean switch case in your onLoadFinished() method:

If you have been banging your head against this (as I did at first), please pay it forward and share this post with another Android dev who might like to know.