Well, we did it. I finally finished the book that I had been working on with my co-author for the last two years. I thought I’d write a short post on my experiences writing a technical book and getting it published. I know many people think about writing books, and I’d like to share my experiences so that others might learn from lessons that I learned the hard way. Overall, it was an absolutely amazing experience and I have a feeling that the adventure is only beginning….
Author: Charles Givre
I am currently attending the Splunk .conf in Orlando, and a director at Accenture asked me this question, which I thought merited a blog post. Why don’t data scientists use or like Splunk. The inner child in me was thinking, “Splunk isn’t good at data science”, but the more seasoned professional in me actually articulated a more logical and coherent answer, which I thought I’d share whilst waiting for a talk to start. Here goes:
I cannot pretend to speak for any community of “data scientists” but it is true that I know a decent number of data scientists, some very accomplished and some beginners, and not a one would claim to use Splunk as one of their preferred tools. Indeed, when the topic of available tools comes up among most of my colleagues and the word Splunk is mentioned, it elicits groans and eye rolls. So let’s look at why that is the case:
Someone recently asked me for assistance with a university project whereby they were asked to predict whether a given article was fake news or not. They had a target accuracy of 70%. Since the topic of fake news has been in the news a lot, it made me think about how I would approach this problem and whether it is even possible to use machine learning to identify fake news. At first glance, this problem might be comparable to spam detection, however the problem is actually much more complicated. In an article on The Verge, Dean Pomerleau of Carnegie Mellon University states:
“We actually started out with a more ambitious goal of creating a system that could answer the question ‘Is this fake news, yes or no?’ We quickly realized machine learning just wasn’t up to the task.”
Last Friday, the Apache Drill released Drill version 1.14 which has a few significant features (plus a few that are really cool!) that will enable you to use Drill for analyzing security data. Drill 1.14 introduced:
- A logRegex reader which enables Drill to read anything you can describe with a Regex
- An image metadata reader, which enables you to query images
- A suite a of GIS functionality
- A collection of phonetic and string distance functions which can be used for approximate string matching.
These suite of functionality really expands what is possible with Drill, and makes analysis of many different types of data possible. This brief tutorial will walk you through how to configure Apache Drill to query log files, or any file really that can be matched with a regex.
I recently completed Technically Wrong by Sara Wachter-Boettcher. Let me start by saying that I’m glad that Ms. Wachter-Boettcher wrote this book. The tech industry has a lot of issues which need to be brought out into the open and it is definitely a positive development that people such as Ms. Wachter-Boettcher are bringing these issues to the forefront. It really is only recently that people are discussing the continuous erosion of privacy, misogyny in the tech industry, lack of diversity and many other issues. Whilst I would not deny any of these issues, I felt Wachter-Boettcher’s analysis was somewhat lacking and didn’t really get at the realities of working in the tech industry. Wachter-Boettcher cites numerous examples of tech gone wrong, such as a smart scale telling a two year old that he needs to lose weight, FaceBook denying a Native American person an account because it felt that their name was not legitimate, and the abhorrent use of proprietary, black box algorithms to make parole recommendations.
Again, it is definitely a positive development that Wachter-Boettcher and others are writing about these issues, but the alternatives and solutions she proposes seem a bit simplistic. While she doesn’t state this directly, much of the book seems to suggest that all of technology’s woes are caused by the lack of diversity in the tech industry. Specifically that “white guys” from elite universities are running everything. I don’t have an electronic copy of the book, but after about half way through this, I wanted to count the number of times the phrase “white guys” appears in the book. Sometimes this phrase includes Asians, sometimes not.
In the last week, beneath all the Trump and Kim Jong Un reporting, were several stories that state that Apple has in effect declared war on data collectors. Make no mistake, what Apple is doing is making it significantly harder for companies big and small to collect your personal data. The significance of this cannot be overstated in that many companies like Google and Facebook’s revenue is based on selling targeted advertising and if gathering this data becomes significantly more difficult, it could affect their bottom lines.
The First Volley: No More Comments and Share Buttons
Last week, I was listening to the keynotes at the WWDC, and overall was pretty unimpressed as exec after exec droned on about new animojis or some other feature that I really didn’t care about, and then, Craig Federighi launched the first volley: Safari is going to block FaceBook and other social media like and share buttons as well as shared comment sections. Facebook, Twitter and other sites use these buttons to track your activity when you are visiting other sites. While it isn’t that big of a deal that this is happening on MacOS, it is VERY significant that Apple is instituting this change on iOS as well. When I heard this, I was pretty shocked, but that was only the first volley, there were more to come.
I’ve been waiting for some time to publish this, but I wanted to write about my experiences interviewing for data science jobs. Here’s my story, I worked at Booz Allen for nearly seven years but I felt it was time for a change. I very much like Booz Allen as a company and if anyone is interested in working there, please don’t hesitate to contact me. But I felt I was ready for different challenges and started looking for work elsewhere.
Now that I started a new position, I thought I’d share some observations about what I learned from interviewing at numerous companies. I wasn’t tracking how many companies I interviewed with, but it was a lot. I have a lot of government experience and got a number of offers from government contracting firms. However, I came to the conclusion that in terms of career progression, joining another government contracting firm was not what I was looking for.
So here’s what I learned…
As more and more research is showing that the open office design actually reduces productivity (here) and (here), I recently shared a post on LinkedIn about how github “de-broed” their workspace, but I thought I’d share my thoughts on what I like, and don’t like in a work space. Above is a picture of my home office with some labels. Not specifically labeled is that there is plenty of natural light. One of the most depressing places I ever worked was a windowless cube farm where the developers liked to leave the lights off. I was going out of my mind!!
- A Door: My ideal workspace has a door so that when privacy is needed, I can close the door and when it is not, I can open it.
- A clock: I know computers have clocks, but having a big visible clock is really helpful for making sure things run on time.
- A comfortable chair, with foot rest: If I’m doing tech work for a long time, I don’t want to be sitting on something that will cause trips to the chiropractor.
- Big Monitors: I’m a big fan of multiple, large monitors, as they really increase productivity.
- Music: I like to listen to music, especially when coding. When I’m working in more public spaces, I have headphones…
- Stress Relief: I play trombone and when things get stressful, one can always reduce some stress by playing some Die Walkure …. LOUDLY.
- Lots of Geek Books: Nothing sets the stage for coding than being surrounded by O’Reilly geek books.
- Family Photos or other Personal Items: I do my best work in a space that feels like my own, so I think it is important that people can have a space with some of their personal items that feels like their own. Hence… I’m not a fan of hoteling or workspaces that set people up to work on large tables.
What do you like in a work space?
I recently read Automating Inequality by Virginia Eubanks and would like to share some thoughts. This review is the first of several book reviews I’ve been working on about books relating to the problems which are emerging from technology. I’ll keep this brief…
I am glad that the conversation about social problems caused by technology is expanding. Books like Automating Inequality are good contributors to that discussion. In this book, Eubanks highlights a few situations where technology has negatively affected people’s lives, primarily poor people. This technology also serves to limit poor people’s lives and opportunities, creating what she refers to as a digital poorhouse.
The use of machine learning can be a powerful tool for developing predictive analytics to One abuse which I found particularly troubling was cited on pg. 137 which is a risk model which calculates a risk score for unborn children.
Vaithinathan’s team developed a predictive model using 132 variables–including length of time on public benefits, past involvement with the child welfare system, mother’s age, whether or not the child was born to a single parent, mental health, and correctional history–to rate the maltreatment risk of children in MSD’s historical data. They found that their algorithm could predict with “fair, approaching good” accuracy whether these children woudl have a “substantiated finding of maltreatment” by the time they turn five.
What I Found Lacking:
What I found lacking in Automating Inequality was the lack of alternative proposals. It is easy to criticize a technical solution, but these systems are often deployed against complex problems and finding a solution often requires a lot of vigilance, persistence and iteration. Eubanks discusses the issue of welfare abuse, and seems to downplay the fact that welfare fraud is in fact a major issue in this country. With some basic research on Google you can unfortunately find countless cases of individuals convicted of welfare fraud. Clearly, welfare programs should make efforts to reduce fraud and make sure that their resources are going to people who truly need the assistance.
What Eubanks seemed to miss was what went wrong in the implementations that she highlighted. In two cases, Eubanks highlighted several systems designed to improve the efficiency and efficacy of welfare programs. From the book, it sounded as if the designers of these programs implemented various technical systems to automate the intake process for benefits. What didn’t happen, and what Eubanks didn’t discuss in the book, was what was missing in these programs: continuous improvement. The government agencies that implemented these programs took the approach that one would take when one is building a bridge or tunnel: get it done and once its done, move on to the next project. This doesn’t work for information systems because they are never done. Once you start using them, there will always be faults and opportunities to improve. If an organization can rapidly iterate and improve the solution over time, they will end up with an effective solution.
Eubanks ends the book with a proposed code of ethics for data scientists and other technologists. I wrote my own code of ethics for data scientists, and it is always interesting to me what others write on the subject. I particularly liked these points from Eubanks’ Code of Ethics
- I will not collect data for data’s sake, nor keep it just because I can
- When informed consent and design convenience come into conflict, informed consent will always prevail. (If only it were so… )
Overall, I found the book to be quite thought provoking, but I did disagree with some of the conclusions.
I’ve been reading a lot lately about the ills of the tech industry, with a few book reviews in my queue to finish, and I posted a question on LinkedIn about what inspired people to get into tech. My motivation was to see if there was a difference in men and women. My hypothesis is that there are societal and cultural factors which discourage girls and women from studying tech (math, Computer science, engineering etc) and hence there aren’t enough qualified women to fill the tech jobs, and ultimately we end up with the current state of affairs where men outnumber women 3 or 4 to 1 in most tech companies.
Anyway, I received the following private response from a former student to whom I shall refer as S. S was a student in one of my recent classes and a delight to work with. Her story is absolutely heartbreaking and needs to be heard. I lightly edited it, only to remove some details which would identify her.
You can share my story but I am not ready to have my name on it. I am going to be looking for a job soon and not everyone will appreciate it. They will see me as slow and too old. I was 54 before I gave myself to permission to study tech and coding languages. Growing up, girls were not encouraged to study math. I was teased about my abilities in math, because I could not recite the times tables. I grew up believing that I couldn’t do math. At home, my brother received an early TI calculator. It was supposed to be shared between us but that didn’t happen. Besides being annoying, it was clear that electronics were not for girls.
I began my university studies in psychology which seemed the only science that did not require math. I was bored and I tried to learn math on my own. Actual classes involved grades and that was disastrous. I somehow passed all the mathematics prerequisites and ended up in graduate school for chemistry. During my quantum mechanics class, I struggled. I went for help from the professor. He realized that I couldn’t do the times tables verbally and completely humiliated me.
At my job, I learned about agile, innovation and human centered design. I loved that these ideas as they provided a framework and a fresh vocabulary to talk about science and problem solving instead of just math. I excelled at facilitating these techniques. Many of the prototypes we needed to wireframe involved a website or an application. I became curious about data and technology, but I would never let myself work in this area. The risk of humiliation was too great. My supervisor already realized that I stumbled verbally with numbers. I did not want to be in a position to lose my job while trying out new skills.
About the same time, I had a routine hearing evaluation and I was diagnosed with great hearing but a serious auditory processing disorder. The audiologist predicted that I probably had terrible problems with spoken arithmetic and verbal math. I was thunderstruck. How could he know that? I had been punished as a child for exactly this issue. I internalized it as part of my self image. Although I was a great reader, I was unable to recite the times tables and do my arithmetic. I couldn’t explain why, maybe I really was a bad kid. After digesting the audiologist’s report, I allowed myself to become more interested in data and technology.
I fight paralyzing “imposter syndrome” every time I sit in front of my computer. I began to take free classes on-line and go to meet-ups and learn even, when I couldn’t talk about it well. I joined groups for women who code. I continue to learn and I just signed up for an intensive software engineering boot camp. I currently volunteer as a teaching assistant for introductory python at two different community women’s coding groups. I continue to attend meet-ups. I am not yet where I want to be but I am finally allowed to move ahead. Data is going to change our world and I don’t want to miss out.