Pittsburgh’s Code & Supply just held a huge (1500 people) conference over the last three days, and of course I’d signed up to attend months ago, because 1) local 2) affordable 3) tech conference 4) with a code of conduct they seemed serious about. Plus, “Abstractions” is a really cool name for a tech conference. The timing ended up being non-ideal for me in a couple of ways: I am really scrambling to get my fall class put together before the semester starts, and I have just had a final interview for a (really good, but) decidedly non-technical job, which I was (am) having all kinds of angst about. But Abstractions happened when Abstractions happened, so I went.
Apprenticeships also seem like a good way to solve this problem:
I definitely need to go to more local coding meetups—and make that a higher priority, in general. The Code & Supply organizers are nice, and they’re trying to be thoughtful about inclusion. I need to just decide “this contract work isn’t getting done tonight” and go. I already knew I liked the folks at Code for Pittsburgh, but, again: I need to put down what I’m doing and just go, even if I’m not sure what I have to contribute to a given week’s topic. I now know how easy it is to throw together a fast map. And, worst case: I take on something more challenging, but don’t get it done that night; so, I have to work on it for longer. No biggie.
I’m going to get my (senior dev) spouse to sit down and pair program with me on some as-yet-undetermined project. It will be good for him, since he’s hiring a more-junior developer to work with him; and it will be good for me, since I’ll have some mentorship at home.
I was introduced to the concept of “UX debt,” which is a useful way to think about something I had long ago intuited: bad interface decisions made for expediency and good interface decisions that aren’t periodically revisited will eventually become liabilities. I’ve lived that reality as both a user and a web librarian, so it’s nice to have terminology for it.
Open offices continue to be a really bad idea, for an ever-increasing number of reasons.
Have empathy – this is the most important skill for developers.
Be courageous – this is the second most important skill for developers. “I don’t know, so I will ask.” (A little hubris—”I’m definitely smart enough to solve this”—can also be OK.)
Nobody should ever give Richard Stallman a platform anymore. I’ve seen a lot of the same material shared by speakers with a more modern and inclusive take—and without patronizing their (tech- and information-literate) audiences, e.g. Kate Krauss from the Tor Project. I know the guy has star power within the tech community and probably lent a sense of legitimacy to the conference among a certain crowd, but he was incredibly off-putting to a large portion of the audience. … On the bright side, he did get us discussing. I made a lot of Twitter friends during that talk. So maybe as a mid-note, instead of an endnote, he could have been a real force for good.
A few pseudorandom notes I don’t want to lose
(Most of these I’m copying off of my Twitter stream for the conference—hence, doing this today—or from the few written notes I made.)
- Read Kathy Sierra’s Badass: Making Users Awesome.
- “Mature engineers lift the skills and expertise of those around them” – John Allspaw, CTO, Etsy
- 6 different flavors of style guide: Brand guide, Design language, Voice and tone, Writing, Pattern libraries, Code; Mailchimp has a good “voice and tone” guide, while The Economist has a good writing style guide
- Contempt Culture
- “Security is about protecting the user, not just their data.” – Emily Gorcenski
- Roughly 20% of people in tech probably have mental illness of some sort (higher percentage than the general population due to ageism).
- The eight fallacies of distributed computing
- Reminder to myself: I can read a tech book (or two) and build a conference talk out of it. People do that. It’s OK.
- As an organization, articulate your first principles. WHY do you do what you do?
- Conviction > confidence
- “There has to be an opportunity for failure. If you can prove you will succeed, you aren’t experimenting.” – Petro Salema
- “When someone fights hard for something that seems irrational, assume they know something you don’t.” -Azy Groth
- “We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten. Don’t let yourself be lulled into inaction.” – Bill Gates, Founder, Microsoft
- Think of your skills as being layered. You have skills in tools/technologies that are applicable within a certain paradigm or specialization, sure, but you also have “deep skills” that go with you always. (I need to think more about mine are, but at first blush, “problem solving” and “coordinating people” are two things that stick out.)
- Think about skill layers, as they apply to career changes, as architectural decisions (deep skills) vs. implementation details (other layers).
- Always cultivate a “beginner’s mind” – be open to possibilities, expect to learn new things. If you’re not learning, what’s the point?
- Make better dotfiles.
My understanding is that the videos of the talks will go online, on Code & Supply’s YouTube channel, sometime soon. If you, like me, are impatient, here are some slides that were shared:
- npm: past, present, and future
- Practical accommodations for mental health
- Building a culture of learning on your team
- Fringe Accessibility
- From Mobile First to Offline First
- A11y 411
Advice to the people who organize the next Abstractions
(This is in no way intended to diminish the amazing work that the organizers this year did — they should be proud of the conference they put on!)
- Mark the travel lanes, so that people can get through, especially people with mobility issues.
- Have a quiet room, with (ideally comfortable) seating, where people can go hide if they’re overstimulated.
- Make the therapy dogs go into a room, or separate them from the rest of the conference in some other way. They were out in the thoroughfare, completely unavoidable, and I had an asthma attack.
- Spread chairs around in public areas (or drag benches over from that hallway). People with foot injuries can’t stand the whole time between sessions and shouldn’t be forced to walk away from everyone just to sit down.
- This one might not be possible for a conference this size, but if you can space out session seating so there are tables available, it would make taking notes and working along with the presenters a lot less awkward.
- Just a thought: instead of the “hallway track” (literally standing in a hallway and requiring us to be brave enough to approach speakers, which I am demonstrably not :)), maybe have something just a tiny bit more like an unconference area. Have a table in Distractions, or somewhere, where people can sign up on a whiteboard (and announce on Twitter) that they’re going to discuss X Topic at Y Time. Because the little impromptu roundtable with Erika and others, about mentoring new devs? That was the highlight of my conference. And it was literally just some people showing up at a table, because Erika said something about it on Twitter.
Some things that were especially great
This was not a conference full of straight white cisgender male speakers. I mean, of course, there were some (which is fine), but the speaker lineup was well above par, in terms of diversity. (I’d love to see stats on attendance, but I don’t remember that information being gathered.)
There was also good diversity of subjects—a nice mix of UX/accessibility, culture/mentoring/inclusion, and “latest JS library”/”stealth functional programming plug.” 😉
There were indications that the code of conduct was actually being enforced. This is great!
There was live captioning for talks in the big rooms, and that is fantastic!
The schedule was presented in multiple different formats, including a calendar that could be downloaded onto devices. I had all the sessions in my iPhone, and that was awesome!
All the speakers had microphones. On their faces. So they couldn’t walk away from them! This made talks so much more accessible.
The organizers (and volunteers?) were really easy to find with their red shirts. That was reassuring, in a quiet way. (It would have been reassuring in a more immediate way if I’d needed their help for something!)
So, to sum up
It was a great conference, with a lot of thought put into it, and I’m so glad I went! I am reinvigorated in my quest to get into tech, and I even have some ideas about how to prepare myself.