When it comes to working with data, we rarely know beforehand the right way to derive insights and extract value. Often, it is impossible to know exactly what can be done with data until we start exploring it. This makes it difficult to set expectations and goals for a data-intensive project. These challenges are made even more complex when data scientists don’t control or have access to data sources, or when the shape and content of the data changes over time. As a result, code and architectural decisions can become chaotic, ad-hoc, and difficult-to-maintain. Data scientists tend to be set to the side without a real plan to integrate their efforts with the rest of the business or other software developers. The science part of data science seems to get in the way of using trusted best practices from the software industry. But it doesn’t have to be this way. In this talk, we’ll cover the differences between traditional software development and development for data intensive products. I’ll give an overview of data collection, pipeline engineering, data exploration, and productionization of machine learning algorithms. While doing so, I’ll discuss what makes data products different, and talk about tools and rituals that organizations and teams can adopt to address the specific difficulties in data oriented projects. Properly applied, these practices improve alignment between data scientists, developers, and stakeholders, and improve the speed of development, quality, and maintainability of the product.
The field of data science is having an identity crisis. The fundamental question of who or what a data scientist actually is, remains largely undecided. Regardless of where the answer will fall, there are a number of tools and techniques that every data scientist should have in their toolbelt. Although the software languages, frameworks, and algorithms will come in and out of fashion, the fundamentals behind the trade of data science, which we talk about in this session, have existed for centuries and will continue to be used for ages to come.
We’ve created a playground data science application that’s ready for you to jump in to. It uses real data, an industry-standard toolset, and addresses a typical machine learning task. We will run you through the workflow and lifecycle of the data science application, and you’ll spend most of the session experimenting and improving the machine learning model.
This talk grew out of the frustration and stigma I felt as I prepared to give a different talk; one which also had a "non-technical" focus. "I think my topic is really important but I also think as a techy femme person, I need to be seen giving more technical talks," I said to myself. But wait a minute! In the tech industry today, skills and conference talks are overlooked and undervalued when they focus on things like interpersonal communication, justice in hiring, ethics in general, emotional sustainability in the workplace, and anything else firmly outside the realm of either hardware or software techniques. The bias favoring "hard skills" and "technical" talks holds "non-technical" skills as somehow less important and less difficult, even as so much team/company dysfunction is the result of deficiency in non-technical realms. This talk explores this tech/non-tech dichotomy, why it's faulty, and why the audience's social engineering skills are as important as their software engineering skills, if not moreso. My goal is to inspire people such that they're ready to demand respect for their social proficiencies in their office, at conferences, and in their lives.
"Good morning, how are you today?" Well to be honest, Matt, I'm having one of those days where I wish I were dead and I'm trying not to think about it. Hows your morning been?
Mental health issues are tough. They're tough for those of us who experience them, and they're tough for our friends and colleagues who want to help. Nothing in this talk is going to change those facts. Mental illness is always going to suck. Nonetheless, we need to talk about it. It doesn't have to suck as much as it does. My goal for this talk is to provide a point of reference, a vocabulary, insight, context, and concrete takeaways for people who want to support their colleagues struggling with mental and emotional health. The ideas in this talk come primarily from other software developers with mental health challenges, my own experiences, and talking to colleagues who have supported me during and after I came out with an eating problem and problems with self harm.
Open source software has enjoyed a relationship with anarchists throughout its history. While “anarchy" has come to be synonymous with “chaos” (and while that may be an accurate description of my GitHub code contributions), anarchy doesn’t have to be chaotic. Open source software often relinquishes power from well funded elites and hands it over to the masses for no cost. But open source code and ideals don't magically equate to justice or freedom.
Anarchy stands in opposition to all tyranny and oppression, which comes in many forms. Sometimes it wears a uniform, sometimes it is democratically elected and comes with an iconic bad haircut. Sometimes it works on GitHub repositories or manages conferences. Sometimes it's you or me. The misuse of power exists at an interpersonal and systemic level, and many of us experience it daily in our office environments and open source projects. It's our job to fight and find alternatives to systems of oppression wherever we see them. Thankfully, though, we can rely on the wisdom and tech of those who came before us, and those around us.
This talk will build on the communication and organizing skills I've learned from years of work in radical activist networks, plus my experiences at an "Open Source by default" firm with no job titles and no bosses, all informed by my graduate studies on organizational structures. It will touch on practical prescriptions for nonviolent communication and conflict transformation, outline good project management in a world without managers, and point out pitfalls like the tyranny of structurelessness. With the right implementation, anarchist ideals can improve our work environments right now. Even in heavily structured environments, a company or project may improve the quality of output while also improving the quality of life for the people it employs.