As I mentioned in my last post, I recently moved from being a Senior Software Engineer to a Team Lead. I’m fortunate to have received the advice early in my career that moving to management is less a promotion and more starting a new job; I immediately started looking for information on how to get better at this new job, fast.
One of my winter break goals was to get through as many books as possible, and High Output Management was at the top of the stack. As soon as I started reading it, I understood why it’s so highly recommended in management circles: it’s the best book on managing teams of people that I’ve read so far. It’s so good, in fact, that some of the best ideas in it seemed obvious to me.The ideas seem obvious because every company I’ve worked for has implemented some part of Grove’s ideas about management. They seem obvious because I have the advantage of living in a world that has had High Output Management in it for the past 30 years.
Take the idea of metrics and outcomes guiding a team. Every company I’ve worked for, especially in tech, has every team or department within it tracking metrics that get reported up the chain on a regular basis. As an engineer, this obsession with team metrics and trying to improve them can seem like a waste of time. “We feel good about the things we’re working on, why do we have to spend so much time quantifying them?”
The answer to this comes almost immediately in High Output Management: Every team is a black box to everyone not on the team, and the only way to know if a team is successful or not is to check the team’s metrics or see what they’ve shipped (which is itself another kind of metric). Thinking about metrics and outcomes in this way permanently changed my approach to teams. I started immediately looking at my team’s reporting metrics not as some arbitrary goal to hit, but as the only measure of the team’s health that most of the rest of the company would see.
Once you start thinking about metrics and outcomes in this way, if you’re like me you’re driven to make sure the metrics are real for your team. “Real” here means that the metrics actually line up with what the team AND the company care about, that your team can do something to affect the metrics, and that the members of the team are bought in to what the metrics represent. That last bit is especially crucial. Once your team knows why the metrics are important and agrees on what they should be, they can start making suggestions for how to improve them that might be better than the planned workstreams.
Speaking of outcomes and ideas that were popularized by High Output Management, let’s talk about OKRs. OKRs are an instance of the endless acronym parade that permeates Silicon Valley, and this one stands for “Objectives and Key Results”. Grove introduces this in talking about “management by objectives” (MBO, hooray another acronym), which is how every team I think I’ve ever been on has been managed without my ever knowing the term. “Objectives and Key Results” is an unfortunately jargon-heavy way to express an idea that I actually love, namely “Here’s where we think we’re going, and here’s how we’ll know if we’re going in the right direction.”
A trivial example. Say I want to get from my house in Alameda to my favorite taco place in Oakland, Xolo. “Get to Xolo” is my objective. There’s a myriad of ways I could check how close I am, and each one of those is a potential key result. I could carefully measure the odometer (metrics based), or I could know that I’m about a quarter of the way there when I hit the dog park, halfway there when I hit the tunnel, and roughly three-quarters of the way there when I turn on 12th st (milestone based). Take this simple idea and expand it to what your team or company cares about, and hopefully some of the chaos of running a team doesn’t just get a little bit clearer.
“Making things clearer over time” could be a subtitle for the book, in fact. Grove lays out his material in such a way that every chapter has at least one idea I found immediately useful, although the later chapters on performance evaluation and especially hiring feel a touch outdated. This is the disadvantage of reading such a seminal book 30 years after it’s publication -- Grove’s ideas were so good we adopted many of them and kept iterating!
After reading High Output Management, I’m doubly indebted to Jacob KM and the others who recommended it to me. Once, because it gave me more tools in my management toolbox. Twice, because I know have an iron-clad recommendation for anyone who asks “what books should I read about being a manager?”. Grove’s book is near the top of that list.
Have you read High Output Management? Think I’m wrong in some of my thinking on it, or want to talk about strategies from the book that worked for you? Drop a note in the comments.
In November, I was promoted from Senior Software Engineer to Team Lead. As of right now, I lead the Platform team at Patreon, and have three software engineers who report to me. I want to talk about how I realized this was something I wanted, how I made this happen for me, and why I’m excited about it.
First, how did I think this was something I wanted? It’s helpful to know that I am mercilessly driven by the idea of impact. At least once a week, and sometimes multiple times a day, I ask myself these questions: “Am I working on the highest-impact thing I could be working on? If not, why not?” Being impact-driven (which dovetails nicely with being outcomes-driven for devotees of that brand of organizational thinking) means that I’m always looking to increase my impact, and especially looking for tools that will give me more leverage.
For the kind of impact I want to have, the impact to shape customers’ experiences and shape the paths of teams and shape the careers of individuals, the tools available to managers and team leaders are more impactful than the tools available to engineers. Now, I expect some disagreement to that statement, and I welcome discussion in the comments. For the goals I care about, the tools of a manager are higher impact than the tools of an engineer.
How did I make this happen for me? I saw an opportunity, and I pushed for it. That sentence masks a truly monumental amount of privilege, and luck, institutional biases that I think about a lot. Would a non-white, non-dude have been as successful in their push? What institutional biases might have kept those around me from pushing? So, there’s a lot hidden that I would love to go into in another post when I say: “I saw an opportunity, and I pushed for it.”
What opportunity? Well, Patreon is constantly working on becoming a more lean, more agile shop. As a result, in the Summer of this year an Engineering Director was leading the Platform team, at a critical time in the Platform team’s history. We were in the middle of trying to launch the Reddit integration, our Product Manager was on his way out to work full-time on being an author, and we had just hired a new grad engineer. I saw that there was an opportunity for a strong leader to step forward, so I did. What followed was a month and a half of me talking to peers, managers, directors, VPs, and HR folk, to see how feasible this was. I ended up writing my own job description for role that I now occupy, and then vetting that job description in another round with the people I listed above. I began pushing in late September, and in early November my transition to Team Lead become official.
As an aside, why “Team Lead” and not “Engineering Manager”? For one, I’m still doing some engineering work, on the order of 40% of my time. This doesn’t mean “I’m coding 40% of my time” but it does mean I’m doing “Senior Engineer” things with 40% of my time, and “Team Lead” things with the other 60%. I’m also Team Lead for the team I was a Senior Software Engineer on, the Platform team at Patreon, and as a result my number of direct reports is fairly small compared to other Engineering Managers at Patreon.
This is probably obvious since I said above that I wrote the job description, but I am the first and so far only Team Lead at Patreon. There are others who I think would be great at the role, and this is one of the reasons I’m excited about it: Team Lead hopefully gives engineers a chance to explore management without “closing the door” on returning to engineering.
Why am I so excited? At the root is how much I am excited about Patreon, and especially my team at Patreon, and what I think the Platform team is capable of. I’d also be lying by omission if I didn’t mention a few other things: I’m excited by the challenges that management presents, and how different they are from engineering. I’m excited to learn about a whole new discipline of work that has so much impact on engineering, but is not strictly engineering. I’m excited to gain a new lens through which to see the world.
I also really hope I don’t fuck it up. I want to do right by myself, my reports, and the company, in roughly that order. If I’m not doing right by me, I can’t be an effective leader or example. If I’m not doing right by my reports, then my team as a whole suffers, and my measured output as a manager crumbles. If my team is unhappy or unproductive, then the company will as a whole will suffer. The challenge of having to manage the stack of responsibilities, of having to coordinate conflicting demands, of figuring out how to build a team while meeting the needs of each person on the team is a challenge that I’m exceptionally excited about.
Want to know more? Want to challenge me on my thinking or ask questions about how I got here? Leave a comment below or ping me on mastodon at @[email protected].
As I started writing this post, I got blocked by the dang title. I couldn't think up one, and so I started writing in the hope that one would come to me.
It'e been a long time since anything was published to this blog. It's not that I haven't been writing; if anything my volume of prose has gone up dramatically in the past year as I've started pushing for more and more documentation on the teams I work in and the projects I lead.
I think there's three reasons nothing has been published here in the past year.
For starters, there's an infinite bikeshed of possibility in running your own blog, powered by software you maintain. See something you want to fix? The bottomless rabbit hole is there, ready and waiting for you to fix it. It becomes nearly impossibly hard to resist the siren song of everything you want to do in code to make the blog better, forgetting of course that the point of the blog is the content, not the chrome.
Secondly, Dunning-Kruger. I'm past the hump of thinking I know anything at all about the subjects I want to talk about, but don't have the confidence to believe that my observations are valid. This position is, thankfully, changing: I'm starting to get some validation through my work at Patreon and with technical organizations that my experience and opinions are valuable, and worth adding to the collective conversation.
Thirdly, and perhaps most importantly, today especially, is that my my own brain chemistry is acting against my best interests at the moment. There is quite a lot from the last six years of my life that I'm processing, and trying to heal, and covering on a regular basis in therapy. I am out of "fighting for survival" mode, and my brain is taking the break in constant survival stress to raise issues that I need to deal with, and which come with their own flavors of toxic brain chemistry.
So, what do? As I was writing this, and talked above about the fact that my prose output has actually increased, I had the realization that I value documentation to an obsessive degree, and that taking the posts in this blog as attempts at "documenting my life, and the experiences I have in it" might get me around some of those blocks posted above.
Mastodon is currently my favorite social network. I love it so much, I started my own server with some friends, and I'm proud to say it's still going strong. You can read about The Wandering Shop in my previous post about why I started it.
Part of the reason I love Mastodon and The Wandering Shop is that it's a social community where we get to define the rules, and we get to control who is and isn't allowed in our neighborhood. Myself and the other shopkeeper, Annalee, do a good job keeping out the riff-raff as per our Code of Conduct. That said, if you aren't on our server, or if you want a tighter grip over who you share with, Mastodon provides some of the most comprehensive options I've seen for privacy in a social network.
So here are 6 things you can do to lock down your Mastodon account.
1. Develop a good relationship with your server admins
While Mastodon provides some excellent options for blocking people and servers just for your account, involving your server admins will help keep bad actors and bad instances off everyone's feed, and help the neighborhood feel better as a whole. This is tougher on a large server like mastodon.social, but the admins there still try to respond to reports as they can. That "personal relationship" is one reason why I prefer the smaller servers.
2. Lock your account
The next steps in this guide are going to be found in your Mastodon preferences, which you can find under the "Gear" tab in the Mastodon web interface. This guide, and all the screenshots, assume your server is on Mastodon 2.0, which many servers have moved to by this point.
In Mastodon, locking your account means that you must manually approve every follower. The Mastodon default is anyone can follow anyone else, without approval. Setting this setting will require action from you every time someone wants to follow you, but it also means no-one can follow you without your permission. This is especially important if you want to...
3-4. Set privacy defaults on toots and unlist from search results
The default for toots that you post in Mastodon is "Public", meaning everyone can see them and re-toot them. The next level of privacy is "Unlisted", meaning anyone can see them if they go looking for them, or if they follow you, but they won't show up on the public timelines, like the "Local" feed or the "Federated" feed. The final level of non-direct-message privacy is "Followers-only". When a toot is followers-only, only your followers can see it, they CANNOT re-toot it, and it won't show up in any public feeds.
All of these options are available on a per-toot basis in every client I've seen, but if you'd like your toots to be more restricted by default, you can change that here. However you are most comfortable using Mastodon is the right way to use Mastodon, but it's worth noting that interesting toots in the public timelines is how people find other interesting people on Mastodon, and removing your toots from that by default may limit how many people get to appreciate what you have to offer.
On this same preference page is "Opt out of search engine indexing" option, which will translate to your public profile and status pages not being crawled by search engines that respect things like robots.txt files.
5. Set up 2FA for your account
This falls under "Good internet hygiene", but it's a good idea to set up two-factor authentication for your account, and Mastodon has made it easy to do so. Accounts getting hacked sucks, turning on 2FA makes that less likely.
6. Donate to Mastodon development and encourage more privacy features
Mastodon is created and run by volunteers, and you can help support the lead developer through the Mastodon Patreon Page. Additionally, suggestions for more privacy features come up all the time in the Mastodon Github, and you can help make them a reality by pitching in your time and expertise.
WordFugue is a blog run by phildini and oboechick. The best way to show your appreciation is to share this article with friends. The second best way is to donate to phildini's Patreon Page.
“If you’re a programmer you should attend technical conferences to further your career.” Some variation of this was said to me so often when I was starting out as a writer of software that it became something like gospel. It became how I approached conferences; I was there to gain skills or a network that would help me further my career in some way, or further the interests of whoever my employer happened to be at the time.
If you approach conferences with this mindset, I think you will be disappointed. I certainly was. And it took a couple years of going to conferences before I realized (with the help of my wife and some close friends, I should point out) that I had the most fun when I focused less on how any particular conference was going to further my career and focused more on making genuine connections with people, and focusing on topics I actually found exciting.
This makes sense to me when I step back to think about it. Writing software, even when you’re on a large project or part of a large team, can be a very lonely, isolating business. We spend most of our time in our own heads, building castles of imagination that we make real through code. Given the viral strains of imposter syndrome, burnout, and depression that runs through our industry, it can feel incredibly difficult to reach out and make connections, to share our problems and commiserate even with our closest peers.
This is the strength of the best conferences for me. Yes, you will learn things at a good technical conference. You will be exposed to ideas and approaches to problems (both technical and social) that you maybe hadn’t thought of before. Delighting in learning is a totally valid reason to attend technical conferences, and part of why I attend so many.
But the primary reason for me is finding and reconnecting with my tribe. Technical conferences, especially in the Python community, are filled with some of the best and brightest people I’ve had the fortune of knowing, and, more than that, are filled with people who are kind, and willing to listen, and also want to connect with others in their community. I will tell you a secret: Many of the best and brightest, those you might be coming to a conference specifically to see speak, are coming because they also want to make those connections. They also want to reach out, commiserate, and find their tribe.
Now let’s talk about DjangoCon, specifically DjangoCon US which is coming up in August. PyCon is the big conference in our community, and it draws the biggest crowds. PyCon is excellent, and I enjoy going every year. I connect with people at PyCon that I basically don’t see for the rest of the year. But where PyCon is the big yearly reunion with the whole community, and can therefore be overwhelming, DjangoCon is the smaller gathering with friends. Where PyCon is, in many ways, a week-long festival for the Python community, DjangoCon is closer to an intimate dinner party, where you can hear more of each other’s conversations, and join in some incredible discussions.
If you’re still searching for a tribe, or want to reconnect with the Python and Django Community, and want to do so in an intimate gathering of friends, I hope you’ll consider attending DjangoCon this year. As an added bonus, you’ll get to hear myself and the other speakers give a frankly incredible lineup of talks. Seriously, I get excited just looking at it.
Now, some people might be turned off by the fact that the conference is in Spokane. It’s a little out of the way, this is true, but this is one of the reasons I get excited about conferences: Chances to visit places I wouldn’t visit otherwise. I’ll also say that the best breakfast I ever had was in a small town in Washington, and I’m excited for the brunch game in Spokane.
P.S. About that “technical conferences will further your career” thing. Nothing has done more for my career, and my well-being as human, as having a collection of real friends that I’ve met at conferences.
WordFugue is an independent collection of writings and ramblings, and we’ll never show you ads. If you want to support our work, consider donating to Philip’s Patreon, or buy a book from our Amazon affiliate store. In the spirit of DjangoCon, consider purchasing Two Scoops of Django, our favorite Django book.
There are many challenges to running an Open Source organization, but the one that I have personally felt the pain of again and again is that our tooling is awful. Github (and realistically we’re all using Github at this point) still feels in many ways like a tool designed around the idea that all the action is going to happen in one repo. This may not be entirely the fault of Github. Git itself is very tightly coupled to the idea that anything you care about for a particular action is going to happen in one, and only one, repository.
When Github released Organizations, the world rejoiced, because we could now map permissions and team members in our source repository the way they were mapped in the real world. Every new feature Github adds to its Organizations product causes more rejoicing, because so many teams work across multiple repos, and the tooling around multiple repos is still awful.
The awfulness of this tooling is probably a strong factor in the current trend towards “microservice, monorepo” code organization, but that’s another post.
I’ve been the equivalent of a core contributor for a half dozen Github organizations, and I’ve noticed that one area where the tooling is especially lacking is around labels. I’ve seen labels used to designate team or individual ownership, indicate the status of pull requests, signal that certain issues are friendly for beginners, and even used as deploy targets for chunks of code. It’s fair to say that labels form a core tool in the infrastructure of every team I’ve seen using Github, and yet the tooling Github exposes for labels is painfully lacking.
I could go on and on about this, but my goal here isn’t to necessarily make Github feel bad. I hope they’re working on better label tooling, and if they want ideas, boy am I willing to give them. But there is one label-specific wall I kept banging my head against, and that is label consistency across all the repos of an Organization.
Some of you read that and feel remembered pain. I feel that pain with you, and we are here for each other. Some of you might have no idea what I’m talking about, so I’ll explain a bit more.
Let’s say you want to add a “beginner-friendly” label to all the repos in your Open Source Organization, so that new contributors can find issues to start with. Right now on Github, you would need to go into every repo, click into the Issues page, click into the Labels tab, and manually create that label. There are no “Org-wide labels”, and no tool for easily creating and updating labels across all the repos of an organization.
Introducing Epithet, a Python-based command line tool for managing labels across an organization. You give it a Github key, organization, and label name, and it will make sure that label exists across all the repos in your org. Give it a color, and it’ll make the color of that label consistent across all repos as well. Have you decided you’re done with a particular label? Epithet can delete it from all your repos for you. Are you using Github Enterprise? Epithet supports that too.
Epithet exists to fill a very particular need in open (and closed) source Github organizations, and it’s still pretty alpha. We use it for the BeeWare project, and it might be used soon for syncing labels in the Ragtag organization. You can start using it today by checking out the (sadly small) documentation, and if there’s a feature missing you’d like to see, I’m happy to work with you on getting a PR submitted.
Managing Open Source organizations is hard. My hope is Epithet makes it a little bit easier.
WordFugue is independent, and we will never run traditional ads. If you like what we're doing, consider donating to phildini's Patreon, or buy a book from our affiliate store. This week we're reading Patrick Rothfuss' "The Name of the Wind".
Python is the best technical community I’ve seen, and close to the best community I’ve seen at this scale. If you’ve been programming for any length of time, you’ve seen technologies and frameworks and languages rise and fall. We often bemoan the loss of certain ideas from these fallen works, but rarely talk about the communities that fell with them. Python is in many ways the most deliberate community that I’ve ever seen around a technology, and my life will be worse if it ever falls.
I think the Python Community is either near an inflection point, or right on top of one. What do I mean by that? I mean that, over the next five to ten years, I see two paths for the Python community and ecosystem. (Because “Python community and ecosystem” is long to type and read, I’m going to use “Python” to mean “the Python community and ecosystem” for the rest of this post.)
Path one, the one I hope we take, is the one where we take active steps to grow Python. It means that we are continuing to welcome new people into the community, from areas we never considered. It means we have a surplus of good, well-paying jobs for Pythonistas at every experience level. It means the companies and organizations creating those jobs recognize what Python gives them, and sponsors the ecosystem and community events to be better than ever.
Path two is the path I’m worried about. It’s the path where we expect Python to take care of itself, where we collectively take a more passive approach to the community that so many of us enjoy, and which has given much to many of us. I think this path results not in Python dying overnight, but in a slow decrease in Python, in Python becoming more and more irrelevant over time. It results in less Python jobs, more Go or Node or “insert language here” jobs. It results in Python being pigeonholed into certain industries, and new Pythonistas being forced to learn some other language to start their career. It results in our major events slowly shrinking over time, and a time where we start counting down attendees instead of counting up.
I’m not going to try too hard to convince you that this is where we are, that we are at or close to a fork in the road. It’s what I believe, and I think you some of you might agree already, but here’s some of the things I’ve noticed that make me think we’re close to such a point.
PyCon 2017 was fantastic, and had more attendees than ever, but had noticeably fewer booths in the expo hall then last year, and I believe fewer sponsors overall.
Other Python and Django conferences, especially the smaller regional conferences, are finding it harder and harder to get sponsors. Some of this is the market tightening, some of this is companies moving out of Python, or not feeling like they get a return on their investment.
More programs and code schools are using Python as their teaching language, but for many the entry-level positions just aren’t there. Some of this is, again, the market not hiring entry-level, some of this is the companies we work for being willing to take risks and train.
Based on the above, and some other feelings and anecdotes, I think we’re right on top of the fork in the road. So what do we do about it? We take deliberate actions to help grow Python. Here’s what I’m planning to do over the next year:
Running for the PSF Board of Directors. Why do I think being on the Board is important in the context of this post? Because I can push for growth at the Python organization level, and I can get things done as a Board member that I can’t get done as a non-Board member of the PSF. Anyone reading this can, and should, run for the Board if they feel so inclined. But I’d also love to see more participation in the PSF committees, especially along the lines of fundraising and outreach. No matter the outcome of the election, I’m going to continue my work on the Sponsorships committee, and keep doing the other things on this list.
Reaching out to University Computer Science departments about using Python. I’m already in the process of arranging a guest lecture with classes in my old CS department about life as a professional Software Engineer. I’m planning to add specifics about how I use Python (which is more and more the introductory teaching language) in my professional life. My hope is I can help connect classroom lessons to professional Python just by showing up and giving a small talk.
Reaching out to University Science departments about Python. If the keynotes at PyCon 2017 taught us anything, they taught us that Python is an incredible resource in research science departments, statistics departments, anywhere deep thinkers need to do computation and visualization. I’m hoping to put together a “Python in Science” roadshow to help with this, but the reality is Software Carpentry is years ahead of me in making this happen, and anything we can to do help with them is almost certainly worthwhile.
Being a Core Contributor to the BeeWare project. Python has great stories around developing web applications, working in the sciences, and doing systems tasks. Our stories around developing consumer apps are lacking, and I don’t think they need to be. BeeWare, and many others, are taking a stab at filling this gap, but for you reading this the action item could be “find a Python project in an area you care about, and work at making it the best it can be.”
Volunteering time to get more companies and projects started in Python. This one is more nebulous, and I haven’t done it yet but plan to soon. I’m planning to reach out to VCs and incubators and especially hackathons and say “Here’s my background, I’m happy to show up to any event and donate my time to help, but I’m only going to help with Python.” I don’t know how this is going to go over, but this idea has some exciting potential. If we want more jobs in Python, we need to be pushing for more companies and projects to use Python, right from the beginning.
If any of these ideas seem interesting to you, feel free to copy them! If they seem interesting but daunting, feel free to reach out to me ([email protected]) to chat about them. If these ideas inspired your own ideas in a different direction, great! Tell me about what you’re doing and I’ll share it far and wide. My goal in listing these ideas isn’t to toot my own horn, but start a conversation about methods for Python outreach, in the hope of growing Python.
Of course, I could be wrong in my beliefs. (I’d actually love to be corrected with stories or data that show I’m wrong, and would happily share them here.) What if Python is healthy, and is going to grow consistently over the next decade?
Then I’d still do everything I’m planning to do, and encourage others to do the same. I think everything we pour into the Python community is valuable, and any new Pythonista we bring in enriches us all in ways we can’t possibly anticipate.
If I’m wrong, and we make Python better for no reason, we’ll still have a better Python.
I'm entering the arena for the third year. I'm running to be a Director for the Python Software Foundation. This post will help explain why.
There's an argument that anything I write here should instead be in my candidate statement. I don't disagree, and the reason I'm writing here instead of there relates to one of the things I'd like to change: Nominating for the Board of Directors requires editing the Python Wiki. The Python Wiki is hard to use, the documentation on it is not well-exposed, and a room full of Pythonistas during the PyCon sprints (including one current Board member) couldn't tell me who maintains it. Beyond that, you have to answer somewhat-esoteric Python trivia to submit your edits.
I'd like a clear definition of what the Board and the community thinks the Wiki is for, and regular check-ins on whether it's serving the community well. I'd like to see us running "PSF Sprints", where Board members or anyone else interested is writing documentation about how the PSF is run. Our election processes and funding processes and budget processes and outreach processes should be checked on regularly, and I'll be pushing for more transparency and openness about how we run the business side of Python.
Speaking of outreach, I'd like the PSF to be doing more of it, and funding groups who are growing the Python community. There will be more about this in a future post, because I have plans on how to get our community of Pythonistas back out into the world growing the community at universities and hackathons and incubators and corporations. I want every group and individual trying to grow Python to know that the PSF has their back, and will put money behind them.
I also want to be on the Board to remind the PSF that they have power beyond grant giving. Yes, the majority of what the PSF Board has done in recent years has been giving grants to organizations around the world. That work is excellent, and I want to see it increase. But the PSF is also in a unique position to be a promotion clearing house and force multiplier for good ideas in the community. When good learning materials are written, they should be easily findable from the official Python websites. When Python events are being held, the PSF should be a cheerleader, spreading the word about what's happening in the community.
These are the things I plan to do as a PSF Director to help grow Python. I haven't even gotten into the investment I want to see us putting into our core tools and platform infrastructure; that will have to be another post and my brain is a little fried from PyCon.
So the only question left is: Why do I need to be on the Board to do these things? And the answer is I don't These are things I'm going to push for no matter what. But the PSF is in many ways the voice of the community, and I want to see that voice brought to bear on the issues that will be affecting our community for the next year and the next decade. I think I can help use that voice to speak for the Pythonistas of the future, and I hope you agree.
Here we are the end of the first conference day of PyCon. Thinking over the day, and including thoughts from the opening reception last night, I'm struck by something that is even more true this year than it was last year:
The Python community is incredible. We are at an inflection point where we need to be making measured, conscious decisions to keep Python and its community thriving.
I'm going to be writing even more about this in the coming weeks, but let me jot down some observations, and then try to sum them up at the end:
1. It was pretty obvious to anyone who had been here last year that there were less sponsor booths in the expo hall. Noticeably less. Speaking to someone who had a booth last year and chose not to this year, there was perhaps a level if disgruntledness with the organizers that caused them to skip this year. That's troubling. What's even more troubling is talking to conference organizers for other Python and Django conferences about how it's gotten harder this year to find sponsors.
2. Jake VanderPlas' keynote this morning highlighted some areas where Python is making incredible inroads, and showcased how Python is becoming the defacto tool in many areas of the science community. They choose Python for many reasons, and one of them is:
"Speed of development is primary, speed of execution is secondary" #PyCon2017
These thoughts really resonated with the audience, based on the number of likes and retweets I got. And I think these are sentiments the community at large shares. We don't (necessarily) choose Python because it's the fastest language on the planet. We choose it because we like working in the language and we love the community that comes with it.
3. Speaking of that community, I didn't get a chance to see as many of the talks as I would like, because I spent so much time chatting with people about fascinating topics in the hallway track. The hallway track continues to be one of the best parts of PyCon, and it was especially noticeable this year that people were being encouraged to participate. One of the amazing things about PyCon is that all the talks are recorded and put online for free, sometimes within hours of their being given, so attending a talk can often be considered secondary to meeting interesting people in the hallway.
4. This is even more pure anecdote than (3), but it felt like I heard of more people finding it harder to get jobs in Python building web applications, and easier in things like data or science. I can't prove this is true, and it might not be all bad, but it's something to watch. Any area where it's suddenly harder to find work in Python means a pillar of our community is weakening, and we should be aware of it.
5. The day ended with lightning talks, and I hope everyone in the audience saw Cameron Dershem's talk about what the Rust community is doing better than the Python community, especially when it comes to improving usability of the language and making it easier to contribute. Furthermore, I hope it was a call to arms for all of us to start pushing for making every aspect of our community feel welcoming, and like new people can make a difference.
Summing up: Python's community still feels like home, to me and many others, and PyCon feels like a homecoming. If we want to make sure the community continues to be incredible, we need to keep an eye on trends in where people and companies are using PyCon. We also need to continue to be excellent to each other, whether the person we're talking to has been here for years or just learned about Python today.
I'm going to keep pushing to make Python better, and I look forward to seeing you all at PyCon tomorrow.
There is a recurring villain in the Terry Pratchett novels called The Auditors. They show up over a number of books as the adversary of Death, and make one of their most daring ploys in Thief of Time, which I also consider in the top five of the Discworld canon.
The Audtiors, who I describe in the singular because it thinks of itself as one entity, is one of the most insidious adversaries in the Discworld because it is not evil, or even mean-spirited. It simply wishes there was more order to the universe, and would prefer all life to stop because life is so disorderly.
One of the best descriptions for the existance of The Auditors begins thusly:
Nine-tenths of the universe is the knowledge of the position and direction of everything in the other tenth. Every atom has its biography, every star its file, every chemical exchange its equivalent of the inspector with a clipboard. It is unaccounted for because it is doing the accounting for the rest of it, and you cannot see the back of your own head.
Nine-tenths of the universe, in fact, is paperwork.
This phrasing has stuck with me recently in regards to critique of the internet and online communities. In many ways, the internet is its own auditor, its own bookeeper, its existance is the record of its existance. And yet, thousands upon millions of words have been written explaining more about the communities and worlds that make up the internet. Entire libraries could be filled with the printed pages of digital commentary on Twitter and Facebook and all manner of internet forum that have come before.
One of those pieces of internet critique, which I will not link to because I do not wish to drive traffic to it, rankled me, to the point where I felt a need to counter it. But to counter it properly, we need to establish some background. Carl Sagan once said "If you wish to make an apple pie from scratch, you must first invent the universe."
And so must we, but the universe we're inventing is The Fediverse, specifically one small corner of it called The Wandering Shop. This is the story of how The Wandering Shop came to be.
Twitter is awful. This is the sentinment that so many of us, myself included, have felt in the past months and years. It's product decisions are opaque, it's community vascillates between cynicism and bigotry on a daily basis, and you can never shake the feeling that you're trying to have an intimate conversation while yelling at the top of your lungs in the public square.
Enter Mastodon, a piece of Open Source software (which in this case, as in most cases of Open Source, means software anyone can edit and everyone has opinions about which they'll happily go to the barricades for). Mastodon has it's own fascinating and complex history, involving multiple internet generations of Open Source and Free Software activists, but it is, in essence, a piece of software that behaves much like Twitter that you can host yourself. This definition is untrue by almost every measure, but it aids wonderfully in understanding.
Two crucial facts about Mastodon are true, and possibly beautiful, making them True again: 1) You can host it yourself, meaning you have full ultimate control over the canonical copy of the data. 2) Anyone who joins your instance, your little slice of the network of servers, is subject to your rules, and your community decisions.
One of the things that Twitter got wrong, in my opinion and the opinion of other heavy Twitter users, is that it thought the only way to grow and to have a userbase committed enough to fill the gaping maw of Venture Capital was to allow free speech to be the default. It's truly mind-boggling how, when unfettered free speech isn't allowed in the classroom, the workplace, on public television or radio, or in most human relationships, the developers of communication tools for humans think that free speech with no rules (or poorly enforced rules, amounting to the same thing) will prompt quality conversations.
Mastodon, from the outset, made no bones of the fact that the owners of the instances could mute or block or kick off individuals who broke that instance's community guidelines. They could even block or mute whole other servers, allowing the instance owners to set their own rules and sanctions.
This is what interested me, when I first read the post from Eugen Rochko that kicked off Mastodon for most of us. I joined immediately, and loved the growing community I found there. Mastodon replaced Twitter in my life so quickly that at times it almost felt like whiplash. My fingers would reach to open Twitter of their own accord, and when my mind returned from wherever it had been I would realize what I was doing, close Twitter, and open Mastodon.
I'm forever grateful to that muscle memory, however, because without it the Wandering Shop would not be. It was during one of those brief unconscious Twitter checks that I saw my friend Annalee suggesting the idea of a moderated Scifi/Fantasy Mastodon instance. You can still see the thread here. We got to chatting, first over Twitter, then over email, and days later The Wandering shop was born.
As you can see from that thread, a strong Code of Conduct was part of the Shop's DNA from the beginning. Many of us, myself included, feel like The Wandering Shop is a real, shared coffee shop that happens to mainly exist in our minds, and so it makes sense to me to say that the guidelines and code of conduct are built into the very walls of the Shop.
Annalee and I wanted to build a community that was open to all, but deliberate in what was and was not acceptable behavior. To the best of my knowledge, we have yet to act on poor behavior from the Shop's patrons (those who have registered their accounts at The Wandering Shop), but we have muted or blocked accounts and instances that we thought were making life in the Shop worse. Additionally, we've put effort into deliberate community building. We made a weekly calendar to encourage conversations, and we try to generally be available as part of the community.
This is, for me, the power of Mastodon, when run deliberately: You can build online communities like neighborhoods, full of people you enjoy sharing the sunset with, and still be connected to the rest of the city down the road. I can honestly say The Wandering Shop is in the top three online communities I've ever been a part of. Twitter and Facebook don't even make top ten.
The article that came out today, that fired me up enough to write this piece, was describing why an instance admin was shutting down his Mastodon instance.
I'm paraphrasing here, but the gist was: "I set up my instance as a place with no rules, where anyone could come and be who they wanted to be, and say what they wanted to say. I was stunned and saddened at the abuse and horrific imagery I had to encounter when dealing with this instance, and so I am shutting it down before it gets me in real trouble."
There is a part of me, a small part, that is always reaching out to connect with other human beings. I don't think anyone could try so hard to start online communities and not have a portion of yearning in that direction. I feel for this man, who tried and experiment and had it go so wrong.
But mostly I look at what is possible when thoughtful care and attention is taken towards creating a deliberate community, and a spark goes off behind my eyes. I think of the world we're building at The Wandering Shop, and compare it to this person's dismissal of the whole concept, and that spark quickly becomes the heart of a forge.