Don’t be that person. Or: How to not be a Kool Aid Man in the “extended workplace”.

Have you ever been out to a restaurant or bar with someone you considered a friend, or maybe a partner, or a date, and it turned out they acted kinda shitty towards the wait staff? Maybe they were unnecessarily impatient, rude, dismissive, entitled, or talking down at people? Or maybe you just witnessed someone acting like that in a public setting and felt some amount of “Fremdscham” (the German word for feeling ashamed for something someone else is doing) ? Yeah? That’s because acting like that is generally considered “bad behavior” and most folks are aware of the rules of common courtesy when interacting with other people, usually those in a position of delivering a form of service.

Cool, Sam, but why are you telling me that? Isn’t this like, a tech blog of sorts?

Well, I recently participated in a number of virtual tech events where I witnessed that very same rude, dismissive, impatient, disrespectful, and entitled behavior (yes, this post is a bit of a rant!) from participants towards the organizers and presenters, and it appears to be more of a systemic problem than just a few individuals being annoying.

Here’s an example from a free live training session I recently attended that was the catalyst for this blog post (note the timestamps for the correct order):

The presenter had clearly explained and demonstrated two free options for using the software at the beginning of the hands-on part, and the teaching assistants in the course had responded to every single one of the participant’s questions. And yet, he posted himself into a rage and acted like a complete ass. I can’t imagine that he’d act like that around his office – and if he did, I hope the company would tell him very clearly that’s not acceptable behavior.

(As an aside, another participant joined the live training 20 minutes before the end of the 2 hour session and demanded someone explain to them how to get started. The training was definitely interesting.)

Another example for interactions that are not necessarily disruptive but just look bad are folks asking for help in Slack channels. I just posted about this on Twitter a while ago:

Screenshot of a tweet saying: "I swear every single #general Slack channel in tech is like 
- User A joined the channel 
- User A: "HEY GUYS here's a huge stack trace help me fix it for free and asap"

Could the eng managers of this world PLEASE sit their engineers down and teach them some manners?"

I’m in a quite a few tech Slack channels and I used to be a maintainer of an open source project, and the typical behavior I notice is:

  • New user joins the channel
  • Immediately posts a question asking for support, often dumping an entire error stack trace into the channel with no warning
  • Frequently cross-posts the same question in other channels
  • Occasionally posts several “anyone?” type follow-ups
  • (Rarely) posts some annoyed or frustrated comment when they don’t receive help
By Source, Fair use,

Maybe I should care less about these kinds of things, but man, seeing this is annoying. I’ve muted most Slack channels I’m in because of too many Fremdscham-inducing interactions. Especially in open source communities, this sort of Kool Aid Man behavior (kicking down the virtual door but going “HELP ME” instead of “OH YEAH”, you get the idea) makes you wonder where people left their manners.

Another version of this is the “mouse asking for milk” behavior, which often follows Kool Aid Man behavior once someone receives help. For those that don’t know, the popular children’s book tells the story of a mouse that receives a cookie, then proceeds to ask for milk (to go with the cookie), a straw (to drink the milk), and other favors. This often has the effect of pressuring the helper to dedicate more time and implicitly puts the responsibility of solving the issue on them instead of the original question asker: “If you don’t continue to help me, you’re letting me down and I can’t solve this problem”.

Look, I understand that we’re all trying to get to results as quickly as possible. Fixing bugs and production fires, figuring out a configuration after banging our heads against the wall for hours, trying to get something to work while following along with a live instructor, all these things are annoying and stressful and make us impatient and want HELP. NOW. But we always have to keep in mind that the people on the receiving end are also just… people. Who are usually trying their best to be helpful, but they might have their own stressors, deadlines, time schedules to stick with, and might not have the capacity to drop everything and help. And maybe you’re the one who’s causing the thing to not work (if you’re in tech you’re guaranteed to have had that experience) – might be time to take a step back and take a break.

I’d also like to clarify that I’m not talking about obviously “bad” or illegal behavior. While many meetup groups, conferences, and open source projects have a Code of Conduct, most of the behavior I refer to is not necessarily a violation of a Code of Conduct, but just generally unpleasant. But keep in mind, just because it doesn’t go against any of the rules doesn’t mean it’s not disruptive, disrespectful, or just plain annoying to the organizers, presenters, volunteers, and other participants. And it makes you, and potentially the company you represent, look kinda bad.

How to not be “that person”

So here’s a thought for folks attending any kind of (virtual) events or participating in Slack communities, message boards, Reddit, GitHub conversations, and other communication channels. I don’t know if anyone’s reading this who should be reading this, but here we go. Before posting anything, ask yourself the following questions:

  • Did I read the “welcome” message and instructions of where to post what?
  • Am I posting in the right channel?
  • Is my question clear and can people actually help me based on the information I’m providing?!
  • Did I use the search functionality to try and see if this question was already answered?
  • Am I asking an unpaid volunteer to do extra work? Have I already taken up a lot of their time?
  • Am I being respectful and mindful of people’s time and other responsibilities?
  • Would I post these kinds of things in my company chat, or say it out loud in a team meeting when my peers and managers are around?
  • Can I wait until it’s a good time to ask that question?

And even after posting a question, there are some things you can do to make everyone’s life easier:

  • Check whether someone actually answered the question, or asked for more details. Respond in a timely manner, or at least let them know that you will get back later.
  • Said differently, pay attention and understand that if someone responds to you, they dedicated time to helping you. Be respectful of their efforts.
  • If you don’t get the help you need, well, so be it. Unless you’re talking to the customer service of a service or product you pay for, you are not entitled to receiving any help, like, ever. And even if you’re paying for the service, keep in mind that customer service staff are humans you should treat with respect. Be persistent if you need to. But for goodness’ sake, please be nice.
  • If the problem is resolved, post that you solved it and ideally, share your solution! This will help people later on, and lets people know that you no longer need help.

Tell your coworkers to not be “that person”

And for the managers out there: I know you’re not responsible for how your reports act outside of the work environment, unless that employee is explicitly there to represent your company. But we all know that the workplace implicitly extends beyond the boundaries of your company’s office, Slack, or email, and that employees are often seen as representing the company in the “outside world”, whether that’s good or bad. If your reports or coworkers (or managers…) behave disrespectful or somewhat disruptive (again, without necessarily violating any Code of Conduct) in an “extended work” setting, that’s just going to look bad and quite possibly make people question your company culture and what kind of people you hire. Well, it definitely makes me question what your company culture is like.

This isn’t an easy conversation to have, but I do believe that any company that onboards new employees likely shares (should be sharing?) some form of “rules” of communication, their company values, or other training that usually boils down to “don’t be rude“. It should be easy enough to include that this also applies to external venues such as (virtual) conferences, Slack channels, message boards, meetups, and other spaces in which the employee is present in a somewhat work-related context and may be seen as representing the company.

And for the presenters, maintainers, and volunteers out there…

Hey there, I see you. Well, I am you. I run workshops, teach coding classes, give conference talks, and help out in tech Slack channels. And I know that putting yourself out there and doing stuff out in public, whether that’s as a volunteer or part of your job, always comes with some amount of pressure and anxiety. Dealing with people who are rude or impatient is never pleasant. Here are some thoughts on how to help with this:

1. Set automated welcome messages in Slack and other communication channels explaining to folks where to post and how. Based on my experience, you can expect some proportion of people to actually read them, and some proportion of that to follow the rules. There will always be people who don’t pay attention, but you can make sure that the rules are actually enforced through gentle reminders: Ask your staff or volunteers to nudge people to post in the right channels, which (hopefully) also will be noticed by other members who will help with that. The dbt folks are pretty good at directing their Slack traffic to the right channels using welcome messages and periodical friendly reminders, see the screenshot below.

Screenshot of the dbt Slack channel stating some rules for what to post where.

2. Add an “FAQ” page to your organization’s website. Reshama Shaikh, a data scientist who’s incredibly active in the NYC tech community I’ve been lucky to collaborate with for years now, recently pointed me to the FAQ page of Data Umbrella, a volunteer-led community group she founded. The FAQ cover a range of questions such as “can you give me career advice” and “can you help me find a job” and kindly point out that the group is entirely run by volunteers who give up their free time and pay out of their own pocket for any kind of expenses (such as MeetUp fees).

3. Have a slide on “How we communicate” rules at the beginning of a talk or workshop. In addition to highlighting the Code of Conduct, you can remind people when and how to ask questions, to use the search function, mention that the talk will be recorded and how the recording will be shared. If you have helpers or TA’s, ask them to enforce those rules, e.g. by posting reminders to hold questions, that the talk will be recorded, or links to the material.

4. Make technology work for you. Honestly, this might be a little dramatic, but see item #1 – there’s going to be a certain number of people who don’t read the rules. One way to make technology work for you, in addition to automated welcome messages, is to lock down the “general” Slack channel to allow only staff announcements, which is a good way to avoid the “new user support question dumping ground” effect. Another option to consider for any kind of live event is to only allow participants of a to join until a few minutes into the event, which avoids people not catching parts and then demanding help 45 minutes into a session.

5. It’s ok to not please everyone. I used to have the “will to please” like a freaking Golden Retriever. But you know what – it’s ok to say no, ignore people, or tell them to wait, for the sake of your own sanity. If someone comes into an event 30 minutes late and you’re a presenter or assistant already juggling several participants, well, maybe the person who came late simply won’t get lucky today and will have to figure things out themselves. Be kind, but firm, and let them know that you won’t be able to catch them up. Sorry. Likewise, if you’re helping someone out in a Slack channel and the mouse asks for more milk, it’s ok to let them know if you don’t have the capacity to help them any further… unless you are working in customer support of course and uh get paid to do exactly this. Otherwise, allow yourself to say no if this is turning from something you enjoy into a chore.

And finally…

I focused a lot on the “don’t make your company look bad” argument in this post, but I think it’s also important to point out that general kindness and respect towards people who dedicate their time to maintaining software, running workshops, giving talks or presentations, should be a given. Whether that’s paid or unpaid, we all need to consistently make an effort to see the person on the other side and man, just give em a break. Chill. Be nice. Accept the fact that sometimes you can’t have it your way. It’s ok. The world won’t end.

Hey there!

I’m Sam, a “DATA PERSON”, based in NYC. I’ve previously worked at data-centric startups doing things like healthcare data analysis and building an open source data quality framework. I also do a lot of conference talks and workshops around data, Python, Postgres, and general data things. Check out the Bio & Contact page for more info.

This blog is a merger of several personal and technical blogs I’ve maintained in the past, so you’ll come across a pretty random mix of technical posts and personal ramblings about my travels and my time in Manchester, UK. Enjoy 🙂

Say hi on Twitter:
Make it official on LinkedIn:
Drop me a line:

“iso trap” – A quarantine inspired cover album

So… it’s been almost exactly 8 months since everything started shutting down in NYC due to covid-19 (and, well, it’s been a clusterfuck of a year but let’s not talk about that right now ok). As so many people, I spent my time in lockdown learning new things – I did a lot of yoga, mastered a handstand, did macrame, way too much tie-dye (anyone need tie-dye baby onesies? HMU.) and well, I taught myself how to use Garage Band and recorded a few songs.

My quarantine inspired album (ok, it’s only 3 songs so far) “iso trap” (from isolation and the music style trap but also a word play on being trapped at home, get it?) combines two of my passions: music, and comedy. In fact, it combines two wonderful things into what I consider to be one of the lowest possible art forms: musical comedy. Don’t even try and argue. Musical comedy is great because it’s just straight up bad. No one, not a single person, ever said “oh man that was an awesome song” when listening to, dunno, Flight of the Conchords. It’s just about tolerable as far as music goes, and the humor is more witty than actually funny, but somehow it’s strangely appealing nonetheless. Musical comedy is the Taco Bell of art. It’s bad and we all know that, but when it’s good, it slaps.

Anyway, here are several songs I wrote, arranged, and recorded. Two of these were performed at my friend Soheil’s virtual variety show “The Cat’s Throne Zoom”, the third one in my kitchen with no audience. Enjoy.

“Everything is canceled”: A song about everything being canceled. Inspired by the Lego Movie. Includes a dubstep breaking and bad white girl rapping.

“You’re not essential”: A love song / PSA about picking the right person for your quarantine bubble, or maybe waiting until Phase 4 reopening to engage. Inspired by a song we all know and love.

“Second lockdown”: Yup, we messed up. A song about starting from square one. A straight up cover of “Closer” by the Chainsmokers using the instrumental, planning to do my own arrangement of this too and maybe get a second person to be the Halsey to my chainsmoker.

What’s next?

When I joined Flatiron Health in February 2014, I had no idea what to expect. I had just moved to New York City – my second ever trip to the US – with two suitcases, crashed on my friend’s couch, and walked into the office in the middle of a snowstorm (I got in late on my first day because I was left stranded by the MTA – pro move!). I was on a 1-year visa and didn’t even know whether it was going to get extended after the year was up, or whether the 20-person startup I had just joined after finishing my PhD in England was even going to last that long.

Almost 5 1/2 years later I’m now looking back onto many late nights at the office, countless meals with my work family, a few drinks (just a few, really!), late night karaoke, rafting and ski trips, pipeline breaks and product launches, both great and absolutely horrifying client calls, several rounds of funding, an acquisition (us buying a company twice our size), another acquisition (this time us getting acquired), almost a thousand new employees, many farewells, wonderful relationships, challenging relationships, my first intern, my first direct report, my first time as a team lead, and my first goodbye to a company that I still talk about as “we” even though I officially left almost a month ago. As I like to tell people who ask me about my time at Flatiron: It’s been a wild ride.

So… what’s next? Honestly, I don’t know. I want to continue doing “data stuff”, but as a non-traditional (as far as the word “traditional” applies to a fairly new field) data scientist who puts data empathy and interpretability before building ML models, it’s going to be an interesting challenge to find the right fit for me. For now, I’m still based in NYC, enjoying the summer, plotting some travel, and reflecting on the things I’ve learned over the past few years.

PyGotham 2015: When Python met the Cookie Monster

Thanks to the NYC Women in Machine Learning & Data Science meetup group, I was able to attend this year’s PyGotham conference on a weekend in late August. With PyGotham being a fairly young conference (it was started in 2011 as an “eclectic Py-centric tech conference”), I had not heard of it before and did not quite know what to expect – and I was positively surprised by the breadth of inspiring talks and the number of enthusiastic Pythonistas I met that weekend.

Day One started bright and early with a 9am keynote by Nick Coghlan of Red Hat, who gave an insightful talk about the challenges of making open source development sustainable. He pointed out that a number of open source projects were handed over to the community where contributors would be happy to add new exciting features, but maintenance and bug fixes were expected to be carried out by “magic internet pixies”. His mention of the importance of work-life balance for open source contributors in particular struck a note with me, since this is something that is often overlooked when talking about getting involved in the open source community.

After a short break to rearrange the rooms, the day continued with a series of thirty minute talks. As a data insights engineer, I was particularly interested in learning more about the tools of the trade, and potentially also hear about some relevant technologies and frameworks that I might not come in touch with on a daily basis. I attended a presentation by Jeff Uthaichai and Chris Becker, who gave an excellent introduction to Docker, a tool that  supports software deployment by allowing users to create a “container” which contains an application along with all its dependencies. The main focus of the talk was a series of recorded demos that showed how easy (or not…) it is to deploy a Docker container to different cloud hosting services. After a short break, the morning session continued with a talk by another excellent speaker, Jeremiah Malina of ChatID, who demonstrated how to set up a real-time analytics services using InfluxDB, a distributed time series database, using an easy to understand example of counting site visits associated with a referral ID.

Of course, attending talks at conferences is only half of the fun – the other half is meeting new people with similar interests, and so I spent most of the breaks in the breakout area outside the conference rooms, filling up on coffee, snacking on cookies, chatting with other attendees, and swapping business cards. One of my highlights of the weekend was my attempt to roll around the breakout area on a self-balancing scooter – think small Segway without anything to hold on to! – which the team from SinglePlatform had brought along.

After lunch, I attended a non-Python talk, which happened to be one of my favorites of the day. Thomas Ballinger, also known as the “Terminal Whisperer”, gave us a whirlwind tour of everything you’ve never thought of doing with your terminal, but you wouldn’t want to miss now that you know how to do it – from replacing existing text and changing text colors to blinking text and advice on how to create blinking git commit messages, Thomas’ talk provided plenty of inspiration on how to make command line interfaces more user-friendly. My final talk of the day was Jarret Petrillo’s excellent introduction to building a data aggregation app in Flask, a Python web framework, or self-proclaimed “microframework”, that can be seen as a lightweight alternative to the popular Django framework.

Day Two of PyGotham started with an engaging keynote talk by Jessica McKellar, a former Director for the Python Software Foundation, who asked us to imagine the Python community as a company which faces issues of sustainability and accessibility. She highlighted a few problems, such as the difficulties of running Python on Windows computers, which basically prohibits its uptake in schools that make heavy use of Windows PCs, and will continue to do so in the near future. Jessica concluded her talk with a very specific call to action to address Python’s accessibility for beginners as a first step to improving the position of “Python, Inc”.

Jessica’s keynote was followed by talk on code reviews by Amy Hanlon, a Hacker School (now Recurse Center) graduate and software engineer at Venmo who I had known since she gave a brilliant demo on overwriting builtin Python functions with Harry Potter spells at a PyLadies meetup in 2014. Amy gave another excellent and insightful presentation, listing some guidelines for code authors and reviewers, and explaining how reducing the amount of ground work a reviewer needs to do (understanding the code, spotting bugs, …) frees up time to get more valuable feedback on your code. After an extended break, I managed to catch the end of Sven Kreiss’ talk on pysparkling, a Python implementation of Spark’s Resilient Distributed Dataset (RDD) interface, had some exciting conversations with attendees from as far as the Dominican Republic over lunch, and met fellow female Pythonistas at the PyLadies NYC mingling session.

The next talk turned out to be another highlight of the weekend: SQLAlchemy ORM as demonstrated through the power of cookies. Jason Myers presented a wonderfully humorous step-by-step demo of setting up a cookie ordering system with SQLAlchemy ORM, a SQL abstraction toolkit that allows users to interacts with relational data as objects by abstracting from the underlying database layer. Jason’s talk was followed by an interesting, though mildly worrying, presentation by Ashwini Oruganti, an Eventbrite engineer and director of the Python Software Foundation, who gave an introduction to HTTPS and pointed out some of the common security flaws in OpenSSL. The final session of this afternoon block was yet another excellent live demo by A. Jesse Jiryu Davis of MongoDB, who walked us through the setup of an application using asynchronous node.js style “coroutines” in Python’s asyncio module.

And with that, my weekend at PyGotham came to a close – a great little conference full of passionate Pythonistas and enthusiastic newcomers, which I will happily attend again in 2016.

Check out my Storify collection of my tweets from the conference!